This is the sort of thing hat makes me wonder what on earth went wrong or even could have been right about Microsoft. Why would spaces be permittable in a file extension at all, ever?
So it’s really just an internal representation detail. You might argue that padding with 0 would be better (if you go for fixed size at all), and nowadays that’s what you’d probably use, but it’s kind of arbitrary anyway, and since spaces were illegal in file names, they just used that. Today, 0 has the useful property of also acting as the terminator for zero terminated strings, which became popular through C. Back then, that mattered less.
Contrast this with modern file systems, where spaces in extensions are allowed (just like anywhere else in the file name, as the distinction usually does not exist on the fs level anymore).
I was mildly impressed at how they packed the datefield into a 16 bit value, losing only odd numbered seconds in the process.
I’m not saying it’s good, but MS at the time had compatibility as one of their highest priority, so that’s what they were going for.
(But the parent’s comment is about the initial implementation, not long file names.)
One has the impression that it looks like it does because they didn't want to touch most of the FAT16 driver code and instead tried to make touchups around the edges.
In theory FAT32 could have introduced a new on-disk data structure but I guess they wanted the minimum required changes to support larger disks.
As the names are fixed to 8.3 there is no such thing as length detection/indication for the string.
DOS couldn't have copied what lots of SQL databases did, since DOS was being written around the same time as the first SQL databases.
My guess would be that, like the three character extension itself, this came from CP/M, not SQL.
Even if it has to be 3 characters, shouldn't they at least be \0?
If you want to support <8-char names, <3-char extensions, or no extension at all, you need to decide on values that indicate this, because those bytes will still need filling with something.
(On 6502-based systems, 0 would be a reasonable choice for a padding value, because you get a free zero check every time you read a byte. The 8086 doesn't work like this... I don't think any particular value suggests itself. Perhaps they thought picking a printable character would be useful.)
EDIT: see https://en.wikipedia.org/wiki/Dir_(command)#/media/File:Spar... for an example.
extension COM: just load the file into memory and start executing from the very beginning (I think the max size of these might have been 64KB or something).
extension EXE: this is a "full" executable with different segments - load it properly
extension BAT: this is a "shell" script, run it with the interpreter
The advantages of COM over EXE were slightly smaller file size on disk and slightly faster startup as you didn't have to set up segments and stuff first. Some versions of DOS even had a program called EXE2BIN that converted an EXE file into a COM file, if this was possible. The joys of the 16-bit "tiny" memory model ...
There was no space on a disk for metadata. You couldn't put metadata on a tape. There wasn't enough memory in the computer for the OS to determine a file type by reading a header, and even if there was, some operating systems had their DOS in ROM, so that would mean never adding any more file types (I'm looking at you, CBM PRG, USR, SEQ, REL files!).
Read a chunk of directory entries into a buffer.
Set ptr to start of the buffer.
Check the extension at ptr[8].
If extension matches, do a thing.
Set ptr to ptr + 32 and loop.
Note that this is for MS-DOS 2.0 which didn't handle "*.FOO" searches on the kernel side (the star expansion was done on the COMMAND.COM side via the MakeFcb [2] procedure). MS-DOS 3.0 introduced the star wildcard on the kernel side, so it might have taken advantage of that... but there isn't source code for MS-DOS 3.0.
[0] https://github.com/Microsoft/MS-DOS/tree/master/v2.0/source
[1] https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/...
[2] https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/...
Also note that DOS 2.0 incurred quite significant changes to fs code, as it was the first version to support directories. Before that, the namespace was flat.
MS-DOS 1.25 does pattern matching mostly the same way [0]. The code is a bit simpler as it doesn't have the crazy macro stuff that MS-DOS 2.0 code has, but if you look a bit around the files, you'll see that it is mostly the same code just moved around and split in several files. The file scan works again in almost the same way, reading each directory entry one by one and doing the pattern matching after the fact.
[0] https://github.com/Microsoft/MS-DOS/blob/master/v1.25/source...
Read "x" as *, because I could not for the life of me get the star work as a star within a word in this comment.