Xref: utzoo comp.sys.ibm.pc:45437 comp.sys.ibm.pc.programmer:178
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucsdhub!hp-sdd!apollo!nelson_p
From: nelson_p@apollo.HP.COM (Peter Nelson)
Newsgroups: comp.sys.ibm.pc,comp.sys.ibm.pc.programmer
Subject: RE programs crashing in Desqview
Message-ID: <48eab494.20b6d@apollo.HP.COM>
Date: 28 Feb 90 17:00:00 GMT
Sender: root@apollo.HP.COM
Distribution: usa
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 67


  phil@pepsi.amd.com (Phil Ngai) posts...
:In article <48e5784c.20b6d@apollo.HP.COM> nelson_p@apollo.HP.COM (Peter Nelson) writes:
:| I recently posted a problem about some simple C programs
:| crashing in Desqview in graphics mode.  I called Quarterdeck.
:| [ Warning: due to recent new releases Quarterdeck's tech support
:| staff is swamped.  I called Desqview during their recommended 
:| "light" period and had to wait on hold for 25 minutes, at 
:
:Gee, I should be so lucky. All I ever get is a busy signal.

  The trick is to call their main number and ask for tech support, 
  rather than calling their tech support line.   Of course, now that
  I've publicized this they'll stop allowing it.

:| BTW, before deciding to buy Desqview I had a couple of conversations 
:| with their tech support staff to try to assess the risks in using 
:| such a product.  One area I focused on was the graphics environment
:| They said that they can virtualize it, I expressed doubt.  One major
:
:They supposedly can virtualize all the IBM modes. They make no
:claims to handle any extended modes and you should not expect
:them to do so.

  I'm running 640X480 X 16 colors, which I believe is standard IBM.
  I gave up trying to run 256 colors because practically nobody
  supports it or agrees on how it's done.

:| area of doubt was color LUT ("palette") collisions.  I said I didn't
:| see any way they could keep one application's changing of the 
:| color look-up-table from affecting colors in other windows.  They
:
:If you mean windows smaller than full size, of course there is
:nothing that can be done about this besides making the active
:window have the correct colors, which is something they should
:be able to do.

 Well, *I* knew that; it bothers me a little bit that I could have 
 have anticipated a limitation of a product I hadn't even *bought yet*,
 that the tech support staff for that product wasn't aware of.

:| They DO attempt to read-save-and-restore the LUTS for switching
:| windows but this doesn't work reliably.  I've had cases where the 
:| colors do not return to their previous state when the other program
:| ends.

:Did you have the "program uses own colors" mode turned on?

   I tried this both ways with the only effect being that in one
   case the colors returned wrong (white on gray, instead of the 
   original green on black) when my program returned to DOS and
   in the other case they returned white, BLINKING!  

   I've been running with DV protection mode = [3] to try to trap whatever
   the problems are with the C programs.  Although nothing has turned
   up there, I did get a protection violation from DOS FORMAT the other
   day amd last night I got one from DOS PRINT.   This is interesting
   because when I was trying to decide whether to buy MSDOS 3.3 or 4.01
   (I settled on 3.3) I called Microsoft's tech support to ask them
   about all the problems that have been reported with 4.01.  They
   said thay were due to sotfware companies not follwing their coding
   guidelines and writing badly behaved code.   Apparently one of those
   software company's initials are M.S. 

                                                        ---Peter