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

61–70 of 179 posts

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

#61

Post by i_don_t_know »

kazinator wrote: post #22

> Anyway, my colleague found that there was one program that needed to allocate around 64KB of memory on the stack and initialize it. The standard way of doing this is to perform a stack probe to ensure that 64KB of memory is available, then subtracting 65536 from the stack pointer, and then initializing the memory in a small, tight loop. Actually, the standard way of allocating 64 kB of memory on the stack is to jus…

IIRC you have to probe every page of the stack on Windows. You cannot just subtract a value from ESP/RSP. If you don't probe every page in order, you get a page fault or some other exception (I don't remember which one).

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

#62

Post by bathtub365 »

urbandw311er wrote: post #49
Taniwha wrote: post #26

Earlier quoted context omitted.

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

In all of the software you’ve written, are you aware of how many on-screen pixels you’ve overdrawn?

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

#63

Post by ashdnazg »

I worked on a transpiler from Nand2tetris assembly to WebAssembly, and had some really annoying memory corruption bug that I just couldn't solve.

That is, until I checked the program I used for testing (which I didn't write), and found the following code:

  dealloc(this)
  return this->field
With the original allocator, this worked fine, since the deallocation didn't touch the memory.

My allocator, however, overwrote the field during the deallocation with bookkeeping stuff, which meant the returned value was not what the programmer intended and after a short while the program crashed.

Unlike TFA, I had the luxury of just fixing the test program.

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

#64

Post by account42 »

jcul wrote: post #55
somenameforme wrote: post #47

Earlier quoted context omitted.

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?

I've seen a lot of code that just assumes fread / fwrite succeeded without bothering to check the return value... But in this case if the code was calling fread 65536 times in a loop and getting 64KiB each time it wouldn't be good either! Sounds like the parent comment had to fix this with the internal cache thing to speed up the small freads. I think they meant the easy fix would have been swapping the args in the o…

There are no small freads in the story, whatever implements those freads supposedly split them up into many calls. But that sound more like a problem of that implementation than the fread callers as size == 1 is correct when you are reading a bag of bytes.

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

#65

Post by account42 »

DonHopkins wrote: post #56
somenameforme wrote: post #47

Earlier quoted context omitted.

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?

The type of programmer who swaps the args to fread tends to be the type of programmer who doesn't bother to check the return value, fortunately. Edit: mort96: So did you check the return value or not?

But the args aren't necessarily swapped just because they end up in a slow case in some implementation.

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

#66

Post by SyzygyRhythm »

Cthulhu_ wrote: post #40
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.

It feels like graphics drivers do / did this a lot too. At the very least they make specific optimizations for specific games, probably by tweaking settings and features that the game developers didn't optimize properly themselves.

There are many, many, cases like this, including correctness fixes. One recent example I remember had a shader that computed: x = a / b * b

The optimizer was allowed, but not obligated, to transform that into: x = a

However, in this case, b was sometimes 0. And if so, the unoptimized version computed: x = a / 0 * 0 = Inf * 0 = NaN

So badness ensued if the that particular path didn't get optimized, which could happen under various circumstances. We had to add some code to ensure that transformation always happened on that game.

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

#67

Post by account42 »

kalleboo wrote: post #52
Cthulhu_ wrote: post #40

Earlier quoted context omitted.

It feels like graphics drivers do / did this a lot too. At the very least they make specific optimizations for specific games, probably by tweaking settings and features that the game developers didn't optimize properly themselves.

Famously if you renamed Quake 3 to "Quack" 3, it would slow down on the ATI Radeon 8500 https://web.archive.org/web/20091016055550/https://hardocp.c...

That's a case of the driver cheating but there are also lots of cases where the game is just full of bugs that the driver has to work around in order to not be blamed for them.

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

#68

Post by wazoox »

ashdnazg wrote: post #63

I worked on a transpiler from Nand2tetris assembly to WebAssembly, and had some really annoying memory corruption bug that I just couldn't solve. That is, until I checked the program I used for testing (which I didn't write), and found the following code: dealloc(this) return this->field With the original allocator, this worked fine, since the deallocation didn't touch the memory. My allocator, however, overwrote the…

IIRC, one of the similar old story from Raymond Chen is about SimCity 2000, that did a similar trick (free memory, then start immediately using it) that worked just fine under DOS, but was a big no-no starting with Windows 95. The game was so common that Windows had to include a special rule to make it run...

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

#69

Post by micampe »

Someone wrote: post #54
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…

> Which basically expanded back in the day to 65k reads of 1 byte for several MB file. Each fread translated to 65k reads of ReadFile Windows API What software did that that badly? If the code asks for (up to) 65,536 single byte items, why would you split that into 65,536 calls? Also, that change changes behavior. The old call could read anything from zero to 65,536 bytes, the new one only can read zero or 65,536 byt…

A long time ago I worked with someone who read 1 byte at a time from a socket because they insisted data was cached so the kernel was going to batch it magically somehow. It took me days to convince them to measure it.

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

#70

Post by account42 »

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

It's definitely Nvidia's problem if this breaks something. Nothing in the D3D/OpenGL specs says that you can (not) use certain executable names.
Post reply on HN