5 ms·
“Note that filename cannot consist solely of spaces, but extension can.” This is the sort of thing hat makes me wonder what on earth went wrong or even could h
by code_duck 8y ago
“Note that filename cannot consist solely of spaces, but extension can.”
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?
- nradov 8y agoI don't know about that specific issue, but some of the weirdness in MS-DOS is based on precedents set by CP/M. It's not really compatible but recycled many of the same concepts.
- jandrese 8y agoCan't blame the horrible way they implemented long filename support on CP/M. I was mildly impressed at how they packed the datefield into a 16 bit value, losing only odd numbered seconds in the process.
- anyfoo 8y agoIt’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.)
- jandrese 8y agoI'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.
- anyfoo 8y agoNot 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.
- xenadu02 8y agoIIRC 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.
- 0x0 8y agoYou 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.
- ahoka 8y agoSo you can have files with "no extension"? The whole land of DOS is about fitting into stupid constraints of the era's HW.
- jstanley 8y agoBut if there were "no extension", that would be a 0-length extension, rather than a 3 character extension with 3 spaces. Even if it has to be 3 characters, shouldn't they at least be \0?
- deleted 8y ago[deleted]
- qpery 8y agoI assume any extension that consists solely of any combination of \x00 and \x20 is to be understood as "no extension"
- deleted 8y ago[deleted]
- anyfoo 8y agoSince spaces are in fact not allowed, choosing between 0 and 0x20 is pretty arbitrary here. You’d probably go for 0 today because C became popular and 0-padding has the useful property of also 0-terminating the string, but at the time that was less of a consideration.
- that_jojo 8y agoIn what world are files required to have an extension?
- tom_ 8y agoThe space for the name is pre-booked, so in a sense all files always have a full 8-char name and 3-char extension, whether they like it or not. 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.)
- hiccuphippo 8y agoWhy even treat the extension as something separate from the filename?
- fit2rule 8y agoFor me, having gotten my ears wet with CP/M, I seem to recall it was so there was a cheap means of indexing files by type if required, since there weren't much in the way of sorted lists built-in, and folders weren't really a thing either.
- reaperducer 8y agoYep. The extension was the only way a program knew what type of data to expect from a file. 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!).
- trasz 8y agoI'm not sure if it actually worked that well in DOS, but in Digital systems, which inspired the DOS shell, it was useful for default file name parts. Using analogy to Unix, the current working directory is useful as a default - to avoid having to retype it. Same with the extension, although with a different semantics.
- ben509 8y ago
- PinguTS 8y agoBecause "empty"/unused characters of the name (including the extension) shall be filled with the space character. As the names are fixed to 8.3 there is no such thing as length detection/indication for the string.
- code_duck 8y agoThat’s a description of part of the problem, not a reasonable excuse.
- red_admiral 8y agoDidn't lots of SQL databases' CHAR(n) type used to be space-padded instead of null-padded too? If I had to guess, DOS simply copied that idea: filename=CHAR(8), ext=CHAR(3) with three blanks the "NULL" value.
- dragonwriter 8y ago> Didn't lots of SQL databases' CHAR(n) type used to be space-padded instead of null-padded too? If I had to guess, DOS simply copied that idea 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.
- anyfoo 8y agoThey are not. The article mentions before that sentence that the spaces are used for padding. In DOS, filenames are fixed 8+3 structures, and unused trailing positions are padded out using spaces. You cannot, for example, have a space at the beginning of the extension, nor is the space at the end considered part of the extension at a higher level. 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).