7

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?

Improve this question
5
  • 1
    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
    Commented Jun 9, 2021 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
    Commented Jun 10, 2021 at 3:22
  • 2
    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
    Commented Jun 10, 2021 at 6:22
  • FASTOPEN installs a "hook" routine into DOS via INT 2Fh function 122Ah. This routine will perform "Lookup", "Insert", "Delete" and "Purge" operations on the cache. The data structures are a bit more complicated than just one fixed entry per file. Each part of the path (directory and file) is cached separately, so no path name hashing.
    – Thomas Kjørnes
    Commented Sep 28, 2022 at 14:16
  • Forgot some important points and could not edit my previous comment. MS-DOS' FASTOPEN implements the cache logic in it's executable as a TSR, while in DR-DOS it's built into the kernel and just configurable as a CONFIG.SYS option similar to BUFFERS.
    – Thomas Kjørnes
    Commented Sep 28, 2022 at 18:44

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .