6 ms·

Why even treat the extension as something separate from the filename?

fit2rule 8y ago
For 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 ago
  Yep. 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!).
  - anyfoo 8y ago
    Hah, at the time, “USR” files were the biggest mystery to me. I knew PRG, SEQ and REL, but this „custom“ file type seemed very special.
  - ddingus 8y ago
    Apple had a file type and nice, long names.
trasz 8y ago
I'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
Early DOS stuff was written in straight assembler, so to search for *.FOO you can just: Read a chunk of directory entries into a buffer. Set ptr to start of the buffer. Check the extension at ptr[8]. If extension matches, do a thing. Set ptr to ptr + 32 and loop.
- anyfoo 8y ago
  Yep, this sounds like the likely answer. Remember that when this structures came up, the “OS” was indeed just a bunch of hand-coded 8086 (and earlier) assembly routines.
- badsectoracula 8y ago
  Since the source code has been released [0], i decided to check it out and sadly it isn't that smart. Searching is implemented in DIR.ASM [1] by reading each entry one by one, matching is done only on the filename (encoded as 11 bytes for FILENAMEEXT) and it only handles "?". Note that this is for MS-DOS 2.0 which didn't handle "*.FOO" searches on the kernel side (the star expansion was done on the COMMAND.COM side via the MakeFcb [2] procedure). MS-DOS 3.0 introduced the star wildcard on the kernel side, so it might have taken advantage of that... but there isn't source code for MS-DOS 3.0. [0] https://github.com/Microsoft/MS-DOS/tree/master/v2.0/source https://github.com/Microsoft/MS-DOS/tree/master/v2.0/source [1] https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/DIR.ASM#L154 https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/... [2] https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/FCB.ASM#L30 https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/...
  - stevekemp 8y ago
    My memory is hazy, but the way that most DOS programs handled file iteration was to use FindFirst/FindNext, and that used data in the program-segment-prefix (PSP) - which was borrowed from CPM.
    - badsectoracula 8y ago
      Yes, the second link is essentially what "FindFirst" calls. A few lines below is the meat for "FindNext".
badsectoracula 8y ago
The table at the beginning of the article should answer that: to save a byte. The dot is not saved, FILENAME.TXT is saved as FILENAMETXT on disk.

For 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 ago
Yep. 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!).
- anyfoo 8y ago
  Hah, at the time, “USR” files were the biggest mystery to me. I knew PRG, SEQ and REL, but this „custom“ file type seemed very special.
- ddingus 8y ago
  Apple had a file type and nice, long names.

trasz 8y ago

I'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

Early DOS stuff was written in straight assembler, so to search for *.FOO you can just: Read a chunk of directory entries into a buffer. Set ptr to start of the buffer. Check the extension at ptr[8]. If extension matches, do a thing. Set ptr to ptr + 32 and loop.

anyfoo 8y ago
Yep, this sounds like the likely answer. Remember that when this structures came up, the “OS” was indeed just a bunch of hand-coded 8086 (and earlier) assembly routines.
badsectoracula 8y ago
Since the source code has been released [0], i decided to check it out and sadly it isn't that smart. Searching is implemented in DIR.ASM [1] by reading each entry one by one, matching is done only on the filename (encoded as 11 bytes for FILENAMEEXT) and it only handles "?". Note that this is for MS-DOS 2.0 which didn't handle "*.FOO" searches on the kernel side (the star expansion was done on the COMMAND.COM side via the MakeFcb [2] procedure). MS-DOS 3.0 introduced the star wildcard on the kernel side, so it might have taken advantage of that... but there isn't source code for MS-DOS 3.0. [0] https://github.com/Microsoft/MS-DOS/tree/master/v2.0/source https://github.com/Microsoft/MS-DOS/tree/master/v2.0/source [1] https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/DIR.ASM#L154 https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/... [2] https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/FCB.ASM#L30 https://github.com/Microsoft/MS-DOS/blob/master/v2.0/source/...
- stevekemp 8y ago
  My memory is hazy, but the way that most DOS programs handled file iteration was to use FindFirst/FindNext, and that used data in the program-segment-prefix (PSP) - which was borrowed from CPM.
  - badsectoracula 8y ago
    Yes, the second link is essentially what "FindFirst" calls. A few lines below is the meat for "FindNext".

badsectoracula 8y ago

The table at the beginning of the article should answer that: to save a byte. The dot is not saved, FILENAME.TXT is saved as FILENAMETXT on disk.