The meaning and use of the OEM Name field in volume boot blocks

You've come to this page because you've asked a question similar to

What is the meaning of the OEM Name field in volume boot blocks? How is the field used?

This is the Frequently Given Answer to those questions. You can read an alternative approach by John Elliot

Although described in much documentation as part of the BIOS Parameter Block, the OEM Name field in a volume boot block is technically not a part of the BPB at all. It is intended to be the name of the manufacturer of the tool that formatted the volume. (So you will find OEM names such as "MSWIN4.1" and "mkdosfs", for example.) It is not intended to be anything more. It certainly isn't any sort of signature to indicate the existence of or the validity of a BPB.

That's as far as most documentation for this field goes. Web pages such as Alex Verstak's guide to the boot sector describe it as "absolutely useless for any other purpose" other than printing out.

They are wrong.

In practice, Microsoft/IBM operating systems check the OEM name field to determine whether they believe the contents of the following BPB.

The reason for this is that one version of MS-DOS and PC-DOS (or, rather, the format command that was bundled with it) was known to create incorrect BPBs. So Microsoft added a kludge to the following versions of MS-DOS and PC-DOS whereby when mounting a volume it would check the OEM Name field to determine which format command from which version of MS-DOS or PC-DOS had created the accompanying BPB, and simply ignore the BPB if it deemed it to have been created by a tool that it deemed to be bad at writing BPBs, making make up a BPB on the fly for the volume, based upon the volume size, and using that instead.

As an object lesson in why such kludges are bad, consider the example of Microsoft MS-DOS 3.x. It implements the kludge to check the OEM Name field, to work around the bug in the PC-/MS-DOS 3.0 format command. But its implementation of the kludge to work around another bug is itself buggy. Ironically, Microsoft MS-DOS version 3.x doesn't trust its own BPBs, because it writes OEM Names of the form "MSDOSn.nn" but only trusts OEM names that begin with the prefix "IBM".

This kludge was then adopted by the DASD manager in OS/2 and by Windows NT. None of the operating systems that employ it mention that they do in their documentation, however.

The mount command in Linux also attempts to employs this kludge, but gets it wrong. Rather than employing the kludge as the sanity check it is intended to be, it employs it as an existence check. If Linux deems the BPB to have been created by a format command that it deems to be bad at writing BPBs, it doesn't sanitize the BPB as PC-/MS-DOS and OS/2 do. It simply behaves as if there is no BPB there at all, and as if the volume isn't formatted at all.

This undocumented handling of the OEM Name field is not only a design disaster it is an implementation disaster, as well.

It is a design disaster because the field cannot be used as designed as a result of what Linux and Microsoft operating systems do. New tools for formatting volumes cannot just use their own names, as the field is intended to be used, because if they do Microsoft/IBM operating systems will ignore the BPB fields of the volumes that they create/write (using BPBs made up on the fly instead) and Linux will fail to recognize the volumes entirely.

Using the field in ways that it was not intended to be used is a design disaster, too. The Volume Tracker in DOS-Windows 9x and DOS-Windows ME rewrites OEM Name fields on the fly, using the OEM Name field as a poor man's disc GUID, which was not its intended purpose. Aside from all of the difficulties that this caused for anti-virus programs (that watch for things that modify volume boot blocks) and OEM-supplied discs for firmware upgrades, this caused problems for discs that weren't formatted in the conventional manner (i.e. where their actual BPB does not contain the same values as the BPB that Microsoft DOS-Windows would make up for the size of the volume — such as using a different choice of cluster size to the choice that DOS-Windows makes, for example). A disc with an unconventional format, but with a trusted OEM Name, would be happily recognized by DOS-Windows 9x/ME until the DOS-Windows Volume Tracker overwrote the OEM Name. Because DOS-Windows 9x/ME doesn't trust the OEM Name values that its own Volume Tracker writes, the on-disc BPB with the unconventional values would be ignored, DOS-Windows would use its own made-up BPB, whose values wouldn't match the actual format of the disc concerned, and the disc would become unreadable.

It is an implementation disaster because not only are the various checks different for MS-DOS, PC-DOS, OS/2, and Linux, they are different for individual different versions of those operating systems. In fact, there is only one value for the OEM name field that all versions of all operating systems will agree to mean that the creator of the BPB is to be trusted: "IBM  2.0". This is ironic, because it is the converse of what should have been the case.

The growth in the number of checks made, in successive operating systems, has in fact been entirely unnecessary. Most of the growth in the checking logic has been to allow new operating system versions that the older checks were too narrow to include. Some of the additional checks in MS-DOS version 5.0, for example, are to allow it to recognize BPBs written by OS/2. (OS/2 versions 1.x and 2.x pretend to be DOS versions 10.x and 20.x to DOS programs. This pretense has been carried over into the OEM Name field.) And each time, the habit has been to make the checks too narrow, so that they have to be expanded yet again when new operating system versions appear. There is no reason to distrust a hypothetical OS/2 version 3.x, but MS-DOS 5.0 does. There is no reason to distrust any version of MS-DOS except version 3.0, but all versions of MS-DOS prior to version 5.0 have not trusted any version of MS-DOS, even themselves.

None of the growth has been to account for any new buggy format programs that came along. In fact it is only the format command in PC-DOS 3.0 that is known to systematically write incorrect BPBs. It should have been the case that any OEM Name at all apart from one, "IBM  3.0", should be usable. Only one test has ever actually been needed. (Compaq DOS 3.31 is the closest to what should have been the case for every operating system.) But it is actually the case that because each time the tests have been implemented too narrowly, and with no thought to forwards compatibility, every OEM Name apart from one, "IBM  2.0", is unusable because at least one operating system doesn't trust it.

On the gripping hand, given that the number of volumes formatted with the PC-DOS version 3.0 format command that a modern operating system has to deal with is exceedingly small nowadays, over two decades since that operating system was superceded, it is quite silly that modern operating systems are still employing these checks on the OEM Name field at all. (That is not to say that sanity checks on the BPB itself, checking that the sector size matches that of the physical disc, are inappropriate, of course.) There is no real reason that the OEM Name cannot be restored to its original intended use, and all of these checks on it removed from modern operating systems, allowing creators of future operating systems and disc formatting tools to use their own names, instead of having to pretend to be IBM or Microsoft.