Fastopen notes

Eric Auer posted this on the fd-dev mailing list, and while it asks more questions than it answers, I thought it would be interesting for FreeDOS users:

See www.vfrazee.com/ms-dos/6.22/help ... Some interesting points from there:

FASTOPEN only seems to cache the "open" call (if you "open" something a second time, time and disk accesses will be saved). By default, 48 entries of 48 byte each will be created. You can at most use 999 entries, and you can put them into EMS. You can only apply FASTOPEN to local disks, at most 24 of them. Syntax:

FASTOPEN drive:[[=]n] [drive:[[n][...]] [/X]

So you give the number of entries for each drive. Minimum is 10. The manpage also tells that the 48 byte are approximately. I think this means that it allocs 48 byte for each entry, but the actual caching stores the full path name plus int 25/26 sector plus entry number for each entry, using some allocation scheme that just takes as much memory as the string actually needs. I guess something like zero-terminated strings one after another, just like program environments in DOS work.

Config.sys can contain SET var=string commands.

The MS config.sys menu definition language / syntax is described as well, but actually I am quite happy with the FreeDOS menu syntax! I guess I will call my screen color command MENUCOLOR=fore[,back] for the ones being used to that from MS. NUMLOCK=[ON|OFF] sounds interesting, too.

DRIVPARM syntax is:

DRIVPARM=/D:int25/26drivenum [/C for changeable] [/F:type for drive types:
  0 160/180/320/360k, 1 1.2M, 2 720k (default), 5 harddisk, 6 tape,
  7 1.44MB, 8 optical, 9 2.88MB] [/H:heads 1..99 default depends on /F]
  [/I 3.5inch floppy but no BIOS to support it (!)] [/N non-removable,
  actually /C meant door switch existing] [/S:sectors per track, 1..99,
  default depends on /F] [/T:tracks number of cylinders]

"Drivparm modifies the parameters of an existing physical drive and does not create a new logical drive"

So I think we can have this:

DRIVPARM=/D:n [/C|/N] /T:c /H:h /S:s /F:x

Actually, /D is specified as 0..255 range, do they mean BIOS drive numbers??? Whatever, the result would be as follows: (note that I do not propose to do anything with /I)

/C and /N modify DOSes notion of int 13.15 return wrt. change line support

/F:... seems to modify what DOS got out of int 13.8, which can return 1=360k 2=1.2M 3=720k 4=1.44M 5=??? 6=2.88M 10h=atapi removable, while DRIVPARM has 0=360k 1=1.2M 2=720k 5=harddisk 6=tape 7=1.44M 8=WORM 9=2.88M

- could anybody shed some light on how this type value is meant to be used???

It should probably also call int 13.17 with AL being one of: 1=320k 2=320k in 1.2M drive 3=1.2M 4=720k and DL being the drive number, and int 13.18 (drive DL CX max cyl/sect, no heads info, returns es:di int 1e vector) to set some default geometry?

The /T:..., /S:... and /H:... should probably change the values that DOS normally reads from int 13.8 (returns CX DH geometry, DL drive count, es:di int 1e vector if floppy, BL floppy drive type as in table with 10h=ATAPI), and should probably call int 13.18 to enforce that geometry.

I have the strong feeling that this in only meant for non-harddisk type drives, that is for 0..127 BIOS drive number. And sectors/track numbers of > 63 do not make sense either. Heads, on the other hand, could be 1..255 rather than 1..99, although I doubt that anything > 2 makes sense for floppies (you cannot change the head count there, you can only fail to use some of the existing heads). Or did MS DOS really allow you to call int 13.9 (init harddisk geometry from int 41/46...!?) ???

I must admit that I doubt that DRIVPARM would be of any use unless your BIOS is broken. In that case, you can supply drive geometry by hand to override invalid detected values. Please tell me who / why / how actually USES DRIVPARM for anything. Even google results are welcome ;-).

Next, we have DRIVER.SYS, which has the following options:

/D:n (BIOS -floppy- drive number, 0..127 range)
[/C] (tell that change line is supported)
[/F:type] (set type code: 0=160..360k, 1=1.2M, 2=720k/other, 7=1.44M, 9=2.88M)
[/H:heads] (1..99 default 2)
[/S:sectrors] (1..99 (???), default: 9, 15, 9, 18, 36 for /F values 0,1,2,7,9)
[/T:tracks] (1..999 default 80, but 40 for /F value 0)

If you give all /H /S /T, you do not need to give /F. So /F is probably mainly to provide geometry default values.

DRIVER.SYS assigns a new drive letter whenever it is used: This allows you to activate the DJ mechanism even when you have several floppy drives. Did anybody actually use this? The manpage also tells that using different parameters for assigning several geometries to one physical drive will not work: The hardware will be set to what the most recently installed DRIVER.SYS considers to be the right geometry, breaking earlier assigned drive letters.

I am not informed well enough about kernel disk driver details, but is it correct that apart from increased table size nothing would stop us from making DRIVER.SYS an internal config.sys command rather than a .SYS file? We could for example add an /L (add a new drive letter) option to DRIVPARM instead of having DRIVER.SYS (and mention that in documentation about the non-existing DRIVER.SYS - I do not think that we need so much compatibility that we would be forced to make driver.sys an actual file).

Please give some opinion / experience about / with DRIVPARM and DRIVER.SYS... Thanks!

Other points:

EGA.SYS is only used as screen content swapper for the DOSSHELL multitasking functionality. As I already suggested to find ourself a nice open file manager (XTree, NC, PCTools, ... clone) instead of using DOSSHELL, EGA.SYS is not needed if you ask me.

Question on HIMEM / FDXMS: MS specifies /INT15=kilobytes to reserve for int 15 memory, what is the syntax for our tools? And for NUMHANDLES? Default value is 32 (1..128) for MS, and for us? MS also tells that Win 3.x in 386 mode overrides NUMHANDLES. /TESTMEM:ON|OFF is of course useful, too. INSTALL is documented as giving programs no environment segment. I wonder why MS claims to have a SET var=value command in config.sys then???

I now get reminded that we have no INTERLNK / INTERSVR (they provide "network" drives through serial / parallel cables. Surprisingly, MS is so kind to provide wiring diagrams!), which similar software would you recommend to use for FreeDOS instead?

The "What's New" manpage tells: DriveSpace instead of DoubleSpace (conversion possible. You can compress, create, defrag, del, format, info, list, mount, tune, resize, uncompress, unmount drivespace drives) - using the HMA for the driver saves 14k for DOS. SCANDISK got added, which is similar to CHKDSK but with nice user interface, undo, surface scan... HIMEM now defaults to /TESTMEM:ON. SMARTDRV now defaults to not delay/pool writes, and even with delayed writes, SMARTDRV writes back dirty buffers when you return to the prompt. MOVE, COPY, XCOPY now ask before overwriting. SMARTDRV now has CD-ROM cache (if MSCDEX loaded before SMARTDRV). SCANDISK can check compressed drives as well, not only their host drives, and there is an integrity checker to avoid writing corrupted compressed data. If you were wondering "write back when idle" still exists, it just is no longer the default even for write delaying mode in SMARTDRV. SMARTDRV uses XMS when the /X flag is given, and only caches physical / host drives, not compressed drives themselves.

Whoops! SORRY! The /X flag is not about XMS. SMARTDRV always uses XMS (extended LIM/AST memory, they mention HIMEM.SYS, so...) :-)). The F5/F8 mode got improved and now also works in autoexec.bat ... by the way, how does FreeDOS do this, standard /... flag for FreeCOM ? (/Y flag, that is)

As MS has it: Could FreeCOM have an /MSG flag for those who have no XMS? The best set of messages to keep out of RAM would probably be the help texts (I am not sure, maybe FreeCOM already works that way?) - they would then be loaded from the binary, or from a separate message file. The help texts are also good candidates for compression (even in RAM, that is). MS DOS DISKCOPY starts using the harddisk for swapping in version 6.22, which speeds up things (hey MS, know XMS?). DEFRAG now uses XMS. The output format of DIR, MEM, CHKDSK, FORMAT changed yet again, for example using 1,000,000 for 1000000 (no other output format improvements are explicitly mentioned :-)).

MS has the MEMMAKER automatic "memory optimization"...

The manpage of MEM, by the way, also details the flags and output format. MS believes to have some antivirus software called MSAV. This is also what creates chklist.ms checksum files. Default extensions to be scanned are 386, app, bin, cmd, dom, dll, drv, exe, fon, ico, ov*, pgm, pif, prg, sys. There are MSBACKUP, MWBACKUP (for Win), RESTORE commands with nice UI, uhm... MSD claims to tell about: Type, CPU, RAM, Video, Ver, Mouse, joystick, drives, lpr and com ports, irq status, tsr, device drivers, bus type, bios version/data, keyboard type, dma config, fpu status, 640k..1M memory map, video bios version/date, video type/mode, network config, boot drive, environment, cwd, mouse irq, mouse type/version/settings, free disk space, disk size, lpt/com port status flags, com settings, tsr name/location/size. It can put all results in a file. I guess COMPINFO can do basically the same, right?

POWER has modes OFF, STD, ADV[:MAX|REG|MIN], where STD turns on default APM if any. Only ADV actually makes APM status controlled by "idleness" of the system (MIN is min savings, MAX is save most energy while idle). You must load it from config.sys but can change settings later. It loads itself into UMB unless you give /LOW switch (-we- can simply use DEVICEHIGH, okay?). As far as I remember, it is best to use the BIOS API for APM :-).

PRINT and MODE have lots of settings, probably we have less... And all those features and the IDE of QBASIC... envy... X-).

RAMDRIVE.SYS could use XMS, EMS or conventional RAM, config'able size, sector size, root dir size. Just for the records.

Please read SETVER details yourself if it interest you. Check out (improve?) Steves PATVER if you want! MS SETVER insists on being loaded from config.sys first.

STACKS can be 0,8..64 of 32..512 bytes each, 0,0 or 9,128 recommended.

SWITCHES in config.sys may be: skip delay, block F5/F8, tell Win to search wina20.386 on win.ini-mentioned location, not \, standard/enh keyboard detection override.

UNDELETE can be used as a TSR to record info on deletion to some "SENTRY" directory (Hi trashcan...). It can auto-undelete with wildcards, in that case it uses #%&0-9A-Z in that order to find non-ambiguous file names. Each delete-tracking entry seems to be 182-185 bytes. The UNDELETE version that MS got cannot undel directories or files in deleted directories, you had to use UNFORMAT for that in MS DOS.

The deletion tracker would purge after 7 days, skip tmp, vm* wm* wga swp spl pmg img thm dov files and files with archive attribute, or if more than 20% of the disk space are used. This smells like an actual trashcan, not a delete tracker. The files are not deleted at all, only moved to \SENTRY\ (?) along with some bookkeeping info. You can configure the delete tracker setting.

Ah, here come the detail: STANDARD is no tracking, TRACKER is keep directory data in PCTRACKER.DEL but do not protect otherwise (13.5k TSR), and finally SENTRY implements a real trashcan/trashbin (13.5k TSR). Do we have TRACKER or SENTRY functionality in FreeDOS already? Cannot be that hard: Intercept deletion calls, turn them into move calls if in SENTRY mode, write bookkeeping data, return to caller.

UNFORMAT scans the drive for directory data and, unless fragmentation or cross-linking block this, reconstructs the FAT. Otherwise, it offers to reconstruct truncated file entries for the affected files. Has modes to simulate and to list found files. Only for 0.5, 1, 2k sector size. Is this roughly what our UNFORMAT does?

The VSAFE protection TSR can trap any of the following events: harddisk formatting, going TSR, writing to disk, "scan for viruses on open" (?), checks for boot sector virusses on disk change, writing of boot sectors or FAT on harddisk, same on floppy, checks if programs try to modify executables. Default checks are format harddisk, virusscan, bootsector scan, harddisk FAT/bootsector protection. The virus list can use EMS or XMS. Has some Alt or Ctrl hotkey popup. Optionally checks files on network drives. Uses chklist.ms checksums.

I think I could write something which checks for: harddisk formatting, writing to harddisk or floppy bootsectors, using lowlevel/dos disk write (int 13,25,26,40), write to / rename executables. Would anybody be interested in having such a "protection TSR" ???

Wow. That probably was everything worth mentioning (forget about graphics, printer, keyb data files... we already know about NLS and codepages) about MS DOS 6.22 help. If you know answers or have comments to some of the above items, please quote only those items which you want to comment on on replying, thanks!