null program

What's been going on in w64devkit the past year

2026-09-20T01:49:36Z

The past year has been exciting for w64devkit, which like any software distribution is never complete. Peter0x44 joined as co-maintainer, and has pushed the project in good, new directions, with ideas I would never have considered. Many of his improvements have gone back upstream, and so you may benefit even if you don’t use w64devkit. I’d like to touch on the various odds and ends from the past year.

Release security

In April I announced that release packaging is now signed. Today all EXEs and DLLS in w64devkit are code-signed with my key. My signing key established a good reputation thanks to thousands of unique signatures observed on the order of ~100,000 hosts — a pleasant side effect from including ~300 binaries in a release. Users should have fewer problems these days with security software. MSYS2 has also adopted my signing tool, aas-sign, which is now included in w64devkit releases.

Builds are now automated by GitHub Actions, triggered when I (and only I) push a new tag. That process code-signs and creates the release. Every step of the release process is transparent, derived strictly from source in the repository. Nowhere does it go behind a curtain and permit secret tampering.

But that’s not all. I enabled release immutability: On publish, release artifacts are locked in and nobody, not even me, can modify them. You can tell by the presence of a release attestation at the end of the artifacts listing. Nobody involved in the project down the road can go rogue and sneak something into an old release.

Toolchain changes

The x64 release is now a “multilib” toolchain. That is it can compile programs for 32-bit Windows, like a superset of the x86 release. The only purpose of the x86 release is to run w64devkit on older hardware or older operating systems. Like the x86 release, it targets Windows XP by default and requires a CPU supporting SSE2 (i.e. at least Pentium 4).

To target x86, pass -m32 when compiling and linking. Or better, use tools prefixed with the i686-w64-mingw32 architecture triple. The latter is easier in general because different tools require different switches, and the prefixed tools are aliases that automatically do the right thing.

$ x86_64-w64-mingw32-gcc -o hello64.exe hello.c
$ i686-w64-mingw32-gcc -o hello32.exe hello.c

Adding multilib was cheaper and easier than I anticipated, and it’s thanks to Peter0x44. It’s already been convenient for me for several projects.

In the past you needed w64devkit’s bin/ on your $PATH in order to use the compiler, because that’s how GCC found the other tools it needs. This is no longer the case, and you can invoke path/to/gcc.exe from scripts and such without touching your path. This required a small GCC patch.

The standard COFF object format supports up to 65,535 sections. When the format was designed this probably seemed like more than enough, but modern C++ programs can easily exceed it, particularly debug builds of programs using lots of lambda functions. As C++ projects grow they eventually hit a threshold where builds fail unless you ask for the bigobj COFF format, which supports over 4 billion sections. This is annoying, and the tools ought to deal with this automatically.

A couple years ago I patched Bintutils to produce bigobj by default so the old limit would never affect a build. The catch is that Binutils lacks an interface to request standard COFF, so you can’t downgrade if needed. Why would you need to? When interacting some simpler linkers like the official Go toolchain (gc)! Some linkers can’t consume bigobj. It also breaks some builds that auto-detect the toolchain’s object format, as some detection scripts don’t know about bigobj (ex. libbacktrace at the time).

Ideally Binutils would quietly upgrade to bigobj as needed. Only large programs see bigobj. Naive linkers and detection scripts only deal with standard COFF. Well, thanks to Peter0x44 that’s now what Bintutils does upstream! My bigobj hack is no longer necessary, and cgo works again.

This past year I’ve decided to put less emphasis on making w64devkit as small as possible, and I’m willing to increase the installation and distribution size for worthwhile features. This is embodied by switching from -Os to -O2 for static runtimes and tools that are computationally expensive. Everything is now a bit bigger and a bit faster. Programs that spend significant time in the standard library will be a little faster, too. Programs already designed for performance will see no difference.

New tools

CMake, Ninja, and a new, graphical CMake debugger are all now included. They require at least Windows 7. I’ve patched CMake to default to Ninja, as CMake’s default is to look for a Visual Studio installation. You can still -G MinGW Makefiles for GNU Make instead of Ninja, but I don’t recommend it. Ninja is faster and more robust.

$ cmake -B build       # configure for Ninja
$ cmake --build build  # build with Ninja

ccmake is included (a Peter0x44 suggestion), a TUI front-end to examine and modify CMake configurations. It’s been useful, more than I expected. You can pass -j for parallel builds, but I strongly recommend using the environment instead, e.g. in your .profile:

export CMAKE_BUILD_PARALLEL_LEVEL="$(nproc)"
export CTEST_PARALLEL_LEVEL=$(nproc)

Yes, parallel testing, too! I also recommend multi-config if that makes sense for you:

$ cmake -B build -G 'Ninja Multi-Config'
$ cmake --build build --config Debug
$ cmake --build build --config Release

I was tempted to make this default, but it changes the build tree layout (Debug/ and Release/ directories) and a shocking percentage of real world CMakeLists.txt break under multi-config because they’re written incorrectly. The world needs a good CMake linter, which could catch most cases statically.

Complementing is Ccache, with special patches from Peter0x44 to improve Windows support. If you switch between branches often then using ccache will speed up your (re-)builds. I also set up the conventional Ccache lib/ccache/ directory. It’s a directory in w64devkit that when added your $PATH transparently backs all your builds with Ccache. On a typical Linux distribution this would be /usr/lib/ccache/. You can enabled it in your w64devkit.ini using path type, too:

path type = minimal+ccache

In my case Ccache hasn’t been useful as I hoped when I added it. I’ve adopted Git worktrees workflow instead, so each branch sits still with its own build tree(s).

To aid COM programming, the kit now includes widl and uuidgen, the open source alternative to Microsoft MIDL, for generating Interface Definition Language (IDL) files. uuidgen is a minimalist rewrite by yours truly of the Microsoft tool.

G. Berthiaume wrote a new tool, make2compdb, that extracts JSON Compilation Database files, compile_commands.json, from Make builds. It operates as a unix filter:

$ make -Bwn | make2compdb >compile_commands.json

I wrote a recycle tool that sends files and folders to the recycle bin, which for the latter is usually faster than deleting them with rm -rf. The trash tool on other systems. I rarely delete files anymore, instead using this command to send them off to sit in the recycle bin for a couple weeks until Storage Sense automatically deletes them.

A few months ago I announced the addition of quilt, an old school patch management tool. The original doesn’t support Windows, so this is a full rewrite in C++. Now that every platform has Quilt, w64devkit’s patches are now managed with Quilt.

NSIS, an installer creator, is now included, so you can build your own application installers. Just the command line tool, makensis. It’s also in a “multilib” configuration, and x64 w64devkit can produce 32-bit and 64-bit installers. (My motivation to add NSIS was my alternative alt-tab switcher, which requires an installer to install properly.)

Zstandard zstd/unzstd is now included because source tarballs are often in .tar.zst format. It’s a great compression format, and ought to be your default (rather than gzip) when you need compression. busybox-w32 tar knows to use zstd for .tar.zst.

Runtimes

Unique to w64devkit, C11 threads are now part of the Mingw-w64 runtime. A new implementation by yours truly, independent of winpthreads, smaller than winpthreads, and requires no special compiler or linker flags. (If you’re careful, you can even use it in CRT-free programs.) The catch is that it requires Windows 7 or later because I built it on SRW locks; XP would have required substantial complexity.

Writing an implementation taught me that C11 threads are underspecified poorly designed — in case it wasn’t already obvious by the presence of recursive locks! This C standard addition did not get nearly the attention is needed and should have been cut (par for the course). My implementation excludes recursive locks. Trying to create one always fails. It also has a weakened thrd_current because the semantics don’t map onto the Windows threading model.

std::terminate actually terminates (traps) instead of calling exit, so it traps in GDB for inspection. This includes uncaught exceptions. It also no longer prints a half-baked stack trace, shedding ~100k of dead weight from most C++ programs. I did this in two steps a year apart, the second just recently. I misplaced the trap in the first change, preventing it from shedding as much weight as it could.

Future directions

Years ago I disabled Link-Time Optimization (LTO) due to bugs in GCC and Binutils. Just having it available in the toolchain triggered LTO bugs. These problems reduced my faith that LTO could produce correct programs, so I disabled it.

However, I’m toying with the idea of not only re-enabling LTO, but even distributing “FatLTO” runtimes, particularly for C++ and Fortran. That is, runtime object files will contain both native code (at -O2 per above) and LTO bytecode. If you don’t request LTO, you get the pre-compiled native code just like today, at no link-time cost. If you enable LTO, it essentially rebuilds the runtime itself at link time. Very computationally expensive, but you get full control, and you can even coerce it back to the old -Os (or even -Oz) if you prefer that.

As far as I can tell, nobody actually distributes a toolchain with FatLTO runtimes, so w64devkit might be the first. I know I’m the first to cross compile FatLTO objects with GCC — remember that everything in w64devkit is cross-compiled — because it’s never worked correctly in a GCC release. My first attempt produced a toolchain that didn’t work.

I’m feeling more confident this time around because fixing LTO bugs is now very easy: Strap a frontier AI into a good coding harness, show it what’s broken, give it all the sources (source.tar), and ~15 minutes later I have a patch. We live in a sci-fi world. I started by fixing known-to-me LTO bugs, enabled FatLTO, then worked through newly-discovered LTO bugs. I’ve been dogfooding it, and nothing new has popped up in awhile, but it will take some time for me to feel confident. I’m less confident in my ability to discover Fortran runtime bugs. Upstream GCC rejects these fixes out of hand, so through no choice of my own w64devkit will have a unique edge in this space.

While some of the new features require at least Windows 7, I’m still committed to supporting Windows XP as a baseline for the x86 release. I keep an old XP laptop on hand, on which I test and enjoy w64devkit. You just have to make do with some older tools, but that’s what you were already doing anyway.

A custom virtual machine for the Stars! 4X game

2026-09-17T02:00:00Z

Stars! is a 1995 4X game (explore, expand, exploit, exterminate) for 16-bit Windows 3.1 that I first played ~28 years ago. While Windows is famously backwards compatible, it’s notoriously difficult to play Stars! today. Windows x64 cannot run 16-bit applications, and playing requires either retro hardware or emulation (otvdm, DOSBox), sometimes paired with Wine. My new, exciting solution, Stars!VM, or Stars! Virtual Machine, embeds a custom 80286 emulator and a Win16 to Win32 bridge. As native Win32, the game looks and feels exactly as it did originally, except sporting a modern file chooser and 4k scaling. It’s indistinguishable from a genuine 32-bit or 64-bit port of the game, especially with the original 16-bit game embedded inside the VM executable.

The signed releases on GitHub embed a compressed copy of the original 16-bit game, so that single EXE is ready to play out-of-the-box with no further setup or downloads. I’m distributing 32-bit builds (but requires SSE2) because there’s no advantage to 64-bit here, and these builds work (almost) everywhere except 16-bit Windows. 32-bit Windows could run the original 16-bit game, but the VM-encapsulated version is better behaved. It doesn’t dump a Stars.ini under C:\WINDOWS, it interacts properly with the task bar, and copy protection is neutralized via the OS bridge.

If you ever been curious about Stars!, now’s the time to try it. The game has a thorough, built-in tutorial, but also check out the manual, wiki, strategy guide, and AutoHost (play-by-email service). The game predates the modern search engine concept, otherwise they might have chosen a better name. I suggest using “stars 4x” in your searches.

If you want to build from source and hack on the VM yourself, the best tool for the job is w64devkit, of course, because it comes with everything you’ll need. Plus the game itself: stars.exe from stars27jrc3.zip.

Implementation details

The emulator itself requires x86 or x86-64 because it does not implement x87 (80-bit floating point) in software, but instead runs these operation directly on the host’s x87 hardware. This is simple, fast, and precise. The project validates the emulation as a whole with a differential fuzzer against the host. The fuzzer randomly generates a 16-bit instruction, emulates it, then runs it with JIT on the host and compares the results.

Handles on Windows are pointer-sized, and so the Win16-to-Win32 bridge maps 16-bit handles to host handles. It marshals between different struct layouts when translating these calls, services the DOS interrupts the game requires, an copies data in and out of guest memory. It’s rather like running a Wasm instance, which of course makes sense in retrospect.

The Win32 bridge is also monitorable and manipulatable using the Model Context Protocol (MCP). AI agents can “see” the UI “DOM” as it’s built, and can drive it by injecting synthetic events into the event pump, all without going through the usual desktop control. The MCP can also read and write guest memory. Opus 5 played a complete game through MCP — which is quite fun to watch — requesting my assistance at just two points when it got stuck in the UI. A foundation for a new Stars!Bench?

Targeting old 16-bit computers, the authors couldn’t afford to build a sloppy, wasteful UI, and so by modern standards the game UI is remarkably fast and responsive. They don’t make ‘em like they used to. Computing the next turn, or “turn generation,” is the computational bottleneck, and so that’s where I focused my optimization efforts. The emulator can trace executed instructions, so I gathered traces of turn generation, then had Fable 5.1 identify and reverse engineer the hottest common routines (e.g. the game’s L’Ecuyer MCG PRNG) and basic blocks. Each was re-written in C and mapped into the instruction decoder as new 80286 instructions. On load the emulator identifies these routines and patches them with the new instruction. This resulted in a nearly ~2x speedup of turn generation. By exploiting local conditions, emulating a particular known program, I get JIT performance without JIT complexity.

The original game doesn’t use buffered I/O, and instead issues many small reads and writes. Passing these small reads/writes straight to Win32 made I/O take ~5% turn generation time, probably worse today than it was back then. Plus it’s just rude. The emulator buffers the game’s I/O calls, further speeding up turn generation.

The game has some sound effects in the “battle VCR” and the final version of the game shipped with Microsoft’s WaveMix.dll. Rather than load and link this DLL, the emulator implements the DLL’s interfaces natively, and these routines are dynamically linked into the 16-bit process. You will not need this DLL with the emulator, nor is it embedded in releases.

The game also has art assets embedded uncompressed in the original EXE, forming the bulk of its ~3MB. Stars!VM uses a custom LZ-based compression algorithm tailored to compressing the original game. It’s compressed when embedded in releases. So the 32-bit version of the game is half the size of the original, at ~1.5MB.

The original game requires a serial code, serving as its copy protection. A code is 8 alpha-numeric characters that must pass two checks. Failing the first is loud, but failing the second will sabotage your game with penalties. You’ll know because it will announce that your people suspect you are a usurper. Most codes you’ll find online are such “usurper” codes. Play-by-email (PBEM) saves embed a hardware signature derived from C and D drive configuration. People playing on different machines using the same serial code recieve the usurper penalty.

I bought a serial code back in the day, but it hasn’t been possible to purchase one a for at least decade now. So the emulator injects a fixed serial code on first run (disable with --prompt-serial), and you won’t need to worry about it. The VM also produces a fixed hardware signature (same as any other emulator), so it looks like everyone running Stars!VM is sharing the a machine, meaning no penalty for key reuse. I cracked the serial code checks anyway, allowing me discover interesting ones. My favorites: CLONEMUM, CROSSNUT, EGGSWAIN, GHOSTKIN, GONKSHOW, GRIPMIME, SEEKCAPS, SIFTBOLD, SIRBUOYS, SLIMFAZE, SLOTMOPS, SPAWNELK, SUNBLOND, WANTNEAR, and WRONGPOX. These look like some of my passwords.

Endless possibilities

I’m quite pleased and excited with the results, especially for a weekend project. It’s breathed life back into the game for me, not only having a better experience running it, but also that I can trivially bend the game to my will in the ways I dreamed about. A few hooks in the right places should open the game to easy modding, but I’m more engineer than modder.

Concurrent, atomic MSI hash tables

2026-05-06T02:01:17Z

Readers will be familiar with Mask-Step-Index (MSI) hash tables, a technique for building fast, open-addressed hash tables in a dozen lines of code. If multiple threads or processes access an MSI table with at least one still inserting elements, care must be taken to avoid data races. This article will show how to add atomic operations to MSI tables in order to support different concurrency constraints.

Let’s begin with the simplest case: An integer hash set, no deletions, only one insert thread (single producer), and consumers do not care about insert order. That is, the producer inserts A then B, but consumers may observe B in the table before A. Suppose this is the hash table in the single-threaded case:

int32_t *lookup(int32_t key, int32_t *table, int exp)
{
    uint64_t hash = ((uint64_t)key * 1111111111111111111u) >> 32;
    uint32_t mask = ((uint32_t)1 << exp) - 1;
    uint32_t step = (hash >> (32 - exp)) | 1;
    for (uint32_t index = hash;;) {
        index = (index + step) & mask;
        if (!table[index] || table[index]==key) {
            return table + index;
        }
    }
}

Keys must be non-zero, and tables are zero-initialized. Usage example:

    // Initialization
    enum { exp = 8 };
    int32_t table[1<<8] = {};

    // Producer
    for (int i = 0; i < nkeys; i++) {
        *lookup(keys[i], table, exp) = keys[i];
    }

    // Consumer
    int32_t key = 1234;
    bool present = *lookup(key, table, exp);

The only problem is the data race on table slots. Since consumers can tolerate out-of-order insertions, ordering does not matter and relaxed atomics eliminate the data race. Insert and query now have different requirements, so it makes sense to distinguish them. Starting with the latter:

bool contains(int32_t key, int32_t *table, int exp)
{
    uint64_t hash = ((uint64_t)key * 1111111111111111111u) >> 32;
    uint32_t mask = ((uint32_t)1 << exp) - 1;
    uint32_t step = (hash >> (32 - exp)) | 1;
    for (uint32_t index = hash;;) {
        index = (index + step) & mask;
        int32_t k = __atomic_load_n(table+index, __ATOMIC_RELAXED);
        if (!k) {
            return false;
        } else if (k == key) {
            return true;
        }
    }
}

Note how all elements are accessed by atomic loads, as a producer may store to any slot at any time. Now producers:

bool insert(int32_t key, int32_t *table, int exp)
{
    uint64_t hash = ((uint64_t)key * 1111111111111111111u) >> 32;
    uint32_t mask = ((uint32_t)1 << exp) - 1;
    uint32_t step = (hash >> (32 - exp)) | 1;
    for (uint32_t index = hash;;) {
        index = (index + step) & mask;
        if (!table[index]) {
            __atomic_store_n(table+index, key, __ATOMIC_RELAXED);
            return true;
        } else if (table[index] == key) {
            return false;
        }
    }
}

This function may load elements non-atomically because there’s only one producer: the current thread. This idea could not be expressed were the type system involved, e.g. _Atomic, but GCC atomics do not involve require such special qualifiers. Stores on the other hand are concurrent with consumers, requiring an atomic store. Single-producer, multiple-consumer (SPMC) usage is nearly identical to the single-threaded case:

    // Producer
    for (int i = 0; i < nkeys; i++) {
        insert(keys[i], table, exp);
    }

    // Consumer
    int32_t key = 1234;
    bool present = contains(key, table, exp);

A concurrent integer hash table is contrived and unrealistic. In a real program a key likely carries some broader semantic meaning. For example, if that “integer” is actually a memory offset known as a pointer, then it points at some object, and it is important that stores to that object happen before consumers observe the pointer in the table:

bool   insert(Thing *thing, Thing **table, int exp)
Thing *lookup(Key key, Thing **table, int exp)

Where usage might look like:

    // Producer
    for (int i = 0; i < nthings; i++) {
        things[i].key = ...;  // update/init object
        insert(things+i, table, exp);
    }

    // Consumer
    bool present = !!find((Key){...}, table, exp);

In this case relaxed atomics are insufficient. Updates to the inserted object may be reordered after the insertion, and consumers will race on those updates. In this case we upgrade to acquire-release:

Thing *lookup(Key key, Thing **table, int exp)
{
    // ...
    for (...) {
        // ...
        Thing *thing = __atomic_load_n(table+index, __ATOMIC_ACQUIRE);
        if (!thing || thing->key==key) {
            return thing;
        }
    }
}

bool insert(Thing *thing, Thing **table, int exp)
{
    // ...
    for (...) {
        // ...
        if (!table[index]) {
            __atomic_store_n(table+index, thing, __ATOMIC_RELEASE);
            return true;
        } else if (table[index]->key == thing->key) {
            return false;
        }
    }
}

In this case producer and consumer synchronize on the atomics. Producer stores are ordered before the release, and consumer loads are ordered after the acquire. Objects are not modified once in the table, so atomics are not required for their fields. On some architectures, including x86, there will be no indication at the ISA level that atomics are in use — i.e. this likely generates the same code as the single-threaded version — and these atomics merely constrain the compiler’s instruction scheduling.

As a side effect of synchronizing, consumers will now observe insertions in the same order as the producer. This is a more realistic and practical situation than an integer hash table.

Multiple producers

The multiple-producer case (MPMC) is more complicated for producers, but consumers are unaffected, so we need only modify insertion. Still without any locks, we will optimistically update the table. We look at the current slot item, and if nothing is present compare-and-swap the new element in place. On failure we acquire the element that won the race, continuing as though it’s what we saw in the first place.

bool insert(Thing *thing, Thing **table, int exp)
{
    // ...
    for (...) {
        // ...
        Thing *current = __atomic_load_n(table+index, __ATOMIC_ACQUIRE);
        if (!current) {
            int pass = __ATOMIC_RELEASE;
            int fail = __ATOMIC_ACQUIRE;
            if (__atomic_compare_exchange_n(
                    table+index, &current, thing, 0, pass, fail)) {
                return true;
            }
        }
        if (current->key == thing->key) {
            return false;
        }
    }
}

This is quite similar my hash trie concurrency enhancement a few years ago.

I have officially retired from Emacs

2026-04-26T00:00:00Z

This article was discussed on reddit and on Hacker News.

This past Tuesday I typed C-x C-c in Emacs for the last time after 20 years of daily use. Though nearly half that time was gradually retiring it, switching to modal editing, then to Vim. Emacs is a platform, and I’d grown accustomed to its applications, especially those I built myself. There was no particular hurry, so replacements came slowly. With my newly-acquired superpowers I could knock out the last two pieces in a few days’ work, namely M-x calc with stackcalc and Elfeed with Elfeed2. I’m especially excited about the latter because it already exceeds the original. Both are multi-platform, native C++ GUI applications using native UI components.

These actively-in-use packages require new maintainers (apply on the project’s issues/discussion):

No wonder it took so long for me to move on! I’m not handing these off to just anyone, and you’ll need to establish your reputation. Having already made contributions is a good sign, even if never merged. I’m willing to transfer them off my namespace, though you’ll need to manage the Melpa hand-off (on which I’ll sign-off). If there are no takers, these projects will be archived but not deleted.

Trying out wxWidgets

The Emacs Calculator is amazing and the best calculator I’ve ever used, which is why nothing I could find was going to replace it. My clone uses GMP and MPFR for multi-precision, so it’s far faster, as to be expected, but it’s not nearly at feature parity. It’s missing esoteric features including symbolic processing. Though it’s enough to cover all of my own usage. I can add more features later. The Emacs Calculator manual served as a specification when building stackcalc.

Elfeed has been a cornerstone of my daily routines for the past 13 years. Nothing else I’ve found scratches that itch for me, so I’ve always known it would require a rewrite someday. Knowing it would take a few weeks of work, and that I already had the feed reader I wanted, made motivation difficult to find. Though now that I can accomplish ~3 weeks of old-way work in a new-way day, this sort of project becomes that much easier to start and finish. Though it’s not yet at a 1.0 release, after a couple days Elfeed2 was working well enough to replace the original Elfeed.

While Dear ImGui was the right choice for dcmake, it would not be so for these two applications. Active rendering doesn’t suit a feed reader left running all day, and I needed a richer toolkit. Professionally I work in Qt, but I wanted something lighter-weight for my projects, accessible via CMake FetchContent. That naturally led to wxWidgets. While it has issues — mitigatable character encoding problems, accidental quadratic time in many places — it’s worked better than I anticipated, letting me rapidly produce native-looking applications on Windows, macOS, and Linux.

Unlike Dear ImGui, wxWidgets is a platform, including sane I/O and path handling. I mostly don’t need platform layers when building applications like these. I can simply rely on wxWidgets’ utilities.

Both of these projects build out-of-the-box on w64devkit thanks to the dependencies being FetchContent-compatible. On all platforms you just need a C++ toolchain and CMake:

$ cmake -B build
$ cmake --build build

Now that I have experience with wxWidgets, learning its limitations and capabilities, it’s likely to be a foundation of most of my GUI projects to come, except where something like Dear ImGui is a better git.

My brave new code-signing world

2026-04-25T18:12:29Z

The new w64devkit release two weeks ago is the first to be code-signed with my identity, verified by Microsoft’s certificate chain. Currently only the release packaging is signed — the self-extracting archive and its payload — but I will soon code-sign individual EXEs and DLLs within the distribution. In fact, all Windows builds of my project releases have been code-signed the past two weeks, including dcmake, and so should everything going forward. My signing identity builds reputation with each download, so users will have an easier time with SmartScreen, and security software generally. Azure Artifact Signing creates the actual signature, but the rest is done with new infrastructure I built myself, aas-sign. As is often the case, the existing options were deficient for my needs, so I had to build it myself.

This code-signing is not free, and simply having aas-sign on hand, or using the GitHub Actions action, is insufficient. You must be serious enough to spend US$10/month for the Azure subscription. After that you are subjected to the labyrinth that is the Azure portal, the most confusing UI I’ve ever used. Luckily we live in an age of wonders, and I could describe to Claude in Chrome what I wanted and it would happen (Sonnet works better than Opus for this). It took as much time to figure out Azure as I spent creating a fully-functional, native debugger front-end. Clear your schedule if you’re going to try it yourself. If it weren’t for AI assistance I would have given up.

The one-time setup process is only open to North America, and involves sharing identify documents (i.e. driver’s license) with Microsoft. Unlike the rest of Azure, that part was streamlined and fairly painless. Between the cost and this requirement, this is a niche space.

However, if this is your niche, aas-sign is currently the best software available. It’s the tool Microsoft should have written, but didn’t due to ongoing institutional failures. The alternatives are a pair of tools: Azure CLI (Python) combined with either Jsign (Java) or SignTool.exe (Windows only). All impose artificial runtime constraints hostile to build pipeline composablility. Poor engineering. In contrast, aas-sign is a native, multi-platform, single-file application.

If you know this space, osslsigncode probably comes to mind, but it produces signatures itself. It doesn’t interface with Azure and so has no role here aside from semi-reliable validation. The most popular use case is code-signing with self-signed certificates, but that actually makes everything worse.

There are two modes for aas-sign: Laptop and Action. Laptop mode is the most compelling, so we’ll start with that, but Action mode is the most useful in practice.

Laptop/desktop mode

Suppose you built an EXE or DLL, and would like to code-sign and publish it. Typically that looks like this:

$ aas-sign sign myapp.exe myapp.dll

It computes an Authenticode for each (concurrently), sends it off to Azure, gets back a signature, then a countersignature, and embeds the signatures in the images. If you have multiple signing identities then you might use --as (“sign as”):

$ aas-sign sign --as eus:contoso:jdoe myapp.exe myapp.dll

The colon-delimited triple is my own invention to combine region (East US), tenant (Contoso), and profile (J. Doe) into one string. The first time you use it, and every ~90 days thereafter, you’ll need to authenticate with Azure first:

$ aas-sign login

This will open a browser (just like az login) to log in, from which it will obtain a token than can be used to obtain signing tokens. (Yes, a token to get tokens; I’m concealing as much complexity as possible.) You might also want to establish a default identity, as typically you’d only have one:

$ aas-sign config eus:contoso:jdoe

Or all at once:

$ aas-sign login eus:contoso:jdoe

My goal was, after enduring the Azure portal sign-up, to maximally streamline code-signing.

Action mode

Manually building, signing, and publishing releases is easy and might be fine if you’re not releasing too frequently — or too ininfrequently that you forget how to do it — but likely you’d want to automate this process. I was stubborn about it myself, until Peter0x44 pushed me hard enough to take it seriously, for which I’m grateful. There’s an official GitHub Action to code-sign with Azure, but it requires a Windows runner, fatally limiting for my own needs. So aas-sign also defines a code-signing action. The previous example would have this in its own action:

  - name: Sign
    uses: skeeto/aas-sign@v1.0.0
    with:
      endpoint:  ${{ secrets.TRUSTED_SIGNING_ENDPOINT }}
      account:   ${{ secrets.TRUSTED_SIGNING_ACCOUNT }}
      profile:   ${{ secrets.CERTIFICATE_PROFILE }}
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      files: |
        myapp.exe
        myapp.dll

The secrets are bunch of strings you (or your AI agent) retrieve from the Azure portal. You also need to create Federated Identity Credential (FIC) for each repository, which I suggest triggering on an environment. (This all may sound like a joke but it’s real.) Again, just ask an AI to do all this stuff. The mandatory Azure interfacing limits how much I can streamline this process. Then aas-sign combines these with per-job tokens GitHub injects into the runner to authenticate (via the FIC) and sign.

I’ve gone through this a number of times, and the AI breezes through the GitHub UI, but struggles through the Azure portal — objective evidence of how awful it is. Idea for a UI benchmark: How many AI tokens does it take to accomplish typical activities?

For w64devkit, my plan is to run aas-sign inside the Docker build and sign executables in the container before it’s SFX-packaged. This is impossible with SignTool.exe and needlessly frictional with Jsign (requires at least a JRE if not a JDK). The easiest path forward was to literally build my own tool from scratch.

I’m considering aas-sign as a new w64devkit command, but it’s so niche that I’m likely to be its sole user. On the other hand, those already running w64devkit in GitHub Actions could use it in Action mode to code-sign their builds without any additional tools.

dcmake: a new CMake debugger UI

2026-04-07T03:04:02Z

CMake has a --debugger mode since 3.27 (July 2023), allowing software to manipulate it interactively through the Debugger Adaptor Protocol (DAP), an HTTP-like protocol passing JSON messages. Debugger front-ends can start, stop, step, breakpoint, query variables, etc. a live CMake. When I came across this mode, I immediately conceived a project putting it to use. Thanks to recent leaps in software engineering productivity, I had a working prototype in 30 minutes, and by the end of that same day, a complete, multi-platform, native, GUI application. I named it dcmake (“debugger for CMake”). I’ve tested it on macOS, Windows, and Linux. Despite only being couple days old, it’s one of the coolest things I’ve ever built. Prior to 2026, I estimate it would have taken me a month to get the tool to this point.

It has a Dear ImGui interface, which I’ve experienced as a user but never built on myself before. Specifically the docking branch. In a sense it’s a toolkit for building debuggers, so it’s playing an enormous role in how quickly I put this project together. All of the “windows” tear out and may be free-floating or docked wherever you like, closely matching the classic Visual Studio UI. I borrowed all the same keybindings: F10 to step over, F11 to step in, F5 to start/continue, shift+F5 to stop. Click on line numbers to toggle breakpoints, right click to run-to-line, hover over variables with the mouse to see their values. Nearly every every UI state persists across sessions, and it opens nearly instantly.

This is just one of many situations I’ve used AI the past month for UI development, and it’s been shockingly effective. I can describe roughly the interface I want, and the AI makes it happen in a matter of minutes. It understands what I mean, filling in the details, sometimes anticipating what I’ll ask for next. If I’m unsure how I want a UI to work, it also offers good advice. If I need simple icons and such, it can draw those, too. It’s all incredibly empowering.

On macOS and Linux it runs on top of GLFW with OpenGL 3 rendering, and on Windows it uses native Win32 windowing and DirectX 11 rendering.

Program arguments given to dcmake populate the top-left arguments text input, which go straight into CMake on start. So you can prepend d to your CMake configuration command to run it inside the debugger. Passing no arguments sets it up for “standard” -B build configuration.

In general, if you don’t have anywhere in particular to look, likely the first thing to do after starting dcmake (in a project) is press F10. It starts CMake paused on the first line of CMakeLists.txt, or whatever script you’re debugging. If you’re trying out dcmake for the first time, that’s a good place to start. Keep pressing F10 to step through that script, watching it run through its configuration. If you F11 through the script then you’ll dive deeper and deeper into CMake itself, which can be insightful.

There is no point in trying to debug --build invocations. It’s just a uniform interface to the underlying build tool, and there is no CMake left to debug at that point. However, it does work with -P script mode invocations. CMake can operate as a platform-agnostic shell script-like tool, but unlike shell scripts you can step through them with a debugger like dcmake.

On Windows it supports Unicode paths all the way through, without a UTF-8 manifest. This took some special care, in particular avoiding any C++ standard library I/O functionality. Current frontier AI cannot handle this detail on their own. The macOS platform required a bit of Objective-C, as it often does, and I’m happy I didn’t have to figure that part out myself.

The next release of w64devkit will include dcmake, complementing its recent addition of CMake. This new tool has already proven useful in its own development.

2026 has been the most pivotal year in my career… and it's only March

2026-03-29T21:38:22Z

In February I left my employer after nearly two decades of service. In the moment I was optimistic, yet unsure I made the right choice. Dust settled, I’m now absolutely sure I chose correctly. I’m happier and better for it. There were multiple factors, but it’s not mere chance it coincides with these early months of the automation of software engineering. I left an employer that is years behind adopting AI to one actively supporting and encouraging it. As of March, in my professional capacity I no longer write code myself. My current situation was unimaginable to me only a year ago. Like it or not, this is the future of software engineering. Turns out I like it, and having tasted the future I don’t want to go back to the old ways.

In case you’re worried, this is still me. These are my own words. Writing is thinking, and it would defeat the purpose for an AI to write in my place on my personal blog. That’s not going to change.

I still spend much time reading and understanding code, and using most of the same development tools. It’s more like being a manager, orchestrating a nebulous team of inhumanly-fast, nameless assistants. Instead of dicing the vegetables, I conjure a helper to do it while I continue to run the kitchen. I haven’t managed people in some 20 years now, but I can feel those old muscles being put to use again as I improve at this new role. Will these kitchens still need human chefs like me by the end of the decade? Unclear, and it’s something we all need to prepare for.

My situation gave me an experience onboarding with AI assistance — a fast process given a near-instant, infinitely-patient helper answering any question about the code. By second week I was making substantial, wide contributions to the large C++ code base. It’s difficult to attach a quantifiable factor like 2x, 5x, 10x, etc. faster, but I can say for certain this wouldn’t have been possible without AI. The bottlenecks have shifted from producing code, which now takes relatively no time at all, to other points, and we’re all still trying to figure it out.

My personal programming has transformed as well. Everything I said about AI in late 2024 is, as I predicted, utterly obsolete. There’s a huge, growing gap between open weight models and the frontier. Models you can run yourself are toys. In general, almost any AI product or service worth your attention costs money. The free stuff is, at minimum, months behind. Most people only use limited, free services, so there’s a broad unawareness of just how far AI has advanced. AI is now highly skilled at programming, and better than me at almost every programming task, with inhumanly-low defect rates. The remaining issues are mainly steering problems: If AI code doesn’t do what I need, likely the AI writing it didn’t understand what I needed.

I’ll still write code myself from time to time for fun — minimalist, with my style and techniques — the same way I play shogi on the weekends for fun. However, artisan production is uneconomical in the presence of industrialization. AI makes programming so cheap that only the rich will write code by hand.

A small part of me is sad at what is lost. A bigger part is excited about the possibilities of the future. I’ve always had more ideas than time or energy to pursue them. With AI at my command, the problem changes shape. I can comfortably take on complexity from which I previously shied away, and I can take a shot at any idea sufficiently formed in my mind to prompt an AI — a whole skill of its own that I’m actively developing.

For instance, a couple weeks ago I put AI to work on a problem, and it produced a working solution for me after ~12 hours of continuous, autonomous work, literally while I slept. The past month w64devkit has burst with activity, almost entirely AI-driven. Some of it architectural changes I’ve wanted for years, but would require hours of tedious work, and so I never got around to it. AI knocked it out in minutes, with the new architecture opening new opportunities. It’s also taken on most of the cognitive load of maintenance.

Quilt.cpp

So far the my biggest, successful undertaking is Quilt.cpp, a C++ clone of Quilt, an early, actively-used source control system for patch management. Git is a glaring omission from the almost complete w64devkit, due platform and build issues. I’ve thought Quilt could fill some of that source control hole, except the original is written in Bash, Perl, and GNU Coreutils — even more of a challenge than Git. Since Quilt is conceptually simple, and I could lean on busybox-w32 diff and patch, I’ve considered writing my own implementation, just as I did pkg-config, but I never found the energy to do it.

Then I got good enough with AI to knock out a near feature-complete clone in about four days, including a built-in diff and patch so it doesn’t actually depend on external tools (except invoking $EDITOR). On Windows it’s a ~1.6MB standalone EXE, to be included in future w64devkit releases. The source is distributed as an amalgamation, a single file quilt.cpp per its namesake:

$ c++ -std=c++20 -O2 -s -o quilt.exe quilt.cpp
$ ./quilt.exe --help
Usage: quilt [--quiltrc file]  [options] [args]

Commands:
  new        Create a new empty patch
  add        Add files to the topmost patch
  push       Apply patches to the source tree
  pop        Remove applied patches from the stack
  refresh    Regenerate a patch from working tree changes
  diff       Show the diff of the topmost or a specified patch
  series     List all patches in the series
  applied    List applied patches
  unapplied  List patches not yet applied
  top        Show the topmost applied patch
  next       Show the next patch after the top or a given patch
  previous   Show the patch before the top or a given patch
  delete     Remove a patch from the series
  rename     Rename a patch
  import     Import an external patch into the series
  header     Print or modify a patch header
  files      List files modified by a patch
  patches    List patches that modify a given file
  edit       Add files to the topmost patch and open an editor
  revert     Discard working tree changes to files in a patch
  remove     Remove files from the topmost patch
  fold       Fold a diff from stdin into the topmost patch
  fork       Create a copy of the topmost patch under a new name
  annotate   Show which patch modified each line of a file
  graph      Print a dot dependency graph of applied patches
  mail       Generate an mbox file from a range of patches
  grep       Search source files (not implemented)
  setup      Set up a source tree from a series file (not implemented)
  shell      Open a subshell (not implemented)
  snapshot   Save a snapshot of the working tree for later diff
  upgrade    Upgrade quilt metadata to the current format
  init       Initialize quilt metadata in the current directory

Use "quilt  --help" for details on a specific command.

It supports Windows and POSIX, and runs ~5x faster than the original. AI developed it on Windows, Linux, and macOS: It’s best when the AI can close the debug loop and tackle problems autonomously without involving a human slowpoke. The handful of “not implemented” parts aren’t because they’re too hard — each would probably take an AI ~10 minutes — but deliberate decisions of taste.

There’s an irony that the reason I could produce Quilt.cpp with such ease is also a reason I don’t really need it anymore.

I changed the output of quilt mail to be more Git-compatible. The mbox produced by Quilt.cpp can be imported into Git with a plain git am:

$ quilt mail --mbox feature-branch.mbox
$ git am feature-branch.mbox

The idea being that I could work on a machine without Git (e.g. Windows XP), and copy/mail the mbox to another machine where Git can absorb it as though it were in Git the whole time. git format-patch to quilt import sends commits in the opposite direction, useful for manually testing Quilt.cpp on real change sets.

To be clear, I could not have done this if the original Quilt did not exist as a working program. I began with an AI generating a conformance suite based on the original, its documentation, and other online documentation, validating that suite against the original implementation (see -DQUILT_TEST_EXECUTABLE). Then had another AI code to the tests, on architectural guidance from me, with -D_GLIBCXX_DEBUG and sanitizers as guardrails. That was day one. The next three days were lots of refining and iteration as I discover the gaps in the test suite. I’d prompt AI to compare Quilt.cpp to the original Quilt man page, add tests for missing features, validate the new tests against the original Quilt, then run several agents to fix the tests. While they worked I’d try the latest build and note any bugs. As of this writing, the result is about equal parts test and non-test, ~9KLoC each.

I’m likely to use this technique to clone other tools with implementations unsuitable for my purposes. I learned quite a bit from this first attempt.

Why C++ instead of my usual choice of C? As we know, conventional C is highly error-prone. Even AI has trouble with it. In the ~9k lines of C++ that is Quilt.cpp, I am only aware of three memory safety errors by the AI. Two were null-terminated string issues with strtol, where the AI was essentially writing C instead of C++, after which I directed the AI to use std::from_chars and drop as much direct libc use as possible. (The other was an unlikely branch with std::vector::back on an empty vector.) We can rescue C with better techniques like arena allocation, counted strings, and slices, but while (current) state of the art AI understands these things, it cannot work effectively with them in C. I’ve tried. So I picked C++, and from my professional work I know AI is better at C++ than me.

Also like a manager, I have not read most of the code, and instead focused on results, so you might say this was “vibe-coded.” It is thoroughly tested, though I’m sure there are still bugs to be ironed out, especially on the more esoteric features I haven’t tried by hand yet.

Let’s discuss tools

After opposing CMake for years, you may have noticed the latest w64devkit now includes CMake and Ninja. What happened? Preparing for my anticipated employment change, this past December I read Professional CMake. I realized that my practical problems with CMake were that nearly everyone uses it incorrectly. Most CMake builds are a disaster, but my new-found knowledge allows me to navigate the common mistakes. Only high profile open source projects manage to put together proper CMake builds. Otherwise the internet is loaded with CMake misinformation. Similar to AI, if you’re not paying for CMake knowledge then it’s likely wrong or misleading. So I highly recommend that book!

Frontier AI is very good with CMake. When a project has a CMake build that isn’t too badly broken, just tell AI to fix it, without any specifics, and build problems disappear in mere minutes without having to think about it. It’s awesome. Combine it with the previous discussion about tests making AI so much more effective, and that it also knows CTest well, and you’ve got a killer formula. I’m more effective with CTest myself merely from observing how AI uses it. AI (currently) cannot use debuggers, so putting powerful, familiar testing tools in its hands helps a lot, versus the usual bespoke, debugger-friendly solutions I prefer.

Similar to solving CMake problems: Have a hairy merge conflict? Just ask AI resolve it. It’s like magic. I no longer fear merge conflicts.

So part of my motivation for adding CMake to w64devkit was anticipation of projects like Quilt.cpp, where they’d be available to AI, or at least so I could use the tools the AI used to build/test myself. It’s already paid for itself, and there’s more to come.

For agent software, on personal projects I’m using Claude Code. It’s a great value, cheaper than paying API rates but requires working around 5-hour limit windows. I started with Pro (US$20/mo), but I’m getting so much out of it that as of this writing I’m on 5x Max (US$100/mo) simply to have enough to explore all my ideas. Be warned: Anthropic software is quite buggy, more so than industry average, and it’s obvious that they never even start, let alone test, some of their released software on disfavored platforms (Windows, Android). Don’t expect to use Claude Code effectively for native Windows platform development, which sadly includes w64devkit. Hopefully that’s fixed someday. I suspect Anthropic hit a bottleneck on QA, and unable to fit AI in that role they don’t bother. You can theoretically report bugs on GitHub, but they’re just ignored and closed. (Why don’t they have AI agents jumping on this wealth of bug reports?)

At work I’m using Cursor where I get a choice of models. My favorite for March has been GPT-5.4, which in my experience beats Opus 4.6 on Claude Code by a small margin. It’s immediately obvious that Cursor is better agent software than Claude Code. It’s more robust, more featureful, and with a clearer UI than Claude Code. It has no trouble on Windows and can drive w64devkit flawlessly. It’s also more expensive than Claude Code. My employer currently spends ~US$250/mo on my AI tokens, dirt cheap considering what they’re getting out of it. I have bottlenecks elsewhere that keep me from spending even more.

As a general rule, for software engineering always use the smartest model available. The cheaper, dumber models cost more in the long run. It takes more tokens to achieve worse results, which costs more human time to sort out.

(Update September 2026: This summer Claude Desktop drastically improved, and is currently the best publicly available coding harness. On the other hand Cursor degraded, adopted dark patterns, and is untrustworthy. With the OpenAI models no longer available on Cursor, there is no longer any reason whatsoever to use it.)

Neither Cursor nor Claude Code are open source, so what are the purists to do, even if they’re willing to pay API rates for tokens? Sadly I have no answers for you. I haven’t gotten any open source agent software actually working, and it seems they may lack the necessary secret sauce.

Update: Several folks suggested I give OpenCode another shot, and this time I got over the configuration hurdle. Single executable, slick interface, and unlike Claude Code, I observed no bugs in my brief trial. Give that a shot if you’re looking for an open source client.

The future is going to be weird. My experience is only a peek at what’s to come, and my head is still spinning. However, the more I adapt to the changes, the better I feel. If you’re feeling anxious like I was, don’t flinch from improving your own AI knowledge and experience.

Frankenwine: Multiple personas in a Wine process

2026-01-19T21:51:38Z

I came across a recent article on making Linux system calls from a Wine process. Windows programs running under Wine are still normal Linux processes and may interact with the Linux kernel like any other process. None of this was surprising, and the demonstration works just as I expect. Still, it got the wheels spinning and I realized an almost practical application: build my pkg-config implementation such that on Windows pkg-config.exe behaves as a native pkg-config, but when run under Wine this same binary takes the persona of a Linux program and becomes a cross toolchain pkg-config, bypassing Win32 and talking directly with the Linux kernel. Cosmopolitan Libc cleverly does this out-of-the-box, but in this article we’ll mash together a couple existing sources with a bit of glue.

The results are in the merge-demo branch of u-config, and took hardly any work:

$ git show --stat
...
 main_linux_amd64.c |   8 ++---
 main_wine.c        | 101 +++++++++++++++++++++++++++++++++++++++++
 src/linux_noarch.c |  16 ++++-----
 src/u-config.c     |   1 +
 4 files changed, 114 insertions(+), 12 deletions(-)

A platform layer, main_wine.c, is a merge of two existing platform layers, one of which required unavoidable tweaks. We’ll get to those details in a moment. First we’ll need to detect if we’re running under Wine, and the best solution I found was to locate ntdll!wine_get_version. If this function exists, we’re in Wine. That works out to a pretty one-liner because ntdll.dll is already loaded:

bool running_on_wine()
{
    return GetProcAddress(GetModuleHandleA("ntdll"), "wine_get_version");
}

An x86-64 Linux syscall wrapper with thorough inline assembly:

ptrdiff_t syscall3(int n, ptrdiff_t a, ptrdiff_t b, ptrdiff_t c)
{
    ptrdiff_t r;
    asm volatile (
        "syscall"
        : "=a"(r)
        : "a"(n), "D"(a), "S"(b), "d"(c)
        : "rcx", "r11", "memory"
    );
    return r;
}

ptrdiff_t write(int fd, void *buf, ptrdiff_t len)
{
    return syscall3(SYS_write, fd, (ptrdiff_t)buf, len);
}

I’d normally use long for all these integers because Linux is LP64 (long is pointer-sized), but Windows is LLP64 (only long long is 64 bits). It’s so bizarre to interface with Linux from LLP64, and this will have consequences later. With these pieces we can see the basic shape of a split personality program:

    if (running_on_wine()) {
        write(1, "hello, wine\n", 12);
    } else {
        HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);
        WriteFile(h, "hello, windows\n", 15, 0, 0);
    }

We can cram two programs into this binary and select which program at run time depending on what we see. In typical programs locating and calling into glibc would be a challenge, particularly with the incompatible ABIs involved. We’re avoiding it here by interfacing directly with the kernel.

Application to u-config

Luckily u-config has completely-optional platform layers implemented with Linux system calls. The POSIX platform layer works fine, and that’s what distributions should generally use, but these bonus platforms are unhosted and do not require libc. That means we can shove it into a Windows build with relatively little trouble.

Before we do that, let’s think about what we’re doing. Debian has great cross toolchain support, including Mingw-w64. There are even a few Windows libraries in the Debian package repository, such as zlib, and we can build Windows programs against them. If you’re cross-building and using pkg-config, you ought to use the cross toolchain pkg-config, which in GNU ecosystems gets an architecture prefix like the other cross tools. Debian cross toolchains each include a cross pkg-config, and it sometimes almost works correctly! Here’s what I get on Debian 13:

$ x86_64-w64-mingw32-pkg-config --cflags --libs zlib
-I/usr/x86_64-w64-mingw32/include -L/usr/x86_64-w64-mingw32/lib -lz

Note the architecture in the -I and -L options. It really is querying the cross sysroot. Though these paths are in the cross sysroot, and so should not be listed by pkg-config. It’s unoptimal and indicates this pkg-config is probably misconfigured. In other cases it’s far from correct:

$ x86_64-w64-mingw32-pkg-config --variable pc_path pkg-config
/usr/local/lib/x86_64-linux-gnu/pkgconfig:...

A tool prefixed x86_64-w64-mingw32- should not produce paths containing x86_64-linux-gnu (the host architecture in this case). Our version won’t have these issues.

The u-config platform interface is five functions:

filemap os_mapfile(os *, arena *, s8 path);  // read whole files
s8node *os_listing(os *, arena *, s8 path);  // list directories
void    os_write(os *, i32 fd, s8);          // standard out/err
void    os_fail(os *);                       // non-zero exit

void uconfig(config *);

Platforms implement the first four functions, and call uconfig() with the platform’s configuration, context pointer (os *), command line arguments, environment, and some memory (all in the config object). My strategy is to link two platforms into the binary, and the first challenge is they both define os_write, etc. I did not plan nor intend for one binary to contain more than one platform layer. Unity builds offer a fix without changing a single line of code:

#define os_fail     win32_fail
#define os_listing  win32_listing
#define os_mapfile  win32_mapfile
#define os_write    win32_write
#include "main_windows.c"
#undef os_write
#undef os_mapfile
#undef os_listing
#undef os_fail

#define os_fail     linux_fail
#define os_listing  linux_listing
#define os_mapfile  linux_mapfile
#define os_write    linux_write
#include "main_linux_amd64.c"
#undef os_write
#undef os_mapfile
#undef os_listing
#undef os_fail

This dirty, but effective trick may look familiar. It also doesn’t interfere with the other builds. Next I define the real platform functions as a dispatch based on our run-time situation:

b32 wine_detected;

filemap os_mapfile(os *ctx, arena *a, s8 path)
{
    if (wine_detected) {
        return linux_mapfile(ctx, a, path);
    } else {
        return win32_mapfile(ctx, a, path);
    }
}

If I were serious about keeping this experiment, I’d lift os as I did the functions (as win32_os, linux_os) and include wine_detected in the context, eliminating this global variable. That cannot be done with simple hacks and macros.

The next challenge is that I wrote the Linux platform layer assuming LP64, and so it uses long instead of an equivalent platform-agnostic type like ptrdiff_t. I never thought this would be an issue because this source literally contains asm blocks and no conditional compilation, yet here we are. Lesson learned. I wanted to try an extremely janky #define on long to fix it, but this source file has a couple long long that won’t play along. These multi-token type names of C are antithetical to its preprocessor! So I adjusted the source manually instead.

The Windows and Linux platform entry points are completely different, both in name and form, and so co-exist naturally. The merged platform layer is a new entry point that will pass control to the appropriate entry point:

void entrypoint(ptrdiff_t *stack);  // Linux
void __stdcall mainCRTStartup();    // Windows

On Linux stack is the initial value of the stack pointer, which points to argc, argv, envp, and auxv. We’ll need construct an artificial “stack” for the Linux platform layer to harvest. On Windows this is the process entry point, and it will find the rest on its own as a normal Windows process. Ultimately this ended up simpler than I expected:

void __stdcall merge_entrypoint()
{
    wine_detected = running_on_wine();
    if (wine_detected) {
        u8 *fakestack[CMDLINE_ARGV_MAX+1];
        c16 *cmd = GetCommandLineW();
        fakestack[0] = (u8 *)(iz)cmdline_to_argv8(cmd, fakestack+1);
        // TODO: append envp to the fake stack
        entrypoint((iz *)fakestack);
    } else {
        mainCRTStartup();
    }
}

Where cmdline_to_argv8 is my Windows argument parser, already used by u-config, and I reserve one element at the front to store argc. Since this is just a proof-of-concept I didn’t bother fabricating and pushing envp onto the fake stack. The Linux entry point doesn’t need auxv and can be omitted. Once in the Linux entry point it’s essentially a Linux process from then on, except the x64 calling convention still in use internally.

Finally, I configure the Linux platform layer for Debian’s cross sysroot:

#define PKG_CONFIG_LIBDIR "/usr/x86_64-w64-mingw32/lib/pkgconfig"
#define PKG_CONFIG_SYSTEM_INCLUDE_PATH "/usr/x86_64-w64-mingw32/include"
#define PKG_CONFIG_SYSTEM_LIBRARY_PATH "/usr/x86_64-w64-mingw32/lib"

And that’s it! We have our platform merge. Build (w64devkit):

$ cc -nostartfiles -e merge_entrypoint -o pkg-config.exe main_wine.c

On Debian use x86_64-w64-mingw32-gcc for cc. The -e linker option selects the new, higher level entry point. After installing Wine binfmt, here’s how it looks on Debian:

$ ./pkg-config.exe --cflags --libs zlib
-lz

That’s the correct output, but is it using the cross sysroot? Ask it to include the -I argument despite it being in the cross sysroot:

$ ./pkg-config.exe --cflags --libs --keep-system-cflags zlib
-I/usr/x86_64-w64-mingw32/include -lz

Looking good! It passes the pc_path test, too:

$ ./pkg-config.exe --variable pc_path pkg-config
/usr/x86_64-w64-mingw32/lib/pkgconfig

Running this same binary on Windows after installing zlib in w64devkit:

$ ./pkg-config.exe --cflags --libs --keep-system-cflags zlib
-IC:/w64devkit/include -lz

Also:

$ ./pkg-config.exe --variable pc_path pkg-config
C:/w64devkit/lib/pkgconfig;C:/w64devkit/share/pkgconfig

My Frankenwine is a success!