SVGA support aside, it will never cease to astound me that you can load Windows 3.x on a modern standards-supporting PC and get basic VGA working out-of-the-box but you cannot do the same on modern Linux/BSD to get a basic software-accelerated VGA framebuffer supported by Xorg/Wayland if you don't have the right drivers installed (and the correct configuration files manually set up).

(the dead xfree86 project was probably the closest attempt to making this "just work" though it had a long way to go; this approach was not preserved in the Xorg fork)

That old Windows 3.1 GUI looks so much more intuitive, efficient, and usable compared to what we've got today.

https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...

What would Win11 even look like on a lower-resolution display such as in TFA?

The Win11 Start Menu is borderline unusable beyond typing in a keyword and praying to the circuits. What happened?

Naive hypothesis: Windows NT and 2k hit a sweet spot, then product managers have been working their magic ever since.

KDE and Gnome are looking more and more appealing over time, despite not changing much. :)

The author mentions the screen being corrupted when a DOS prompt is opened in windowed mode. This can happen because the DOS prompt runs in a separate VM (in V86 mode), and makes calls into the VGA ROM BIOS via INT 10h. The VGA ROM BIOS on this machine is probably a wrapper over VBE; that is, it probably contains IN and OUT instructions that talk to the VBE I/O ports, 0x1CE and 0x1CF. These reads and writes from the DOS VM will, by default, be allowed to reach the physical hardware if they are not virtualized by the VMM.

This is a common problem that authors of Windows 3.x/9x display drivers had to handle, although the specific I/O port numbers to be virtualized vary by graphics adapter. There are samples in the Win95 DDK that show how to use the VMM services Install_IO_Handler and Enable/Disable_Global_Trapping to set up I/O port traps, and VDD_Get_VM_Info from within the trap handler to determine the VM that currently owns the CRTC. This allows the trap handler to reach a decision about whether to allow an I/O to reach the hardware, or to virtualize the access in some way. A good virtualization policy to start with is probably just to drop any writes from non-CRTC-owner VMs. Any additional needed complexity can be added from there.

The Virtual Display Device (VDD) runs as part of the underlying virtual machine manager, and acts somewhat like a multiplexer for the video hardware. If a DOS app is full screen, its commands are directly sent to the ‘real’ VGA adapter; otherwise, they’re emulated by the VDD.

It's interesting to see others (re)discover this architecture, which IMHO was quite ahead of its time, since it predates modern hypervisors with hardware pass-through. The Windows 3.x GUI itself, including its preemptively-multitasked processes, effectively runs as an extended (protected-mode) DOS process inside a VM running DOS, and the hypervisor kernel, VMM32, is what multiplexes between it and other VMs running DOS processes. Thus one part of the display driver sits under GDI and interacts with the "hardware", while the other part in ring 0 virtualises the hardware and multiplexes it with the other VMs.

This would fix it for DOSBox, but that fix would be tied to whichever video adapter it's emulating. I don't want that, I'm trying to make the generic VBE patch work better!

Having written a Win9x VESA framebuffer driver for the Intel GMA950 as well, and added basic acceleration (blitter and fill commands), and encountering basically the same issue, I realised what may be the reason Win9x never came with a generic VESA driver: the VDD needs to know how to save and restore the GPU state, the details of which are obviously vendor-dependent. I did come up with some ideas on how that could be done generically, i.e. emulate/trace the VBIOS and see which ports/MMIOs it touches on each mode switch, but never got around to implementing it.

While on DOSBox I get text mode with lots of corrupted characters, on the Eee PC I get a broken version of the GUI where some of the colours have disappeared.

That looks like the palette registers didn't get saved and restored correctly. Also, the corruption at the top of the screen can be avoided by moving the high-res display plane up by 256K, so as to leave the first 256K of VRAM for the VGA plane and VGA emulation. Fortunately the Intel GMA has a bunch of publicly available documentation (although not for the 900 nor 950, and only for the 810/815 and 965+ but the majority of the registers and commands have not changed) you can refer to for the details.

> it can't even run most up-to-date Linux distros due to its lack of x86_64 support

My Eee is successfully chugging along with 32bit Debian. Firefox is too heavyweight to do much but lag, but mpv works well enough to stream video. But I mostly use it when I'm running behind on a book and basically need a typewriter that can run pandoc, and fewer distractions.

That title was... slightly confusing. That said, I will always feel a sense of awe when I read about how those old, DOS-based versions of Windows worked behind the scenes. Everything is held together by software duct tape, yet somehow it works.

I remember when the ET4000H came out and it was not supported by Windows 3.1 at the time, I had to call MS tech support and they sent me a driver disk that arrived 8 hours later.

Best support I've ever had for a pirated product.

don't know if article's author is watching this, but I told patch's author about this article. https://www.bttr-software.de/forum/board_entry.php?id=22124#...

That is fun, I have an EEEPC 207g, those smaller ones. It still works, but I never thought about retro gaming with it - mine is just "collecting dust", it would be fun to try these things on it!

Idly comparing the silly little annotations, I notice the following state changes you've probably also stared at to the point of semantic satiation...

  Functional GUI: M_LIN8 G800x600 > 800x600 @00000+100+Dch4
  Functional DOS: M_TEXT T80x25   > 720x400 @00000+050-W
  Broken GUI:     M_VGA  G400x600 > 400x600 @00000+200-Dch4
  Broken DOS:     M_TEXT T80x25   > 720x400 @00000+250-W

- Broken DOS and Broken GUI are 200 or 250, functional are 100 or 050. What's that address?

- Broken GUI is somehow in M_VGA mode instead of LIN8. How and why did it get like that, and is that related to why it somehow got into 400x600, horizontally half of 800x600 (??). (True "textmode" is actually 720x400, as seen in both DOS modes.)

Unrelated to the actual article, but so refreshing seeing a website with a design/structure that reminded me of the best years of internet. How I miss left sidebars, tables and more!

[dead]