For one reason or another, I recently found myself wanting to play the original retail 2004 build of Half-Life 2. Given that I now use Linux full-time, I have to do so under Wine, using Lutris to launch it and DXVK for the Direct3D 9 implementation. I quickly ran into some issues though. The first I encountered is that it would freeze and try and consume all of my system memory. Ouch. This is because it allocates textures endlessly until it can’t any more, in a poor attempt to determine how much video memory is avaiable. On a modern system with 12 GB of video memory and 48 GB of system memory, it ends poorly… Fortunately this one was trivial to fix: just add a `dxvk.conf` next to `hl2.exe` containing: [hl2.exe] d3d9.maxAvailableMemory = 1024 Then I hit another issue: it thought I had less than 128 MB of system memory. Specifically, it thought I had -1 bytes of system memory. Those of us (un)fortunate enough to know enough about Win32 can guess what’s happening: it’s using `GlobalMemoryStatus`. This function returns the amount of memory the system has in a 32-bit integer, and it handles amounts of memory above 4GB very poorly: > On computers with more than 4 GB of memory, the GlobalMemoryStatus function can return incorrect information, reporting a value of –1 to indicate an overflow. On modern Windows, it’s possible to set a per-application compatibility level, which will make Windows will try and behave like a previous version of the OS. Setting it to Windows XP compatibility fixes this issue, and it will cause `GlobalMemoryStatus` to report a valid amount of memory. Unfortunately, Wine seemingly has no such compatibility setting for this function, at least that I could find. So, I decided to do the only reasonable thing: patch the binary to remove this check. First, we need to find the module where the check is located. The Source engine is highly modular, and has a load of DLLs: There are some Linux .so files there, but they’re for the dedicated server. Client support for Linux was 9 years away yet. Fortunately, finding the right one was trivial. bin $ grep -rn 128MB dxsupport.cfg:2351: "name" "Matrox Parhelia 128MB" grep: engine.dll: binary file matches It’s in `engine.dll`. Time to crack it open using Ghidra. `engine.dll` is the largest module in the engine, so it took a little while to analyse. Ghidra has a handy “Defined Strings” window that lets us view all of the strings in the module, and search through them: From there, we can jump to where the string is referenced. And we found the memory check! It’s exactly as guessed: it’s using `GlobalMemoryStatus` which is returning an invalid value. The check essentially compiled to a `JGE` instruction at memory location `0x20162057`: if the memory is above 128 MB, it will skip over raising an error. We can easily get rid of the check by replacing it with a `JMP`, so it always skips over the error: right-click the instruction and select “Patch Instruction”. Export the DLL from File > Export, selecting the Raw Bytes format. Ghidra appends a `.bin` to the file extension, so copy it over your `engine.dll` manually. This has removed the memory capacity check. However, the code uses the memory size to determine the size of an internal engine heap; this will get clamped to the range of 48 to 64 MB. Due to unsigned shenanigans, the -1 value actually gets clamped to the upper of that bound. You can override it with `-heapsize` if you wish (it takes a value in kB). Now you can play the retail build of Half-Life 2 on Linux. Have fun. A slight caveat is that exporting the DLL from Ghidra doesn’t just change the instruction; it exports the whole binary from its datamodel anew. As such while it’s functionally identical the file has might have some differences. If you just want to fix this issue, using a hex editor to patch it is probably better: given an `engine.dll` with SHA256 `21cbf8e15551906eab2b27348d43876167e8b7e520cee6efc95a18b7a96ee051`, change the byte at offset `0x162054` from `7d` to `eb`. This was my first time actually patching a binary to get it working. At least it was simple… this article is basically about changing a single byte.

For a while, Zandronum has supported saving credentials for its account system to the system keyring using the `login_add` command, so you don’t have to keep typing your password into the console or storing it plaintext in your configuration file. This was only supported on Windows since the feature was first added, but I recently added support for libsecret, so this feature can now be used on Linux starting with Zandronum 3.3. This means you can now store your auth passwords in KDE Wallet1, GNOME Keyring, KeepassXC, or any other Secret Service implementation. You can also use `login_default_user` to set a default username to use, reducing the effort of logging in to just typing `login`. Naturally, to use this feature you will need to build Zandronum with libsecret - simply install the relevant package and build, and it should just work. The feature is optional, so similar to other dependencies like GTK, if it’s not found it will silently be disabled. It’s already available in the CI builds, and should be enabled whenever we start releasing official testing builds for 3.3, and eventually and inevitably, the release builds. A small bit of refactoring was also done to facilitate this, so it should be easier to add other storage backends in the future. Specifically, macOS doesn’t have support for this feature yet… For demonstration purposes, here’s a couple of screenshots of this in action: under KDE Plasma under MATE, using GNOME Keyring 1. If the Secret Storage implementation is even called KDE Wallet? KDE appears to be in a sort of transition period towards being Secret Service-native. ↩

The Online Safety Act is restricting freedom of expression in the UK.