Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

stable release ready BUT... (Announce)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 03.12.2009, 14:20

> > P.S. Interestingly, it seems that WRAPPER cannot be used to load a
> driver
> > if the system needs the LASTDRIVE command to be used.
>
> Hmmm... in general, for real /block devices/ I don't think there is a
> problem. UIAM, the LASTDRIVE command is processed by MS-DOS to build the
> System File Tables /before/ processing installable device drivers. Note:
> MS/PC-DOS make several passes of the Config.sys (3 in total, I think), you
> should not believe they haven't "seen" the lastdrive=... line before they
> present it to you!
DEVICE= lines are processed in the last or second-to-last pass; the FILES= and LASTDRIVE= lines have been recorded then. However, LASTDRIVE= doesn't affect System File Tables (SFTs). As their name implies SFTs are allocated for opened files, therefore the FILES= line is responsible for the (total) number of (regular) SFTs in the system. LASTDRIVE= instead sets the number of Current Directory Structure (CDS) entries. The CDS therefore is an array of LASTDRIVE entries. A DOS drive letter (or the DOS drive number) is an index into the CDS array. All drives such as "local" (FAT) drives, SUBST links, JOINed "local" drives and "network redirector" drives require CDS entries.

The recorded LASTDRIVE= value seems to be used only between processing DEVICE= and INSTALL= lines (i.e. after drivers are loaded). Before that, DOS probably creates a CDS just large enough to hold entries for all "local" drives installed yet. Previously I thought DOS would create a CDS with 32 entries (the maximum) initially and would cut that down later; however it could've assumed all drives to be "local" during DEVICE= processing. So the actual behaviour is better than I thought, because SHSUCDX already aborts before installing its drives.

> But the CD (and DVD) drivers are special devices which don't fit well in
> the old DOS driver model, being treated as network drives, hence each of
> these devices need both a /character/ mode driver specific to the device
> model and the MSCDEX or compatible redirector.
No they don't. The requirement of character devices is imposed by MSCDEX's design. Redirected drives don't need DOS devices.

> The latter, not the CD/DVD
> driver proper, is what creates/rearranges/messes with SFTs & drive
> letters as needed to provide the illusion of a block mode device.
There's no such illusion. The drive appears to the user the same, but below the DOS API (Int21) "network" and "local" drives are handled completely differently. They both use SFTs and CDS entries but the content of a "network" and "local" SFT/CDS is mostly different. (It might be worth to note that the different content of the "network" structures is defined by the redirector and completely ignored by DOS.)

> A question of mere academic interest anyway, I can't see whatsoever could
> be gained by loading the MSCDEX with WRAPPER.

What about loading device drivers from the CD? This would be especially useful for a boot CD. Of course most device drivers can now be loaded either by DEVLOAD or by updating them to load as executable too, but these related to low memory management can't without dropping DOS's UMA/HMA initialization. (Linking UMBs to DOS's chain (DOS=UMB) yourself isn't difficult, but relocating the DOS code segment to the HMA (DOS=HIGH) requires knowledge of DOS's exact behaviour and code, which probably changed with every version.)

---
l

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22762 Postings in 2122 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum