Hacker News new | ask | show | jobs
by musicale 1117 days ago
> 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?
1 comments
JoeAltmaier 1117 days ago
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.

link
musicale 1117 days ago
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.

link
pjmlp 1117 days ago
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

link
JoeAltmaier 1117 days ago
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.

link