Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
On microcomputers, the famously laughed 8.3 file names (by Amiga and Mac users!) were used by PC/MS-DOS, which in turn inherited this limit from CP/M. But why did Gary Kildall use this scheme of eight plus three for CP/M?
It was because the fairly common 6.3 scheme of the time was considered too small :-)
Seriously: 8.3 wasn't a particularly onerous restriction at the time. Many PDP-11 operating systems had a 6 character name, 3 character extension (all upper-case) limit. The TOPS-10 system, on PDP-10, similarly had 6.3 as a limit. Some PDP-8 systems had a 6.2 limit.
These are technical limits:
PDP-11, 16-bit words: so 2 words name, 1 word extension (in RAD50)
PDP-10, 36-bit words: so 1 word name, a halfword extension (in SIXBIT)
PDP-8, 12-bit words: so 3 words name, 1 word extension (I suppose a 6-bit code)
I list DEC systems since they are the ones I was familiar with, but other contemporary systems would have been similar.
Early UNIX on PDP-11 was a little more restricted: 8 char filenames, with no special provision for an extension (so any dot would have been part of the stored name, unlike DEC systems). See DIRECTORY (V) in the 1971 manual.
CP/M and DOS show a certain amount of DEC familiarity in their structures, in any case. Microcomputer OS implementors with experience on other systems would have applied that experience to their own design.
Going back a little further, CTSS (on IBM 7090/7094, possibly the first interactive system) named files with two "names", which you can regard as equivalent to name and extension. Each was 6 characters, or one 36-bit word.
In general, many early system designers opted for fixed-length structures. They are easier to deal with, and since storage was not plentiful, smaller fixed-length structures were preferred. Just enough to get the job done was sufficient.
So, I can't say exactly why 8.3 and not some other small size, but small was certainly adequate by most contemporary standards. A name didn't need to be written out as an English sentence; it was simply required to be reasonably mnemonic. Given, for example, that all RSX-11M drivers had names like xxDRV.SYS, it was perfectly obvious what each driver was for. We didn't even need to use the full 6 characters :-)
[Part of what is described here can be found on Herb Johnson's great site about CP/M history, the other is experience of 30+ years in mainframe procedure]
CP/M was, Dave explains, heavily influenced by DEC's TOPS-10 operating system, one Kildall was quite familiar with. Its 6.3 structure nicely fits the 36-bit nature of the PDP-10 (as well as other DEC machines).
But to get to CP/M, the story took several intervening turns.
Kildall wrote 8008 emulators and a PL/M compiler for Intel (later used in the upcoming ISIS operating system). The compiler was developed on a PDP-10 in Fortran under TOPS-10 - Intel used PDP-10 before the MDS-800 (the first 8080-based development system, running ISIS) was ready.
At that time, Kildall had already started a project to make PL/M a self-hosted system on an 8008 and later 8080. He tried to sell this to Intel, but Intel refused, as they believed then that all development would stay on minicomputer systems (notably PDP-10). Systems like the Intelec-8 were only intended for debugging and as a flexible environment for prototypes.
This changed soon and Intel opted to develop the Multibus and the MCS-800 as a stand-alone 8080-based development system - with ISIS as its designated operating system. Except Intel opted to develop in-house, not using Kildall's offer.
Being, for the most part, a down-port of the tools used on the PDP-10, it came naturally that ISIS used many of the conventions of TOPS-10, including a file system with a 6.3 name convention.
Kildall in turn acquired one of the first MDS-800 systems (running ISIS) to finish his CP/M project for generic 8080 machines. The very first known version of CP/M has a BIOS fitting the MDS-800.
While proven to work fine in many DEC installations, the 6.3 scheme had a huge shortcoming when transferring/accessing IBM files, as IBM used a basic 8-character file name for tape files and in turn also for (floppy) disk (*1). Transferring an IBM file to TOPS-10 more often than not ended up crippling the name - especially if the extension had to be spared for TOPS-10 usage. It's easy to imagine how this resulted in endless problems when exchanging more than one file at a time.
Increasing the file name size to 8.3 added legroom to reduce such issues.
Equally importantly, the CP/M catalogue entry simply had room to do so. One catalogue entry is 32 bytes, of these the first 16 are used to store the metadata, while the second store up to 16 block numbers the file uses.
3 bytes were needed for organisation, which would leave 13 for a file name. Instead of using all, two were kept as reserved (*2), resulting in the 8.3 structure we know (*3).
So in the end it's simply what was possible without spending everything.
*1 - Well, no, it's not 8, but 17 in a volume label, or 44 in a catalog entry, which are again made up of one or multiple times 1..8 characters joined by a '.' giving something we would today call sub-directories - except they weren't really ones. Confusing? Well, not really, but an explanation would need quite some room to describe each environment. In the end and for all practical means, exchange files were usually kept to 8 character names.
*2 - Quite a good idea as one of these was later (CP/M 2.x) used to allow files larger than 512 KiB.
*3 - It's maybe important to keep in mind that these were NOT 8-bit characters, but 7-bit. This fact was used in CP/M 2.x to store various flags in the high bits of the file type for flags (Read Only and Hidden) and in CP/M 3.x to add a backup bit, while the second 'reserved' byte now added an 'incomplete record' counter, which finally allowed that an exact file length could be managed - before that, files were always multiples of 128 and CTRL-Z used as EOF marker ... if possible.
If you think of memory restrictions, small file names make more sense. You would want a directory structure allocating maybe 32 bytes to each directory entry. Those bytes would include the file name, a pointer to the file allocation block, attributes, date/time, etc. As Another-Dave pointed out, the genesis of DOS was CP/M, which was preceded by even earlier systems. Those original systems were sometimes lucky to have 8 kwords (16 kbytes) of RAM total. There was no room to waste on long file names.
