Why Castrol Honda Superbike crashes on (most) modern systems

2025-11-16T00:00:00+00:00

A friend cleaned up and gave me a copy of a game I've not heard about before: Castrol Honda Superbike World Champions, a motorbike racing game for PC, released 1998 by Interactive Entertainment Ltd. and Midas Interactive Entertainment.

</a> </div>
Given the age of the game (and looking at the system requirements) it's clear that the game comes from the tricky era of early 3D-accelerated PC gaming. For context, my copy of the game helpfully asks to install DirectX 5.
Before Windows was known for cramming AI and account requirements into every single corner of the system, no matter how unnecessary, it was known for its excellent backwards compatibility with older software. Generally, unless there are genuine bugs (and sometimes even despite them), Windows tries its hardest to run old applications correctly.
Pushing my luck and trying to run it on my Windows 7 machine, however, resulted in either a getting stuck on a black screen, or a crash, seemingly at random:
</a> </div>
Let's go back in time and see how far we need to go to get it running: Installing and running it on my Windows 98 and Windows XP machines was as uneventful, and the game works just fine 1</a>, including with 3D acceleration. Glorious 1024x768x16:
</a> </div>
Debugging the issue #</a></h2>
Debugging is more fun than playing, so let's get started! :^)
I pulled over the installation directory to my main machine and ran Detect It Easy</a> to see what we can learn about the executable:
</a> </div>
Linker: Microsoft Linker(5.10)</code> and Compiler: Microsoft Visual C/C++(...)[libcmtd]</code> are the interesting bits here. Notice how it's libcmtd</code>, not libcmt</code>? The binary is linked against the static debug version of VC5's runtime. The debug runtime has heaps of extra checks andlogging</a>, which might help later.
Let's attach a debugger and see what's going on. Given that the game crashes very early on (before the credits intro screen), I hoped to see something right away. The cases where the game got stuck in a loop seemed to actually get stuck in some Windows API call stack.
Anyway, the cases where it crashed gave a clearer starting point:
</a> </div> The game seems to be stuck after a call to DirectInput's DirectInputCreateEx</code> function. At this point I started to do some static analysis of the functions leading to this call. While doing that I noticed that the game seems to have quite extensive logging, anything from game initialization to memory allocations. If you're interested in all the logs, here are the config settings to enable them all: In Config.dat</code>, switch ErrorLog</code>, FileLog</code>, MallocLog</code> from off</code> to on</code>. These are the "normal" log files the game produces.</li> ErrorLog</code> produces error.log</code>, which is the general log file.</li> FileLog</code> produces files.log</code>, tracking all opened files and their access modes.</li> MallocLog</code> produces malloc.log</code>, tracking all memory allocations and frees. The devs even kept descriptions for every allocation site!</li> </ul> </li> Set an environment variable named errorfile</code> to any file name (not path). The game will write logs to that file in the game directory. You might also need to create an empty *.c</code> file in the game directory.</li> Just gives a bit of extra logging.</li> </ul> </li> </ul> Bonus: add a setting named windowed=true</code> to the config file to force windowed mode; only works correctly in 16-bit mode (garbled graphics in True Color). </blockquote> After enabling all the logging, I ran the game a few more times, and noticed that the last log messages in error.log</code> before the crash were these: 0> Instance : Mouse 0> Product : Mouse 1> Instance : Keyboard 1> Product : Keyboard 2> Instance : Gaming Mouse G502 2> Product : Gaming Mouse G502 3> Instance : Gaming Mouse G502 3> Product : Gaming Mouse G502 4> Instance : Gaming Mouse G502 4> Product : Gaming Mouse G502 5> Instance : Gaming Mouse G502 5> Product : Gaming Mouse G502 6> Instance : USB Keyboard 6> Product : USB Keyboard 7> Instance : USB Keyboard 7> Product : USB Keyboard 8> Instance : LED Controller 8> Product : LED Controller </code></pre> Great, the game is enumerating input devices— uh, why is there an "LED Controller" device? The motherboard in my Windows 7 machine has a built-in LED controller, so that checks out. Maybe the detection isn't working properly, and the game is trying to use it as an input device? After disabling the LED controller in Device Manager, the game started up just fine, consistently! So far, so good. Of course I wanted to know what was actually going wrong, though, so let's see where these messages are printed. Side quest: CD check #</a></h2> The game seemed to close without any notice if I forgot to insert the game disc. A quick trace showed that the GibbonPosture</code> setting in f1.cfg</code> is used to point to the disc drive from which the game was installed. The only check seems to be that the path redist\dsetup.dll</code> exists on the disc. Copying the redist folder to the installation directory and changing the setting to GibbonPosture=.\</code> seems to work just fine. :) The bug #</a></h2> Finding the Instance :</code> and Product :</code> log messages in the binary was easy enough. They are referenced in only one function, which is a DIEnumDevicesCallback</code></a> callback function that is provided to IDirectInput::EnumDevices</code> (Microsoft has only kept the documentation for the DX8 version</a> of EnumDevices left online, but it's close enough). This is the pseudocode of the call and the callback, and the relevant data structure: struct DinputDeviceData { char instance_name[128]; char product_name[128]; DWORD dwDevType; GUID guid; }; // ... BOOL __stdcall dinput_enumdevices_callback(LPCDIDEVICEINSTANCEA lpDevice, LPVOID pvRef) { int index = g_dinput_device_index; g_direct_input_devices[index].guid = lpDevice->guidInstance; strcpy(g_direct_input_devices[index].instance_name, lpDevice->tszInstanceName); strcpy(g_direct_input_devices[index].product_name, lpDevice->tszProductName); g_direct_input_devices[index].dwDevType = lpDevice->dwDevType; log_line("%d> Instance : %s\n", index, lpDevice->tszInstanceName); log_line("%d> Product : %s\n", index, lpDevice->tszProductName); if ( LOBYTE(g_direct_input_devices[index].dwDevType) == DIDEVTYPE_JOYSTICK ) { int joystick_index = g_joystick_index; g_joystick_info[joystick_index].dinput_device_index = index; g_joystick_info[joystick_index].field_4 = 0; g_joystick_info[joystick_index].field_8 = 0; g_joystick_info[joystick_index].field_38 = 0; g_joystick_info[joystick_index].field_1 = 0; g_joystick_index = joystick_index + 1; } g_dinput_device_index = index + 1; return DIENUM_CONTINUE; } // ... g_dinput_create_hresult = DirectInputCreateA(hInstance, 0x500u, &g_dinput_instance, 0); g_dinput_device_index = 0; g_joystick_index = 0; g_dinput_instance->lpVtbl->EnumDevices( g_dinput_instance, 0, dinput_enumdevices_callback, 0, DIEDFL_ATTACHEDONLY); </code></pre> So, for each enumerated device, the game stores some general information about it in the global array g_direct_input_devices</code>. Then, if the device is a joystick (generally, a game controller), it also adds it to g_joystick_info</code>. Can you guess the bug yet? :) If not, here's the declaration of the global arrays: DinputDeviceData g_direct_input_devices[8]; // ... JoystickInfo g_joystick_info[8]; </code></pre> There's only space for eight DirectInput devices in the array! 8> Instance : LED Controller</code> was the ninth one, overwriting lots of important other data in the process, including timer handles and the actual DirectInput instance pointer. But it gets worse: The game uses DirectInput for game controllers only. Copying the device info out of lpDevice</code> is entirely pointless for other types of devices. Just moving the DIDEVTYPE_JOYSTICK</code> check up would have hidden the bug for basically all setups, since you'd have to have more than 8 game controllers connected for the game to write out of bounds. Actually, there would've been an even simpler workaround: EnumDevices</code> allows passing a DIDEVTYPE</code> as a filter: g_dinput_instance->lpVtbl->EnumDevices( g_dinput_instance, DIDEVTYPE_JOYSTICK, dinput_enumdevices_callback, 0, DIEDFL_ATTACHEDONLY); // ^^^^^^^^^^^^^^^^^^ </code></pre> This would make DirectInput call the callback for game controllers only. Without it, all devices, whether they are keyboards, mice, or actually any HID devices, are enumerated. (I've checked the DirectX 5 SDK docs, and even there it mentions the HID device support.) This includes the vendor-defined devices of my mouse and its emulated keyboard (for macros), and of course the motherboard's LED controller. The moral of the story? Always check your bounds, kids! You'll never know if some weirdo comes along and plugs in a dozen game controllers to their PC. :^) The fix #</a></h2> Over on GitHub</a> I've pushed a minimal patch as a classic DLL shim. With the provided dinput.dll</code> in the game directory, the game will load that instead of the system one. DirectInput has only one relevant exported function that we need to shim: DirectInputCreateA</code>. The rest of the API is implemented via COM interfaces, for which we can modify the respective vtables as needed. I've implemented two fixes in the shim: Inject the DIDEVTYPE_JOYSTICK</code> filter in the call to EnumDevices</code> to only return joysticks/game controllers.</li> Cancel enumeration once 8 joysticks have been found.</li> </ol> For fun, I've also tried to minimize the size of the shim DLL -- the final binary weighs in at 2 KiB. These are the reasonable settings I changed: Compile with opt-level = "z"</code> to optimize for minimum size. (though the code is so low-level that it's effectively the same as opt-level = 3</code>)</li> #[no_std]</code> to avoid linking the Rust standard library.</li> codegen-units = 1</code> and lto = true</code> to enable whole-program optimization.</li> panic = "immediate-abort"</code> to remove all unnecessary panic handling code; an unwrap will immediately abort the process.</li> </ul> And these are the cursed ones: /NODEFAULTLIB</code> to not link against any MSVC runtime library; added my own minimal DllMain</code>.</li> /FORCE:UNRESOLVED</code> to ignore the missing symbols for _aullrem</code>, _aulldiv</code>, and _fltused</code>. We aren't using any of these, but the LLVM target still seems to insist on linking them in.</li> /FILEALIGN:512</code> to force the linker to use the minimum supported PE section alignment in the file.</li> /MERGE:.rdata=.text</code> merges the read-only data section into the code section.</li> Prevent zero-initialization of the system directory path by using MaybeUninit</code>.</li> Storing globals in static mut</code> just like the original game does. Since the fix is specific to this game I can do these "global" assumptions here :^) Ensure all globals are zero-initialized so the .data</code> section is 0 bytes in the binary.</li> </ul> </li> .unwrap_unchecked()</code> to avoid any extra branches where they aren't needed.</li> /DEBUG:NONE</code> to not generate debug information, and not store a .pdb</code> path in the binary.</li> </ul> </blockquote> Furthermore, I switched to rust-lld.exe</code> as the linker, as it's fine with setting /SUBSYSTEM:WINDOWS,4.0"</code> and /OSVERSION:4.0</code> without complaining. :) Since there is no linked runtime code at all, the resulting binary should work on any 32-bit Windows version, even without Rust9x</a>. I've tested it on Windows 7 and Windows 98 SE. Feel free to grab the compiled DLL from the releases page</a>. Except for True Color rendering, which seems to be broken</a>, no matter the system, graphics card, or game version? Investigating that is left as a mystery for another day. ↩</a> </li> </ol> </section>

Compiling Rust binaries for Windows 98 SE and more: a journey

2020-05-26T00:00:00+00:00

Discussion on /r/rust</a>, HN</a>, Rust user forum</a>

tl;dr: It actually works, mostly! See the conclusion</a> down below.

Did you know that Rust</a> has a Tier 2 target</a> called i586-pc-windows-msvc</code>? I didn't either, until a few days ago. This target disables SSE2 support and only emits instructions available on the original Intel Pentium</a> from 1993.

So, for fun, I wanted to try compiling a binary that works on similarly old systems. My retro Windows of choice is Windows 98 Second Edition, so that is what I have settled for as the initial target for this project.

Some inspiration also came from C# running on Windows 3.11</a>.

Prerequisites #</a></h2> Visual C++ Toolset #</a></h3> After a quick search online it seems that the Visual C++ 2005 toolset is the last one that officially supports building for Windows 98. A quick Windows 10 VM and Visual Studio installation later, I've copied the whole Microsoft Visual Studio 8</code> folder over to my host machine, knowing from previous endeavours that the CLI tools in Microsoft's C/C++ toolset are pretty much portable, as long as the environment variables are set correctly. The toolset includes a handful of batch files like vsvars32.bat</code>, setting the proper paths and variables automatically. I've copied it and altered all the paths to point to the correct locations on my host machine. Rust #</a></h3> Since I was sure that some tinkering with rustc</code> and/or the standard library will be necessary, I've checked out the Rust repo. Some scoop install python</code>, setting the correct host and target in the config.toml</code>, and python x.py build -i --stage 1 src/libstd</code> later, Rust and all the dependencies began compiling! After 26 Minutes and 18 Gigabytes the stage 1 compiler and standard library for x86_64-pc-windows-msvc</code> and i586-pc-windows-msvc</code> have been built! Props to the people that wrote the extensive documentation inside of config.toml.example</code> and online</a>, making the build not much harder than your regular ol' Rust crate! In order to use the fresh new toolchain, we have to tell rustup</code> about it: rustup toolchain link win98 D:\RustProjs\rust\build\x86_64-pc-windows-msvc\stage1 </code></pre> Let the tinkering</del> linkering begin #</a></h2> First of all, I've created a new binary crate/project and changed the Hello, world! to Hello, Windows 98!, of course. To make sure that the project always uses our own toolchain, the default has to be overridden: rustup override set win98 </code></pre> After confirming that the toolchain works by building with the default MSVC tooling (cargo run --target i586-pc-windows-msvc</code>), I have tried building again, but this time from within the vsvars32.bat</code> development environment: cmd call vsvars.bat cargo clean cargo build --target i586-pc-windows-msvc </code></pre> But nope! For some reason Rust/Cargo tries to pass in the x86_64-pc-windows-msvc</code> library object files, so link.exe</code> rightfully errors with: fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' </code></pre> I think it has something to do with the full vsvars32.bat</code> config, but I did not feel like debugging it further, so I have tried to use the old linker (and libs) only. Calling link.exe</code> without the vsvars32.bat</code> environment does not output anything and just exits with an error code. In order to configure the MSVC environment just for the linker call, I have created a linker.cmd</code> batch file: @echo off call vsvars32.bat link.exe %* </code></pre> To tell cargo to use another linker, we can add a .cargo/config</code> file: [build] target = "i586-pc-windows-msvc" [target.i586-pc-windows-msvc] linker = 'D:\RustProjs\hello-w98\linker.cmd' # show the linker command line rustflags = ["-Z", "print-link-args"] </code></pre> Now it looks like it has linked the files successfully, but there is no .exe</code> file in sight! It took me an embarassingly large amount of time to get the idea to run the linking command manually: error: linking with `D:\RustProjs\hello-w98\linker.cmd` failed: exit code: 1103 ... = note: Setting environment for using Microsoft Visual Studio 2005 x86 tools. hello_w98.xw46fam95fk1t5e.rcgu.o : fatal error LNK1103: debugging information corrupt; recompile module </code></pre> [current-time seri here] It took me embarassingly long again when retracing the steps while writing this blog post, since I didn't bother checking what caused it to "fail successfully". Batch files don't work like rust expressions after all, so you have to append an exit /B %ERRORLEVEL%</code> line to have the batch file exit with the exit code of the linker... </blockquote> But who needs debugging information anyways? :) [profile.dev] debug = false [profile.release] debug = false </code></pre> It has finally linked successfully, but the executable requires the VC 2005 redistributable, which I have installed on both the Windows 98 SE system and my host computer. The program has stayed stubborn: </a> </div> Even putting the MSVCR80.dll</code> that comes with the tools I've linked the executable with directly into the executable folder did not work! One more option to add to rustflags</code>: rustflags = ["-Z", "print-link-args", "-C", "target-feature=+crt-static", "-C", "link-args=unicows.lib"] </code></pre> This is highly discouraged for regular applications, but so is trying to compile for Windows 98 targets I guess. :) While I was at it, I have also added the Microsoft Layer for Unicode</a>, also known as unicows.lib/dll</code>. This library enables calling the "wide"/W</code> variants of many Windows APIs, which I assumed would be necessary anyways, since Rust supports Unicode of course. Of course I didn't read quite enough on how to actually add the library to a program, but more on unicows</code> later... This executable actually runs fine on my host system now, and in the Windows 98 VM a more descriptive error message appears, one that means that the program is actually trying to run! The message informs us that the entry point KERNEL32.DLL:AddVectoredExceptionHandler</code> could not be found. Looking this function up it seems it was added with Windows XP. It is time to get to work in the standard library! </a> </div>Intermission: KernelEx #</a></h2> KernelEx</a> is a compatibility layer for Windows 9X/ME, allowing these systems to run some modern executables by providing missing system APIs. This works by patching the kernel in-memory via a device driver. I have tried running the executable with KernelEx throughout this journey, but AddVectoredExceptionHandler</code> is not one of the APIs it provides. Browsing through the Rust source #</a></h2> Creating a new target #</a></h3> I have actually done this part directly after setting up the Rust compilation by just searching for i586-pc-windows-msvc</code>. In i586_pc_windows_msvc.rs</code></a> the target is defined by overwriting a few options of the regular i686-pc-windows-msvc</code> target: use crate::spec::TargetResult; pub fn target() -> TargetResult { let mut base = super::i686_pc_windows_msvc::target()?; base.options.cpu = "pentium".to_string(); base.llvm_target = "i586-pc-windows-msvc".to_string(); Ok(base) } </code></pre> Especially of note are the TargetOptions</code></a>, which define lots and lots of interesting target-specific values, like crt_static_default</code> for example, rendering target-feature=+crt-static</code> redundant. The actual mapping of the target name/triplet to the spec file happens here</a>. After copying the spec file as i586-pc-windows-msvclegacy.rs</code>, adding it to the target list and changing the target</code> entry in the config.toml</code> file, the new target is up and ready to be used! I have also added unicows.lib</code> to libstd's build.rs</code></a> file for good measure (still without reading about it): // ... } else if target.contains("windows") { if (target == "i586-pc-windows-msvclegacy") { println!("cargo:rustc-link-lib=unicows"); } println!("cargo:rustc-link-lib=advapi32"); println!("cargo:rustc-link-lib=ws2_32"); println!("cargo:rustc-link-lib=userenv"); } else if target.contains("fuchsia") { // ... </code></pre> Yanking out AddVectoredExceptionHandler</code> #</a></h3> The AddVectoredExceptionHandler</code></a> Windows API function is used by Rust to provide a nicer error experience in case of a stack overflow</a>. However, as seen in other targets, this handling is completely optional. Incidentally the UWP implementation</a> is one of these targets, so we can just replace the regular implementation with that one (and even keep the Handler</code> type, so no further source changes are needed). I wanted to not affect the host Windows target, however, so I have created a copy of the whole libstd/sys/windows</code> folder as libstd/sys/windows_legacy</code>, adding an admittedly wonky compilation condition to libstd/sys/mod.rs</code>: // ... } else if #[cfg(all(windows, not(target_arch = "x86")))] { mod windows; pub use self::windows::*; } else if #[cfg(all(windows, target_arch = "x86"))] { mod windows_legacy; pub use self::windows_legacy::*; } else if #[cfg(target_os = "cloudabi")] { // ... </code></pre> This changes the sys</code> module used for any 32-bit Windows of course, instead of just i586-pc-windows-msvclegacy</code>, but I couldn't find any way to conditionally compile for a specific target triple, since that is not directly exposed as a configuration option. Since my host target is 64-bit, that was good enough™, though. :) All C FFI declarations used for interfacing with Windows are neatly packed in c.rs</code></a>, where I removed the declarations for AddVectoredExceptionHandler</code>, SetThreadStackGuarantee</code> and a few structs needed for those, since the compilation settings in the Rust codebase rightfully deny any unused code. In a "proper" implementation I would maybe expose another target_something</code> configuration option to match against, potentially even down to compatibility info per API per version. After this change and another recompile of the sample application the AddVectoredExceptionHandler</code> error message is gone, only to be replaced by a message about a missing KERNEL32.DLL:RtlCaptureContext</code> export: </a> </div> I've quickly googled to find out whether KernelEx supports this function, and it does! Turning KernelEx on, opening the executable again, and I am greeted by my very first Rust output on Windows 98! </a> </div> Granted, using KernelEx is cheating, but it gave me the confidence that a true legacy Windows compatible executable is within the realms of possibility. The hunt for RtlCaptureContext</code>, part one #</a></h2> As with AddVectoredExceptionHandler</code>, RtlCaptureContext</code></a> was introduced with Windows XP, so we will have to get rid of it. I couldn't find a reference to this function in the Rust source (more on that in part two), so let's get out some reversing tools! Since a Portable Executable (PE)</a> file usually has an .idata</code> section with all the import information, I wanted to validate it with Dependency Walker</a>. That tool froze when loading the test executable for some reason, so I switched to the open-source alternative called Dependencies</a>: </a> </div> So yes, the import is definitely there. The next tool I have utilized was Ghidra</a>, a reverse engineering and code analysis toolset. Ghidra can auto-analyze the binary to find all usages of the imported functions, for example. But, to my surprise, the import is not used at all according to the auto-analysis! So the most sensible thing to do is to open a hex editor, find the string RtlCaptureContext</code> and replacing it with an import name that definitely exists in Windows 98, filling any additional space with \0</code>. I have chosen GetCurrentThread</code> just because it happened to be the import prior to RtlCaptureContext</code>. The program runs to completion without any errors now, yay! But it also doesn't output anything, oops. Even when putting unicows.dll</code> next the executable, it just doesn't output anything. At that point I've tried changing the Hello, Windows 98!</code> implementation to one with byte strings, writing directly to stdout</code>: use std::io::Write; fn main() { let stdout = std::io::stdout(); let mut lock = stdout.lock(); lock.write(b"Hello, Windows 98!").unwrap(); } </code></pre> ... which did not change a thing. [current-time seri here] Yes, I know, anyone with some form of knowledge about the Windows console knows that this was an exercise in futility, as I remember/find out below :) </blockquote> OllyDbg to the rescue #</a></h2> Let's summarize: We are on Windows 98 SE</li> without debugging info/symbols</li> in a release-compiled executable that doesn't output anything</li> </ul> How are we going to debug the problem? We use OllyDbg 1.10</a>, which runs perfectly fine on Windows 98, like in the good ol' times! After firing up Olly and loading the executable, checking that everything works as expected, I've gone back to the import list to find out which kernel function would be a good candidate to set a breakpoint on. WriteFile</code> seemed like a good candidate, so I've reloaded the executable in Olly, right-clicked in the disassembly window, selected Search for → all intermodular calls, found two call to WriteFile</code>, set breakpoints on both, pressed "play" to have the program running until a breakpoint and ... </a> </div> ... it's not called. This means that WriteFile</code> probably wasn't the correct function, or it didn't even try calling it because of something. I've went with the first option first and looked again for other suspicious function imports. None of them seemed related to writing to the console though, so I have tried another way: finding the string the program writes to the console itself! Next to the all intermodular calls context menu entry there is an all referenced strings entry. That search did yield the Hello, Windows 98!</code> string, but it seems that OllyDbg stuggled with the static analysis, and marked the whole area that uses the string as data. Even after helping Olly by explicitly marking it as data and re-analyzing the binary, no additional calls seemed to be found. I've switched back to Ghidra, where the correct function was obvious: WriteConsoleW</code>. Noting the addresses where it is used, I've gone back to OllyDbg to see what it shows at those locations. And there it is, a normal call to WriteConsoleW</code>. How did it not show in the list of intermodular calls? Well... </a> </div> I've sorted the list by the "Destination" column, which shows a wrong function name! Back on track, I've set breakpoints on both of these calls, pressed "go", and: </a> </div> The breakpoint hits, we see our string as a parameter on the stack, and step over the call. OllyDbg has a nice status window that shows the current register values, and also other values helpful for debugging Windows applications, like the GetLastError</code></a> value: </a> </div> ERROR_CALL_NOT_IMPLEMENTED (0x00000078)</code> ... makes sense on Windows 98! At that point I had realized: that the Windows NT console Rust targets is Unicode/UTF-16, so my attempt at writing a byte string directly to stdout</code> was converted to unicode anyways (notice how Olly also shows the string passed in as parameter as UNICODE</code>), and</li> that I have added unicows</code> incorrectly, since WriteConsoleW</code> definitely is one of the supported functions</a>.</li> </ul> Get unicows</code> working #</a></h2> Since the error undoubtedly points to unicows</code> not working correctly, I've finally taken a closer look at the documentation [1]</a> [2]</a> and I've found a nice blog post explaining how it works</a> under the hood. I have removed the old unicows.lib</code> include from both the standard library's build.ts</code> and changed the project's rustflags</code> to include basically exactly what the documentation says: formatted for readability, actual TOML arrays have to be inline [build] target = "i586-pc-windows-msvclegacy" [target.i586-pc-windows-msvclegacy] linker = 'D:\RustProjs\hello-w98\linker.cmd' rustflags = [ "-Z", "print-link-args", "-C", "target-feature=+crt-static", "-C", 'link-args=/nod:kernel32.lib /nod:advapi32.lib /nod:user32.lib /nod:gdi32.lib /nod:shell32.lib /nod:comdlg32.lib /nod:version.lib /nod:mpr.lib /nod:rasapi32.lib /nod:winmm.lib /nod:winspool.lib /nod:vfw32.lib /nod:secur32.lib /nod:oleacc.lib /nod:oledlg.lib /nod:sensapi.lib unicows.lib kernel32.lib advapi32.lib user32.lib gdi32.lib shell32.lib comdlg32.lib version.lib mpr.lib rasapi32.lib winmm.lib winspool.lib vfw32.lib secur32.lib oleacc.lib oledlg.lib sensapi.lib' ] </code></pre> After patching out RtlCaptureContext</code> once again, I was greeted with my first truly Windows 98 SE compatible executable! Sleeping over the results, I've realized that unicows</code> still wasn't included correctly... Get unicows</code> properly working #</a></h2> The next day I've followed my train of thought about the linking process. Looking at the final linker command line: ... "advapi32.lib" "ws2_32.lib" "userenv.lib" "libcmt.lib" "/nod:kernel32.lib" "/nod:advapi32.lib" "/nod:user32.lib" "/nod:gdi32.lib" "/nod:shell32.lib" "/nod:comdlg32.lib" "/nod:version.lib" "/nod:mpr.lib" "/nod:rasapi32.lib" "/nod:winmm.lib" "/nod:winspool.lib" "/nod:vfw32.lib" "/nod:secur32.lib" "/nod:oleacc.lib" "/nod:oledlg.lib" "/nod:sensapi.lib" "unicows.lib" "kernel32.lib" "advapi32.lib" "user32.lib" "gdi32.lib" "shell32.lib" "comdlg32.lib" "version.lib" "mpr.lib" "rasapi32.lib" "winmm.lib" "winspool.lib" "vfw32.lib" "secur32.lib" "oleacc.lib" "oledlg.lib" "sensapi.lib" </code></pre> We can see that "advapi32.lib"</code>, "ws2_32.lib"</code>, "userenv.lib"</code>, and "libcmt.lib"</code> are added before the linker args from the .cargo/config</code>, meaning the respective /nod</code> (/NODEFAULT</code>; disable default import) entries are without effect, and functions imported from these would not be wrapped by unicows</code>, as the linker priority order goes from left to right. So where do these imports come from? I have remembered seeing them in the build.rs</code></a> of the standard library. Now to find out how they get there. [current seri here] Starting from here, all the Rust source code links will point to the tree at the exact commit I was at when working on this, since some of the features (e.g. #70093</a>) are newer than the 1.43.1 that is current at the time of writing. </blockquote> After a bit of searching I have found librustc_codegen_ssa/back/link.rs</code>, with linker_with_args</code></a> looking promising! In fact, the called link_local_crate_native_libs_and_dependent_crate_libs</code></a> and add_upstream_native_libraries</code></a> look even more promising. To make sure this is the place that actually adds the libraries to the linker command line, I have just added a println!</code> in the for</code> loop at line 1935: println!("lib: {}: {:?}", name, lib.kind); </code></pre> Seems to be the right place! The call to add_upstream_native_libraries</code> is actually wrapped in a condition checking for a compiler debugging (-Z</code>) option, allowing us to deactivate the addition of these libraries: if sess.opts.debugging_opts.link_native_libraries { add_upstream_native_libraries(cmd, sess, codegen_results, crate_type); } </code></pre> This means adding -Z link_native_libraries=no</code> to the ever-growing list of rustflags</code> should do the trick. Additionally, I have added the libraries required by libstd</code> to the end of the linker args, after unicows</code>: rustflags = [ "-Z", "print-link-args", "-Z", "link_native_libraries=no", "-C", "target-feature=+crt-static", "-C", 'link-args=/nod:kernel32.lib /nod:advapi32.lib /nod:user32.lib /nod:gdi32.lib /nod:shell32.lib /nod:comdlg32.lib /nod:version.lib /nod:mpr.lib /nod:rasapi32.lib /nod:winmm.lib /nod:winspool.lib /nod:vfw32.lib /nod:secur32.lib /nod:oleacc.lib /nod:oledlg.lib /nod:sensapi.lib unicows.lib kernel32.lib advapi32.lib user32.lib gdi32.lib shell32.lib comdlg32.lib version.lib mpr.lib rasapi32.lib winmm.lib winspool.lib vfw32.lib secur32.lib oleacc.lib oledlg.lib sensapi.lib ws2_32.lib userenv.lib libcmt.lib' ] </code></pre> Now the linker command line looks correct and all wrapped libraries should be properly wrapped by unicows</code>! link_native_libraries=no</code> is not a perfect solution, but good enough for now. The hunt for RtlCaptureContext</code>, part two #</a></h2> Until this point, each and every new executable needs to be edited to "remove" the RtlCaptureContext</code> import that is still added somehow. In order to find the source, the tool dumpbin</code>, part of the MSVC toolset, comes to help. First I've confirmed that RtlCaptureContext</code> is actually imported: dumpin /imports hello-w98.exe </code></pre> Then I've gone through all libraries listed in the linker call, in order, to find the one that mentions RtlCaptureContext</code> somewhere in its defined symbols. Of course libstd</code> is the one: dumpbin /symbols "D:\RustProjs\rust\build\x86_64-pc-windows-msvc\stage1\lib\rustlib\i586-pc-windows-msvclegacy\lib\libstd-ca1f5c4034a86a91.rlib" | rg Rtl 239 00000000 UNDEF notype External | _RtlCaptureContext@4 </code></pre> Let's open the file in Ghidra, which detects it as having 32 subfiles (first time I've seen such a thing, interesting!): </div> There is probably a better way to do this, but I have opened them one by one until I found the one importing RtlCaptureContext</code>. In the end it was the one starting with 5pja0</code>, and the function calling our target was backtrace::backtrace::trace_unsynchronized</code>. Doh, libstd</code> of course has dependencies that are not part of the rustc tree! And there</a> is the call, finally. Searching for backtrace</code> in the project reveals that there is a compilation option in config.toml</code> that allows turning off backtraces: [rust] # Whether or not `panic!`s generate backtraces (RUST_BACKTRACE) backtrace = false </code></pre> So I have turned backtraces off, recompiled everything, checked the imports and RtlCaptureContext</code> 🦀 is 🦀 gone 🦀! The executable seems to be fully compatible now, without modifications, with Windows 98 SE, at least with this very limited subset of features needed for displaying Hello, Windows 98!</code>. Sidenote: Disabling backtrace support reduced the binary size by about 50KiB, interesting! Windows NT 3.51 and debug symbol support #</a></h2> Since the executable now works on Windows 98 SE, I've tried Windows NT 3.51 next. This worked out of the box (and should be easier anyways since it already supports the W</code> unicode APIs out of the box). It works without further changes because NT 3.51 uses the same PE subsystem version 4</code></a> that NT4 and Windows 98 SE use, both of which are (more or less</a>) supported by the VC2005 linker. </a> </div> It seems that to go even lower, to NT 3.1, a subsystem version of 3.10</code> is needed. The original way</a> of setting that was to use verfix.exe</code> from the NT 3.1 SDK, and looking for modern alternatives I have found that editbin.exe</code> of the VC toolset has the same functionality as well. Just watch out for behavior changes</a> depending on the subsystem version. But wait, the subsystem can be set via the linker options directly... Can the modern VC2019 linker be used? I have added /SUBSYSTEM:CONSOLE,3.10</code> to the linker args and tried again: link.exe</code> just gives a warning, stating that the subsystem version is invalid and will be replaced by the default version (6.0</code>; Vista or later). It seems that the linker only allows supported subsystem versions. What about editbin.exe</code>? editbin /SUBSYSTEM:CONSOLE,3.10 hello-w98.exe</code> gives the same warning but changes the version regardless! Linking with the modern linker against modern libraries causes it to import unavailable APIs again (probably from the modern MSVCRT), so the way to go is to still load the old vsvars32.bat</code> environment, but call the modern linker via its full path. And, by using the modern linker, there are now no problems loading the debugging information anymore either! Conclusion #</a></h2> With relatively small changes to the standard library and compilation settings, and by using old linker libraries, we can make simple applications work on legacy Windows versions already. It's debatable of how much use all of this is, but the journey was fun nonetheless! If someone is interested in bringing this further, here are some of the open TODOs and ideas I've gathered while working on this: Go through src\libstd\sys\windows\c.rs</code></a> and check/rewrite ALL the APIs in a legacy-compatible way I've thought about maybe adding additional configuration options</a>, one for each Windows version or API set, allowing the standard library to target any API level specifically. This could be done here</a>, for example.</li> Note that the current Microsoft docs on the Windows API do not contain information about API support for versions older than Windows 2000. For that you will need an old MSDN Library as reference.</li> </ul> </li> Implement an ANSI/Codepage based version of OsStr</code>/OsString</code> for Windows 9x systems, removing the need for unicows</code></li> Minimize configuration needed (esp. when using unicows</code>) Ideally unicows</code> would not be needed anyways, so all of the tricks of disabling the addition of native libs could be skipped</li> If unicows</code> should stay supported (or toggleable), add it to the linker args generation logic in rustc</li> </ul> </li> Get backtrace</code>s working again, if possible</li> Get dynamic MSVCRT linking working</li> Try out and test other VC toolsets and Windows versions to see how low you can go—it doesn't seem like anything should prevent going down to Windows 95. Win32s</a> seems unlikely though.</li> </ul> You can find the rustc</code> changes I've made over on GitHub in the windows-legacy-poc</code> branch</a>, if you're at all interested! My config.toml</code> basically looks like this: [build] build = "x86_64-pc-windows-msvc" target = ["i586-pc-windows-msvclegacy"] [rust] backtrace = false </code></pre> Also see the blog's footer for my contact information if you have any comments, questions or suggestions. Thank you for reading!

Obligatory picture #</a></h2>
</a> </div>

Sample program #</a></h3>
Windows NT 3.51 (VM):</p>
This one is missing the network tests as NT 3.51 and earlier never got WinSock 2 support.</p>
</a> </div>
Windows 95 B (real hardware):</p>
</a> </div>
Windows XP (real hardware):</p>
</a> </div>
Windows 11 (real hardware):</p>
</a> </div>

seri.tools

Rust9x update: Rust 1.93.0-beta

Why Castrol Honda Superbike crashes on (most) modern systems

Rust9x update: Rust 1.84.0-beta

Rust9x update: Rust 1.76.0-beta

Rust9x: Compile Rust code for Windows 95, NT and above

Compiling Rust binaries for Windows 98 SE and more: a journey

How IDA 7.2's installer password was found

seri.tools

Rust9x update: Rust 1.93.0-beta

What's new? #</a></h2> Rebased and partially reimplemented all fallback code on-top of Rust 1.93-beta</strong>.</li> target_vendor</code> is on the way to being deprecated. Rust9x now uses target_family = "rust9x"</code>, instead.</li>

Why Castrol Honda Superbike crashes on (most) modern systems

Rust9x update: Rust 1.84.0-beta

Rust9x update: Rust 1.76.0-beta

Rust9x: Compile Rust code for Windows 95, NT and above

Announcing Rust9x (Rust 1.61.0-beta) #</a></h2> </a> </div> Blazingly fast! Y2k compliant! Works everywhere!</em></p> </blockquote>

Compiling Rust binaries for Windows 98 SE and more: a journey

OllyDbg to the rescue #</a></h2> Let's summarize:</p> We are on Windows 98 SE</li> without debugging info/symbols</li>

How IDA 7.2's installer password was found