From: "Matthias Paul" Organization: IBH, RWTH-Aachen To: opendos-developer AT delorie DOT com Date: Fri, 18 Apr 1997 15:32:46 GMT+0100 Subject: Re: Usage of directory entries Reply-to: Matthias DOT Paul AT post DOT rwth-aachen DOT de Message-ID: <15382B777B3@ibh.rwth-aachen.de> Precedence: bulk On Fri, 18 Apr 97 22:26 Lorier replied to Mark Habersack: > >P.S. Matthias, the undocumented /T switch to command.com causes > >command.com to reload itself when it finds a certain type of TSR > >(I think that it should be a multitasker) If so, this should tell us something... ;-) >What type of TSR? >Hmm... Anyone have any idea what "Multipath=" or something in >Config.sys in Dos6.2 is for? [MULTITRACK] You probably meant MULTITRACK=, didn't you? This directive allows to enable/disable multi-sector access at the INT 13h interrupt. While MULTITRACK=ON is the faster default, some systems with old BIOSes, imporper VDS, weird SCSI drives, and some PS/2 machines require MULTITRACK=OFF. If I understand this well, under Novell DOS and OpenDOS you can achieve the same (or at least similar) results using the undocumented DEBLOCK=xxxx directive. Since I have written about it several times in the official caldera mailing list and in opendos AT delorie DOT com, I'll do only a short summary here (for more details, please have a look at the mailing list archives or at my MPDOSTIP.ZIP...): DEBLOCK=FFFF (the new default) can be compared with MULTITRACK=ON DEBLOCK=A000 (old default) DEBLOCK=0000 can be compared with MULTITRACK=OFF The hex-value is the segment address where to stop multi-sector access, and some systems require it not to be in paged memory. Of course, DEBLOCK=0000 is much slower than DEBLOCK=FFFF, since all file-io has to routed through a single-sector deblocking buffer in low memory. [COMMAND /T] Well, option /T works with or without a TASKMGR installed. It requires, that the currently running command processor (where typing in COMMAND /T) also is COMMAND.COM. It will crash, if 4DOS is the current command processor (of course, 4DOS *can* be an underlaying command processor). COMMAND.COM's behaviour of stacking batchjobs on giving /T is IMHO only useful in conjunction with the TASKMGR ('T' like 'T'ASKMGR, 'T'ask, or 'T'erminate). Because I have not yet seen this test for a special 'TSR' in my COMMAND.COM disassembly (which - I must admit - is uncomplete due to hard disk space limitations on my current systems), which install check is tested than by COMMAND.COM? However, if it actually checks for the multitasker, this really might be one of the causes for the problems with 4DOS... Bye, Matthias ------------------------------------------------------------------ Matthias Paul ! My eMail address has changed. For some time ! Ubierstrasse 28 ! mails to former ! D-50321 BRUEHL ! will be forwarded to the new address. ! eMail: WWW : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html ------------------------------------------------------------------