ARM64 programs built with Visual Studio crash with 0xC000007B

It’s because Visual Studio seems to copy an x86 version of the VC++ runtime into system32 on ARM64 systems. That’ll make it crash with a bad image format error. If you copy the ARM64 version of vcruntime140.dll (for me, found in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Redist\MSVC\14.28.29325\arm64\Microsoft.VC142.CRT) into the build directory, binaries will work.

Notes with the Parallels Beta on Apple Silicon

QEMU recently gained Apple Silicon hypervisor support. That was pretty damn cool for the first few weeks of M1 in people’s hands. Even without any optimizations, Windows 10 on M1 outclasses the Surface Pro X and even my Ryzen gaming desktop. Unfortunately, that didn’t include 3D acceleration (though virtio-gpu is now a thing for 2D).

Luckily, Parallels has ported their virtualization software to M1. It’s incredibly janky (and certainly deserving of a technical preview because of that!), but shows a lot of promise, complete with D3D11 support for games. Unfortunately, it requires some hacks to get running stable, but it’ll work fine after that.

Continue reading

Cursed MinGW cross-compiling techniques

I tend not to like cross-compiling, but sometimes it’s just the simplest solution, particularly if Windows and autotools come into the mix. Recently, I wanted to build xz for Windows, and build it in some particular ways.

windres (the GNU Windows resource compiler) will eat CPPFLAGS, but it won’t process most of them the same way. I often like to use it as a shorthand for both C++ and C compiler options (like -O2), but if windres is in play, only put preprocessor related things. As an example, if you enter -O2 for CPPFLAGS, you get unknown format type `2'.

If you need to target pre-Windows XP, be sure that the compiler is before 7.3. This patch has a hard dependency on a symbol that exists only on XP.

The end result is now I have a cursed xz for an even more cursed operating system:

xz 5.2.5 on Windows ME