I got tired of paying to emulate a 1970s terminal, so I built a native macOS client in C++ (DX3270)

El Dockerr — Thu, 28 May 2026 13:39:17 +0000

If you work with IBM Mainframes (z/OS, z/VM) on a Mac, you’ve probably noticed a glaring issue: every halfway-decent TN3270 terminal client costs money. Sometimes a lot of money.

We’re talking $50–$100+ for software that essentially emulates a 1970s text terminal. One popular commercial option even charges a recurring subscription just to let you type on a green screen. That felt absurd to me.

The free alternatives out there usually fall into three categories:

They require Java (slow, resource-heavy, and clunky on macOS).
They run inside X11 (no thanks).
They are abandonware that breaks on every macOS release.

So, I decided to build my own from scratch.

Introducing DX3270

After a weekend of intense frustration and diving deep into ancient IBM GA23-0059 architecture manuals, I released DX3270 (hosted under the X3270 repo).

It is a completely free, MIT-licensed, native macOS TN3270/TN3270E terminal emulator.

Check out the repository here: GitHub

I wanted something that actually feels like it belongs on a Mac. No Java, no X11, just native performance.

How I Built It

I wrote DX3270 entirely in C++ and Objective-C++. By building it on top of native macOS frameworks, it achieves a completely different level of performance and system integration compared to cross-platform electron/Java wrappers.

Rendering: I used Apple's CoreText for calculating glyph metrics to ensure a pixel-perfect character grid.
Security: Native OpenSSL integration for implicit TLS (TLS 1.2+) on any port.
Protocol: Full TN3270E (RFC 2355) negotiation.

One of the hardest (and most interesting) parts was implementing the IBM Structured Field Read Partition Query. Without this Query Reply, mainframe menus like ISPF simply won't render correctly. Getting the exact hex codes right (like fixing the PF10-12 AID codes based on strict IBM standards) was a huge learning curve.

Key Features

I recently updated the app to support dynamic screen buffers and multiple models. Here is a quick breakdown of what DX3270 can do:

Multi-Model Support Model 2 (24×80), Model 3, 4, 5, and a custom Large model (62×160) using 14-bit buffer addressing.
Authentic Font Bundled with the incredible open-source IBM 3270 font by Ricardo Bánffy.
Native UI Green-on-black phosphor, authentic 600 ms cursor blink, and a block cursor.
Traffic Monitor Built-in floating hex dump monitor (⌘⇧D) to debug raw Telnet/TN3270 bytes in real-time.
Export Tools Pixel-perfect PNG screenshots (⌘⇧P) and EBCDIC-to-UTF-8 formatted text exports (⌘⇧T).

Try it out!
If you work in Mainframe, use a Mac (Apple Silicon or Intel), and are tired of paying for the privilege of connecting to your own environments, DX3270 is for you.

I actually built this tool just for my own sanity, but after it got some unexpected traction on LinkedIn, I realized a lot of other developers share this exact pain point.

I’ve set up GitHub Actions to automatically publish pre-built .dmg files for both Apple Silicon and Intel architectures on every release. You can download the latest version directly from the Releases page.

I would absolutely love to hear your feedback, bug reports, or feature ideas. Feel free to open an issue or drop a comment below!

Happy connecting!

I hacked a CMAKE replacement, and maybe it's for you

El Dockerr — Wed, 22 Oct 2025 07:55:35 +0000

Let’s be honest: CMake can feel like trying to read hieroglyphs while blindfolded.
Half the time it’s fighting you, the other half it’s pretending to help. And I use Linux at home and Microsoft at work. Bringing this together as a C++ developer is very painful.

So... I built something else.
Meet Bodge — The Idiotic Build System.

🧠 What Is “Bodge”?

bodge [/bɒdʒ/ verb] — make or repair (something) badly or clumsily.

Yeah. The name is self-aware.

I was frustrated by fiddling around with CMAKE on windows, and Visual Studio is absolutely painful and I was wondering why nobody tackled this issue.
So, as I learned in my puberty as a nerd, when nobody is willing to do, do it yourself, it started as a weekend experiment to see if I could make something that just builds C++ projects without ceremony — and before I knew it, I’d bodged together a fully functional cross-platform build system. Okay - to be honest I was wondering how easy it can be to have something in place that matches MAVEN or Cargo for C++. (See: https://github.com/el-dockerr/bodge)
And it was perfect for my work as well, so I spread the work in my Company, and in no time we had something useful that shrink the toolchain and dependencies. Just a G++ compiler and Bodge in place.
Without working around on CMAKE to get it run on Windows.
Same on Linux - just G++ and Bodge with a nice sleek .bodge file. No make no cmake, no wrong encoding, and no wrong formatting.

It’s minimal.
It’s hacky.
It’s surprisingly powerful.
And it might actually replace CMake one day (if I’m crazy enough to keep going).

🧩 Why Bodge Exists

If you’ve ever wrestled with CMake or other meta-build tools, you know the pain:

Layers of cryptic commands,

endless dependency hell,

and the creeping feeling that your build files are writing themselves.

Bodge aims to fix that by being simple, declarative, and self-contained — like Cargo for Rust or Maven for Java, but for good old C++.

All you do is define what you want to build, what compiler to use, and what libraries you depend on.
That’s it.
No ceremony. No black magic.

Here’s the best part: Bodge can even fetch your dependencies directly from Git repos, build them, and chain everything together automatically.

⚙️ The Philosophy

I wanted to design a build system that:

Uses a single human-readable config file (.bodge)

Works identically on Windows, Linux, and macOS

Lets you define dependencies, build sequences, and targets without tears

Doesn’t require external generators or a PhD in scripting

The dream?
A single executable that builds your C++ project — clean, predictable, and portable.

🧱 A Minimal Example

Here’s a dead simple .bodge file:

name: MyProject
compiler: g++
output_name: my_app
cxx_flags: -std=c++17, -Wall, -O2
sources: src/**
include_dirs: include
libraries: pthread, m

That’s all it takes.
Run bodge and you’ve got your binary. 🎉

Want to build for Windows or Linux specifically?

bodge --platform=windows_x64

Or check what platforms are available:

bodge platform

It’s that easy.

💡 Key Features

Bodge already does a lot — and I keep adding new stuff as I go. Some highlights:

🧩 Multi-Target Support

Build executables, shared libs, and static libs — all from one config.

⚙️ Automatic Source Collection

Just point to a folder (src/**), and Bodge gathers all .cpp files recursively.

🚀 Daemon Mode

Yes, it can watch your source tree and rebuild automatically when you save.
Perfect for active development and CI setups.

🪄 Build Sequences

Create workflows like “build → package → deploy” directly in your .bodge file:

sequence.deploy: build:main mkdir:dist copy:my_app.exe->dist/my_app.exe

🌍 Cross-Platform by Design

Supports Windows, Linux, Unix, macOS, ARM, and x86/x64 — automatically detecting your system and applying platform-specific flags.

🔗 Git Dependency Fetching

Need a 3rd-party library? Just list its repo in .bodge, and it’ll pull and include it automatically.
No more “clone this, copy that, run this script” nonsense.

🧰 Example: Multi-Target Project

Here’s a more advanced setup to give you an idea of Bodge’s structure:

name: MultiTarget
compiler: g++
global_cxx_flags: -std=c++17, -Wall, -static-libgcc, -static-libstdc++
global_include_dirs: include
# Shared library
libcore.type: shared
libcore.output_name: core
libcore.sources: src/lib/**
# Executable that depends on it
app.type: exe
app.output_name: my_app
app.sources: src/**
app.libraries: core
# Build all
sequence.build_all: build:libcore build:app

You can build everything or just one target:

bodge build app

Or run a whole workflow sequence:

bodge sequence build_all

🔁 It Builds Itself

Yep.
You can build Bodge using Bodge.
That was my personal “it’s alive!” moment.
Just run:

bodge --platform=windows_x86

Or, if you’re feeling nostalgic:

make all

💾 Download

You can grab precompiled binaries for Windows, Linux, and macOS from the GitHub Releases
.
Or clone the repo and build from source (it’s super straightforward).

❤️ Why You Might Love It

Bodge is not trying to be smarter than you — it’s trying to get out of your way.
You tell it what you want, it builds it, and it doesn’t argue.

If you’re tired of CMake boilerplate or opaque “meta scripts,” Bodge might just be the breath of fresh air you’ve been waiting for.

🧑‍💻 Contribute or Follow Along

This is still an early-stage project, but it’s already working nicely for small and medium C++ projects.
If you’re curious, or if you’ve cursed at CMake recently (we all have), check it out: https://github.com/el-dockerr/bodge

👉 GitHub: Bodge – The Idiotic Build System

Give it a ⭐ if you like where it’s going — it really helps me stay motivated to push the next features.

☕️ Final Thoughts

I didn’t set out to reinvent the wheel — I just wanted one that didn’t squeak.
If you’ve ever thought “CMake is overkill for my project,” give Bodge a try.
It’s small, self-contained, and fun to use — just the way C++ building should be.

Let’s make C++ building less painful, one bodge at a time.

DEV Community: El Dockerr