21

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.

  • 10
    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
  • 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. – Jeff Zeitlin Jun 6 '17 at 11:31
  • 5
    @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
  • 6
    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
28

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.

  • 2
    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 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. – Thorbjørn Ravn Andersen Jul 12 at 12:46
12

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
12

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
4

[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-Reinstate Monica Aug 9 '17 at 20:37
  • 3
    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
  • 1
    @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
3

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
3

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.

  • 1
    For which computer did you do this? – Curt J. Sampson Jul 10 at 3:17
2

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

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
0

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 at 15:10

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.