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.

  • 3
    For CP/M, the BIOS is actually a part of the OS, so CP/M does use "its own drivers" (they are called "BIOS"). Early MS-DOS was clearly influenced by CP/M, and they just decided to put the BIOS into ROM. It then gained some kind of independence afterwards, and became what we understand today under BIOS. – dirkt Jun 6 '17 at 8:32
  • 5
    While some of PC-DOS was in ROM, MS-DOS was available for computers that did not embed all of the "BIOS" in ROM. Both PC and MS variants had two hidden files that defined the core of the operating system - in IBM's case (PC-DOS) the files were called IBMBIO.COM and IBMDOS.COM; in the generic case (MS-DOS), they were (normally) called IO.SYS and MSDOS.SYS. Where MS-DOS was 'branded' to match the computer manufacturer, IO.SYS may have referenced the computer's ROM BIOS; in cases where MS-DOS was sold/distributed by a third party for use on "any" computer, IO.SYS loaded all of BIOS into RAM. – Jeff Zeitlin Jun 6 '17 at 11:31
  • 3
    @Jeff citation needed there, IO.SYS doesn’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. – Stephen Kitt Jun 6 '17 at 18:05
  • 5
    I have to say I’m amazed such a claim is getting upvotes :-/. – Stephen Kitt Jun 6 '17 at 18:11
  • 4
    @JeffZeitlin There's no code that access hardware directly (except for minor things like the interrupt controller) in 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. – Ross Ridge Jun 7 '17 at 1:51

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.

  • 1
    Saying "CP/M had a bootloader in ROM" isn't meaningful -- CP/M ran on many different machines with widely varying ROMs. There was no single ROM bootloader common to them all. – john_e Jun 7 '17 at 9:47
  • @john_e Good point. It would be better to say all it required was a boot loader in ROM. – JeremyP Jun 8 '17 at 8:44
  • I think it wasn't merely ease of booting; the original PC shipped with as little as 16kb and MS-DOS was only one of the operating environments offered: IBM wanted to hit all possible use cases so e.g. Microsoft's ROM BASIC was also right there. It didn't run on MS-DOS or anything else, it's a complete firmware solution. Just like all of the immediate competitors of 1981. So BIOS stuff can be shared only because it's right there in ROM. – Tommy Aug 4 '17 at 19:33

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.

  • Modern operating systems often run not in protected mode, but in long mode. On Intel, you can have protected mode with 24- or 32-bit addressing (80286 or 80386+ style), or long mode with 64-bit addressing. Anything that runs on an Intel-compatible architecture in 64-bit mode is running in long mode. – a CVn Aug 10 '17 at 14:01
  • @Michael I'm not sure what you're responding to, exactly. Perhaps the claim that modern processors boot in real mode? The operative word there is boot. The OS's bootloader almost immediately changes them into running in protected or long mode, but they are not in either of those modes initially. – Cody Gray Aug 10 '17 at 14:04
  • No, your claim that "modern operating systems don't run in real mode. Instead, they run in protected mode." Only 32-bit modern operating systems run in protected mode. 64-bit modern OSes on Intel-like architectures run in long mode in order to be able to access 64-bit registers. See the Wikipedia article I linked previously for a longer discussion than fits in the comments. – a CVn Aug 10 '17 at 14:14
  • Ah, I see what you're saying. Missed that. Will update. Thanks @Michael. – Cody Gray Aug 10 '17 at 14:17
  • Hmm, so it takes about 35 years for compatibility to decay... x87 FOPcode compatibility was broken earlier though, but with a possibility to revert. – Ruslan Nov 11 '17 at 20:35

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 primary reason to bypass the BIOS drivers was to get faster screen updates. – Thorbjørn Ravn Andersen Dec 24 '18 at 21:18
  • This is the answer. There was no concept of standardization back then. Not even serial ports had a single chipset command set. In fact, there wasn't even a single way to talk to the I/O chips: some processors used memory mapped I/O and others had I/O ports (i.e., special instructions). Addresses weren't standard. Command codes and flag bitmasks weren't standard. And don't get me started on mass storage ... It was the wild Wild West out there... – davidbak Mar 14 at 22:54

[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.

  • 2
    Actually, plenty of software wrote directly to video memory - bypassing both the BIOS & DOS function calls - even for text. This became so common that true multitasking/multiuser systems were relatively limited until the 80386. With the 80386, the OS could trap video memory accesses from processes not in the foreground and either save for screen refresh later or even route to serial terminals (Concurrent DOS 386 - an evolution of CPM->MPM->CPM86->MPM86->Concurrent CPM->Concurrent DOS 386). – manassehkatz Aug 9 '17 at 20:37
  • 2
    Many add-on cards did provide their own BIOS. For example, you could install a disk controller that hooked into INT 13H by way of its own BIOS. That way, no extra drivers were needed, as all software already used INT 13H (one way or another) for disk access. – a CVn Aug 10 '17 at 14:04
  • Graphics (pixels and such) were never supported in BIOS. That was text only. – Thorbjørn Ravn Andersen Dec 24 '18 at 21:21
  • @ThorbjørnRavnAndersen: BIOS has/had calls to program the video card into graphics modes and write single pixels (int 10h, AH=0Ch). Slow enough to be useless in practice already when conceived, bit it was there! (The mode-setup calls were less useless, and tended to be used even by software that would subsequently access the video RAM directly to write pixels). – Henning Makholm Apr 18 at 18:17

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:

  1. Space in RAM to be used.
  2. Space on a 360k floppy disk.

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.

  • PC-DOS 1.0 only supported 160 KB floppies. I think 1.1 raised the limit to 180 KB by increasing the number of sectors per track. 360 KB floppies came later. – a CVn Aug 10 '17 at 14:03
  • 8" drives (and 5.25" HD later) could hold up to a megabyte. – Thorbjørn Ravn Andersen Dec 20 '18 at 22:53

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.

  • "Those days the computer was very much what you had when you purchased it." Actually, no, not at all. For the IBM 5150, quite the opposite. Look at the stock IBM PC without any expansion cards: no graphics, no printer, no floppy disk controller. Basically just the CPU, keyboard port, cassette tape recorder port, a small amount of RAM, and power. Wanted to hook up a screen? Install a graphics card (initially MDA or CGA). Wanted a printer? Add the printer port card. Etc. If you go back just a little farther, S-100 systems didn't even have a CPU on the motherboard; that was really just the bus! – a CVn Aug 10 '17 at 14:08
  • @MichaelKjörling Revised answer to clarify that it primarily talked about CP/M machines. – Thorbjørn Ravn Andersen Aug 13 '17 at 14:22

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.

  • It was a while before systems regularly bumped against the 640 KiB limit of address space usable for software RAM. The IBM PC maxed out at 640 KiB; it wasn't until the IBM PC/AT you could add more, and even then only because it used the 80286 instead. – a CVn Aug 10 '17 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.