[comp.binaries.ibm.pc.d] In praise of QEMM-386

ndh@stl.stc.co.uk (Neale D Hind ) (01/29/91)

Summary of this posting
_______________________

o   QEMM-386 seems an excellent product (I have no connection with
    Quarterdeck)
o   When trying to maximise the number of Devices/TSR's in high memory,
    try swapping around the order in which they are loaded in your
    config.sys and autoexec.bat files.
o   Do read through the Fine-tuning parameters in the manual. Especially
    the EMBMEM and EXTMEM if you are having problems with applications
    clashing (eg some need expanded, others extended, memory).
o   Statements in postings along the lines of "Product 'A' does not work
    with product 'B'"  most likely mean "I do not know how to make product
    'A' work with product 'B'"


There has beem quite a few postings about QEMM-386 under DOS.  I have
been very impressed with the product (using v5.11).  The problem, if
any, is with the documentation rather than the software - everything you
need is in there somewhere, but finding it is the difficulty. (But with
the vast combinations of machine/software that must be around this is not
really surprising).

I am running QEMM on an i486 PC (company not mine - sigh!!!) that has a WD
Ethercard installed and is dedicated to two applications PC/FOCUS
(database system) and Lotus 1-2-3 r3.1 (spreadsheet - as if you needed
telling).

The Ethercard takes up nearly 80k with print redirection loaded.
PC/FOCUS wants as much conventional memory as possible and will use up
to 2mb expanded, 1-2-3 r3.1 wants as much extended memory as possible.


First Problem - Maximise use of high memory
___________________________________________

The first problem was shifting as many TSR's into high memory as
possible.  Initially they would not all go - tucked away on page 56 of
the manual was a (small print) reference to the fact that TSR's often
require much more memory to load than they need to remain resident.
BUT it didn't tell you that 'OPTIMIZE' doesn't try shifting the order
around of TSR's in your autoexec.

The solution was to load them high with the /getsize parameter (page 41
- finds out how much memory they really need) and then alter the order
in your autoexec (after all who cares if keyb is loaded before or after
the Ethercard software).

The net result is that 101k of TSR's / DOS resources are now loaded high
and the machine is left with 593k of conventional memory.


Second Problem - Expanded v Extended
____________________________________

After installing 1-2-3 r3.1 it would not load (something about the
hardware not conforming to some standard or other).  With a vanilla
configuration it worked fine so the error message was a red herring.

The dirty fix was to add the parameter EXT=1000 (page 19) to the QEMM
command in config.sys. This let 1-2-3 run with 1mb extended memory
leaving more than enough for PC/FOCUS to run with it's maximum expanded
memory (2mb).  But this seemed inelegant, so I read the bits of the
manual that at the time had seemed irrelevant. (ie Windows 3.0
installation).

Tucked away in the Windows 3.0 section of the manual (have all
those people who complain about the product with Windows read pages
10 - 12?) is a reference to an EMB parameter which talked about VCPI and
EMS memory allocation schemes.

I had seen the term VCPI in the 1-2-3 manual and so, trial and error at
work, the EMB parameter (page 19) was added to the QEMM command in
config.sys and lo and behold, PC/FOCUS sees all the memory as expanded
and 1-2-3 sees it all as extended.

Moral
_____

Don't expect a software package to manage something as sophisticated as
machine memory to do a 100% job first time round on it's install
routine.  Expect some sweat to get the best from it.

----
Neale D. Hind - (N.D.Hind@stl.stc.co.uk)

valley@uchicago (Doug Dougherty) (01/29/91)

ndh@stl.stc.co.uk (Neale D Hind ) writes:

>Summary of this posting
>_______________________

>o   QEMM-386 seems an excellent product (I have no connection with
>    Quarterdeck)
>o   When trying to maximise the number of Devices/TSR's in high memory,
>    try swapping around the order in which they are loaded in your
>    config.sys and autoexec.bat files.
>o   Do read through the Fine-tuning parameters in the manual. Especially
>    the EMBMEM and EXTMEM if you are having problems with applications
>    clashing (eg some need expanded, others extended, memory).
>o   Statements in postings along the lines of "Product 'A' does not work
>    with product 'B'"  most likely mean "I do not know how to make product
>    'A' work with product 'B'"

Yes.  One question though (probably get an answer quicker here than from
QuarterDeck - they may be a great company technically, but their customer
support sucks) :

	Given that programs often need much more space to load than they
	leave resident, it should be possible to load them in such a way
	that even though there isn't enough High Ram available for their
	load image, if there is enough available for their TSR image,
	all is well.  I.e., 386MAX supposedly (haven't seen it up close
	and personal) allows you to temporarily deactivate the EMS page
	frame, so that a TSR can load part of its run time image there.
	I.e., suppose your TSR requires 40K to load, but only 17K resident.
	Further, suppose that the only remaining slot of High Ram starts
	at D800:0 and the EMS page frame is at E000:0.

	Would QEMM allow you to load your TSR high?  If so, how?

c164-al@juliet.uucp (Joon Song) (01/29/91)

In article <valley.665103177@gsbsun> valley@uchicago (Doug Dougherty) writes:
>	Given that programs often need much more space to load than they
>	leave resident, it should be possible to load them in such a way
>	that even though there isn't enough High Ram available for their
>	load image, if there is enough available for their TSR image,
>	all is well.  I.e., 386MAX supposedly (haven't seen it up close
>	and personal) allows you to temporarily deactivate the EMS page
>	frame, so that a TSR can load part of its run time image there.
>	I.e., suppose your TSR requires 40K to load, but only 17K resident.
>	Further, suppose that the only remaining slot of High Ram starts
>	at D800:0 and the EMS page frame is at E000:0.
>
>	Would QEMM allow you to load your TSR high?  If so, how?

How about -

            device = c:\qemm\qemm386.sys ram frame=none forceems

This is probably not the solution you had in mind, but it will let you
free up the EMS page frame, and use it to load TSR's and other device
drivers.

Joon Song

valley@uchicago (Doug Dougherty) (01/30/91)

c164-al@juliet.uucp (Joon Song) writes:

>In article <valley.665103177@gsbsun> valley@uchicago (Doug Dougherty) writes:
>>	all is well.  I.e., 386MAX supposedly (haven't seen it up close
>>	and personal) allows you to temporarily deactivate the EMS page
                                   ^-----------^
				   (That's the key!!)

>How about -

>            device = c:\qemm\qemm386.sys ram frame=none forceems

>This is probably not the solution you had in mind, but it will let you
>free up the EMS page frame, and use it to load TSR's and other device
>drivers.

>Joon Song

No.  I need EMS.

dgil@pa.reuter.COM (Dave Gillett) (01/30/91)

In <valley.665103177@gsbsun> valley@uchicago (Doug Dougherty) writes:

|	Given that programs often need much more space to load than they
|	leave resident, it should be possible to load them in such a way
|	that even though there isn't enough High Ram available for their
|	load image, if there is enough available for their TSR image,
|	all is well.  I.e., 386MAX supposedly (haven't seen it up close
|	and personal) allows you to temporarily deactivate the EMS page
|	frame, so that a TSR can load part of its run time image there.
|	I.e., suppose your TSR requires 40K to load, but only 17K resident.
|	Further, suppose that the only remaining slot of High Ram starts
|	at D800:0 and the EMS page frame is at E000:0.

|	Would QEMM allow you to load your TSR high?  If so, how?

|ndh@stl.stc.co.uk (Neale D Hind ) writes:

|>o   When trying to maximise the number of Devices/TSR's in high memory,
|>    try swapping around the order in which they are loaded in your
|>    config.sys and autoexec.bat files.


     It seems to me that the "easy" solution is to load TSRs that need big
load areas but small resident areas *first*, so that TSRs with smaller load
areas don't produce this problem.
                                                Dave

valley@uchicago (Doug Dougherty) (01/31/91)

dgil@pa.reuter.COM (Dave Gillett) writes:

>In <valley.665103177@gsbsun> valley@uchicago (Doug Dougherty) writes:

>|	Given that programs often need much more space to load than they
>|	leave resident, it should be possible to load them in such a way
>|	that even though there isn't enough High Ram available for their
>|	load image, if there is enough available for their TSR image,
>|	all is well.  I.e., 386MAX supposedly (haven't seen it up close
>|	and personal) allows you to temporarily deactivate the EMS page
>|	frame, so that a TSR can load part of its run time image there.
>|	I.e., suppose your TSR requires 40K to load, but only 17K resident.
>|	Further, suppose that the only remaining slot of High Ram starts
>|	at D800:0 and the EMS page frame is at E000:0.

>|	Would QEMM allow you to load your TSR high?  If so, how?

>|ndh@stl.stc.co.uk (Neale D Hind ) writes:

>|>o   When trying to maximise the number of Devices/TSR's in high memory,
>|>    try swapping around the order in which they are loaded in your
>|>    config.sys and autoexec.bat files.


>     It seems to me that the "easy" solution is to load TSRs that need big
>load areas but small resident areas *first*, so that TSRs with smaller load
>areas don't produce this problem.
>                                                Dave

Yes.  Unfortunately, all of my TSRs exhibit the pathology (of taking up
much more space to load than to be resident)