Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!apollo!nelson_p
From: nelson_p@apollo.HP.COM (Peter Nelson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: programs crashing in Desqview
Message-ID: <492380c4.20b6d@apollo.HP.COM>
Date: 12 Mar 90 00:03:00 GMT
Sender: root@apollo.HP.COM
Distribution: usa
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 50


 boyer@iuvax.cs.indiana.edu (Charles David Boyer) posts

>nelson_p@apollo.HP.COM (Peter Nelson) writes:
>
>>    After posting some problems I've had in running certain 
>>    programs under Desqview I've received many responses from 
>>    other people describing problems they've had with Desqview.
>>    I've also read of other problems in running certain programs
>>    under Desqview here on the net and on various BBS's. 
>
>>    As a result of all this I am forced to sadly conclude that 
>>    Quarterdeck's product, while probably adequate for certain
>>    "known-to-be-safe" applications, is not yet a reasonable
>>    choice for a general-purpose environment.  Based on my
>
>Since there has been an awful lot of DesqView bashing related to your
>problems, I think I would like to balance the argument on the other side.
>I have been using DesqView since version 1.0 and find it to be a very good
>"general" environment.  Yes, it does require tweaking, an
>understanding of the environment, the applications you are running, and the
>limits of DOS in a multitasking environment.
 
 But this was the basis of my complaint: Desqview gives no indication
 of the degree to which this is necessary.   Moreover, it is not
 usually possible (or practical, anyway) to understand the "applications
 you are running", in terms of how they interact with the system to
 result in the problems they experience in Desqview.   You seem to be
 making the same assumption that Quarterdeck does in their manual
 that programs are all written in assembler and we have the source
 code!  "Understanding" the application from Desqview's standpoint means
 knowing how much stack space it uses, how it allocates buffers, what
 functions it uses DOS for, the BIOS for, or direct calls to the hardware
 for, and so forth.   And even if you do manage to find these out you
 usually have no control over it.   For instance, I found out WHY
 Fastback crashes in Desqview, but that didn't suggest a way to run
 it in Desqview.

>I do not think, however, that your inability to find a synergy with DV
>means that it is a bad program. In particular, I do not think that
>you have enough experience with Desqview to make the general, negative
>remarks that appear in your note.

 But remember from my posting, I am not just basing my comments on MY 
 experience but on postings or email from many other people.   Also,
 remember that people who presumably know much more than I do about
 Desqview, i.e., their tech support staff, have been just as stumped 
 as me about some of these problems.

                                                    ---Peter