For a while there if you had the same business-class machines under WinXP as with Win98, the difference in speed was phenomenal. XP was just a dog and it was a loss that has never been recovered. And now you just have to live with the fact that NT5 was actually not nearly as slow as NT6 has been :\
After careful consideration it was largely attributed to the existence of a Harware Abstraction Layer in the NT form of Windows.
For the longest time this was also a major speed advantage that Linux had over Windows on the same hardware.
In the 8-bit universe the CP/M OS took up somewhere around 6 - 8 KILObytes. My earliest DOS (North Star DOS) took up 0A00 H bytes (a mere 2560 bytes!)
The hardest thing in coming to Unix/Linux from the DOS world was that hardware is out of bounds for direct-access. You have to work with a hardware driver and the OS.
For graphics and sounds abstracting that without adding many more transistors would have enormously slowed down graphics and sound generation (for example, even on the more powerful PC, which had a BIOS to abstract away writing text to the screen, programs had to bypass that and write directly to screen memory to get decent performance)
So, short-term, it only had disadvantages.
because an 8-bit microprocessor like a 6502 didn't have an MMU and it would have been uneconomical to add it.
- it would have required external circuitry. consider the evil genius lengths Woz went to so save just a couple chips in the apple ii.
- home computers were quite expensive, the difference even a couple dollars worth of hardware would count. instead, put every penny into performance and capabilities with the most minimal system possible.
- it would certainly slowed the hardware down. at minimum you have to keep track of kernel vs. user mode. no 8-bit microprocessor has a way to do that so you'd have to build some external MMU to track the address the code was running from or some other scheme. then you'd have to block addresses from "user" code. all that takes time and bus cycles.
- it would certainly slowed the software down too and make it a lot bigger. you have to keep track of kernel vs "user" code. you'd have to provide a way to program that MMU hardware for adding new kinds of hardware. you'd have to account for DMA. you'd need at least some kind of minimal driver framework to keep track of all that stuff.
> Wouldn't this have allowed 8-bit computers to improve more rapidly in terms of graphics and sound while maintaining software compatibility?
nope. the best way to demonstrate this is the 8088/8086 IBM style ROM BIOS routines. while not "protected" in hardware, these are an example of the kind of framework and software that abstracts the direct hardware access for an early computer. it didn't make things easier or better and it was widely ignored with many programs using the hardware directly.
- while some programs did cleanly use only the BIOS entry points to talk to hardware, few did so exclusively.
- especially games, graphic intensive programs, and software that talked to specialized hardware features could not handle the speed and capability penalties of using BIOS vs. direct hardware access. wait, i just described almost all software for these computers...
- the performance penalties for going through DOS or BIOS vs. direct access for things like video, sound, disk IO could be 10x to 100x.
- BIOS as an API did not do an especially good job of maintaining software compatibility. it was too low-level but not low-level enough. it was to broad and complicated, but never managed to adequately cover everything flexibly enough.
- so talking to hardware is one kind of API and BIOS is a different API. the former was ironically better. even if it wasn't formally standardized, much hardware grew to be compatible to de-facto standards and many many computers were extremely portable to each other just at the hardware layer anyway. BIOS wasn't better enough of a standard to make it worth the significant other downsides to using it. in fact, it seemed that BIOS access was buggy but direct hardware access was more reliable as well.
- so the 8-bit (and 16-bit) industry couldn't have cared less about software compatibility. if you can directly peek/poke your sound-blaster card with less hassle, less code, and it ran much faster why do you want a library/driver-model/os getting in the way?
so why did we ever get os, and drivers, MMUs and so on for home computers anyway? that's the real question:
- it wasn't software compatibility or rapid development
- the model of direct hardware ownership really broke down when we wanted to run more than one program at a time. eventually we could afford enough memory to run more than one program at once and switch between them. even window them.
- at that point, primitive attempts to task switch like TSRs in DOS had a really hard time dealing with programs that assumed they "owned" the hardware.
- a couple years earlier, direct hardware access was reliable, high performance and reliable. now programs that did this suddenly were instead sources of bugs, flaky behavior, and annoyances or reduced capability (i.e. didn't work with task switchers).
so home computers, at least in the x86 world, went through an evolution, becoming more and more like a "real" mini-computer os's with protected memory and a kernel/drivers. this required hardware like the 32 bit 80386/486/pentium and software like OS/2 and windows nt/2000. things like windows 3.1/95/98 representing intermediate evolutionary steps where the direct hardware access and memory was not quite protected.
but by this time, hard-drive space, memory, cpu speed were all approximately 100x (or even 1000x) what the old 8-bit micros did for similar price.