It's 11 Dec 96  20:28:38,
We'll return to Jack Pfisterer and All's
discussion of DESQview conflict?
 JP> A specialized DOS application I must use includes DESQview (v2.0).
 JP> In a VDM session under OS/2 WARP v3.0 it runs and executes one set of
 JP> specifi- cations without problem; but when I try to execute a second
 JP> set the pro- gram displays DESQview error messages calling for more
 JP> "system" memory.
Running DESQView under OS/2 is a rather tricky proposition at the best
of times, but the good news is that it _can_ be done.  I was muching
around one night, mainly because I was amused at the idea of a
multitasker within a multitasker, and set about getting DV up and
running (version 2.63).  The first thing I found is that the later the
DV version, the more difficult it is to run under OS/2.  2.63 has a
nasty tendancy to bomb DOS sessions with a fatal SYS error.  The
solution is to use a VMB session.  Booting real DOS under OS/2 will
provide an environment in which DV will run quite fine, I got it running
in a VMB almost as though it was running under plain DOS.
The other tweaks you'll need are:
1. Allocate expanded memory, especially if your application multitasks
under DV.
2. Allocate at least 64k XMS, so you can load either DOS or DV in the
HMA. Experiment, to see which gives the best results (from memory, only
DOS will load high, as DV won't use HIMEM.SYS, and OS/2 reccommends you
use the HIMEM.SYS supplied with OS/2).  Allocate UMBs in the VMB's
CONFIG.SYS.  BTW, I haven't tried the VIDEO_MODE_RESTRICTION settings to
gain larger windows under DV.  You might like to try that.
3. Change the MAP_LOW_OS setting to 576, to give secondary windows a
larger size (this controls how much conventional memory is mappable).
4. Set DV up to use the CGA mode driver (VGA mode doesn't work properly,
especially if you're trying to use 50 lines).  DV in CGA mode is fine.
 JP> Although the application copy of DESQview has no means for changing
 JP> "system" memory, I contrived to patch in higher values.  It turns out
 JP> that a "system memory" setting of 90 or higher (along with "common
 JP> memory" increased to 50) eliminates the error messages; but it also
 JP> turns out that this does not eliminate the underlying problem.  I
 JP> still cannot run a second set of specifications without interruption.
 JP> The program now just kicks me out of DESQview, back to the application
 JP> main menu with a couple of protesting beeps but without going through
 JP> the error message rigmarole.  Some gain, but not yet the whole
 JP> enchilada. (In case you wondered, a setting of 110 produces the same
 JP> result, but with THREE beeps.)
 JP> The folk at Quarterdeck were shocked by the high memory value settings
 JP> I used; but told me I would have to seek help from the developer of the
 JP> program in which DESQview was incorporated.  That developer is no
 JP> help.
 JP> Are there other settings that need to be changed to overcome this
 JP> prob- lem?  If it's a conflict between DESQview and OS/2 (not
 JP> unlikely), any ideas about what it is and how it might be
 JP> eliminated--either in DESQ- view settings or in OS/2 settings?  Any
 JP> suggestions, ideas, clues or wild guesses will be appreciated.
Hope my experience is of help to you.  Your "common memory" problem may
be caused by running under OS/2's DOS emulation.  I'd seriously try
setting up a boot disk image for the application, and tweak the
CONFIG.SYS in that boot image, as per my suggestions.
If you have any problems, feel free to ask. :-)
For a speedier reply, you can e-mail me at tlang@quest.apana.org.au. :-)
... Put your hard drive to your ear. Can you hear the C:?
--- FMail/386 1.02
---------------