28

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
2
  • 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 '18 at 22:28
  • 3
    if you had two files named question.txt and questiont.xt, which one would open if you use "edit questiontxt"? – htmlcoderexe Jun 28 '18 at 8:34
128

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
14
  • 11
    This should be the accepted answer, as it hits the nail: A FAT12/16/32 file name consists of two fields: 8 characters (base) file name, and 3 characters file name extension. – rexkogitans Jun 26 '18 at 7:08
  • 20
    "kettle of worms"? as opposed to "can of fish"? – Martin Smith Jun 26 '18 at 7:31
  • 14
    @MartinSmith Just my penchant for mangling English expressions: "Kettle of worms", "Not the sharpest pin in the cookie jar", etc. – Alex Hajnal Jun 26 '18 at 11:28
  • 7
    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 '18 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 '18 at 13:23
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
  • 8
    This doesn't explain why e.g. 7.4 FAT filenames weren't possible. – Alex Hajnal Jun 25 '18 at 23:07
  • 9
    @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. With Monica. Jun 26 '18 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 '18 at 9:50
  • 23
    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 '18 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 '18 at 1:00
7

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 '18 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 '18 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 '18 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 '18 at 13:40
  • 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 '18 at 14:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.