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.

  • 15
    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, 2017 at 8:32
  • 6
    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. Jun 6, 2017 at 11:31
  • 9
    @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. Jun 6, 2017 at 18:05
  • 9
    I have to say I’m amazed such a claim is getting upvotes :-/. Jun 6, 2017 at 18:11
  • 6
    @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.
    – user722
    Jun 7, 2017 at 1:51

12 Answers 12


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.

  • 3
    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, 2017 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, 2017 at 8:44
  • 1
    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, 2017 at 19:33
  • 1
    The CP/M machine I used back then had a boot loader that required sector 0 to be in single density format. Then when CP/M was running the rest of the floppy was in double density format. Jul 12, 2019 at 12:46

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.

  • 3
    The primary reason to bypass the BIOS drivers was to get faster screen updates. Dec 24, 2018 at 21:18
  • 3
    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, 2019 at 22:54

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.
    – user
    Aug 10, 2017 at 14:01
  • 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, 2017 at 20:35
  • On CP/M machines there was no ROM BIOS. The BIOS was read from the disk along with the operating system. Jul 9, 2019 at 4:51
  • As an aside, it's amazing that the A20 gate lasted as long as it did -- it was only necessary for a very small proprtion of real mode programs, and as of 80386 systems the same effect could have been achieved in software using V86 mode and a page table that wrapped memory around explicitly, so I wonder why this wasn't the preferred solution for 386+ systems?
    – occipita
    Oct 3, 2020 at 19:08
  • "The ROM BIOS routines are designed to be called from real mode" — some BIOS routines are available for protected-mode calls: e.g. VBE 2.0 provides protected-mode video routines. Not that they would be used much though: even uvesafb driver in Linux still required V86 mode or, for 64-bit kernels, x86emu.
    – Ruslan
    Apr 4, 2022 at 11:47

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

  • 3
    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). Aug 9, 2017 at 20:37
  • 4
    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.
    – user
    Aug 10, 2017 at 14:04
  • Graphics (pixels and such) were never supported in BIOS. That was text only. Dec 24, 2018 at 21:21
  • 3
    @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). Apr 18, 2019 at 18:17
  • 1
    It's you who's got it spot on, upvoted. BIOS was a good idea carried out badly, meant to be the HAL of its day. Each motherboard manufacturer would have their own BIOS variant to communicate with the particular hardware ICs they'd chosen with the I/O address map they wanted. So they'd be free to use any ICs or circuit for the timers, DMACs, keyboard interfaces etc. But... when programmers bypassed the painfully slow BIOS and talked directly to hardware to squeeze performance out of those also-slow CPUs, the BIOS idea fell apart...
    – TonyM
    Oct 7, 2020 at 15:04

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:

  1. Write a disassembler in Basic and use it to disassemble the Basic interpreter which came with the computer. Print out the disassembly.

  2. Get hold of the documentation for the relevant Intel chips.

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

  4. 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).

  5. Write an assembler (in Basic, since there is nothing else, yet) to convert the assembler code into actual machine code bytes.

  6. Write those bytes to the right place on a bootable CP/M disk.

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

  • 2
    For which computer did you do this?
    – cjs
    Jul 10, 2019 at 3:17
  • This is quite odd. It is based on having a ROM BASIC or bootable BASIC disk (huh?) that had disk read/write routines in it to disassemble. I think much more common was either a ROM BASIC that had no disk access or perhaps a paper tape loadable BASIC (like the first Microsoft BASIC for Altair) which also had no disk access. More likely is yes, use BASIC as a shortcut for the terminal I/O (whether memory mapped or serial) but create the disk routines by looking to similar CP/M implementations on other systems. Dec 9, 2020 at 20:10
  • Pertec PCC2000. It was a disk BASIC. Dec 9, 2020 at 22:22
  • According to old-computers.com/museum/computer.asp?st=1&c=1300 CP/M was an option for the machine, in which case why would anyone start with reverse-engineering the BASIC to get to CP/M? But then again, if you did it, either the CP/M wasn't available or you had "reasons". Dec 10, 2020 at 3:00
  • "since there were no debuggers available it was also pretty bug-free" Well, something like that... Dec 20, 2020 at 0:38

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!
    – user
    Aug 10, 2017 at 14:08
  • @MichaelKjörling Revised answer to clarify that it primarily talked about CP/M machines. Aug 13, 2017 at 14:22

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

  • Certain aspects of video behavior were very consistent. The biggest difficulty was that different EGA (and later VGA) cards took different approaches to trying to handle CGA compatibility. If the EGA was showing an 8x14 font and software tried to set the cursor to lines 4-7, should the cursor appear on lines 4-7 or 7-13? Should the translation be done by the BIOS "set cursor" call, or in hardware, and what should determine whether it's performed at all? Ironically, many compatibility problems with EGA software are a result of vendors' trying to be compatible with existing software.
    – supercat
    Jul 9, 2019 at 15:10

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.

  • 1
    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.
    – user
    Aug 10, 2017 at 14:03
  • 8" drives (and 5.25" HD later) could hold up to a megabyte. Dec 20, 2018 at 22:53

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.
    – user
    Aug 10, 2017 at 14:12

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:

  • One floppy was intended for computers with IDE hard disk,
  • one floppy was intended for computers with ST-506 hard disk,
  • one for computers having one of 11 supported SCSI controllers and
  • the last one for computers having one of 10 other supported SCSI controllers.

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

  • 1
    And it's worth noting that the reason for the different floppies between the IDE and ST506 versions is that it wasn't realistically possible to autodetect the different hardware. The controllers here used the same IO ports in a similar but not exactly identical way, and using the wrong driver would appear to work initially but fail later on.
    – occipita
    Oct 4, 2020 at 6:48

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .