OS/2 Museum's history of DOS mentions the FASTOPEN.EXE TSR was introduced in DOS 3.3. Its entry on DOS 4.0 adds some implementation details.

It reminded me of the DR DOS FASTOPEN=nnnnn directive in CONFIG.SYS, which Wikipedia says works "considerably different" than the DOS TSR.

I assume both variants increase the speed of opening files by caching FAT information as it is read.

This page further states DOS FASTOPEN.EXE needs 48 bytes for each cached file. I'm guessing it caches directory entries. If so, and since FAT16 allocates 32 bytes per directory entry, what are the other 16 bytes used for?

Meanwhile, this DR DOS guide indicates the nnnnn parameter specifies in bytes

the size of the table FASTOPEN creates in memory. The default is 512, creating a table 1,024 bytes. … Each entry in the table takes two bytes of memory.

This documentation also (confusingly) says to create a table one kilobyte in size, nnnnn should be 1024, so there's a mistake somewhere in there. Still, if each entry is two bytes in size, that doesn't sound like a directory entry cache. Or does it mean FASTOPEN manages a table of nnnnn filenames and each entry is associated with a 2-byte value?

(As a side note, a different DR DOS user guide adds:

FASTOPEN.EXE is supplied with DR DOS, but does not perform any function. It is supplied explicitly for applications which require it to exist.

I assume the primary motivation for this was so users who migrated from DOS to DR DOS wouldn't see errors when their existing AUTOEXEC.BAT failed to run FASTOPEN.EXE.)

How do the MS-DOS and DR DOS FASTOPEN variants work?

  • Guesswork: it sounds most likely to me that FASTOPEN.EXE uses a linked list structure (or similar) which needs one pointer for chaining (16-bits would be a sane size for that in real mode). The DRDOS version looks like it uses a table, perhaps a hash-table (or simpler). There are then two choices, open or closed addressing. As two bytes is pointer-ish, open is possible, and that another structure allocated for each file, in excess of the initial table. The guide suggests excess files are ignored, though, so it could be closed, but with the auxilliary structure allocated only on use. – Dan Sheppard Jun 9 at 19:30
  • 1
    16-bit near pointers make sense, but that leaves 14 bytes unaccounted for (assuming the 48-byte information is correct). The DR DOS documentation, while confusing, seems to indicate the config value approximates total RAM usage. Since dynamic allocation for drivers and TSRs is unusual, I'm inclined to think the value is for a fixed pool size. – Jim Nelson Jun 10 at 3:22
  • 1
    The other 14 (or less due to alignment) bytes might store meta information like the drive and its identification (serial number, hash?) of the directory entry. And timestamps to decide which entries to reuse if the table gets full. – the busybee Jun 10 at 6:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.