This reminded me of work I did for Proton/Wine a few years back: finding a buffer overflow in the Rockstar Games Launcher installer NSIS script, having to implement an ancient deprecated Windows named pipe mode that RGL uses, reverse-engineering the VRAM display/detection in GTA IV…<p>If anyone wants to do this kind of reverse-engineering for a living, we’re hiring at CodeWeavers: <a href="https://www.codeweavers.com/about/jobs" rel="nofollow">https://www.codeweavers.com/about/jobs</a>
Anyone else see the title and the site domain think, "Oh, was Salt Lake an obscure Intel architecture that was <i>too</i> stable and caused errors in programs because there weren't enough CPU errors during startup?"<p>The actual debugging war story (decompiling an old InstallShield installer and detailed examinations of a routine that presumed that 64MB was more VRAM that anyone would _ever_ need) was quite good too.
I love this super interesting debugging war story, on such a pointless target. There's something delicious about putting so much effort and coming to such a satisfying conclusion when working on such an obscure game.
I'm intrigued why MS decided to have GlobalMemoryStatus return a negative number if there is more than 4GB, rather than returning the maximum value.
If I was more skilled with a debugger, I'd try to dig into why one of my favorite childhood games (an arcade WWII dogfighter game) runs just fine on Windows for ARM64, EXCEPT resetting inventory between each level, which makes final bosses much less fun, as part of the game is stacking powerups.
This wasn't a problem back in 2002. Back then, you could just leak however much memory you'd need to bring the total down to a positive number.<p><a href="https://web.archive.org/web/20020207000806/https://www.php.net/manual/en/function.leak.php" rel="nofollow">https://web.archive.org/web/20020207000806/https://www.php.n...</a>