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…
Thanks for the often unrecognized work that goes in creating something like this.
Once in a while I try some of my father old games with my steam deck ('90s game like the OG Colin Mc Rae Rally or the early Need For Speed games)and I'm impressed how they work with basically no issues on current-gen devices.
Anyone else see the title and the site domain think, "Oh, was Salt Lake an obscure Intel architecture that was too stable and caused errors in programs because there weren't enough CPU errors during startup?"
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.
When interpreted as an unsigned integer, it actually corresponds to the maximum value of almost 4 GB (0xFFFFFFFF). Note that the fields are declared as SIZE_T, which is unsigned. (Not sure if they always were.) The installer may be incorrectly assigning the value to a signed integer type.
I think it's worse than that. It returns the max value (2GB) when there is more than 2GB but less than 4GB, but a negative value if there is more than 4GB.
2^32 is 4294967296, or 4 GiB. Back before Windows ran on 64-bit machines, 4 GiB was as big a number as a standard int could represent. Updating it for 64-bit mode would mean breaking 32-bit programs, so "fixing" it isn't necessarily an upgrade.
I was thinking the same. I’m guessing that originally the lack of a bounds check was for efficiency’s sake (save a CPU cycle or two) and they chose not to update it assuming people would use the newer API.
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.
I think it depends on application. For a video game, that’s what you should do. However, that’s not really advisable for a database where broken invariants might lead to corruption.
In open source software where you can throw it over the fence and say "no warranty", perhaps.
In commercial software where your users will say "Y" even when they have 16MB of RAM, have an awful time, waste your money calling your support in that unsupported configuration (and forget to mention it), and leave negative reviews - no, hard blocks make a lot of sense.
Vogons is a great place with lots of experts on vintage software and hardware. Definitely recommend it to anyone interested in either running old stuff or just on history/tidbits/how-things-worked like that post.
mrpippy|2 years ago
If anyone wants to do this kind of reverse-engineering for a living, we’re hiring at CodeWeavers: https://www.codeweavers.com/about/jobs
easyThrowaway|2 years ago
Once in a while I try some of my father old games with my steam deck ('90s game like the OG Colin Mc Rae Rally or the early Need For Speed games)and I'm impressed how they work with basically no issues on current-gen devices.
svieira|2 years ago
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.
aftbit|2 years ago
thayne|2 years ago
layer8|2 years ago
The actual behavior of GlobalMemoryStatus is a bit more complicated, see https://ftp.zx.net.nz/pub/archive/ftp.microsoft.com/MISC/KB/....
Narishma|2 years ago
zamnos|2 years ago
dhosek|2 years ago
johncalvinyoung|2 years ago
Gordonjcp|2 years ago
klyrs|2 years ago
https://web.archive.org/web/20020207000806/https://www.php.n...
bombcar|2 years ago
slaymaker1907|2 years ago
Arainach|2 years ago
In commercial software where your users will say "Y" even when they have 16MB of RAM, have an awful time, waste your money calling your support in that unsupported configuration (and forget to mention it), and leave negative reviews - no, hard blocks make a lot of sense.
mahin|2 years ago
mysterydip|2 years ago
DMell|2 years ago
qingcharles|2 years ago
el_don_almighty|2 years ago