[comp.os.msdos.desqview] Desqview Not Running Programs

jf@spocom.guild.org (Jason Bassford) (06/07/91)

        Several months ago I discovered that Desqview would not run a 
couple of my programs properly.  Either they crashed or I got random dots 
appearing every once in a while on my graphics screen.  I got onto the 
Quarterdeck Canada support line but was unable to get my proglem 
resolved.  Now I just simply live with the fact that I have to exit DV 
and turn Qemm off (I have set up batch files for this) before I run the 
programs.
        However, as I continue to read messages re Desqview, I keep 
coming across people who cannot get DV to run programs properly.  Some of 
these problems are solved but some are not, no matter what is tryed.  So 
I asked myself, what could be going on here?  I know, for instance, that 
one of the programs which crashes on me with DV/Qemm (Chessmaster 2000) 
runs perfectly well on another persons computer with the same setup.  
Trying to apply certain scientific methods to this question I have come 
up with an hypothesis.
        It seems to me that a lot of these problems must be do to the 
fact that many of us (myself included) are using IBM clones.  Quite 
possibly there could be a glitch in the hardware of these computers which 
results in these many and inconsistent problems.  Because if it's not the 
software, what else could it be.  Anybody out there, if you have a 
program which simply REFUSES to work with DV and/or Qemm ask yourself 
this question.  Are you using an IBM or are you using a clone?  I would
be interested in knowing the answer to this.
        If it's possible that these problems are simply a matter of 
hardware then (while annoying for the computer owner), it would, 
nonetheless, dispel some of those many hours of frustration that we have 
all experienced when we KNOW that something just won't work but keep 
trying it anyway.

                Jason Bassford.

stanton@lurch.stanford.edu (Scott Stanton) (06/11/91)

In article <TwF732w164w@spocom.guild.org> jf@spocom.guild.org (Jason Bassford) writes:

           It seems to me that a lot of these problems must be do to the 
   fact that many of us (myself included) are using IBM clones.  Quite 
   possibly there could be a glitch in the hardware of these computers which 
   results in these many and inconsistent problems.  Because if it's not the 
   software, what else could it be.  Anybody out there, if you have a 
   program which simply REFUSES to work with DV and/or Qemm ask yourself 
   this question.  Are you using an IBM or are you using a clone?  I would
   be interested in knowing the answer to this.

                   Jason Bassford.

It is more likely to be BIOS problems rather than actual hardware
glitches.  You might compare notes with other people who have had
problems and see if you are all running unusual BIOS's.  In
particular, compare your BIOS to the machine that you got your setup
to work on.  You might be able to switch BIOS's and solve your problem
if this turns out to be the culprit.


--
--Scott Stanton     (stanton@cs.stanford.edu)   
--

smsmith@magnus.acs.ohio-state.edu (Stephen M Smith) (06/12/91)

stanton@lurch.stanford.edu (Scott Stanton) writes:
>jf@spocom.guild.org (Jason Bassford) writes:
>
>           It seems to me that a lot of these problems must be do to the 
>   fact that many of us (myself included) are using IBM clones.  Quite 
>   possibly there could be a glitch in the hardware of these computers... which 
>
>It is more likely to be BIOS problems rather than actual hardware
>glitches....

I suspect that there are more memory conflicts than people realize,
too--especially in the high ram area (>640k <1024k).  Sometimes
a simple NRH parameter on the QEMM386 line will solve the problem.
Hardware does some strange stuff sometimes...I've got a very
compatible Micronics 386-33 with the latest Phoenix BIOS, and I
have to use the following line:

DEVICE=C:\QEMM\QEMM386.SYS RAM NRH FR=C800

It took me over a week to figure out that my system MB utility
wouldn't work correctly with the page frame at the standard
E000-EFFF address!

Stephen M. Smith  \  +  /
<smsmith@magnus.  \+++++/    " #*&<-[89s]*(k#$@-_=//a2$]'+=.(2_&*%>,,@
 acs.ohio-state.  \  +  /      {7%*@,..":27g)-=,#*:.#,/6&1*.4-,l@#9:-)  "
 edu>             \  +  /
 BTW, WYSInaWYG   \  +  /                              --witty.saying.ARC