MS-DOS OAKs

Prior to 1991, Microsoft did not sell MS-DOS to end users directly. Although MS-DOS 3.2 (1986) and later was available to system builders as a “packaged product”, most PC users would get an OEM version of MS-DOS with a new computer. Before 1986, that was the only way to get MS-DOS at all. Or DOS in general, if PC DOS is counted as a very special OEM version of MS-DOS. But where did the OEM versions come from?

Microsoft shipped DOS to OEMs in the form of the MS-DOS OEM Adaptation Kit, or OAK. The OAK consisted of binary files, source files, object files, and electronic documentation required to “install” MS-DOS on (or port to) an OEM platform. Over time, as the PC hardware was converging and DOS was evolving, the amount of code OEMs needed to adapt was getting smaller and the bulk of OEM versions of MS-DOS consisted of unmodified binaries provided by Microsoft. In fact Microsoft did not want OEMs to make significant changes, since Microsoft wanted to avoid unnecessary differences between various OEM releases of MS-DOS.

The OS/2 Museum has access to the OAKs for MS-DOS 3.21 and 3.30, covering roughly the 1986-1990 time period when those DOS versions were prevalent. A typical MS-DOS OAK can therefore be examined in closer detail.

The MS-DOS 3.21 OAK is from May 1987 while the 3.30 OAK is from July of the same year. The two versions are not substantially different, although traces of the evolution of DOS between those two versions are clearly visible.

The OAK reflected the structure of MS-DOS, with the “BIOS” (IO.SYS or IBMBIO.COM) on the lowest level, the “DOS” (MSDOS.SYS or IBMDOS.COM) in the center, and the shell (typically COMMAND.COM) running on top.

The OAK contained the full source code to IO.SYS, since that was the part of DOS closest to the hardware and most likely to require adapting to the OEM’s platform. That said, by the time MS-DOS 3.2 appeared, the PC hardware was getting increasingly uniform and the changes a typical OEM would need to make weren’t major. Even so, there was still room for heavily customized hardware.

The DOS itself (MSDOS.SYS) was only shipped in the form of object files at that time. Microsoft had realized that an increasing number of utilities and applications relied on certain details of DOS implementation and OEMs should not be allowed to change those internals (nor should they have any need to). This became especially important after the release of DOS 3.0 when network redirectors heavily relied on various details of internal DOS implementation (such as DOS data segment layout). However, OEMs still had the option of making additions and relinking MSDOS.SYS.

The command shell, COMMAND.COM, was only shipped as a binary and OEMs were not expected to modify it. On the other hand, several hardware-specific utilities were shipped with full source code. That included FORMAT and SYS which dealt with possibly non-IBM-compatible storage devices, PRINT which could be modified to support OEM printers, and SORT which could be adapted for national collating sequences.

The base OAK only allowed limited customization of DOS utilities messages. On request, OEMs could receive additional disks with tools for customizing (and typically translating) messages.

The boot sector source code was also provided and could be modified by the OEM. The assembled boot sector was inserted into the FORMAT and SYS utilities.

It is likely that the MS-DOS 3.2 OAK was somewhat different from the previous releases, simpler and more streamlined. In version 3.2, Microsoft abstracted the low-level disk interface with the addition of generic IOCTLs. With that change in place, Microsoft rather than the OEM supplied utilities like FORMAT and SYS. That reduced the OEMs’ effort in adapting MS-DOS and at the same time made MS-DOS more uniform across OEM releases.

To give the reader a better picture of what was (or wasn’t) in an OAK, here’s the MS-DOS 3.21 OAK README file. The README file included a complete file list as well as a list of both resolved and unresolved known bugs in MS-DOS.

The Adaptation Guide (AG) was the primary OAK documentation and provided the OEMs with basic guidance for adapting MS-DOS to their systems. The AG included excerpts from the MS-DOS Programmer’s Guide, but also included additional information. For example, the GET_DPB call (INT 21h/32h), not described in the official MS-DOS programming information, was documented in the OAK.

The OAK also contained user documentation in ASCII format. It was assumed that the OEM would modify or enhance it as necessary and format the documentation in accordance with its own standards. Any screen captures were likewise to be supplied by the OEM, since they were likely to contain customized messages. For OEMs with highly IBM-compatible hardware, it is possible that adapting the documentation may have taken more effort than adapting MS-DOS itself.

Note: The OS/2 Museum is looking for other MS-DOS OEM Adaptation Kits, both older and newer than the 1987 kits. 5¼” disks welcome.