Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The time the x86 emulator team found code so bad they fixed it during emulation

devblogs.microsoft.com

Post reply on HN
Print view View original

41–50 of 179 posts

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#41

Post by AHTERIX5000 »

hodgehog11 wrote: post #2

I think we're starting to see more of this sort of thing happening now with Proton and Wine gaining prominence in the Linux community. Some games (Elden Ring comes to mind) have bad enough PC ports when they come out that the compatibility layer can incorporate a hotfix to improve performance, while users of the software on the original platform still had to suffer.

Yep, someone needs to do the same workarounds Windows drivers do but on Linux and the translation layer is a good spot for them, look at https://github.com/HansKristian-Work/vkd3d-proton/blob/938d7... for example

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#43

Post by Klayy »

tester756 wrote: post #33
murderfs wrote: post #23

Earlier quoted context omitted.

If you go back 5 years, everyone was using Quake 3 Arena as the benchmark. ATI got in some hot water because if you renamed quake3.exe to quack3.exe, your FPS would drop by 15%, because they were silently reducing quality to juice their benchmark numbers.

5 or 50? I'd say 5 years ago it was already Witcher 3, Cyberpunk 2077, GTA 5, etc.

5 years before hl2

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#44

Post by easyThrowaway »

dlcarrier wrote: post #11

SimCity had a read-after-free bug that Microsoft patched in Windows 95. That was a lot easier for customers than having Maxis fix it, which could have required exchanging copies of the game.

The most interesting part is that IIRC they shipped the entire Windows 3.11 memory allocator to make it work.

I have very little understanding on how allocation works at OS level, but I'm surprised there are no wrappers like dgVoodoo or dxWrapper specifically for this kind of issues. There are quite a bunch of old Windows games (Need for Speed 1-4 for a start) that refuse to run on modern OSes due to rather...bold memory management strategies.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#45

Post by hurtigioll »

tester756 wrote: post #34
limflick wrote: post #32

Earlier quoted context omitted.

Couldn't that also cause glitches since optimizations meant for HL2 might not work for, say San Andreas? I understand some optimizations might be universal but I can't help but think about unexpected behavior.

Who's problem is this? Nvidia probably doesnt officially say anything about this and 99.9% of people do not rename process name

of course they do.

nvidia even has an official api for a game to identify itself so they dont need to look at executable name

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#46

Post by zoenolan »

Gigachad wrote: post #16
hodgehog11 wrote: post #2

I think we're starting to see more of this sort of thing happening now with Proton and Wine gaining prominence in the Linux community. Some games (Elden Ring comes to mind) have bad enough PC ports when they come out that the compatibility layer can incorporate a hotfix to improve performance, while users of the software on the original platform still had to suffer.

Fairly sure GPU drivers do the same thing where they include a ton of per game tweaks to make them run faster. It does feel like a fragile way of doing things where an external component that should be agnostic to the software running ends up including a handful of junk trying to fix stuff that should have been fixed by the consumer of the driver.

The big one I remember was many applications, not just games assuming the buffer swap was performed by a blit into the display buffer, not an framebuffer pointer update. They relied on the previous frames data still being in the back buffer. For those applications you were forced to blit the buffer, not swap the pointer and take a performance hit.

I also remember a media player being called out by name in the code for doing invalid operations, needing a work around and code to detect it was running just to function.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#47

Post by somenameforme »

psanchez wrote: post #20

This reminds me of a story from 15 years ago, where I was developing a technology to download games on demand by hooking into the OS calls. There was a particular game that was superslow when this tech was applied. Original game loading took around 15-20 seconds, whereas once the tech was applied it took easily 3-5 min, even with all data already downloaded. When I started digging into it, I realized the reason was t…

Doesn't that break anything relying on the return value? fread gives you the number of objects read as a return. So I think a pretty typical thing would be to fread and then parse that number of characters, and that'd just break?

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#48

Post by limflick »

tester756 wrote: post #34
limflick wrote: post #32

Earlier quoted context omitted.

Couldn't that also cause glitches since optimizations meant for HL2 might not work for, say San Andreas? I understand some optimizations might be universal but I can't help but think about unexpected behavior.

Who's problem is this? Nvidia probably doesnt officially say anything about this and 99.9% of people do not rename process name

Phrasing, I wasn't blaming anyone, just curious about the technicalities.

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#49

Post by urbandw311er »

Taniwha wrote: post #26
psanchez wrote: post #20

This reminds me of a story from 15 years ago, where I was developing a technology to download games on demand by hooking into the OS calls. There was a particular game that was superslow when this tech was applied. Original game loading took around 15-20 seconds, whereas once the tech was applied it took easily 3-5 min, even with all data already downloaded. When I started digging into it, I realized the reason was t…

I used to be a graphics card/chip architect for macs in the early/mid 90s - our chips were the fastest, but some programs were resistant because they did stupid stuff: pagemaker invalidated the font cache every time it went thru its main loop, quark with ATM did an n*2 thing every time it wrote text etc etc. We had special hardware to accelerate text drawing and it did nothing because the software pissed it away. We…

This is a horrible and yet not unexpected insight into the internals of Excel

Re: The time the x86 emulator team found code so bad they fixed it during emulation

#50

Post by rincebrain »

easyThrowaway wrote: post #44
dlcarrier wrote: post #11

SimCity had a read-after-free bug that Microsoft patched in Windows 95. That was a lot easier for customers than having Maxis fix it, which could have required exchanging copies of the game.

The most interesting part is that IIRC they shipped the entire Windows 3.11 memory allocator to make it work. I have very little understanding on how allocation works at OS level, but I'm surprised there are no wrappers like dgVoodoo or dxWrapper specifically for this kind of issues. There are quite a bunch of old Windows games (Need for Speed 1-4 for a start) that refuse to run on modern OSes due to rather...bold me…

Apparently the recollection of the fix was that they deferred actually freeing memory for a while if they detected it was SimCity running. [1]

[1] - https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

Post reply on HN