IBMBIO.COM (at the top of the listing ofCOM files) inIBM PC DOS 1.0.IBMBIO.COM is asystem file in manyDOS operating systems. It contains the system initialization code and all built-in device drivers. It also loads the DOS kernel (IBMDOS.COM) and optional pre-loadable system components (like fordisk compression or security),[1][2] displays boot menus, processes configuration files (likeCONFIG.SYS) and launches the shell (likeCOMMAND.COM).
The file is part ofIBM'sPC DOS (all versions) as well as ofDR DOS 5.0 and higher (with the exception ofDR-DOS 7.06).[2][3] It serves the same purpose as the fileIO.SYS inMS-DOS, or DRBIOS.SYS inDR DOS 3.31 to3.41.[2][3] (For compatibility purposes with some DOS applications the IBMBIO.COM file name was briefly also used by the IBM version ofOS/2 1.0, where it resembled theOS2BIO.COM file as used byMicrosoft.)
The file is located in theroot directory of the bootableFAT-formatted drive/partition (typically C:\) and typically has thesystem,hidden, and (since DOS 2.0 also the)read-onlyfile attributes set.[4][5][6][2][3] Under DR-DOS the file may be optionallypassword-protected as well.[3][nb 1] Under PC DOS, thesystem attribute is set in order to mark the file as non-movable, a restriction technically not necessary under DR-DOS.[7][5][6][8][3] As IBMBIO.COM is a binary image containing executable code rather than a trueCOM-style program, thehidden attribute is set to keep the file from being accidentally invoked at the command prompt, which would lead to a crash.[5] This is no longer necessary forDR-DOS 7.02 and higher, because under these systems the file is afat binary also containing a tiny COM-style stub just displaying some version info and exiting gracefully when not being loaded by aboot sector.[2][5][9]
In thePCbootup sequence, the first sector of the boot volume contains aboot loader called thevolume boot record (VBR) and is loaded into memory and executed.
If this is a VBR of PC DOS before 3.3 it would load both system files into memory by itself.[4][10] As the PC DOS VBR cannot mount the FAT file system, the system files have to be stored in the first directory entries on the disk and be located at fixed physical positions on the disk stored in consecutive sectors, conditions of which theSYS utility must take care of.[4][10]
If the loaded boot sector is aPC DOS 3.3 (or newer) VBR, the requirements are slightly relaxed. The system files still have to be stored in the first two root directory entries on the disk, but the VBR will use only the first entry to load the first three sectors of IBMBIO.COM into memory and transfer control to it.[10][nb 2] This part of IBMBIO.COM then contains a somewhat larger boot loader which:
UnderDR DOS 5.0 and higher, the first step is skipped, since a DR-DOS VBR is capable of mounting the FAT file system, locate the IBMBIO.COM (or DRBIOS.SYS) file anywhere in the root directory and load it into memory by itself.[7][2][5][11][8][3][nb 3][nb 4] The filename of the IBMBIO.COM file to be loaded by the boot sector is stored in the boot sector rather than necessarily in the first root directory entry, likewise the filename of the IBMDOS.COM file to be loaded by IBMBIO.COM is stored in IBMBIO.COM itself rather than necessarily in the second directory entry on the disk.[12][2][5][3] Also, similar to the IBMBIO.COM loader in the VBR, the IBMDOS.COM loader in IBMBIO.COM is capable of rudimentarily mounting the filesystem as well, therefore it is not necessary for the system files to be stored in the first two directory entries, to reside at fixed physical positions or be stored in consecutive sectors. Consequently, it is also no longer necessary to set thesystem attribute.[7][5][6][8][3] Instead, the system files can be simply copied to the disk (without SYS), given a DR-DOS boot sector already resides on the disk.[5][6][2][8][3]
Microsoft sometimes calls this component the I/O system,[4][13][14] but it is generally known as DOS BIOS (the DOS-related part of theBasic Input/Output System). The term BIOS was originally coined byGary Kildall in 1975 forCP/M,[15][16][17][18][19][20] but is also used to describe a similar component or layer in other operating systems by Digital Research, IBM, Microsoft and many others.
In a more generic sense, some vendors refer to this portion as the RAM BIOS of operating systems such asDOS orCP/M in order to contrast it with the built-in ROM BIOS of a machine.[21]
/R[:password] option available in some versions of theSYS command.[a] The boot loader would simply ignore a set file password while loading the file, but once the system has been booted, the system files could not be accessed without knowing the password, thereby providing an additional level of protection from accidental attempts to delete or modify the system files. (This file password feature is independent of volume or boot passwords also provided by DR-DOS in certain configurations.)SYS /DR:ext multi-boot feature.[f] For the further addition of alternative boot units,LBA,FAT32 and the optional facility to also bootPC DOS/MS-DOS in addition to DR-DOS, the7.07 sectors had to resort toself-modifying code,opcode-level programming inmachine language, controlled utilization of (documented)side effects, multi-level data/codeoverlapping and algorithmicfolding techniques to still squeeze everything into the 423 bytes available for code in a single physical sector of 512 bytes, as it was a requirement forbackward- and cross-compatibility with other operating systems inmulti boot andchain load scenarios.[…] the DR-DOSFDISK does not only partition a disk, but can also format the freshly created volumes and initialize their boot sectors in one go, so there's no risk to accidentally mess up the wrong volume and no need forFORMAT /S orSYS. Afterwards, you could just copy over the remaining DR-DOS files, including the system files. It is important to know that, in contrast to MS-DOS/PC DOS, DR-DOS has "smart" boot sectors which will actually "mount" the file-system to search for and load the system files in the root directory instead of expecting them to be placed at a certain location. Physically, the system files can be located anywhere and also can be fragmented. […]
NWDOSTIP.TXT is a comprehensive work onNovell DOS 7 andOpenDOS 7.01, including the description of many undocumented features and internals. It is part of the author's yet largerMPDOSTIP.ZIP collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the file.)[5][…]SYS has been improved underDR DOS 5.0 so you don't have to worry about leaving the first cluster free on a disk that you want to make bootable. The DR DOS system files can be located anywhere on the disk, so any disk with enough free space can be set to boot your system. […](NB. The source attributes this to theSYS utility while in fact this is a feature of the advanced bootstrap loader in the boot sector. SYS just plants this sector onto the disk.)
[…] TheDR-DOS boot sector loads the whole IBMBIO.COM file into memory before it executes it. It does not care at all about theIBMDOS.COM file, which is loaded by IBMBIO.COM. […] The DR-DOS boot sector […] will find the […] kernel files as long as they are logically stored in the root directory. Their physical location on the disk, and if they are fragmented or not, is don't care for the DR-DOS boot sector. Hence, you can just copy the kernel files to the disk (even with a simpleCOPY), and as soon as the boot sector is a DR-DOS sector, it will find and load them. Of course, it is difficult to put all this into just 512 bytes, the size of a single sector, but this is a major convenience improvement if you have to set up a DR-DOS system, and it is also the key for the DR-DOS multi-OSLOADER utility to work. TheMS-DOS kernel files must reside on specific locations, but the DR-DOS files can be anywhere, so you don't have to physically swap them around each time you boot the other OS. Also, it allows to upgrade a DR-DOS system simply by copying the kernel files over the old ones, no need forSYS, no difficult setup procedures as required for MS-DOS/PC DOS. You can even have multiple DR-DOS kernel files under different file names stored on the same drive, and LOADER will switch between them according to the file names listed in theBOOT.LST file. […]
[…] Added a stub which displays the build info if COUNTRY.SYS was erroneously considered being an device driver (DEVICE=COUNTRY.SYS). Also displays the same info if started as .COM program. […] Added a second compression method to further decrease the size of IBMBIO.COM. […]
[…] The DR-DOS boot sector […] searches for the IBMBIO.COM (DRBIOS.SYS) file and then loads the *whole* file into memory before it passes control to it. […]
An excerpt of the BDOS.PLM file header in thePL/M source code ofCP/M 1.1 orCP/M 1.2 forLawrence Livermore Laboratories (LLL)
[…]/* C P / M B A S I C I / O S Y S T E M (B I O S) COPYRIGHT (C) GARY A. KILDALL JUNE, 1975 */[…]/* B A S I C D I S K O P E R A T I N G S Y S T E M (B D O S) COPYRIGHT (C) GARY A. KILDALL JUNE, 1975 */[…]
[…] The first commercial licensing ofCP/M took place in 1975 with contracts betweenDigital Systems andOmron of America for use in their intelligent terminal, and withLawrence Livermore Laboratories where CP/M was used to monitor programs in theOctopus network. Little attention was paid to CP/M for about a year. In my spare time, I worked to improve overall facilities […] By this time, CP/M had been adapted for four different controllers. […] In 1976,Glenn Ewing approached me with a problem:Imsai, Incorporated, for whom Glenn consulted, had shipped a large number of disk subsystems with a promise that an operating system would follow. I was somewhat reluctant to adapt CP/M to yet another controller, and thus the notion of a separated Basic I/O System (BIOS) evolved. In principle, the hardware dependent portions of CP/M were concentrated in the BIOS, thus allowing Glenn, or anyone else, to adapt CP/M to the Imsai equipment. Imsai was subsequently licensed to distributeCP/M version 1.3, which eventually evolved into an operating system calledIMDOS. […]
[…] Whenwe failed to produce an operating system in a timely manner,Glenn started talking with Gary aboutCPM […] It took several months of twisting Gary's arm to get Gary to port it to the 8080. The final success came when Glenn talked Gary into just separating the I/O from the rest of it, with Glenn promising to re-write the I/O module for theIMSAI 8080 (which he did). So CPM on theIMSAI was a joint effort between Glenn and Gary. […]
Killian: "[…]Glenn […] would be talking withGary, and he started twisting Gary's arm. He said, "Hey Gary, why can't we run this in thisIMSAI?" "The I/O's all different, won't run." But Glenn persists and finally makes a deal with Gary. He says, "Okay Gary, if you split out the I/O, I'll write theBIOS, basic I/O's system," and Glenn named it then. "We'll split it out separately. I'll write that part, as long as you can make a division in the program there." And he got Gary to do that and Glenn put those two pieces together and was running Gary's CP/M on an IMSAI. Glenn let us know that, and it wasn't too much later thanBill was down there making arrangements with Gary Kildall to licenseCP/M. […] Now that the BIOS is separated out, anybody could write a BIOS for their machine, if it was 8080-based, and run this, so he started selling that separately under the companyDigital Research that he formed and did quite well."
