MS-DOS and IBM PC DOS related operating systems are commonly associated with machines using the
Intel x86 or compatible
CPUs, mainly
IBM PC compatibles. Machine-dependent versions of MS-DOS were produced for many non-IBM-compatible x86-based machines, with variations from relabelling of the
Microsoft distribution under the manufacturer's name, to versions specifically designed to work with non-IBM-PC-compatible hardware. As long as application programs used DOS APIs instead of direct hardware access, they could run on both IBM-PC-compatible and incompatible machines. The original
FreeDOS kernel,
DOS-C, was derived from
DOS/NT for the Motorola 68000 series of CPUs in the early 1990s. While these systems loosely resembled the DOS architecture, applications were not binary compatible due to the incompatible instruction sets of these non-x86-CPUs. However, applications written in high-level languages could be ported easily. DOS is a single-user, single-tasking operating system with basic
kernel functions that are
non-reentrant: only one program at a time can use them, and DOS itself has no functionality to allow more than one program to execute at a time. The DOS kernel provides
various functions for programs (an
application program interface), like character I/O, file management, memory management, program loading and termination. DOS provides the ability for
shell scripting via
batch files (with the
filename extension .BAT). Each line of a batch file is interpreted as a program to run. Batch files can also make use of internal commands, such as
GOTO and
conditional statements. The operating system offers an application programming interface that allows development of character-based applications, but not for accessing most of the
hardware, such as
graphics cards,
printers, or
mice. This required programmers to access the hardware directly, usually resulting in each application having its own set of
device drivers for each hardware peripheral. Hardware manufacturers would release specifications to ensure device drivers for popular applications were available.
Boot sequence • The
bootstrap loader on PC-compatible computers, the
master boot record, is located beginning at the
boot sector, the first sector on the first track (
track zero), of the boot disk. The
ROM BIOS will load this sector into memory at address :, and typically check for a signature "" at offset . If the sector is not considered to be valid, the ROM BIOS will try the next physical disk in the row, otherwise it will jump to the load address with certain registers set up. • If the loaded boot sector happens to be a
Master Boot Record (MBR), as found on partitioned media, it will relocate itself to : in memory, otherwise this step is skipped. The MBR code will scan the partition table, which is located within this sector, for an active partition (modern MBRs check if bit 7 is set at offset , whereas old MBRs simply check for a value of ), and, if found, load the first sector of the corresponding partition, which holds the
Volume Boot Record (VBR) of that volume, into memory at : in the similar fashion as if it had been loaded by the ROM BIOS itself. The MBR will then pass execution to the loaded portion with certain registers set up. • The sector content loaded at : constitutes a VBR now. VBRs are operating system specific and cannot be exchanged between different DOS versions in general, as the exact behaviour differs between different DOS versions. In very old versions of DOS such as DOS 1.x, the VBR would load the whole IO.SYS/IBMBIO.COM file into memory at :. For this to work, these sectors had to be stored in consecutive order on disk by using the SYS command. In later issues, it would locate and store the contents of the first two entries in the root directory at : and if they happen to reflect the correct boot files as recorded in the VBR, the VBR would load the first 3 consecutive sectors of the IO.SYS/IBMBIO.COM file into memory at :. The VBR also has to take care to preserve the contents of the
Disk Parameter Table (DPT). Finally, it passes control to the loaded portion by jumping to its entry point with certain registers set up (with considerable differences between different DOS versions). • In later DOS versions, where the VBR has loaded only the first 3 sectors of the IO.SYS/IBMBIO.COM file into memory, the loaded portion contains another boot loader, which will then load the remainder of itself into memory, using the root directory information stored at :. For most versions, the file contents still need to be stored in consecutive order on disk. In older versions of DOS, which were still loaded as a whole, this step is skipped. • The DOS system initialization code will initialize its built-in device drivers and then load the DOS kernel, located in
MSDOS.SYS on MS-DOS systems, into memory as well. In Windows 9x, the DOS system initialization code and built-in device drivers and the DOS kernel are combined into a single IO.SYS file while MSDOS.SYS is used as a text configuration file. • The
CONFIG.SYS file is then read to
parse configuration parameters. The variable specifies the location of the
shell which defaults to
COMMAND.COM. • The shell is loaded and executed. • The startup batch file
AUTOEXEC.BAT is then run by the shell. The DOS system files loaded by the boot sector must be
contiguous and be the first two
directory entries. As such, removing and adding this file is likely to render the media unbootable. It is, however, possible to replace the shell at will, a method that can be used to start the execution of dedicated applications faster. This limitation does not apply to any version of DR DOS, where the system files can be located anywhere in the root directory and do not need to be contiguous. Therefore, system files can be simply copied to a disk provided that the boot sector is DR DOS compatible already. In PC DOS and DR DOS 5.0 and above, the DOS system files are named
IBMBIO.COM instead of
IO.SYS and
IBMDOS.COM instead of
MSDOS.SYS. Older versions of DR DOS used DRBIOS.SYS and DRBDOS.SYS instead. Starting with
MS-DOS 7.0 the binary system files IO.SYS and MSDOS.SYS were combined into a single file IO.SYS whilst MSDOS.SYS became a configuration file similar to CONFIG.SYS and AUTOEXEC.BAT. If the MSDOS.SYS
BootGUI directive is set to 0, the boot process will stop with the command processor (typically COMMAND.COM) loaded, instead of executing WIN.COM automatically.
File system DOS uses a filesystem which supports
8.3 filenames: 8 characters for the filename and 3 characters for the extension. Starting with DOS 2 hierarchical directories are supported. Each directory name is also 8.3 format but the maximum directory path length is 64 characters due to the internal current directory structure (CDS) tables that DOS maintains. Including the drive name, the maximum length of a fully qualified filename that DOS supports is 80 characters using the format drive:\path\filename.ext followed by a null byte. DOS uses the
File Allocation Table (FAT) filesystem. This was originally
FAT12 which supported up to 4078 clusters per drive. DOS 3.0 added support for
FAT16 which used 16-bit allocation entries and supported up to 65518 clusters per drive.
Compaq MS-DOS 3.31 added support for
FAT16B which removed the 32‑
MiB drive limit and could support up to 512 MiB. Finally MS-DOS 7.1 (the DOS component of Windows 9x) added support for
FAT32 which used 32-bit allocation entries and could support hard drives up to 137 GB (127 GiB) and beyond. Starting with DOS 3.1, file redirector support was added to DOS. This was initially used to support networking but was later used to support CD-ROM drives with
MSCDEX. IBM PC DOS 4.0 also had preliminary installable file system (IFS) support but this was unused and removed in DOS 5.0. DOS also supported Block Devices ("Disk Drive" devices) loaded from CONFIG.SYS that could be used under the DOS file system to support network devices.
Drive naming scheme In DOS, drives are referred to by identifying letters. Standard practice is to reserve "A" and "B" for
floppy drives. On systems with only one floppy drive DOS assigns both letters to the drive, prompting the user to swap disks as programs alternate access between them. This facilitates copying from floppy to floppy or having a program run from one floppy while accessing its data on another.
Hard drives were originally assigned the letters "C" and "D". DOS could only support one active partition per drive. As support for more hard drives became available, this developed into first assigning a drive letter to each drive's active
primary partition, then making a second pass over the drives to allocate letters to logical drives in the
extended partition, then a third pass to give any other non-active primary partitions their names (where such additional partitions existed and contained a DOS-supported file system). Lastly, DOS allocates letters for
optical disc drives,
RAM disks, and other hardware. Letter assignments usually occur in the order the drivers are loaded, but the drivers can instruct DOS to assign a different letter; drivers for network drives, for example, typically assign letters nearer to the end of the alphabet. Because DOS applications use these drive letters directly (unlike the /dev directory in
Unix-like systems), they can be disrupted by adding new hardware that needs a drive letter. An example is the addition of a new hard drive having a primary partition where a pre-existing hard drive contains logical drives in extended partitions; the new drive will be assigned a letter that was previously assigned to one of the extended partition logical drives. Moreover, even adding a new hard drive having only logical drives in an extended partition would still disrupt the letters of RAM disks and optical drives. This problem persisted through Microsoft's DOS-based 9x versions of Windows until they were replaced by versions based on the NT line, which preserves the letters of existing drives until the user changes them. The reserved names are: • COM1 through COM9 (
serial communication ports) • LPT1 through LPT9 (
Parallel port for
line printers) • CON ("console"; represents keyboard in the input
stream and display in the output stream) • AUX ("auxiliary"; represents the first connected COM port) • NUL (
null device) added in
86-DOS 1.10 and
PC DOS 1.0 In
Windows 95 and
Windows 98, typing in the location of the reserved name (such as CON/CON, AUX/AUX, or PRN/PRN) crashes the operating system, of which Microsoft has provided a security fix for the issue. In
Windows XP, the name of the file or folder using a reserved name silently reverts to its previous name, with no notification or error message. In
Windows Vista and later, attempting to use a reserved name for a file or folder brings up an error message saying "The specified device name is invalid." These names (except for NUL) have continued to be supported in all versions of MS-DOS, PC DOS and DR-DOS ever since. LST was also available in some OEM versions of MS-DOS 1.25, whereas other OEM versions of MS-DOS 1.25 already used LPT1 (first
line printer) and COM1 (first
serial communication device) instead, as introduced with PC DOS. In addition to LPT1 and LPT2 as well as COM1 to COM3, Hewlett-Packard's OEM version of
MS-DOS 2.11 for the
HP Portable Plus also supported LST as alias for LPT2 and 82164A as alias for COM2; The PLT device (present only in some HP OEM versions of MS-DOS) was reconfigurable as well. Filenames ended with a
colon () such as NUL: conventionally indicate device names, but the colon is not actually a part of the name of the built-in device drivers. Colons are not necessary to be typed in some cases, for example: ECHO This achieves nothing > NUL It is still possible to create files or directories using these reserved device names, such as through direct editing of directory data structures in disk sectors. Such naming, such as starting a file name with a space, has sometimes been used by viruses or hacking programs to obscure files from users who do not know how to access these locations.
Memory management DOS was designed for the Intel 8088 processor, which can only directly access a maximum of 1 MiB of RAM. Both IBM and Microsoft chose 640
kibibytes (KiB) as the maximum amount of memory available to programs and reserved the remaining 384 KiB for video memory, the
read-only memory of adapters on some video and network peripherals, and the system's BIOS. By 1985, some DOS applications were already hitting the memory limit, while much of reserved was unused, depending on the machine's specifications. Specifications were developed to allow access to additional memory. The first was the
Expanded Memory Specification (EMS) was designed to allow memory on an add-on card to be accessed via a 64 KiB page frame in the reserved upper memory area. 80386 and later systems could use a
virtual 8086 mode (V86) mode memory manager like
EMM386 to create expanded memory from extended memory without the need of an add-on card. The second specification was the
Extended Memory Specification (XMS) for 80286 and later systems. This provided a way to copy data to and from extended memory, access to the 65,520-byte
high memory area directly above the first megabyte of memory and the
upper memory block area. Generally XMS support was provided by
HIMEM.SYS or a V86 mode memory manager like
QEMM or
386MAX which also supported EMS. Starting with DOS 5, DOS could directly take advantage of the HMA by loading its kernel code and disk buffers there via the DOS=HIGH statement in CONFIG.SYS. DOS 5+ also allowed the use of available upper memory blocks via the DOS=UMB statement in CONFIG.SYS.
DOS under OS/2 and Windows The DOS emulation in OS/2 and Windows runs in much the same way as native applications do. They can access all of the drives and services, and can even use the host's clipboard services. Because the drivers for file systems and such forth reside in the host system, the DOS emulation needs only provide a DOS API translation layer which converts DOS calls to OS/2 or Windows system calls. The translation layer generally also converts BIOS calls and virtualizes common I/O port accesses which many DOS programs commonly use. In Windows 3.1 and 9x, the DOS virtual machine is provided by WINOLDAP. WinOldAp creates a virtual machine based on the program's PIF file, and the system state when Windows was loaded. The DOS graphics mode, both character and graphic, can be captured and run in the window. DOS applications can use the Windows clipboard by accessing extra published calls in WinOldAp, and one can paste text through the WinOldAp graphics. The emulated DOS in OS/2 and Windows NT is based upon DOS 5. Although there is a default configuration (config.sys and autoexec.bat), one can use alternate files on a session-by-session basis. It is possible to load drivers in these files to access the host system, although these are typically third-party. Under OS/2 2.x and later, the DOS emulation is provided by DOSKRNL. This is a file that represents the combined IBMBIO.COM and IBMDOS.COM, the system calls are passed through to the OS/2 windowing services. DOS programs run in their own environment, the bulk of the DOS utilities are provided by bound DOS / OS2 applications in the \OS2 directory. OS/2 can run Windows 3.1 applications by using a modified copy of Windows (Win-OS/2). The modifications allow Windows 3.1 programs to run seamlessly on the OS/2 desktop, or one can start a WinOS/2 desktop, similar to starting Windows from DOS. OS/2 allows for 'DOS from Drive A:', (VMDISK). This is a real DOS, like MS-DOS 6.22 or PC DOS 5.00. One makes a bootable floppy disk of the DOS, adds a number of drivers from OS/2, and then creates a special image. The DOS booted this way has full access to the system, but provides its own drivers for hardware. One can use such a disk to access cdrom drives for which there is no OS/2 driver. In all 32-bit (IA-32) editions of the Windows NT family since 1993, DOS emulation is provided by way of a
virtual DOS machine (NTVDM). 64-bit (IA-64 and x86-64) versions of Windows do not support NTVDM and cannot run 16-bit DOS applications directly; third-party emulators such as DOSbox can be used to run DOS programs on those machines. == User interface ==