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
format command in IBM PC-DOS version n.m
in Microsoft OS/2 version n.m
format command (specifically the
back-end DLLs for that command) in IBM OS/2 version n.m
format command in Microsoft MS-DOS version n.m
format command in Microsoft DOS-Windows version n.m and
Microsoft Windows NT version n.m
format command in Novell DOS version n.m
format command in DR-DOS version n.m
mformat command in the mtools utility suite for Linux
mkdosfs command in Linux
|Format utility in PC Tools
format command in TAU
format command in RxDOS version n.m
|disk administration tool in Windows NT 2003
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.
|Trusts BPBs according to these rules for the OEM Name field
|PC-DOS version 3.0
In other words: Only trust PC-DOS 2.0.
|Compaq DOS version 3.0
In other words: Only trust Compaq DOS 2.x, PC-DOS 2.0, and PC-DOS 3.0.
|PC-DOS version 3.1
In other words: Only trust PC-DOS 2.0, and PC-DOS 3.1.
|PC-/MS-DOS versions 3.2 and 3.21
In other words: Only trust PC-DOS 2.0, PC-DOS 3.0, and PC-DOS 3.2.
|MS-DOS version 3.3
In other words: Only trust PC-DOS 2.0 and all PC-DOS 3.x except PC-DOS 3.0 and lower.
|Compaq DOS version 3.31
In other words: Trust everything except PC-DOS 3.0 or anything that uses a non-printable-US-ASCII OEM Name.
Compaq DOS 3.31 also tests that the jump instruction at the start of the boot block is valid, that the high order nybble of the BPB's media descriptor byte is 0xF, and that the cluster size in the BPB is a power of 2.
|PC-/MS-DOS version 5.0
In other words: Trust versions 2.0, 10.x, and 20.x of everything. Don't trust version x0.x of anything (i.e. both version 0.x and versions 30.x to 90.x). Don't trust any version less than 3.x of anything. Trust versions 4.x to 9.x of everything. Don't trust version 3.1 of anything.
PC-/MS-DOS 5.0 also tests that the jump instruction at the start of the boot block is valid, that the high order nybble of the BPB's media descriptor byte is 0xF, that the sector size in the BPB is 512, and that the cluster size in the BPB is a power of 2.
|Linux (util-linux up to at least version 2.12)
The reason for this is that one version of MS-DOS and PC-DOS (or, rather,
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
formatcommand. 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 "
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.
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
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.