Why did Windows 95 keep window coordinates at multiples of 8?
Retro-computing aficionado Gravis noticed that up until Windows 95, horizontal window positions are quantized. “Do you know anything about that?”
It is totally understandable but nonetheless feels weird to me that Windows 95 is considered to be retro-computing.
Okay, so why are window coordinates quantized at multiples of 8?
Because bit block transfers between coordinates that are not multiples of 8 are really annoying.
Consider a packed bit array, with eight bits stored in each byte. And now you want to copy another bit array into it.
| source | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | |||||
| ↓ | ↓ | ↓ | ↓ | ↓ | ↓ | ↓ | ↓ | ↓ | ↓ | ↓ | ↓ | ↓ | ↓ | ↓ | ||||||
| destination | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª | â–ª |
Since computer storage is addressed as bytes, rather than bits, you have to do a lot of bit unpacking, shifting, merging, and re-packing.
But if the offset in the destination is a multiple of eight, then you can move entire bytes across instead of having to do all the bit fiddling. This is a huge performance gain.
You’re probably more used to calling these packed bit arrays “bitmaps”, and bitmaps are really important in graphical environments.
The screen itself is a giant bitmap, and this means that copying data to the screen goes much faster if x-coordinate of the destination resides on a full byte boundary. And the most common x-coordinate is the left edge of a window’s contents (known as its client area).
Applications can request that Windows position their windows so that their client area began at these advantageous coordinates by setting the CS_ style in their window class. And pretty much all applications did this because of the performance benefit it produced.
So what happened after Windows 95 that made this optimization go away?
Oh, the optimization is still there. You can still set the CS_ style today, and the system will honor it.
The thing that changed wasn’t Windows. The thing that changed was your video card.
In the Windows 95 era, predominant graphics cards were the VGA (Video Graphics Array) and EGA (Enhanced Graphics Adapter). Older graphics cards were also supported, such as the CGA (Color Graphics Adapter) and the monochrome HGC (Hercules Graphics Card).
All of these graphics cards had something in common: They used a pixel format where multiple pixels were represented within a single byte,¹ and therefore provided an environment where byte alignment causes certain x-coordinates to become ineligible positions.
Once you upgraded your graphics card and set the color resolution to “256 colors” or higher, every pixel occupies at least a full byte,² so the requirement that the x-coordinate be byte-aligned is vacuously satisfied. Every coordinate is eligible.
Nowadays, all graphics cards use 32-bit color formats, and the requirement that the coordinate be aligned to a byte offset is satisfied by all x-coordinates.³ The multiples of 8 are no longer special.
¹ The VGA also supported 8-bit color, but Windows didn’t use it because of its extremely low resolution.
² The VGA so-called Mode X is an odd case because it is a planar 256-color mode, so even though every pixel occupied a full byte, you were nevertheless better off if coordinates were a multiple of 4. Windows didn’t use Mode X, so that little quirk never really entered the picture.
³ I guess you could force your video card into a 16-color mode and try to relive the world where pixels don’t occupy full bytes, and some x-coordinates perform better than others.
Light
Dark
9 comments
Windows 95 already did not officially support anything less than VGA.
I don’t agree that aligning coordiates to multiples of 4 would be beneficial in unchained 8bpp VGA modes (“Mode X” and derivatives). In these modes, each pixel occupies a full byte, it’s just that you can’t access all the pixels at the same time, but only 0, 4, 8, 12, … or 1, 5, 9, 13, … or 2, 6, 10, 14, … or 3, 7, 11, 15, …. Copying a bitmap to an arbitrary position is thus easily possible: Copy every fourth pixel to the appropriate plane, switch to the next plane, copy the next set of pixels, switch planes again, and so on. Things become slightly more interesting for VRAM-to-VRAM copies, but even that is solveable.
I do agree that the whole point is moot though: The highest-resolution mode you can get this way is something like 360×480, and all “Super VGAs” that could do 640×480 or higher in 256 colors defaulted to a banked (or even fully linear) instead of a planar memory layout.
Relevantly, the VGA 16-colour mode used by Windows used planes, so that each pixel was represented by the same bit in four different bytes, rather than being a linear packing of pixels into nybbles which would have only required even coordinates.
windows 95 in Cga I don’t think so. There have been some attempts to hack it to get it to work but efforts not hugely successful. If windows would even start with the driver its not exactly usable. Ega in win95 at least works with a win 3.1 driver but its not something you could do out of the box with a normal win95 installation but ega 4 bit colour works much the same as vga just at a lower resolution
By way of comparison: GEM doesn’t have a CS_BYTEALIGNCLIENT style, so the demo applications force the client X coordinate to be word-aligned in the WM_SIZED and WM_MOVED handlers — whether or not it’s necessary.
I found out that X386 early on did not even support VGA 16 color mode.
I always wondered what CS_BYTEALIGNCLIENT|CS_BYTEALIGNWINDIW but WS_BORDER would do, but even my Win3.1 had SVGA so I don’t know.
Hi,
A little bit off-topic, but could anyone please shed some light on why NT 3.51 and NT 4.0 did not care about the IDE drive’s “fixed-bit” being set when partitioning and installing? They install, make and access any partitions on a removable device, but NTs beginning with Windows 2000 “lost” this capability. NT 5.0+ neither can be installed on any of the “non-first” partitions of a removable device, nor can it access any of the non-first partitions of a removable IDE device. It really puzzles me as I just could not/cannot figure out why NT 4.0 and below did/does not care about the “fixed-bit” and what the technical reason is that NT 5.0 and above cannot handle such disks like their predecessors. Maybe explaining this would be a good candidate for a new article? 😉
I don’t have easy access to documents right now, but my guess is that early IDE didn’t foresee removable storage on the interface (or drives weren’t implementing the spec fully yet), so Windows didn’t check/couldn’t trust the drive type. Later versions came out when drive type was a thing that could be reliably tested.