[JoeAltmaier]

DOS provided a tiny fraction of what Windows provided?

A full kernel acts as gatekeeper to system resources. While DOS provided access to some resources, it was single-process and so had no gatekeeping. No concept of different pools of resources, different lifetimes of activity. No comprehensive cleanup.

Half of a kernel (or more) is taking things from one list and putting them on another list, so when something exits or dies or faults, it can release resources that were allocated to the dying thing.

The hardware access was the lowest, simplest part of that. And DOS used the BIOS anyway, for half of what it did (floppy drivers etc). Which meant it had not a chance in hell of performing well (executing out of ROM or whatever).

[musicale]

> it had not a chance in hell of performing well (executing out of ROM or whatever)

If CP/M-86 performed well, why wouldn't DOS? They're very similar.

Wouldn't the "shadow RAM" technique of copying the ROM BIOS into RAM solve any ROM slowdown issues?

[JoeAltmaier]

Sure. But add to that, they were crappy drivers. Minimal things just to ship the product. No support for thread-safe or isolation or anything. In fact, they just looped on i/o ports waiting for device completion - no dma, no interrupts, nothing.

Enough to boot. But worthless for any real OS.

[musicale]

If you're running a single app (e.g. a game, or WordStar), adding a "real" OS usually doesn't buy you much in terms of raw performance (though maybe you get better responsiveness during background printing or other multitasking.) In fact a "real" OS tends to add overhead.

Games are notoriously performance-intensive, and early 1990s PC games tend to run well on DOS - Windows just adds overhead. For that matter, many arcade machines used simple drivers and lacked a "real" OS as well.

Moreover, if you're not trying to run some multitasking workload with background tasks (and indeed you don't want to if you care about performance for your game), then polling in a game loop/frame loop may be more efficient than interrupts.

And when you're trying to extract maximal performance, as in the PC demoscene, you often want direct access to the "bare metal" devices themselves - something which DOS happily allows. Windows provides little - or negative - value.

[pjmlp]

Hence why WinG was created, DirectX's predecessor.

It was the first attempt to move game studios into Windows 3.x.

Another piece of history that will be lost as there are so few of us that remember it and it is badly documented.

https://en.wikipedia.org/wiki/WinG

https://www.uvlist.net/groups/info/wingapi

[JoeAltmaier]

That's called 'embedded' and it has it's place.

It's nearly always better to take interrupts than poll. A device driver that leaves the game to execute game code, putting results on a queue the game can test in it's poll loop, makes the UI responsive. Otherwise it'd hang every time a write to disk occurred, waiting for seek, then shifing the bytes out. Not a benefit to anybody.