Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
Modern versions of Windows (and other modern operating systems I suppose) have their own drivers to access hardware.
But as I have read, in the old days, if CP/M or MS-DOS wanted to access hardware, they would use the BIOS drivers to do that for them.
So why did CP/M and MS-DOS not have their own drivers to access hardware? My guess is that if they had drivers for all available hardware at that time, then the size for these operating systems would become too large.
The BIOS originated as part of the CP/M operating system. It was the "layer" that interfaced directly with the hardware and as such, was usually machine specific. The idea is that, if you separate out the hardware interactions into one module and provide a standardised interface that the rest of the OS uses (and user programs), then the only thing you need to change when porting to a new computer is the relatively small BIOS.
With DOS and the IBM PC, a large part of the BIOS was moved from the OS into ROM to make it easier to boot the machine (CP/M had a bootloader in ROM, but I think it was pretty basic) but it's still effectively part of the DOS operating system. Once Windows came along, the operating system took over more of the tasks that had traditionally been the responsibility of the BIOS until by the time of Linux, Windows NT and Windows 95, the BIOS was only used to get to the point of having the operating system running and was henceforth ignored.
So the answer to your question is that effectively the BIOS is MS-DOS's and CP/M's drivers.
CP/M was hardware independent - there was no notion of a reference machine (as the IBM PC was for MS-DOS), so CP/M could not provide drivers. The hardware producer had to develop the drivers and deliver them with CP/M, and the driver package was simply called BIOS ("Basic Input/Output System"). This worked quite well over the lifetime of CP/M.
MS-DOS started with the same concept, but soon software accessed the hardware directly, bypassing the BIOS, and also after a short time the BIOS API no longer fit the requirements of the higher level O/S. This led to the degradation of the BIOS from really being the "Basic Input/Output System" to just being the boot loader.
The simple answer is that they just didn't need them! Why reinvent the wheel, when the required interface is already provided by the ROM BIOS? This allows the operating system to be more portable and to support a wider variety of machines and hardware from different vendors, because the vendor provides and is responsible for the ROM BIOS routines. Size of the OS itself was also certainly a consideration, as you rightfully point out.
The converse question is, then, why do modern operating systems have their own drivers to access hardware? And the answer to that is rather simple, too: because they have to! The ROM BIOS routines are designed to be called from real mode, but modern operating systems don't run in real mode. Instead, they run in protected mode (32-bit) or long mode (64-bit). Since the ROM BIOS services are unavailable from these modes, the operating systems must provide their own drivers. The ROM BIOS services are often still used, even by modern operating systems, during the boot-up phase before they switch into protected/long mode. (All x86 processors boot in real mode, compatible with an 8088, even to this day.*)
__
* Except that, as of the Intel Haswell microarchitecture, the A20 gate is no longer supported.
uvesafb driver in Linux still required V86 mode or, for 64-bit kernels, x86emu.
[I am assuming the question is limited to functionality built into the PC, not functionality added via installed cards etc. Obviously the BIOS couldn't provide routines for the latter, so drivers would have to be supplied]
Having lived through the introduction of the original IBM PC, I have to say that in my opinion the submitter has the question backwards - what should actually be asked is 'Why do modern systems use their own drivers when the BIOS provides the needed functionality?" The fact is, it was always intended that user programs should only perform certain functions via the BIOS routines - the BIOS was the 'wall' protecting the hardware from the user.
What actually happened is, some applications eventually started generating graphical interfaces instead of textual interfaces, but when they tried using the graphical routines in the original IBM PC BIOS they found that the routines were so slow - they were notoriously badly written - they had no choice but to write into video memory directly to achieve palatable performance. And of course different PC clones had slightly different graphics hardware, so people had to supply multiple custom drivers for their products. Windows itself had to do the same. Everything snowballed from that.
Of course, it is also possible that everything would have been driven in that direction anyway, for reasons stated elsewhere.
There was no BIOS on the early computers. There was only the hardware. To get CP/M to work on a computer, somebody had to write a BIOS which would receive calls from CP/M (read character, write character, read disk sector, write disk sector) and make the hardware obey.
If your computer didn't have a ready-made CP/M distribution (which would have been distributed linked with a specific BIOS for that computer), you had to write one yourself. Here were the steps in my case:
Write a disassembler in Basic and use it to disassemble the Basic interpreter which came with the computer. Print out the disassembly.
Get hold of the documentation for the relevant Intel chips.
Referring to the chip documentation and to the way that Basic did it, write "read sector" and "write sector" routines (disk controller chip plus DMA), using the equivalent functions in the disassembled Basic interpreter as a guide.
Decide on what escape sequences to use for cursor positioning, and write a "write character" function which understands them. (The screen display was textual, in a fixed area of RAM, and the screen display chip had a useful register telling it which of the 24 lines to count as "line 1", so that scrolling could be done just by changing that register).
Write an assembler (in Basic, since there is nothing else, yet) to convert the assembler code into actual machine code bytes.
Write those bytes to the right place on a bootable CP/M disk.
Boot it up.
Once this was done, the next stage was to rewrite the already written BIOS code so that it could read by CP/M's own assembler. From then on, the built-in Basic was redundant.
It was all quite straightforward, if intricate, and since there were no debuggers available is was also pretty bug-free.
One of the things to understand here, was that at the time of CP/M you had very little memory and it was a long time ago where many concepts had not been introduced yet. Drivers came later when computers could be modified easily with new hardware. Those days the computer was very much what you had when you purchased it.
The BIOS layer is essentially what we today would consider a statically linked set of drivers, typically written in assembly by the manufacturer. CP/M itself was the same binary on all machines (which could be very, very different) and had a standard API in talking to the hardware and the BIOS implemented that API. This was probably the reason CP/M became so popular. The hardware in CP/M 2.2 was not much more than the keyboard input, screen output, printer output (no buffering), and floppy disk sector read/write. CP/M 3.0 was a bit more complex.
For MS-DOS the initial machines were very different (and still had very little memory - Zork could run in 48 Kb, and 640 Kb was very expensive) so BIOS was the way to talk to the hardware. It took quite a while before the clones got good enough to not need this. BIOS may still be needed in the boot sequence even for modern PC's even if UEFI is rapidly replacing it.
So the answer was: Not invented yet, and even if it was the memory was better spent for programs.
Insofar as graphics went, it's important to keep in mind that prior to the early 1990s, low-level details about how different video cards actually worked weren't necessarily widely known, or implemented in a manner that was hardware-identical to a PS/2 VGA card.
Case in point: VGA (as implemented on the PS/2) actually had support for tiled graphics (in the form of custom fonts), but almost nothing dared to actually USE it (Microsoft's shell for MS/DOS 6 and XM-tracker come to mind as two of the only popular apps that took advantage of it as a way to render a mouse pointer onto a textmode screen... basically, using 9 of the custom characters to render whatever 9 characters happened to be in the 3x3 grid around the mouse pointer, along with the mouse pointer itself). The problem was that there was no official BIOS support for it (at least, not prior to SVGA BIOS extensions becoming a de-facto standard), and there was no guarantee that a given third-party "VGA" card worked in precisely the same way as IBM's official "VGA" graphics... or that the third-party "VGA" card had direct hardware support for custom characters AT ALL. And documentation for stuff like this was insanely hard to come by prior to the first books like the one written by Richard Ferraro in 1990.
It's hard to believe now that you can look up almost anything online, but back in 1989, low-level register details about arbitrary video cards really weren't all that well known... partially, because vendors didn't want to make it easy for competitors to make register-compatible copies of their own cards, and partially because they didn't want to make it easy for the companies whose designs THEY copied to sue THEM for infringement. Unless you lived somewhere like Boston or Silicon Valley, even LARGE bookstores rarely sold books about esoteric programming topics... when such books existed at all.
Going back to the example of Richard Ferraro's book. In 1990, I lived in Miami and went to both Barnes & Noble and Borders all the time. The first time I ever remember seeing a copy of that particular book on the shelves (at the Borders store across the street from Dadeland Mall) was sometime around 1994... and it wasn't cheap.
In retrospect, "most" PC videocards actually DID work almost exactly the same way (at least, insofar as "VGA" was concerned). But at the time, there was an almost-neurotic perception that programming the bare-metal hardware would cause endless compatibility problems... and even if you were willing to live dangerously, the information itself wasn't easy to come by.
In 1992, I was an Amiga refugee who'd finally jumped ship and bought a loaded 486DX33 with S3 '911 graphics card. At the time, I knew that it was possible to program 486 assembly language using flat addressing (or more precisely, using 2-gigabyte segments and setting the segment pointer to 0), but spent MONTHS trying to find out how to actually GET a PC into what we now would refer to as "unreal mode" (in fact, using "the internet").
Even in 1992, you couldn't just waltz into Borders, grab a book about PC assembly language, and expect to find nice chapters coherently explaining things like "Unreal Mode" or "DOS Extenders". From what I recall, there WAS a chapter somewhere in the manual for Borland's TurboASM that touched upon it... but it was purely a minimal reference guide that was utterly incomprehensible to someone who didn't already understand the topic. Information-wise, the late 1980s and early 1990s really were an information dark age. There were lots of books about programming Realmode assembly and making BIOS calls... but absolutely, positively, NOTHING on mainstream bookstore shelves about programming bare-metal hardware. At least, not until the mid-90s (though, as noted, the books themselves started to get published around 1990... you just couldn't stumble over them & had to already know they existed).
the size for these operating systems would become too large.
I think that's a big part of it. Building their own hardware drivers would require both:
I'm sure those considerations were measured against using their own hardware drivers. No need to "re-invent the wheel" for hardware access, when they were tight on space to begin with, and could just use the routines delivered with the BIOS.
Also, there was no good support infrastructure for loading third party drivers for new hardware (released after the DOS version used) - and any loadable (or even worse TSR or firmly compiled-in) driver, whether third party or included in the OS, ate away at the always tight "lower" RAM (the sub-640K area) capacity, whereas anything kept in ROM did not. Also, in floppy-oriented systems, it was common to make bootable disks with just the core OS for application programs - another place where you took capacity if you loaded anything from disk that was available in ROM.
The "BIOS" doesn't just consist of what is in the ROMs on the mainboard, but sometimes is also augmented by "option ROMs" on extension cards - which equalled a built-in device driver for hardware that executed known functions but needed a different register-level protocol to access it - for example, hard drive controllers often brought firmware along that helped the BIOS and OS handle them, especially at boot time when there was no way to load a third party driver from disk since it would have to be loaded into the BIOS and boot loader to access the disk at all.
You have to keep in mind that early IBM-compatible PCs did not have "standard" hardware.
The hard disk would be a good example:
Today, most computers typically have SATA hard drives, so an operating system must support SATA to support hard disk access.
In the 1980s there were controllers for hard disks with ST-506 interface, IDE hard disks and a lot of different SCSI hard disk controllers.
Mid-1990s Linux versions show what it meant not to use the BIOS to access the hard disk:
The Linux distributions came with different kernels for different hard disks; the "Slackware 2.3" distribution (1995) used four different boot floppy images (booting from CD was not supported) if you wanted to install from an IDE CD-ROM:
(If you wanted to install from a non-IDE/SCSI CD-ROM, there were even more images on the CD-ROM.)
MS-DOS would also have required multiple disks for different hard disk types if it did not use the BIOS.
And because Linux used 1440K floppies and (early) MS-DOS used 360K floppies, you would not have required four different disks but maybe 10.
Early MS-DOS versions came on two 360K floppies; 10 additional floppies containing different device drivers would have meant selling MS-DOS on 12 floppy disks instead of only 2 - knowing that the customer would definitely never use 9 of these 12 disks.
The original idea of using the BIOS to access certain hardware seemed like a good one, and for the most part it worked well. The BIOS is like a driver that DOS uses to access hardware. Imagine having all the drivers for your computer in a ROM chip, and all you had to do was install the operating system and all the drivers were there automatically!
As the hardware in PCs became more advanced, and operating systems became more advanced, using the BIOS for drivers became a problem as the driver software in the BIOS began to hold back the rest of the system. As operating systems improve, drivers need to be tweaked to achieve optimal performance, and this is not possible with the drivers in a BIOS ROM. With the introduction of the 286 CPU and protected mode the problem got more serious as an operating system operating in protected would have to interface BIOS drivers that were meant to be executed in real mode. This was pretty much the end of having drivers in the BIOS. From this time on, drivers were made specifically for use with the operating system they would be used with.
DOS 1 is the only DOS version to not support drivers. Anything higher supports drivers.
In essence, writing to register-and-interrupt is a relatively simple process. I wrote an RPN calculator, the control structure was 10 lines of BASICA, and six registers. The nature of the thing was that there was a continual stream of characters, which would toggle various states of the registers.
When a function was invoked, it would read registers and return the answer to A. If a certain condition (error-flag = 0), then the value in A would be expanded to display, and the stack (T,Z,Y,X,L) moved about.
Some of the loaded drivers in DOS provide an interrupt interface. Installing a mouse will not make programs that don't know about the mouse see it. The mouse has its own interrupts, and moves an overlay on the screen to match what the motions of the rodent are.
One of the big things in MSDOS-compatable computer era (ie pre-dos 5), is that the video bios differed from machine to machine, one bought games for the IBM or the Tandy or whatever, just as one buys machines for X-Box or whatever.
It must be remembered that IBMDOS.COM and MSDOS.SYS are little more than interrupt providers for standard drivers. These change much less from version to version: identical in MS-DOS 6.20/1/2 for example.
IO.SYSdoesn’t contain a generic BIOS... “Generic” MS-DOS still requires all the BIOS services to be provided externally, typically by ROM or flash of some sort.IO.SYS. It uses the computer firmware, the BIOS, to do all the actual interaction with hardware. It's fact that the BIOS provides a common interface to the hardware that lets MS-DOS work different kinds of mutually incompatible hardware. Even hardware that didn't exist when MS-DOS written, that's why you can boot MS-DOS off a USB drive.