ID:X2 XDV.COM/DV.COM - vs - DV.EXE
Quarterdeck Technical Note #125
by Dan Sallitt

Q: Why does DESQview fail when I use XDV.COM or DV.COM but work
correctly when I use DV.EXE?

  XDV.COM, which is usually renamed to DV.COM by the DESQview
Install program (before DESQview 2.26, the Install program did
not automatically perform this renaming, though Quarterdeck's
documentation recommended that it be done manually), is a loader
that places bits of DESQview code in high memory areas.  It is
useful on any system that has expanded memory, or on any system
that has extended memory and is using DESQview's QEXT.SYS driver,
or on any system using QEMM.SYS.  If DESQview loads successfully
when started with the DV.EXE file but not when started with
XDV.COM or DV.COM, there are two likely possibilities:

1) The system's expanded memory manager (EMM) has allowed
DESQview to place a piece of its code in an area between 640K and
1024K (known as the reserved memory area) that is already being
used by hardware in the system;

2) QEXT.SYS is conflicting with another program that is using the
first 64K of extended memory.

  In the first case, one must determine which part of the area
between 640K and 1024K is in conflict, then exclude it using the
expanded memory manager's parameters.  If you know the hardware
in the system, you should consult the manuals (or the
manufacturers) of the expansion boards in the machine to
determine the addresses that are being used for ROM extensions,
buffers, etc.

  If your system is a 386 running QEMM-386, the QEMM.COM Accessed
screen (also available as the Manifest QEMM 386\Accessed screen)
can provide valuable hints about what areas of memory are in use. 
To use the Accessed screen, remove the RAM parameter (if it is in
use) from the QEMM line in the CONFIG.SYS file, add the ON
parameter, and reboot the machine.  Any area that the Accessed
screen then shows as having been touched, but that the QEMM Type
screen shows as Mappable or Rammable, is a good candidate for
exclusion.

  Failing this, you should use the /X parameter to DV.COM or
XDV.COM to exclude different areas of reserved memory, making the
exclusions smaller and smaller until the conflict is pinpointed. 
Like most memory managers, DV.COM/XDV.COM takes hexadecimal
addresses; in hexadecimal, the range A000-FFFF represents the
addresses between 640K and 1024K.  Thus the command line

          XDV /X:A000-FFFF

prevents DESQview from putting its code anywhere between 640K and
1024K.

          XDV /X:A000-CFFF

excludes the first half of this area, and

          XDV /X:D000-FFFF

excludes the second half.

All the possible 16K areas that can be excluded on DV.COM/XDV.COM
are listed below.

A000-A3FF   A400-A7FF   A800-ABFF   AC00-AFFF
B000-B3FF   B400-B7FF   B800-BBFF   BC00-BFFF
C000-C3FF   C400-C7FF   C800-CBFF   CC00-CFFF
D000-D3FF   D400-D7FF   D800-DBFF   DC00-DFFF
E000-E3FF   E400-E7FF   E800-EBFF   EC00-EFFF
F000-F3FF   F400-F7FF   F800-FBFF   FC00-FFFF

  To exclude a number of these consecutive ranges, use the
endpoints of the first and last block that you want to exclude. 
For instance:

          XDV /X:A000-ABFF

excludes the first three 16K areas above 640K.

  To determine if QEXT.SYS is in conflict with anything in the
system, use this special exclusion on DV.COM or XDV.COM:

          XDV /X:FFFE

  Since the Quarterdeck Expanded Memory Manager-386 (QEMM-386)
and other expanded memory managers for 80386 machines allow
DESQview to place code in the QEXT area without the actual
presence of the QEXT.SYS driver, this exclusion should be tried
when troubleshooting 80386 machines in general.

  If the /X:FFFE exclusion eliminates the problem, look in the
CONFIG.SYS and AUTOEXEC.BAT files for drivers or terminate-and-
stay-resident programs that may be using extended memory.  If a
program is in conflict with QEXT.SYS, the program may take
parameters that will prevent it from using the addresses between
1024K and 1088K, which QEXT.SYS must use.

  It sometimes happens that a problem with XDV.COM or DV.COM is
not localized: that is to say, almost any use of the .COM files
to put DESQview code in almost any area causes the problem.  In
such cases, one should probably look for a low-level conflict,
usually on the hardware level.  One situation of this sort occurs
on 80286 (or lower) systems on which an expanded memory board is
used to backfill motherboard memory without the user having
disconnected the already existing motherboard memory.  The
resulting address conflict causes immediate crashes with DV.COM
or XDV.COM; DV.EXE will also crash in this circumstance, but not
until DESQview has to allocate expanded memory to open multiple
windows.

       Copyright (C) 1991 by Quarterdeck Office Systems
             * * * E N D  O F  F I L E * * *