ID:TP TOPS network, DESQView and QEMM 386 by TOPS Corp. Technical Support #163 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 * * *