delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/2000/11/24/10:15:28

From: "Matthias Paul" <PAUL-MA AT reze-1 DOT rz DOT rwth-aachen DOT de>
Organization: Rechenzentrum RWTH Aachen
To: opendos AT delorie DOT com
Date: Fri, 24 Nov 2000 16:14:09 +0100
Subject: Re: Optimizing CONFIG.SYS...
X-mailer: Pegasus Mail v3.22
Message-ID: <848BE414A59@reze-1.rz.rwth-aachen.de>
Reply-To: opendos AT delorie DOT com

On Thu, 23 Nov 2000 Arkady V.Belousov wrote:

> AFIAR, when you execute CONFIG.SYS step by step then DOS show you in
> which order it accepts CONFIG.SYS statements. Unlike DR-DOS in MS-DOS only
> DEVICE statements order have significance.

For those who don't know, there's a fundamental difference between 
how MS-DOS and DR-DOS execute CONFIG.SYS. Both have there Pro's 
and Con's. Personally I prefer the DR-DOS style, but if all you 
want is to create simple boot menus, they are easier to implement
in the MS-DOS style.

MS-DOS compiles the CONFIG.SYS in at least two passes and creates 
in an internal memory buffer a tagged list of commands to be 
executed. The list is then sorted in various groups and later 
interpreted step by step.

DR-DOS uses a true interpreter when executing CONFIG.SYS. One
of the advantages is, that there is no limit in the CONFIG.SYS 
file size. DR-DOS can handle CONFIG.SYS files up to 2 Gb. ;-) 
AFAIR MS-DOS has a file size limit of 64 Kb (or less, since the 
internal buffer is smaller AFAIK. Well, I don't think, many users 
have seen the "Too many statements in CONFIG.SYS" in MS-DOS, 
though ;-). 
Also, GOTO=, GOSUB=/RETURN=, SWITCH=, ONERROR=, and CHAIN= statements 
would be hard to do for a compiler, but they reflect the natural
way of doing for an interpreter.
On the other hand, newbies often find the Microsoft way of 
CONFIG.SYS boot menus easier to understand (though it is less 
powerful), and implementing MS-DOS style CONFIG.SYS boot menus 
in addition to the DR-DOS language would be no easy task for 
DR-DOS (it is possible to think of the MS-DOS style syntax as 
macros of the DR-DOS configuration language, but an emulation 
of this kind would not be trouble-free when the user makes 
mistakes, e.g. it is still possible to create endless loops in 
DR-DOS. When you attempt to create recursions of CONFIG.SYS
sub-groups under MS-DOS, you'll find that each group is only 
included one time.

MS-DOS records the DEVICE[HIGH]= and INSTALL[HIGH]= statements 
in the order of their appearance in CONFIG.SYS. When it has
finished its basic setup, it will then first execute all the 
DEVICE[HIGH]= statements in the list followed by all the 
INSTALL[HIGH]= statements, optionally followed by SHELL= etc.
This is why under MS-DOS device drivers and TSRs are loaded
in different chunks (see MEM /DEBUG).
Although you can load TSRs before device drivers under DR-DOS
(a feature I often miss under MS-DOS!), it still tries to mimic 
the MS-DOS memory layout to some extend by loading the drivers 
in different memory regions (if there are more than one).

 Matthias
 
-------------------------------------------------------------------
Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany
eMail: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web  : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
-------------------------------------------------------------------

- Raw text -


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