Shareware 1 2 the Maxx/sw_1.zip/sw_1/MEM_MAN/QOPTIMIZ.ZIP/OPTIMIZE.TEC

Text File | 1992-03-26 | 24KB | 431 lines

ID:OP Quarterdeck's OPTIMIZE Program
Quarterdeck Technical Bulletin #191
by Russell Bell
last revision:  13 February 1992

     The purpose of this document is to give a brief statement of what the
OPTIMIZE program does and explain in detail how to handle common problems that
can occur when it is run.

1)  What is OPTIMIZE?

     OPTIMIZE.COM is a program Quarterdeck supplies with its memory managers
(QEMM-386 and QEMM-50/60) and its memory enhancer, QRAM.  The same program is
used on all three products.  Beginning with version 6, QEMM-386 has a new
phase of OPTIMIZE for using the Stealth feature.  This will be covered in a
separate section of this technote.

     In this bulletin references to QEMM-386 should be construed to apply to
all three products.  The technote is not directly related to the functioning
of DESQview but DESQview may have more memory available for its windows if the
system has been OPTIMIZEd.

2)  What does OPTIMIZE do?

     The purpose of the OPTIMIZE program is to configure the CONFIG.SYS and
AUTOEXEC.BAT and any batch files CALLed in the AUTOEXEC.BAT to leave the
computer with the most conventional memory (the memory below 640 kilobytes)
possible and the largest possible remaining areas of High RAM.  OPTIMIZE does
nothing permanent to the computer other than edit the CONFIG.SYS and
AUTOEXEC.BAT and CALLed batch files.  All the work that OPTIMIZE does can be
done by the user by hand or reversed by hand in whole or in part.  The
OPTIMIZE program does it more quickly and almost always better.

3)  How does OPTIMIZE work?

     The first step of OPTIMIZE copies the CONFIG.SYS to CONFIG.QDK and the
AUTOEXEC.BAT to AUTOEXEC.QDK so that, if OPTIMIZE fails for some reason, or if
the user wishes to return to the configuration before OPTIMIZation, the
original system files are available.

     The second step of OPTIMIZE puts the "RAM" parameter on the QEMM-386
command line and runs "LOADHI/GS" on all the device drivers in the CONFIG.SYS
and all the TSRs in the AUTOEXEC.BAT and CALLed batch files and then reboots
the computer.  For QRAM users the RAM parameter is redundant:  QRAM creates
high RAM automatically.  On systems with DOS versions 2.x and 3.x all the
buffers (except one) will be moved from the CONFIG.SYS to the AUTOEXEC.BAT to
load them high.  On systems with DOS version 4 it is a more efficient use of
memory to load the buffers into expanded memory using the DOS feature, the
"/x" parameter.  Quarterdeck's BUFFERS.COM cannot be used with DOS 4.  On
systems with DOS version 5, buffers load into the HMA when you use DOS=HIGH,
so OPTIMIZE leaves buffers in the CONFIG.SYS unless you request more buffers
than can fit in the HMA, in which case BUFFERS.COM may be used to load buffers
high.  See below for a further discussion of this issue.  For more detail on
this issue, read Quarterdeck Technical Bulletin #226, "Buffers".  OPTIMIZE
uses the "/GS" parameter to determine how much memory a driver or TSR requires
to be loaded into memory.

     If the AUTOEXEC.BAT ends with a program that remains in control of the
computer (such as a menu program like DOS Shell or PC Shell) rather than
exiting to DOS then you must exit this program to continue OPTIMIZation.

     The third step of OPTIMIZE actually loads the device drivers and TSRs
high.  If it fails, the old CONFIG.SYS and AUTOEXEC.BAT are restored.

     If all the device drivers and TSRs can be loaded high then OPTIMIZE will
load them all high and leave a new CONFIG.SYS and AUTOEXEC.BAT on the system.
If they cannot all be loaded high, OPTIMIZE runs through all possible
configurations and chooses the ones that leave the most conventional memory
available.  If the OPTIMIZE process has completed then the screen will read:

     The OPTIMIZE process is complete.

If it does not then something has gone wrong.

THE LOADHI UTILITIES

1)  What does LOADHI do?

     LOADHI.COM loads resident programs (TSRs) into the high RAM created by
QEMM-386 (or QEMM-50/60 or QRAM).  LOADHI.SYS performs the same function for
device drivers.

2)  What can LOADHI not do?

     LOADHI.SYS cannot load high any program or driver that loads more than
thirty-two programs or drivers in turn.  If you are calling a batch file from
the AUTOEXEC.BAT then you must put its contents explicitly in the AUTOEXEC.BAT
in order for OPTIMIZE to load them high.  Alternatively you may load them high
by editing the batch file yourself as described in the LOADHI chapter of the
manual.

3) How much memory is needed to load a program high?

     LOADHI must have enough memory available to load a program.  A program
may use more memory to load than to remain resident.  LOADHI/GS reports both
the amount of memory needed to load and the amount needed to stay resident.
The amount of memory needed to load, not just the amount needed to stay
resident, must be available in one contiguous block for a program to be loaded
high.  OPTIMIZE creates a file named "LOADHI.OPT" in the QEMM (or QRAM)
directory that contains two numbers for each TSR or device driver:  the memory
size needed to load the TSR (or device driver) and the memory size needed for
it to stay resident.

4)  Why does my program not load high?

     Some programs refuse to be loaded high.  They may be unwilling to be
loaded above conventional memory or they may refuse to be crammed into the
region in which OPTIMIZE puts them or they may have some other complaint.
These programs are rare, but there is no fix for their objection.
     If a program (or device driver) does not remain resident there is no
point in loading it high.  This can be discovered by looking at the second
number LOADHI/GS reports (or the second number in LOADHI.OPT):  if this number
is 0 then the program does not stay in memory and does not need to be loaded
high.

5)  How can I tell what is being loaded high?

     Running "LOADHI" with no parameters or programs to load will give a
status report indicating what the high RAM regions are, what is loaded into
them, and what areas are available.  The First Meg/Programs page of Manifest
also shows what programs are loaded high as well as those loaded low.

     TROUBLESHOOTING

1)  What should I do if OPTIMIZE fails?

     If OPTIMIZE does not end by reporting "The OPTIMIZE process is complete,"
you should look at your CONFIG.SYS and AUTOEXEC.BAT to see if they are
unchanged.  If they are as they were in the beginning then OPTIMIZE has not
completed.  If the CONFIG.SYS contains "DEVICE=C:\QEMM\RSTRCFG.SYS ****
OPTIMIZE S%tep 2 [or 3]  ****" and the AUTOEXEC.BAT is "@OPT2" or "@OPT3" then
OPTIMIZE has failed and you should restore CONFIG.QDK to CONFIG.SYS and
AUTOEXEC.QDK to AUTOEXEC.BAT.  Beginning with QEMM-386 version 6, QEMM-50/60
version 6, and QRAM version 2, there is a program called "UNOPT" which
reverses the changes OPTIMIZE has made; you may run it to return your
CONFIG.SYS, AUTOEXEC.BAT, and CALLed batch files to the state they were in
before running OPTIMIZE by running UNOPT instead.  If the CONFIG.SYS and
AUTOEXEC.BAT do not have these lines in them, and they are not as they were
before running OPTIMIZE, and LOADHI reports that there are programs loaded
high, then OPTIMIZE was successful and you just missed the message "The
OPTIMIZE process is complete".

   2)  What can go wrong?

     A)  In general:

     If you have a third-party disk partitioner then drives other than C:
sometimes do not exist until it is loaded.  In these cases if you put QEMM-386
on any drive other than the C: drive, the disk partitioner must be loaded
first.

     OPTIMIZE cannot OPTIMIZE a CONFIG.SYS or AUTOEXEC.BAT longer than 512
lines.

     DOS does not allow lines longer than 128 characters in the AUTOEXEC.BAT.

          During the OPTIMIZE process lines are temporarily lengthened.  If
     you have a very long line, OPTIMIZE may increase it to more than 128
     characters long.  Shorten such a line if possible. If this is not
     possible then using the "/PATH" switch on OPTIMIZE may help.  See the
     section on "switches" below.  OPTIMIZE may also fail in certain rare
     circumstances if QEMM-386 is the first line in the CONFIG.SYS.  Try
     putting something harmless that does not get loaded high in the
     CONFIG.SYS before the QEMM-386 line, such as the "FILES=??" command
     (where "??" is the amount of FILES you want to load in the CONFIG.SYS).

     Some error messages may be reported during the OPTIMIZation process that
can be ignored, since OPTIMIZE proceeds normally after reporting the error.
For example:

--If you are using a command processor other than Microsoft's COMMAND.COM
(such as 4DOS) that has internal commands that Microsoft's DOS does not have,
LOADHI will not recognize them.  LOADHI will treat such a command as an
external command, reporting a "file not found" error when it is encountered.
     You can solve this problem by creating a file called OPTIMIZE.EXC in the
QEMM directory which contains the names of all the commands you want OPTIMIZE
to ignore.

     B)  In the first step:

     All that happens in the first step of OPTIMIZE is that backup copies of
the CONFIG.SYS and AUTOEXEC.BAT are made to CONFIG.QDK and AUTOEXEC.QDK.
Nothing should go wrong here.

     C)  In the second step:

     If OPTIMIZE fails at the second step then the two likely causes are some
conflict with memory management or a conflict in the address space.  The most
common cures for conflicts in memory management are the QEMM-386 parameters
"NOSH and "NT".
     QEMM-386 tries to manage the unused portions of five different varieties
of Chips & Technologies ShadowRAM but sometimes incorrectly identifies a
different implementation as one that it knows how to use.  "NOSH" tells QEMM-
386 not to try to use the ShadowRAM, clearing this kind of error.
     "NT" tells QEMM-386 not to try to manage Top Memory.  This is another
kind of memory, located at the top of the 16 meg address space, that QEMM-386
may misdetect or mismanage.  If your machine has no ShadowRAM or Top Memory
then these parameters will not affect the performance of the computer.

     The other likely cause of OPTIMIZE failing at the second step is that
QEMM-386 is placing High RAM in a portion of the address space used by another
device (hardware device) on the system.  If you have a network card, disk
controller with ROM, scanner with a RAM buffer, video capture card, or any of
a number of devices, you may have such a conflict.   QEMM-386 does not always
recognize the address space used by these devices; an explicit exclude
parameter ("x=mmmm-nnnn") on the QEMM-386 command line may be needed.  You
should consult the manuals of your hardware to find out what pieces of the
address space they use.  If this is not possible then you can follow the
analysis procedure as explained in the QEMM or Manifest manual before running
OPTIMIZE or adding the RAM parameter.  If you wish to do none of these you can
exclude all of the high RAM area ("x=a000-ffff") and then cut down on this
exclude ("x=c800-efff", then "x=c800-dfff", then "x=c800-d7ff", and so on; or
"x=e000-ffff", then "x=e000-efff", then "x=e000-e7ff", and so on) until you
find the smallest portion(s) of the address space that QEMM386 must be
instructed not to use to prevent the conflict.  The Quarterdeck Technical
Bulletin #219, "Using QEMM-386's Analysis", explains the use of the Analysis
feature of QEMM-386 to find excludes.

     The OPTIMIZE process can also fail at the second step if the file
"RSTRCFG.SYS" is corrupted.  You can copy this file over anew from the QEMM-
386 source disk to the QEMM directory.

     Finally, some programs will fail on the second step of OPTIMIZE because
they are incompatible with the /GS function of the LOADHI program, even though
the /GS parameter used in the second step of OPTIMIZE prevents any actual
loading into HIGH RAM.  In this case you should remark the program out (by
inserting the command "rem" at the beginning of the line on which the program
is loaded) for the duration of the OPTIMIZE process.  If this program is
needed in order to load other programs, you may create a file called
OPTIMIZE.EXC in the QEMM directory and put the names of any commands you do
not want OPTIMIZE to load high in it.

     C)  In the third step:

     If OPTIMIZE fails at the third step then the cause is:

      i) an attempt to load some driver or program high that objects;

      ii) loading high into a piece of the address space that is being used
          by a hardware device (conflicts are often found only when
          something is loaded high into an area);

      iii) the existence of a bus-mastering hard disk controller
           (usually a SCSI disk controller, but others are possible
           culprits).

     i)  If some driver or TSR misbehaves when loaded high then the cure is to
create a file called OPTIMIZE.EXC in the QEMM directory and enter the name of
this program in it.  You may need to find out which program is causing the
problem by OPTIMIZing with the AUTOEXEC.BAT out of the way (by renaming it to
something else) to isolate the problem to the CONFIG.SYS or AUTOEXEC.BAT and
then narrowing down which program(s) object to being loaded high by loading
partial AUTOEXEC.BATs.

     ii)  If an address conflict is the problem then the area in conflict must
be excluded as mentioned above in the troubleshooting section for step 2.

     iii)  If your system has a bus-mastering hard disk controller then you
must use the "db=xx" parameter on the QEMM command line.  "xx" should be a
number between 2 and 10.  This parameter sets aside a buffer of "xx" kilobytes
in unmapped conventional memory for diversion of disk i/o from mapped memory.
If you do not know whether you have such a device give this a try to see if it
works.  If your system has a bus-mastering device then a better solution is to
use the VDS (Virtualized DMA Services) driver that the manufacturer may have
written.  If your bus-mastering device is not a hard disk controller the VDS
driver is necessary if you wish to LOADHI.  See the Quarterdeck technical note
#121, "Bus-Mastering Devices and QEMM-386," for more information on this
subject.

STEALTH
     Beginning with version 6, QEMM-386 offers a new feature called Stealth,
in which QEMM-386 maps High RAM (and/or the page frame) over ROMs, monitors
the interrupts pointing into those ROMS, and when those interrupts come in,
maps the appropriate ROM into the page frame and redirects the interrupt
vector to its new location in the page frame.  When OPTIMIZE finished its
normal process, as described above, if it has not loaded every device driver
and TSR high, it asks you if you wish use Stealth.  If you choose to use
Stealth, OPTIMIZE will test your system to see if either Stealth mode is
compatible with your machine and CONFIG.SYS and AUTOEXEC.BAT.  If it is, it
will add a Stealth parameter (ST:M or ST:F) to the QEMM386.SYS line of the
CONFIG.SYS and re-OPTIMIZE with the additional High RAM.

     Quarterdeck has never seen a machine on which ST:F will not work.  If
OPTIMIZE reports that ST:F will not work, it is likely to be a device driver
or TSR in the CONFIG.SYS or AUTOEXEC.BAT.  You should try running
OPTIMIZE/STEALTH without anything else in the CONFIG.SYS and no AUTOEXEC.BAT
to see if it really is your computer, rather than a device driver or TSR that
is incompatible with Stealth.
     For more information about Stealth, see Quarterdeck Technical Bulletin
#205, "Troubleshooting Stealth."

DOS 5
     Although versions 6 of QEMM-386 and QEMM-50/60 and version 2 of QRAM
allow DOS 5's LOADHIGH and DEVICEHIGH to work, it is better to use
Quarterdeck's LOADHI.COM and LOADHI.SYS instead because LOADHI can load
programs into specific regions (the whole point of OPTIMIZE) and LOADHI/GS
can determine how much memory a program needs to load.  Using LOADHIGH and
DEVICEHIGH OPTIMIZE cannot do either of these two things, limiting its
usefulness greatly.

PROGRAMS THAT LOAD THEMSELVES HIGH
     Some programs load themselves high.  OPTIMIZE cannot determine how
much High RAM these programs use and the amount of High RAM they use throws
off OPTIMIZE's calculations.  It is usually preferable to use switches on such
programs to tell them to load low and let LOADHI load them.  If you do not do
this, place such programs at the end of the AUTOEXEC.BAT so that the High RAM
they use does not throw off OPTIMIZE's calculations.  A more sophisticated
approach is to EXCLUDE an amount of High RAM equal to the amount such a
program uses, remark it out during the OPTIMIZE process, then remove the
EXCLUDE and unremark the program afterwards.

     DOS RESOURCES

BUFFERS:  OPTIMIZE tries to load buffers high for all DOS versions 2.x and
3.x.  It does this by decreasing the buffers loaded in the CONFIG.SYS to one
and loading the rest in the AUTOEXEC.BAT with a statement like:

     C:\QEMM\LOADHI /R:1 C:\QEMM\BUFFERS=20

One buffer must be left loaded in the CONFIG.SYS (DOS defaults to providing a
higher number if none are specified).  For more information on buffers, read
Quarterdeck Technical Bulletin #226, "Buffers."

1)  What if I have DOS 4?

     Microsoft changed the structure of buffers with version 4 of DOS, making
it possible to load buffers into expanded memory.  This is preferable to
loading them high because no address space at all is used.  If you are using
DOS 4 or later then you may use the "/x" switch (e.g.:  "buffers=20/x").  Note
that expanded memory can be used only in 16K increments, so that buffers
loaded into expanded memory are allocated 30 at a time; no matter how few you
specify, with the "/x" parameter you get at least 30.  Before using the "/X"
parameter for DOS buffers, run Manifest and check the "Hints" section to
verify that it suggests loading buffers high with /X.  Some early DOS 4
versions have a bug which make it unwise to use this feature.  Manifest can
detect this and will not recommend loading buffers high if it detects the bug.
In addition, the /X parameter should not be used on BUFFERS until the RAM
parameter has been placed on QEMM-386.

2)  What if I have DOS 5?

     Beginning with versions 6 of QEMM-386 and QEMM-50/60, and version 2 of
QRAM, the BUFFERS.COM program allows buffers to be loaded high in DOS version
5.  If you are loading DOS high with the DOS=HIGH command, then DOS is putting
buffers into the HMA.  OPTIMIZE will leave these alone, since that portion of
the HMA would go unused if the buffers were not loaded into it.  If you try to
load more buffers into the HMA than will fit, DOS loads them low.  OPTIMIZE
will try to load buffers high if DOS loads them low.

3)  What if I am using a third-party disk partitioner?

     You may find that your buffers are using some huge amount of memory.  If
you are creating disk partitions larger than 32 MB with a version of DOS
earlier than DOS 4, the size of each buffer increases with the size of the
sector.  If you are missing a lot of memory then you may want to check the
DOS/Overview page of Manifest to see how much space your buffers are taking.
A buffer is 528 bytes for a normal 512-byte sector.  For partitions larger
than 32 MB the sector size grows by factors of two and the buffer size
follows.  This has nothing to do with OPTIMIZE or QEMM386:  your buffers use
this much space even if you do not run OPTIMIZE or load QEMM-386.  You can see
this by comparing the amount of memory the buffers are using in the
DOS/Overview page of Manifest with and without QEMM-386.

FILES, FCBS, LASTDRIVE:  OPTIMIZE does not load any of these DOS resources
high.  Since they use a comparatively small amount of memory, this does not
affect most users. If you want to load them high, you must do so by hand in
imitation of the way buffers are loaded high: decrease the number in the
CONFIG.SYS to a minimum and use LOADHI (for example: C:\QEMM\LOADHI
C:\QEMM\FILES=40) in the AUTOEXEC.BAT.  Note that because the drive specifiers
must be contiguous LASTDRIV creates a duplicate set of drive specifiers high
for all that were loaded low.  This means that the number loaded low should be
minimized in the CONFIG.SYS (for example:  "lastdrive=c" since DOS defaults to
"lastdrive=e") if "LASTDRIV.COM" is used to load drive specifiers high.
Although OPTIMIZE does not load any of these DOS resources high, once you have
them loaded high OPTIMIZE will fit them into high RAM in the location in which
they will most efficiently fit.

     SHARE

     If you have disk partitions larger than 32 MB with DOS 4 or greater and
are partitioning the disk with FDISK then SHARE.EXE is loaded implicitly by
DOS.  Optimize will not load it high unless it is explicitly invoked in the
CONFIG.SYS, for example:

     install c:\dos\share.exe


     NETWORK OPTIMIZATION

     If you are OPTIMIZing on a system where the COMSPEC is being changed to a
network drive then the AUTOEXEC.BAT and CONFIG.SYS in the directory where the
comspec points will be changed by OPTIMIZE.  If you want the AUTOEXEC.BAT and
CONFIG.SYS on a local drive to be OPTIMIZEd instead then OPTIMIZE can be
invoked with the "/B:a" switch (for example:  OPTIMIZE /B:a) where "a" is the
drive containing the AUTOEXEC.BAT and CONFIG.SYS to be OPTIMIZEd.


     SWITCHES

     /B:x
     This switch causes OPTIMIZE to modify the CONFIG.SYS and AUTOEXEC.BAT
files on the "x" drive.
     /L
     This switch causes OPTIMIZE to modify only those lines of the CONFIG.SYS
and AUTOEXEC.BAT that already have the LOADHI instruction on them (for
example:  "device=c:\qemm\loadhi.sys /r:2 driver.sys" or "c:\qemm\loadhi /r:1
c:\mouse\mouse"). This can be used to run OPTIMIZE and leave programs that you
do not want loaded high untouched.  You can do this by running OPTIMIZE, then
removing the LOADHI portion ("C:\QEMM\LOADHI /r:?") from the line of the
program that you do not want loaded high, then running OPTIMIZE /L.
     /PATH
     This switch adds the OPTIMIZE path to each command line so that
"C:\QEMM\" is not added every time LOADHI is invoked.  This makes these lines
shorter and may be useful for those with very long lines.


SUMMARY

     OPTIMIZE is an important feature of QEMM-386, QEMM 50/60, and QRAM.  It
is unparalleled in loading programs into memory in the most efficient manner.
Problems running OPTIMIZE are rare and it is worth the user's time to resolve
them.  Once the problem is solved the user should be able to run OPTIMIZE in
the future, when he/she changes his/her system's configuration, without
additional difficulty.

  ************************************************************************
  *This technical note may be copied and distributed freely as long as it*
  *is distributed in its entirety and it is not distributed for profit.  *
  *         Copyright (C) 1991-2 by Quarterdeck Office Systems           *
  ************************ E N D   O F   F I L E *************************