Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ukma!xanth!ginosko!uunet!sli!rich
From: rich@sli.com (Rich K. Braun)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: DESQview 386 Question
Message-ID: <1989Aug7.053410.12364@sli.com>
Date: 7 Aug 89 05:34:10 GMT
References: <956@swdev.Waterloo.NCR.COM> <8989@cs.Buffalo.EDU> <1681@garcon.cso.uiuc.edu>
Reply-To: rich%sli@uunet.uu.net (Rich K. Braun)
Organization: Software Leverage, Inc. Arlington, MA
Lines: 35

I just purchased DESQview 2.2 for my new 386, and have had positive
experiences so far.  It can run any number (well, up to 256) of simultaneous
tasks, and seems to handle I/O contention between various tasks quite well
(e.g. you can run a C compiler, a BBS, or a database application which
performs disk I/O in the background while accessing the same disk in your
active window).

One comment I have on their windows (are any DESQview developers reading this?)
is that they don't provide a way to query the user for a command line when
invoking an application from the top-level menu.  You have to run things which
need command lines (such as editors) under the PC-DOS shell, which eats up
memory.

While I'm on this subject, I wonder if anyone out there knows of a C compiler
which runs under DESQview in native mode, producing code which will run in
native (386) mode?  I'd love to see GNU C capable of doing this.

On memory allocation:  the DESQview manual contains several pages of text
on how to set things up such that it doesn't consume 145K of "conventional"
memory when firing up an application.  Since some of my applications really
want to have 640K or more, I'd like to set this up.  But I must confess that
my first pass through the DESQview manual didn't make things obvious, and
I'm also confused on the difference between the various extended and expanded
memory standards on the PC.  (Why did Intel do this to us?  Life's so simple
on the 68020, where you just have a 4G linear address space...)

On disk I/O performance:  apparently DESQview robs the foreground process of
enough CPU cycles to hurt disk I/O dramatically.  I'm running an RLL disk
with 1:1 interleaving, and it appears that although I can read an entire
track full of sectors in a single revolution from PC-DOS, if I do the same
thing under DESQview with certain applications (XCOPY is the simplest example),
it's clear that the disk has to spin several times before a track is read in.
Any clues on how to prevent this from happening?

-rich