Writing a byte and then reading it back

The always-wonderful Raymond Chen posted a completely-brilliant description of an old bug:

There was a bug that said, "The splash screen for this MS-DOS game is all corrupted if you run it from a compressed volume."

What was the real problem? Well, Chen explains:

• The Windows 95 I/O system assumed that if it wrote a byte, then it could read it back

  The optimization above relied on the property that writing a byte followed by reading the byte produces the byte originally written. But this doesn't work for video memory because of the weird way video memory works. The result was that when the decompression engine tried to read what it thought was the uncompressed data, it was actually asking the video controller to do some strange operations. The result was corrupted decompressed data, and corrupted video data.

• What is the purpose of the bmPlanes member of the BITMAP structure?

  If you have 16 colors, then you need four bits per pixel. You would think that the encoding would be to have the each byte of video memory encode two pixels, one in the bottom four bits and one in the top four. But for technical reasons, the structure of video memory was not that simple.

• Machine Organization I

  In EGA and VGA, the Graphics Controller (GC) manages transfers of data among the video memory, CPU registers and the latches.

• ID3D12Resource::Map method

  your app must honor all restrictions that are associated with such memory

Wow.

There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy