Mail Archives: opendos/2000/11/30/08:45:56
On Wed, 29 Nov 2000 Patrick Moran wrote:
> > The 7 KB footprint indicates it is using DPMS and that it had problems
> > to load into UMBs because there was not enough free UMB memory
> > available in one continous chunk (I recall something in the area
> > 160 Kb that is required - this is why my INSTCDEX utility exists.)
>
> Actually it loads in two chucks. With QEMM I found it can load with 65000
> bytes (probably less if I experimented more but was satified with that
> amount.)
It could be that the low level portion (including the buffering)
and the higher level file system stuff are loaded in different
segments. Maybe it was consuming more memory on my system because
I have set the buffers to max?
> > (The 112 bytes environment footprint will probably vanish with
> > future issues - not only with NWCDEX.)
>
> I downloaded the program and will check it out sometime, but if it takes 900
> bytes of conventional memory, I won't need it until I use QEMM or something
> else that does not let it all load into UMB and extended memory. I can get
> by with 112 bytes in an area I can't use anyway. (At least at this time I
> cannot.)
Hm, my INSTCDEX has nothing to do with the 112 byte environment not
being freed by NWCDEX, if you mean that. (I mentioned that my
personally enhanced issue of NWCDEX as well as other drivers do free
the environment, and if Lineo would at some time open up DR-DOS,
I will make this available to everyone. I still haven't lost hope...)
INSTCDEX allows to load NWCDEX in CONFIG.SYS (which normally does
*not* work for various reasons) and thereby the chance that it can be
completely loaded into UMB will be increased. INSTCDEX is not a
resident tool, it is an utility that patches around in internal data
structures, and allows to temporarily save state data on disk, while
the Current Directory Structure (CDS) is relocated into UMBs after
CONFIG.SYS processing has finished.
I'm not sure, Patrick, if you can make good use of INSTCDEX in
your configuration, because you said you already *can* load high
all the stuff, and even if not, you said, you *can* load NWCDEX
in CONFIG.SYS (the only reason I currently see, why this works for
you even without INSTCDEX, is that your system sees only one or two
DOS partitions, because otherwise the pre-set of the LASTDRIVE value
(the reported count of slots in the pre-CDS) would be used up
already (and you can expand this only by loading block device
drivers, or - under DR-DOS - by patching around in the kernel's
internal data structures (INSTCDEX /LASTDRIVE does that)).
The LASTDRIVE setting only takes effect after CONFIG.SYS has
finished, in the same moment when the pre-CDS (in low memory)
is freed and the actual CDS is build (in UMB memory when DOS
goes up).
NWCDEX takes 928 bytes of conventional memory, when it uses EMS.
So far I was not able to load this portion high. Anyone?
However, many people are still using EMS *and* let NWCDEX use
DPMS *and* have problem to load the 7 Kb real-mode portion into
UMBs. Those people are probably better off forcing NWCDEX to use
EMS instead of DPMS.
(BTW: NWCDEX has a bug, and will hang if you force it to
use EMS when EMS is not present.)
> > Try CONFIG.SYS YEAR2000=OFF. The DR-DOS 7.02+ IBMBIO.COM hooks INT 1Ah
> > to correct the RTC date.
[...]
> Is there a way to turn Y2K back on after QEMM is installed and not
> interfere with anything?
QEMM works with and without YEAR2000=OFF. There are two issues,
though:
1. One of the Stealth methods has problems with YEAR2000=ON
(which is the default when you omit this directive).
You can work around this by either YEAR2000=OFF, or by
using one of QEMM's special options, DO1A, IIRC (see
DR-DOS README.TXT).
If I remember correctly you could switch YEAR2000=ON/OFF
in CONFIG.SYS several times under DR-OpenDOS 7.02 (but the
INT 1Ah was flaky in this issue), but at least under
DR-DOS 7.02+ it only senses for YEAR2000=OFF and YEAR2000=ON
is ignored. So, if your ROM-BIOS has faulty date support,
you would need to load a 3rd party Y2K-fix after loading
QEMM. This should work. Such TSRs are freely available
from many places, including ASUS (ASUS2000.COM) or
Heise Verlag, Germany (c't magazine, www.heise.de).
2. QEMM's DOSUP has problems because of the changed layout
of handles since DR-OpenDOS 7.02+. Previous issues
had 5 handles in one chunk in low memory during CONFIG.SYS
and 8 or more handles in two chunks (8+x) afterwards.
Due to the introduction of the FILESHIGH/FCBSHIGH
directives, this has changed a little, and it now
has 5+3 handles in two chunks in low memory and
optionally x handles in a third chunk either in
low memory or upper memory, depending on FILESHIGH/
FCBSHIGH. This is completely valid in terms of
DOS standards, but QEMM's DOS-UP objects (probably
just because it does not expect this layout under
an OS or the DR-DOS family).
The other QEMM features still work, though.
If you really want to make this work, back in
1997 I developed a simple patch for the IBMBIO.COM
file which forces the old layout. This was posted
several times in this forum (I think I called it
IBMBIO85.SCR), but I could locate it in my archives
if anybody still needs it.
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 -