Microsoft's latest Windows update might or might not have improved performance for the company's flagship operating system, but there was a time when its engineers cared about performance. A lot. 

Veteran Microsoft engineer Raymond Chen on Monday hearked back to that time by telling another war story from the glory days of Windows, when a team was working on an x86-32 emulator for an unnamed processor (though it isn't particularly difficult to identify potential candidates).

The emulator used binary translation – native code was generated for the original x86-32 code. Chen explained, "This offered a significant performance improvement over emulation via interpreter. You can imagine that x86-32 is just a bytecode, and the emulator is a JIT compiler."

The team came across a function that needed to allocate 64 KB of memory. Simple enough stuff – check that there is enough memory available, subtract 65536 from the stack pointer, and then initialize the memory in a loop.

Use the comments to correct me, but this sounds like loop rolling, where repetitive code gets condensed into a loop.

However, it appeared that a compiler had … optimized … the code "by unrolling the loop into 65,536 individual 'write byte to memory' instructions, each 4 bytes long."

Perhaps a bit quicker, but goodness – quite the memory hog. "All in all," wrote Chen, "it took this program 256 kilobytes of code to initialize 64 kilobytes of data."

Almost like a glimpse into a future where operating systems don't appear to give two hoots about efficient use of storage. What would that look like?

As for the engineers working on the CPU emulator, Chen said, "This offended the team so much that they added special code to the translator to detect this horrible function and replace it with the equivalent tight loop."

It would be interesting to know what that same team would make of the internals of some Windows binaries today, but it is heartening to know that, at one point, engineers cared about memory efficiency enough to reroll something. Sure, there might, just might, have been a performance hit, but spitting out 256 KB of code just to initialize 64 KB of data?

Naughty. Very naughty. The much younger version of this hack, optimizing the heck out of code to fit within the confines of computers from yesteryear, would have been horrified. ®