31

In MS-DOS (and FAT16), you could only have 8.3 file names (like QUESTION.TXT) with only single-case letters and numbers (and a few symbols). The MS-DOS Editor also defaulted to 8.3 - typing edit questiontxt in MS-DOS 6.22 would edit QUESTION.TXT.

While everything used 8.3, were 9.2 names possible?

For example, instead of the example above (QUESTION.TXT), would QUESTIONT.XT be an allowed filename (although it would not be practical)?

Improve this question
7
  • 16
    You could fake it by displaying an 8.3 name as 9.2 but no other program would display the name this way.
    – user722
    Jun 25, 2018 at 22:28
  • 4
    if you had two files named question.txt and questiont.xt, which one would open if you use "edit questiontxt"?
    – htmlcoderexe
    Jun 28, 2018 at 8:34
  • As I recall only vaguely, PKUNZIP 2.04g (maybe an earlier version?) could extract a long filename in MS-DOS 6.22 (possibly using the shell named 4DOS), and then it would show up in DIR. Of course, this violated specification. You couldn't use DEL on the filename (although using . worked alright-ish enough), and I would expect(/hope, for sensibility's sake) that CHECKDSK would remedy the violation (somehow, possibly by just deleting the violating file). Since so much DOS software was custom-written code, you could sometimes have non-standard situations be treated in inconsistent ways.
    – TOOGAM
    Jan 25 at 9:35
  • @TOOGAM that is a 4DOS extension: its version of DIR and various other commands look for a DESCRIPT.ION file and display file descriptions (long file names) stored there. Since this relies on a regular file, it works with any archiver, but few programs can actually work with the descriptions.
    – Stephen Kitt
    Mar 7 at 20:06
  • @StephenKitt I don't think so. I was well familiar with the hidden DESCRIPT.ION file (which is an 8.3 filename). I was familiar enough that I think I checked and COMMAND.COM showed the file too. This was too many years ago and trying to verify that would be too time consuming right now, so I realize I'm not proving much or displaying a lot of solid logic to back my point here, but I don't believe this was an issue with me not understanding the involvement of the DESCRIPT.ION file. (Even so, thank you for your feedback.)
    – TOOGAM
    Mar 7 at 22:18

3 Answers 3

Reset to default
135

No. The FAT12/16/32 filesystems store the filename and extension together in a fixed-length 11 character field. The first 8 characters of this field is the filename and the last 3 is the extension. Trailing space characters in both the filename proper and its extension are ignored. The '.' character between the filename and extension is implicit. Additionally, the '.' character is not a valid character in either the filename or the extension. Spaces, however, are permitted. Note that the above does not apply to VFAT which is its own kettle of worms.

   on disk:          on screen:
┌───────────┐
│AUTOEXECBAT│  <=>  AUTOEXEC.BAT
│CONFIG  SYS│  <=>  CONFIG.SYS
└───────────┘
Improve this answer
13
  • 21
    "kettle of worms"? as opposed to "can of fish"?
    – Martin Smith
    Jun 26, 2018 at 7:31
  • 17
    @MartinSmith Just my penchant for mangling English expressions: "Kettle of worms", "Not the sharpest pin in the cookie jar", etc.
    – Alex Hajnal
    Jun 26, 2018 at 11:28
  • 8
    And using kettle of worms to describe VFAT is putting it mildly. If you want a fun evening, try repairing a broken VFAT filesystem with a hex editor.
    – Alex Hajnal
    Jun 26, 2018 at 11:31
  • 18
    Even worse. I was once sent a data file someone had named COM_something_or_other. (For "Community".) DOS thought it was a COM port. IIRC I had go fiddle with a hex editor before anything useful could be done with it. But that's beating a dead horse of a different color.
    – MickeyfAgain_BeforeExitOfSO
    Jun 26, 2018 at 13:23
  • 6
    I still like to pass files called something like this\is:a\file, to my friends that are still using Microsoft Windows.
    – ctrl-alt-delor
    Jun 26, 2018 at 19:45
28

No. The file extension is a first class concept in the DOS file systems, a legacy of CP/M, vs, say, Unix file systems where an extension is simply a naming convention.

Improve this answer
11
  • 9
    This doesn't explain why e.g. 7.4 FAT filenames weren't possible.
    – Alex Hajnal
    Jun 25, 2018 at 23:07
  • 10
    @Alex The "legacy" defined it that way : at 8 characters on one side and 3 on the other side. So other combos were just not supported.
    – JB.
    Jun 26, 2018 at 9:10
  • 2
    @AlexHajnal The answer implies that you cannot "abuse" one character of the extension for a longer base name because the separation is hard-coded into the file system, other than for file systems that see 8.3 file names just as a string of 12 characters.
    – mastov
    Jun 26, 2018 at 9:50
  • 24
    A clearer way of saying this would be that the filesystem stores exactly 11 bytes of name, and does not store a location for the .; the location is implicit, and by convention, at position 8.
    – R.. GitHub STOP HELPING ICE
    Jun 26, 2018 at 14:50
  • 3
    While MS-DOS directly utilized the concept of an extension namespace from CP/M, that came directly from Gary Kildall's use of TOPS-10 concepts (6.3 names). That idea itself can be traced to CTSS, which had files with two part names, but no period. That's pretty close to the dawn of interactive computing.
    – user71659
    Jun 27, 2018 at 1:00
8

Setting aside the file system (other file systems besides FAT were possible on MS-DOS using redirector technology or via the shell approach (ie NetWare)), 8.3 was still a requirement due to the fact that a number of INT 21h functions used the FCB (file control block). (The FCB has hardcoded locations for filename and for the extension.) In particular functions 0Fh through 17h all used FCB(s). (See Ralf Brown's interrupt list.) So a program using FCB functions would not be able to specify a 9 character filename or a 4 character extension.

Additionally the Program Segment Prefix contained two FCBs, so any program examining PSP would need be able to interpret a non 8.3 filename.

Improve this answer
5
  • That reminds me. Do you remember a 512MB limit on hard-disks, because of a limitation on the PC-BIOS. No one sold cheep IDE any bigger than 512MB. My Amiga had a limit of several terabytes per file. So I wanted a bigger drive, but could not get one.
    – ctrl-alt-delor
    Jun 26, 2018 at 20:10
  • 2
    @ctrl-alt-delor, the limit was 504 MB (or 528 MB if you're working in metric). 1024 cylinders * 16 heads * 63 sectors * 512 bytes per sector = 528 482 304 bytes.
    – Mark
    Jun 26, 2018 at 20:24
  • @ctrl-alt-delor I don't remember. MSDOS with FAT16 and a 8192 byte logical sector size would give 512MB (64K*8192) max partition size.
    – Χpẘ
    Jun 26, 2018 at 20:24
  • @Χpẘ it was 512MB or 800MB or something like. It was caused by the incompatible intersection of limits in DOS and BIOS.
    – ctrl-alt-delor
    Jun 27, 2018 at 13:40
  • 1
    The max partition size in DOS is 2GB, but some BIOS's had a limitation around 500 megabytes. I've used MS-DOS on more modern systems, & it hasn't had a problem with 2GB partitions(of course, it can't use partitions greater than 2GB because of a limitation in FAT16).
    – JustinCB
    Jun 27, 2018 at 14:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .