Mail Archives: opendos/2000/11/24/10:32:32
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: <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html
-------------------------------------------------------------------
- Raw text -