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.

Who trusts whom

Operating system

Trusts BPBs according to these rules for the OEM Name field

PC-DOS version 3.0

Test

Result

First 4 characters are not 'I', 'B', 'M', ' '

Make up own BPB

Last 3 characters are '2', '.', '0'

Use given BPB

Else

Make up own BPB

In other words: Only trust PC-DOS 2.0.

Compaq DOS version 3.0

Test

Result

First 4 characters are 'C', 'C', 'C', ' '
and characters 6 and 7 are '2' and '.'

Use given BPB

First 4 characters are not 'I', 'B', 'M', ' '

Make up own BPB

Last 3 characters are '2', '.', '0'

Use given BPB

Last 3 characters are '3', '.', '0'

Use given BPB

Else

Make up own BPB

In other words: Only trust Compaq DOS 2.x, PC-DOS 2.0, and PC-DOS 3.0.

PC-DOS version 3.1

Test

Result

First 4 characters are not 'I', 'B', 'M', ' '

Make up own BPB

Last 3 characters are '2', '.', '0'

Use given BPB

Last 3 characters are '3', '.', '1'

Use given BPB

Else

Make up own BPB

In other words: Only trust PC-DOS 2.0, and PC-DOS 3.1.

PC-/MS-DOS versions 3.2 and 3.21

Test

Result

First 4 characters are not 'I', 'B', 'M', ' '

Make up own BPB

Last 3 characters are '2', '.', '0'

Use given BPB

Characters 6 and 7 are not '3', '.'

Make up own BPB

Character 8 is either '0' or '2'

Use given BPB

Else

Make up own BPB

In other words: Only trust PC-DOS 2.0, PC-DOS 3.0, and PC-DOS 3.2.

MS-DOS version 3.3

Test

Result

First 4 characters are not 'I', 'B', 'M', ' '

Make up own BPB

Last 3 characters are '2', '.', '0'

Use given BPB

Characters 6 and 7 are not '3', '.'

Make up own BPB

Character 8 is less than '1'

Use given BPB

Else

Use given BPB

In other words: Only trust PC-DOS 2.0 and all PC-DOS 3.x except
PC-DOS 3.0 and lower.

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

Test

Result

Last 3 characters are '2', '.', '0'

Use given BPB

Characters 5 to 7 are '1', '0', '.' or '2', '0', '.'

Use given BPB

Characters 6 and 7 are '0', '.'

Make up own BPB

Word 4 is less than 0x2E33 ('3.')

Make up own BPB

Word 4 is greater than 0x2E33 ('3.')

Use given BPB

Character 8 is less than '1'

Make up own BPB

Else

Use given BPB

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)

Test

Result

First 3 characters are 'I', 'B', 'M'

Use given BPB

First 5 characters are 'M', 'S', 'D', 'O', 'S'

Use given BPB

First 5 characters are 'D', 'R', 'D', 'O', 'S'

Use given BPB

First 5 characters are 'M', 'S', 'W', 'I', 'N'

Use given BPB

First 5 characters are 'M', 'T', 'O', 'O', 'L'

Use given BPB

First 7 characters are 'm', 'k', 'd', 'o', 's', 'f', 's'

Use given BPB

First 8 characters are 'C', 'H', '-', 'F', 'O', 'R', '1', '8'

Use given BPB

Else

Treat the volume as unformatted

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.