delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/04/18/09:40:52

From: "Matthias Paul" <MPAUL AT ibh DOT rwth-aachen DOT de>
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>

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 <MPaul AT ibh DOT rwth-aachen DOT de>  !
 D-50321 BRUEHL    ! will be forwarded to the new address.       !
 eMail: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>                       
 WWW  : URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html    
------------------------------------------------------------------

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019