It’s horrible, but compatibility often leads to horrible things. Remember that they wanted disks with long file names to work on old systems, and have them be able to manipulate files with long file names as usual (through their short names), in all kinds of manners.

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.)

I'm saying that even taking reverse compatibility into mind (which they didn't even have, FAT32 couldn't be read by a FAT16 driver) the way the filenames are encoded is a mess with the name being split up by attribute and checksum bytes.

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.

Not sure what you mean. They did it precisely for compatibility. It worked for FAT16 (and probably FAT12, for that matter) as well, and in fact long file names came before FAT32. Anything that would trip up older DOS versions or any other FAT consumers was a no-go.

IIRC Long filename support was introduced with Windows 95, which shipped with FAT16. It wasn’t until OSR2 that they introduced FAT32.

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.

You could boot into pure DOS in win9x even on fat32, and pure DOS does not support long file names. Perhaps they kept that hack to be compatible with the fat32 "light" implementation of the DOS that shipped with win9x.