Why did fonts in Windows 1.01's Write application look so poor?

Question

In Windows 1.01 Write, the fonts were kind of blocky:

Here's what the same text looked like in a modern word processor:

Even the terminal had smoother text than Windows 1.01:

Why did Windows 1.01 Write had such blocky text?

Answer 1

Your images appear to have been generated via emulation, with heavy anti-aliasing that doesn't show what it looked like in reality.

Here's Windows 3.1 Write in native VGA resolution without any image processing, captured from PC-Task running on an Amiga 1200:-

Here's part of that screen magnified so you can see the individual pixels:-

Finally, here's what it looks like running on a real PC and displayed on a VGA CRT monitor (HP Pavilion M50):-

You can still see the individual pixels, but the CRT has blurred them slightly. At this magnification you can also see the CRT shadow mask and even some of the individual RGB phosphor dots. A higher magnification would show that all the 'white' dots are actually triads of red, green, and blue.

Due to the natural blurring effect of the CRT display, there is no need to anti-alias the fonts. Anti-aliasing at this resolution can make the text look a bit smoother, but it also reduces the apparent sharpness and can reduce its readability.

Here's your screenshot magnified so you see the individual pixels. This text looks very blurry due to heavy anti-aliasing, making it harder to read than the original 'bitty' bitmap font.

Answer 2

Because those were low-resolution bitmap fonts.

In Windows 1.01, most fonts were monochrome bitmap fonts, and not particularly high-resolution at that. (There were CONTINUOUSSCALING ‘plotter’ fonts included as well, but Write could not make use of those.) Additionally, Windows did not render any fonts with antialiasing before Windows 95 (with the Microsoft Plus add-on).

In the asker’s screenshot, Windows is running at (I am guessing) a pretty feeble (by today’s standards) 640×350 resolution with 16 colours, as offered by the EGA adapter. This was the highest resolution one could get with that Windows version (with built-in drivers at least). Your emulator stretches that small resolution to make it more legible on your screen, and additionally stretches the screen vertically to reproduce the 4:3 aspect ratio of computer monitors of the time. The bilinear interpolation algorithm employed by the scaling process produces a blur effect. This is how the picture looks like without any scaling:

You may notice the fonts look pretty squished vertically compared to how fonts look in Windows today. This was, in fact, deliberate: like your emulator, Microsoft also took screen aspect ratio into account, and provided separate versions of the ‘Helv’ (mislabelled above as ‘Arial’, later known as MS Sans Serif), ‘Tms Rmn’ (mislabelled as ‘Times New Roman’, later known as MS Serif) and Courier fonts for different pixel aspect ratios. Most PC screen modes of the time had non-square pixels, and not just because a pixel is not a little square.

At 640×350, the amount of screen space taken by one pixel is ~1.6‰ horizontally and ~2.9‰ vertically; for comparison, for a 720p (1280×720) screen those numbers are ~0.8‰ horizontally and ~1.4‰ vertically, making it about twice the granularity in each dimension. To be able to fit more text on a single screen at resolutions this low, fonts had to be frugal with pixel use, with some characters like ‘i’ or ‘l’ being as few as three pixels wide. If we zoom in on the pixel grid, we can see the amount of detail such resolution is able to afford:

With so few pixels to spare, some compromises had to be made, and because the display could only use 16 colours, we could forget about using shades of gray to approximate strokes not aligning with the pixel grid. To save disk space, Windows 1 didn’t even include higher-resolution sizes or bold variants of those fonts: they were rendered synthetically by drawing each pixel multiple times or drawing a glyph a second time at an offset. The screenshot demonstrates the latter with the ‘Helv’ font: look how the vertical stroke of the ‘T’ glyph is thicker than the horizontal one. Though some of the imperfections can be attributed simply to the fact that the fonts weren’t even all that well-drawn for their native pixel size: look for example at Courier’s ‘e’ glyph.

Compare that to the screenshot of modern Windows, where, thanks to a much higher resolution and sophisticated subpixel antialiasing, without zooming in we can barely notice that a rectangular grid of pixels cannot actually represent the curved strokes of the letterforms perfectly:

Where in Windows 1.01 the glyph height of the first line written in ‘Times New Roman’ was barely 8 pixels, here the actual Times New Roman takes 15 pixels, leaving more room for subtle details like serifs.

But text mode also uses bitmap fonts. Why does it then look better? MDA/CGA text mode renders an 80×25 grid of characters from an 8×16 font, embedded (usually) inside 9×16 character cells, for a total resolution of 720×400 pixels. Because each character can use up the entire 8×16 area of the character cell, it has more room for strokes that are thicker relative to details like curvature and serifs, which makes the scaling artefacts less pronounced, especially with interpolation:

Gray is the pixel grid, green is the character cell grid. Still a bit blurry, but much more pleasant to look at.

Answer 3

It isn't. The examples are comparing apples and oranges. As they cover three different situations/usages:

Bitmap Emulation vs. Native Usage vs. Character Emulation

The results are based on what hardware is emulated, in what mode and _on which modern device.

Lets for simplicity assume the modern screen is a rather average, if not lower end 2560 by 1440.

1. Native Handling (Example #2)

   Here the full native resolution will be used by windows and fonts are projected using this. So using a font (and scaling) that gives like 40 text lines on a screen will allow each letter to be rendered in a character cell of 36 pixel. Quite some room for fine detailed rendering.

2. Character Adaptor Emulation (Example #3)

   Here the emulator provides a classic character based display adaptor, like MDA or CGA (or any other offering character mode). To display its 80 by 25 character on a full screen it gets a 32 by 57 pixel character cell. Quite more than the 8 by 8 of a CGA or 9 by 14 of a MDA.

   Now, the emulation could simply scale the genuine font. Due the way higher resolution users would perceive this as, well, blocky :)) So the emulation goes ahead and uses a native scalable font, modelled after the adaptors font, instead, giving a quite smooth appearance.

3. Bitmap Emulation (Example#1)

   Here the emulation does not work font based, as before, but pixel based. Windows 1 sees for example an EGA graphics card with its 640 by 350 pixel resolution and draws as fine as it can do. With a font/scaling size set to reach for example 30 text lines, this comes down to 12 pixel height per line. Nice for back then.

   The emulation has no idea what Windows 1 is displaying here. All the emulation sees is the same bitmap buffer which it needs to display. Scaled to the modern screen each emulated pixel gets displayed as 4 by 4 native pixel. There is no way an emulation can smooth that out the same way as a native implementation can, as it has no knowledge what the pixels are about (*1,*2).

   On the other hand is does add a little smoothing on each pixel (*3), which already helps to reduce blockyness, but since this can only be done on a pixel by pixel base it will not remove any blockyness due the original rendering (*4). It's more like emulating the analogue nature of classic displays, where each and every pixel was kinda smooth.

   All it can do is turn them into rather sharp (aka blocky) 4 by 4 blocks.

Bottom Line: what you see is simply the effect of emulating old output methods on modern hardware in a best possible effort.

---

Now, if one would run the Win 1 Write in a more modern Windows (*5), the display would be quite smooth as ist would render with the native resolution supported by this version.

A similar effect might be possible by adding a higher resolution screen driver to Win 1 (*6).

---

*1 - Same way anti-aliasing of a graphics card does need model information to work.

*2 - Well, if the emulation does not just emulate the PC Hardware, but also hooks the loaded windows, it could guess what some output is about. That more like letting an older program run on a newer Windows/screen. It will be not only imperfect, but also result in tons of potential incompatibilities.

*3 - When looking close at the first picture it's visible that the emulation tries to smooth out the bitmap. Two adjacent white pixel meet in in white, while black do the same in black. But a white to black border in either direction is turned into a gray scale ramp. Nicely visible at the i-dot.

Since pixels are the only data elements the emulation has to work with, all smoothing is done around each pixel in conjunction with its 8 neighbors.

*4 - Without it would look incredible blocky on today's super sharp digital screens. Maybe the emulation you're using has some way to switch the improvements off :)

*5 - A Win version still offering the 16 bit interface - so essentially at least up to Win95.

*6 - Within limits as fonts weren't scalable as now. So adding some new fonts as well might be necessary to use the higher resolution.

Answer 4

Windows 1.0’s Write application doesn’t care about how the text it displays is rendered — it relies on its operating environment to display it. As such, it supports smooth fonts, even though Windows 1.0 itself (and Windows 2.0 etc.) doesn’t.

Thus if you run the Write executable in a more modern environment, you’ll see it display anti-aliased text (I don’t have a setup right now to provide a screenshot). This might be difficult with the original Windows 1.0 Write binary, but you can perform a similar test with the Windows 3.0 binary.

This is how Windows 95 with Microsoft Plus! was able to provide anti-aliasing for most applications running on it: the font rendering was changed, and all applications which relied on Windows to display fonts for them used the new font display code.