Jason Aller Floppy Collection/101.img/QW10INST.ZIP/QWHITE10.EXE/TOPS.TEC

Text File | 1990-07-02 | 10KB | 157 lines

ID:TP TOPS network, DESQView and QEMM 386
by TOPS Corp. Technical Support
April, 1989

                                 OVERVIEW

DesqView is a multi-tasking windows environment for DOS-based machines,
made by Quarterdeck Office Systems in Santa Monica, CA. The current version
(as of January, 1989) is 2.22. It can be run on any machine running DOS 2.0
or higher, on an 8088, 8086, 80286, or 80386 microprocessor. On 386-based
machines, it is most commonly used in conjunction with Quarterdeck's 386
Expanded Memory Manager, QEMM-386, to form a combination generally referred
to as DesqView386. You can run DesqView on a 386 without QEMM-386, but you
lose significant memory-management capability, ending up with an
environment virtually identical to DesqView on a 286, only faster. The
current version of QEMM-386 (as of January, 1989) is 4.23. Note that
DesqView and QEMM-386 are separate products which must be purchased
separately, and can be used together, or independent of one another. For
the reason stated above, it is rare to find someone running DesqView on a
386 without QEMM-386. However, for reasons which will become clear, many
people who do not own DesqView buy and use QEMM-386 as their 386 Expanded
Memory Manager of choice. In fact, we may wish to recommend QEMM-386 as a
solution to TOPS/DOS users on 386 machines who are having trouble running
their applications in conventional RAM.

QEMM-386 has two major functions. Firstly, it can transform a 386's
standard 'extended' memory into 'expanded' memory (LIM EMS 4.0 and EEMS
3.2), which can then be accessed by programs designed to take advantage of
expanded memory, as well as by DesqView, which can use it to create
'virtual' DOS environments for simultaneous operation of multiple programs.
Secondly, it can map RAM into the unused addresses between 640K and 1MB (so-
called 'HIGH DOS RAM') and allow a user to load TSR modules (such as TOPS
modules, for example) into it, thus making more 'conventional' RAM
available to applications. These two functions are optional, and can be
managed independent of one another, but the first will have a significant
impact on the second, for the following reason. How much HIGH DOS RAM is
available is a function of the particular machine architecture and attached
peripherals (display adapter, etc.) AND of whether or not you invoke
Expanded Memory Emulation. Managing Expanded Memory requires a 64K page
frame in HIGH DOS RAM. (DesqView can perform many of its expanded memory
operations without a page frame, but most applications that use expanded
memory require the page frame to access it.) This function will therefore
reduce the amount of HIGH DOS RAM available to TSRs by 64K. Obviously, from
the point of view of someone who merely wishes to get TOPS 'out of the
way', it would be best to disable Expanded Memory Emulation. But the price
one pays is effectively rendering useless all that expensive Extended
Memory with which one's 386 is loaded. This presents an interesting dilemma
for someone running TOPS and QEMM-386 without DesqView. Do they disable
Expanded Memory Emulation, get as much as possible of TOPS into HIGH DOS
RAM, and have the maximum amount of conventional RAM (but no Expanded RAM)
available for their applications? Or, conversely, do they enable Expanded
Memory Emulation, which forces them to put more of TOPS into conventional
RAM, but makes Expanded RAM available to their applications? If you are
running DesqView386, you get less benefit out of disabling Expanded Memory
Emulation, since DesqView can use half of the page frame area anyway to
clear its code out of conventional memory, and since certain DesqView
features require a page frame.

QEMM-386 consists, mainly, of a device driver (QEMM.SYS) and two command-
line utilities (QEMM.COM and LOADHI.COM). QEMM.SYS is loaded from
CONFIG.SYS with a command of the form: DEVICE=[d:][path]QEMM.SYS [options].
If QEMM.SYS is installed, DesqView, when launched, will recognize it, and
take advantage of the services it provides. QEMM.SYS works by using the
'virtual 8086' mode of the 386 microprocessor to provide such services as
Expanded Memory Emulation. It has three possible 'states' in this regard -
AUTO, ON and OFF. AUTO means that Expanded Memory will be available only
when a program needs it. ON means it will always be available, and OFF
means it is not available. The default state (which can be set as an option
to QEMM.SYS) is AUTO. The current state can be checked and set using
QEMM.COM. The default state for Expanded Memory Emulation is enabled. To
disable it, add the option FRAME=NONE to QEMM.SYS. HIGH DOS RAM Mapping is
enabled by adding the option RAM to QEMM.SYS. (Note that this forces the
initial state to ON, and it cannot be overridden.) To load TSRs into this
RAM, use the utility LOADHI.COM with a command of the form: LOADHI
[d:][path]program. There must be a contiguous section of high memory that
is large enough to load the TSR, or LOADHI.COM returns an error, and loads
the TSR into conventional RAM. You can get a map of the first 1MB of RAM by
entering the command QEMM without any parameters. This will also return the
current 'state' of QEMM.SYS, and the amount of Expanded Memory, if any.


                           DesqView386 AND TOPS

I recently tested DesqView386 2.2 (as well as QEMM-386 4.2 as a stand-alone
memory manager) with TOPS/DOS 2.1 and NetPrint 2.0 on a Compaq386/20 with
2MB RAM, VGA, and Compaq DOS 3.31. Results were uniformly excellent on both
AppleTalk and Ethernet IF the basic rules of DesqView/QEMM/TOPS
compatibility are followed.

Rule #1: Do not run DesqView on a TOPS Server. There appears to be a basic
incompatibility between DesqView and TOPS' Server functionality. This
applies not only to DesqView386, but also to DesqView on a 386 without QEMM-
386, as well as to DesqView on a 286, 8086 or 8088. It is fine to have the
full client/server software loaded, but if you have something published and
someone tries to access it, you will have problems. Usually, both client
and server will eventually hang. Note that I found no problem being a TOPS
Server when just QEMM-386 was loaded and active, unless DesqView was loaded
as well. I did not test being a Print Server, but I would expect similar
results.

Rule #2: The LAP driver must have DMA set to none if QEMM-386 is loaded and
active ('state' is ON). This is true in the case of ALAP and ELAP503,
although the symptoms using ALAP are much more dramatic. If ALAP is set to
use DMA 1 or 3, and QEMM is ON, you will hang when you load TOPS or
NetPrint. If QEMM is AUTO, you will probably hang at some point after
loading DesqView, or otherwise accessing Expanded Memory from an
application. The problems seem to take longer to develop when using ELAP503
with a DMA channel, but they were unavoidable. Since the default for
ELAP503 is DMA=0, this will not normally be a problem. The rule of thumb
is, if you are using QEMM-386, disable DMA.

Rule #3: With DesqView, configure the LAP driver to use a software access
interrupt other than the default. The default software access interrupt
used by all the TOPS LAP modules is 5C. We suggest configuring the driver
to use some other interrupt, such as 60. This can be most easily
accomplished through the "CONFIGURE" option in the SETUP program.

Rule #4: Load TOPS and/or NetPrint BEFORE loading DesqView. All TOPS and
NetPrint functions can be executed from within DesqView EXCEPT for the
actual loading of the memory resident modules.

When the above four rules were followed, all the TOPS network functions I
tried worked flawlessly. I was able to see network servers and printers,
print to network devices, mount remote volumes, (and publish and act as a
server, if DesqView was not loaded), do bi-directional copying between two
machines, and run programs remotely, both from the command line in DOS with
QEMM.SYS on, as well as from DOS Windows in DesqView. You can even create a
DesqView Program Information File for TOPSMENU and CONFIGUR, and run them
in a DesqView Window. In one interesting experiment, I modified the Program
Information File for Microsoft Word 4.0 to run off drive D:, then I mounted
a Macintosh folder, copied the contents of my Word subdirectory into it,
launched Word remotely off the Mac drive, opened a Word document, edited
it, saved it, and printed through NetPrint, all from within DesqView with
QEMM.SYS active. I was able to perform all these functions both with TOPS
and NetPrint loaded in conventional RAM, as well as when various TOPS and
NetPrint modules had been loaded into HIGH RAM with LOADHI.COM.

The same tests were performed with the previous version of DesqView,
version 2.01, and its companion QEMM-386, version 4.1, with identical
results, with one exception. If you try to load a TSR with LOADHI.COM, and
there is insufficient contiguous HIGH RAM available, LOADHI will inform you
of the fact, and load the program into conventional RAM. If this occurred
with a TOPS module under QEMM-386 4.1, TOPS functions would no longer work.
It was necessary to LOADHI only those modules which would fit in HIGH RAM,
and do a conventional load on the others. This problem did not occur with
QEMM-386 4.2.

It is important to keep in mind that different architectures and designs
are employed in different 386-based machines. This can sometimes result in
different behavior from TOPS with 386 Expanded Memory Managers on different
machines. We have seen the exact same programs and configurations work on
one 386 machine, and fail on another. In general, reports from the field
have been uniformly positive regarding TOPS and DesqView386 when the above-
mentioned rules are followed.

                  * * *   E N D   O F   F I L E    * * *