Hi,
bzt wrote:
Brendan wrote:
Yes, once upon a time there was an OS that was a crippled piece of trash that sucked and died because it used BIOS (because end users didn't know better); but that is not a valid excuse to waste time on a new/modern crippled piece of trash that will suck and die (now that everyone has known better for over 2 decades).
It seems we don't agree on that. I think it wasn't crippled at all, I think the philosophy behind DOS/BIOS was brilliant (provide code for every device and use an uniform interface (ints) to use that, so that the OS does not need to have drivers).
Every OS provides a uniform interface of some kind; the problem is that the uniform interface for DOS was extremely poor (even for a single-user, single-tasking, real mode OS on the hardware that existed back then). The OS *did* need drivers (including using BIOS and device ROMs as "pseudo-drivers", and including actual drivers designed for DOS), except that often it failed to provide any drivers and application developers were forced to be do it themselves (and ruin future proofing because you can't install new devices and expect old applications to support them).
The concept behind DOS was "let's recycle a piece of trash for the sake of getting something to market, without caring about how poorly designed it is" because everyone at the time (including IBM) expected PC to be dead within a few years anyway. It was never intended to be good.
bzt wrote:
The only reason BIOS failed because it was realmode, and couldn't keep up with protmode. I'd like to point out that the Amiga used a similar architecture (drivers in ROM with unified interface) but there wasn't any processor mode upgrade or new device types and therefore it wasn't obsoleted.
No; BIOS failed because it's a crippled joke (and "real mode" had nothing to do with that at all). Don't forget that protected mode came with virtual8086 mode specifically to allow old real mode code to be executed without much problem.
PC succeeded because hardware manufacturers were able to create new CPUs, new motherboards, new devices and new device types. Every other home computer (TRS-80, BBC Micro, Commodore 64, Amiga, ...) become obsolete because there wasn't competition among hardware manufacturers and there wasn't the flexibility to handle new devices or new device types.
bzt wrote:
Brendan wrote:
DOS did (eventually) have drivers for CD-ROM (and "mscdex.com" to support file systems like ISO9660, etc), and did have drivers for SCSI controllers (and drivers for some network cards, and some sound cards, and...).
As I said, BIOS failed to keep up with hardware improvements. Btw imho CDROM was really badly designed, it should have used the standard disk int interface as USB Floppies and disks do in the first place. Hardware manufacturers seems to have learned from CDROM's mistake.
Hardware manufacturers have nothing to do with software interfaces provided by firmware or OS. Firmware manufacturers learned that firmware is too inflexible to do much more than start an OS.
bzt wrote:
Brendan wrote:
Of course (with or without drivers) the disk IO performance was extremely bad (no file caches, no prefetching in the background, no "buffered writes" in the background, etc); and (because of the lack of video drivers) lots of games had to have support for many video cards built into them (which wasn't as bad back when there weren't as many devices to support, but is incredibly silly now that there's so many).
Well, you can always have a specialized driver in your OS for full performance, but still it would be nice to have a
Basic Input Output System in firmware. And please don't forget that games stopped shipping video card drivers by the introduction of VESA. Now VESA was a good way to extend BIOS imho. It followed the concept IBM engineers originally had at least.
It went in waves. First games just used "int 0x10", then games came with built-in drivers to support better video modes, then VBE came along, then games came with built-in drivers for 3D acceleration (then DOS died).
bzt wrote:
Brendan wrote:
Ironically; UEFI is mostly just a 64-bit DOS clone (single-tasking, simple/bad synchronous APIs, no protection, simple/bad FAT file system, etc), which is what OP wants to create.
Agreed. The biggest problem with that is it's unusable after ExitBootServices. BIOS provided run time services, which is an undeniably better design imho. You can technically forget everything EFI related once your kernel is started, which simply renders the complexity of EFI ridiculous.
ExitBootServices is the thing I like most about UEFI. It gives a clear transfer of ownership (from "firmware owns all hardware" before ExitBootServices to "OS owns all hardware" after ExitBootServices); and signifies the point during boot where an OS's boot code no longer has to tip-toe around in fear of upsetting someone else's code and can actually start behaving like an OS.
bzt wrote:
Brendan wrote:
Also note that (as far as I'm concerned) the OP is trying to invent an excuse to continue 20 years of failing to learn anything useful.
Well, partially agree. Yes, developing such a BIOS is pointless and there's not much to learn from it. But I think failing was caused by misusing the original BIOS concept, and not because the concept was bad. They should have introduced new int services for sound cards and another one for network cards for example, following the original structure (one int for every device, one for console, one for video, one for disks, one for keyboard etc.). The idea the OP has is great, it's just outdated by decades as the industry took a different path.
They should've added new interfaces for sound and network, and replaced all the old "synchronous" APIs with APIs that aren't pure trash, and deprecated "A20 gate" and fixed the PIC chip configuration and forced "RTC date/time is UTC", and provided protected mode entry points capable of handling paging, and added support for multi-CPU and 3D accelerated video and scanners and full "print quality" printers and CD burners, and added support for "hot-plug everything" (starting with USB), and provided fault tolerance throughout all of that; and even if they did all of that I'd still say it's too inflexible for a competent OS developer to bother with.
Cheers,
Brendan