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