The time the x86 emulator team found code so bad they fixed it during emulation
paulmooreparks
92 points
11 comments
June 16, 2026
Related Discussions
Found 5 related stories in 110.0ms across 10,715 title embeddings via pgvector HNSW
- 80386 microcode disassembled nand2mario · 237 pts · May 23, 2026 · 54% similar
- The RCE that AMD wouldn't fix MrBruh · 250 pts · June 11, 2026 · 54% similar
- Continuing the story of early DOS development oldnetguy · 12 pts · April 28, 2026 · 53% similar
- Never Bet Against x86 raphinou · 65 pts · March 06, 2026 · 52% similar
- 8087 Emulation on 8086 Systems ingve · 65 pts · April 24, 2026 · 51% similar
Discussion Highlights (7 comments)
hodgehog11
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.
classichasclass
Betting Alpha was the native architecture in question. It seemed to have the best support.
m1r
Couldn't they just turn the optimization off for this loop?
notorandit
> they fixed it during emulation It means the fix was applied to run during the emulation loop execution, not that the fix was found and applied while the emulation loop was running. Which would have made it an emulation code escape.
jeffbee
People from Transmeta told me stories about how their translators were full of special case optimizations to fix horrors they discovered in Microsoft Windows itself.
yieldcrv
> All in all, it took this program 256 kilobytes of code to initialize 64 kilobytes of data. solidity sweating profusely
dlcarrier
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.