Hi Johnson,

> I sincerely ask Jack's to let me host his drivers because I want to
> provide the DOS user an alternative, a choice. His QHIMEM let me have
> 620K base memory, I got plenty of base memory for me...

You might have noticed that Dima had even MORE memory free even
though he does NOT use QHIMEM ;-)

> Conventional          639K        14K       625K
> >Note: SHCDX33A now in conventional memory, thaks to Eric Auer for advice.
> Did you found SHCDX33A have any problem when loaded high? Can you
> share your experience with us?

The trick is that if you load SHSUCDX in "normal" way, it
relocates itself to UMB. But if you LOADHIGH (LH) SHSUCDX,
it relocates itself AWAY from UMB. To stop this, you have
to use the /c option of SHSUCDX (if you use LH), or you
have to stop using LH (then SHSUCDX can relocate itself high).
This happens for both SHSUCDX and SHSUCDX, uhm, SHCDX33A.

> And please don't blame Jack, he have no intention to compete with
> FD-HIMEM, he just want a "simpler" XMS manager.

Those who want a stripped down XMS manager can already use FDXXMS.

>   SHCDX33A     8,416    (8K)
>   FDXXMS       2,432    (2K)
>   UMBPCI         176    (0K)

> CC91h      ..       5,968    SHCDX33A 
> 0276h       80        ..     Device=QHMBOOT   Attr=A000h  Name=QHMLOW$
> C802h      ..       2,000    Device=QHIMEM    Attr=A000h  Name=QHIMEM$
> 029Eh      160        ..     Device=UMBPCI    Attr=E000h Name=UMBPCIXX

I assume that Dima has more cdrom drives, so his SHSUCDX takes more RAM.
Your two MEM tools differ somehow in how they measure, but you can
assume that QHIMEM+QHMBOOT together take 300 bytes less RAM than FDXXMS.
It would have been a good idea if Jack had written a patch for FDXXMS
to let it use QHMBOOT instead of re-inventing the wheel and writing
QHIMEM, based on questionable sources. After all, it is a good idea to
let the XMS driver be loaded into UMB (as possible with QHMBOOT+QHIMEM)
but it is NOT a good idea to annoy people by introducing yet another
XMS manager, indirectly blaming the others of being so bad that it would
not be worth the effort to improve them.

A really good driver more or less by Jack is actually XCDROM / QCDROM:

> C8E4h      ..       2,400    Device=QCDROM    Attr=C800h Name=SHSU-CDN
(by the way, what is qbuf...?)
> 027Ch      528        ..     Device=QDBOOT    Attr=8000h  Name=QBUF$

>  cae8     5008    VIDE-CDD    device driver

Note that saving 2.5k of memory is quite good but that it is not
necessary at all as we both have the driver in UMB anyway :-)).

For comparison of memory drivers:
  028e     2672    HIMEM       device driver
  0336     3360    EMM386      device driver
  040f     3152   COMMAND     program      
  04d5 [free area starts here]
  ca02      400    KBD-EA2     device driver
  ca1c     3248    NANSI       device driver
  cae8     5008    VIDE-CDD    device driver
  cc22     7552    CDRCACHE    device driver
  cdfb      624    MORESYS     device driver
  ce23     2496    FILES       data area    
  cec0     2288    LASTDRV     data area    
  cf56    12976   LBACACHE    program      
  d4a3      912   FDAPM       program      
  d4dd     3312   CTMOUSE     program      
  d5ad [rest is free - almost: COMMAND environment at dfdf, 0.5k]
(some lines omitted)

So I have 620k low DOS RAM and 41k UMB free and I even have a 64k
EMS 3.0 page frame (otherwise I would have more UMB free) and a
VESA VBE 3.0 compatible BIOS :-). 620k are 635,120 bytes to be exact.

As I have not seen programs which need more than 590k low DOS RAM,
all available drivers are good enough. The only too big driver in
my collection is the network card packet driver, because it does
not work well when loaded into UMB. I usually do not use networking
in DOS normally, so most of the time, I simply do not load the driver.

Have a nice DOS :-)


This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
Freedos-user mailing list

Reply via email to