From: "Matthias Paul" Organization: Rechenzentrum RWTH Aachen To: opendos AT delorie DOT com Date: Fri, 24 Nov 2000 16:32:03 +0100 Subject: Re: Optimizing CONFIG.SYS... X-mailer: Pegasus Mail v3.22 Message-ID: <8490A580ED4@reze-1.rz.rwth-aachen.de> Reply-To: opendos AT delorie DOT com On Thu, 23 Nov 2000 Arkady V.Belousov asked: >> Chicago's ENHANCED and SINGLE arguments are accepted, >> but ignored because they make no use under DR-DOS. ^^^^ err, "sense" is what I meant... > > What mean these arguments? As far as I remember they switch internal flags to control some of the auto-loaded drivers, but right now, I cannot remember what it was exactly, sorry. I do remember that I found them meaningless for DR-DOS when I implemented the other additions. I would have to look up this stuff, if you really need this info. Anyone? > And what mean MULTITRACK statement? (If I right understand some > allusions then this makes multitrack floppy drive read?) This directive was loosly documented for MS-DOS 4.00+, but is undocumented since MS-DOS 6.0+. It allows to control the behaviour of read and write operations beyond track (that is cylinder) boundaries in the floppy disk sub-system. Hard disk I/O is *not* affected. It exists because some ROM-BIOSes (under some unknown circumstances) have problems with this (maybe in Protected Mode environments???). MULTITRACK=ON is faster, of course, and this is the default chosed by the system when no MULTITRACK= directive was found in CONFIG.SYS (apparently the system runs with MULTITRACK=OFF until this moment). Under DR-DOS a similar MULTITRACK= directive was introduced with 7.02+ (not documented) but it does not directly copy the exact behaviour of MS-DOS. The actual semantic is somewhat different: DR DOS 6.0+ (actually not the original issue, but business update 1993, as well as DR PalmDOS and DR DOS "Panther" (10/1992)) has an undocumented DEBLOCK=hhhh directive, which allows to change the segment value up to which DR-DOS performs multi-sector I/O. Above this value DR-DOS will deblock anything through a single-sector buffer in low memory. The less DR-DOS needs to deblock, the faster it is. This means that DEBLOCK=FFFF is the fastest setting. On the other hand, DEBLOCK=0 will force the kernel to deblock anything, which makes the system *much* slower, but sometimes fixes strange floppy access problems (frequently seen for example with early issues of Novell DOS - presumably due to EMM386 shortcomings, and reportedly (by Mark Aitchison) also seen under DOSEMU). When not using DEBLOCK= in CONFIG.SYS, IBMBIO.COM will work with an internal setting of DEBLOCK=A000 until CONFIG.SYS is finished, and (Novell DOS 7 and higher) will then perform an automatic detection to see if it is safe to enable multi-sector access in UMB memory. If this test fails, the setting remains A000h (the start of the video memory), otherwise it is changed to FFFFh (the end of the HMA). Many early bus master controllers (e.g. SCSI and ESDI host adapters) failing to implement the Virtual DMA Specification (VDS) will not work correctly when multi-sector access is attempted in paged memory (in a Protected Mode environment like provided by EMM386 when it is mapping-in XMS memory in the UMB memory range). One of the possible reasons I can imagine is that the physical memory addressed by the DMA controller does not match the memory layout provided by the CPU when it runs in Protected Mode, so that the DMA controller would bypass any protection scheme and more or less randomly corrupt memory contents. But there might be other problems, including timing issues in Protected Mode. When DEBLOCK=hhhh is found in CONFIG.SYS the setting overrides the A000h default as well as the automatic detection method. The DEBLOCK= syntax was slightly enhanced with DR-OpenDOS 7.02+ and now also supports DEBLOCK=ON which is equal to DEBLOCK=0 and DEBLOCK=OFF which is equal to DEBLOCK=FFFF. While the DEBLOCK= setting (which deals with multiple sectors) is not an exact duplication of MS-DOS' MULTITRACK= behaviour (which deals with multiple cylinders), it appears to have similar effects. Hence, a cheap emulation of MS-DOS' MULTITRACK= was added to DR-DOS, which just works opposite to DEBLOCK=ON | OFF, that is, MULTITRACK=ON sets DEBLOCK=FFFF and MULTITRACK=OFF sets DEBLOCK=0. Note, that under DR-DOS DEBLOCK= (and thereby also MULTITRACK=) affects harddisk *and* floppydisk access, while under MS-DOS MULTITRACK= only affects floppies. Also, switching multi-tracking off is not as drastic as switching multi-sector access off. Anyway, by forcing single-sector deblocking (DEBLOCK=0), multi-tracking is also disabled implicitly. (Right now, I don't recall, if DR-DOS' disk driver actually performs floppy multi-tracking or if it deblocks any such requests. Please keep in mind, that the behaviour of MULTITRACK= might change to be more MS-DOS like with possibly future issues of DR-DOS.) >>> [common] >> I would move this directive down to the end of the CONFIG.SYS file. > > Why? Many setup programs look for the MS-DOS style [COMMON] group to place their CONFIG.SYS changes there. Other programs just append their changes to the end of the CONFIG.SYS file. Since they usually mess up DR-DOS style CONFIG.SYS configurations anyway, I like to direct them to a safe dummy playground where they can mess around without destroying my configuration (still have to see a setup program beating "hand-optimized" configurations). Putting [COMMON] at the end of the file, and placing an EXIT somewhere before it, I ensure this potentially bogus stuff is never executed (mind that while [COMMON] is accepted by DR-DOS for syntax compatibility with MS-DOS, it means nothing to it, that is, it works similar to REM). Having all the changes condensed at one place in the file also makes it easier to have a look and adapt them to the true configuration(s), if changes would really be require there. Of course, not all setup programs work this way, so this is no general purpose solution. So, if the configuration is as simple (and MS-DOS compatible) as in Arkady's example, it may actually make more sense to move the [COMMON] to the beginning of the file, as Arkady suggests. For DR-DOS itself, there is no difference, where you place the [COMMON] directive or if you remove it at all. It's all up to you... >BTW, how many uses each additional LASTDRIVE? Each entry costs 88 bytes, AFAIR. This is mainly for the extra record in the Current Directory Structure (CDS), the structure, that holds the current path and a number of flags and state variables for each drive letter. >> BREAK=OFF > > =on is much better in my taste: by MS-DOS specifiaction >differences between ON and OFF are in handling ^Break at disk IO >time. I.e. if program uses console IO then you can break it even >with BREAK=OFF, but if program don't access console or disk in long >time periods then even with BREAK=ON you can't break it. The same is true for DR-DOS (AFAIR: BREAK=OFF means check for break flag only during INT 21h standard I/O, BREAK=ON means check for break flag on *any* INT 21h). Well, since I feel bad about breaking programs any non-offical way, in particular when they are doing disk I/O, I prefer BREAK=OFF (for special purpose exceptions see below). I usually try to avoid anything that could possibly cause corruption of the disk system. This is just a matter of personal taste, and there's nothing wrong in general with using BREAK=ON. BTW, a trick I use in my own console programs (like CHCC, COUNTRY, CPI, etc.) is to check, if output is redirected, and if not, I let them display either a rotating bar in a box like [-] [\] [|] [/] ... or just a string like "SPACE, BS" every second while they're proceeding without screen output. This ensures there is some invisible and low-bandwidth standard output going on every now and then and thus reasonable short CTRL+C user response times even with BREAK=OFF. Well, I know CTRL+C is sometimes used to break hanging programs during development, but I don't need this, because Axel's and mine's advanced keyboard driver FreeKEYB (as well as its pre-decessor K3PLUS) provides several extended break methods being more adequate for this purpose: First of all, LCTRL+ALT+SHIFT+C (or its shortcut ALTGR+SHIFT+C) clears any pending keystrokes from the keyboard buffer. This ensures that a subsequently issued CTRL+C is placed first in the buffer. Some applications "hang" when you have "typed ahead" and then suddenly have a demand to break the currently running (but ill-behaving) program. (Well, not that much of a problem for the 15 keystrokes fitting into the standard keyboard buffer, but FreeKEYB has a configurable extended buffer which by default holds 255 keys...) CTRL+BREAK instead of CTRL+C clears the keyboard buffer and issues INT 1Bh (the break interrupt) instead of inserting CTRL+C into the keyboard buffer and praying that it will be processed in time. CTRL+BREAK will thereby set the system's internal break flag so that the next time the system checks the break flag, it will issue INT 23h. (This is also a feature of the standard keyboard driver KEYB.) SHIFT+CTRL+BREAK works like CTRL+BREAK, but additionally switches BREAK=ON, so even with a default setting of BREAK=OFF I can still switch it on if I have a true demand for it. (Under some older DOS issues, this fails for COMMAND.COM and internal commands, but not while external programs are executed.) After issueing SHIFT+CTRL+BREAK, the break setting usually remains BREAK=ON until switched back off by BREAK=OFF at the prompt (but this also depends on the command shell: at least older issues of the Novell DOS COMMAND.COM restore the break setting when returning from external programs, but this still allows to break out of external programs, anyway... ;-) If these break methods aren't sufficient to exit a program, FreeKEYB & K3PLUS still provide a joker called Break-to-DOS method. It is executed on LCTRL+ALT+BREAK keypresses. This will kill the currently running process by using the DOS terminate function. This is, of course, dangerous, and if this method isn't combined with tools like MARK/RELEASE or HBREAK, the system will likely hang or crash soon after (depends on the type of the killed program). Therefore all these methods can be enabled and disabled via the FreeKEYB API (and command line switches). Oh, I forgot, BREAK=OFF makes the system slightly faster... ;-) Matthias ------------------------------------------------------------------- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany eMail: Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html -------------------------------------------------------------------