nelson_p@apollo.HP.COM (Peter Nelson) (02/28/90)
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
Massachusetts to California long distance phone rates.]
They suggested switching the ATi VGAwonder card to 8 bits
or, as a diagnostic measure, removing QEMM.
I chose the latter and the problem seemed to go away. Of
course so did most of my memory. Any idea what this says
about the problem?
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
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
said, in effect, "no problem". Probably they meant, "no problem
for us". I certainly have had "no problem" in clobbering the
colors in one window by changing the LUTs from a program in another
window. A glance at the manual shows that this is to be expected.
So Quarterdeck's another company whose tech support needs to have
a better understanding of their product.
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.
BTW, I had another problem running Desqview yesterday. I was formatting
a pile of 3.5" disks in a Desqview window (one of two that were open)
and I got an error from Desqview's protection mechanism indicating
that the DOS "format" had committed a protection violation! I
quit out of that and started over and formatted another 10 disks
without incident. I had the protection set to [3] so it's possible
that it was finding a real DOS error that was simply not noticed before.
How do I tell?
---Peternelson_p@apollo.HP.COM (Peter Nelson) (02/28/90)
Recently I posted something about programs crashing in Desqview.
As a result I got mail from others who have had the same problem
(unfortunately I don't yet have a solution).
But this does raise another question.
Someone once said that " [...] is like a talking dog. It's
not a question of how well it does it. The wonder is that it
can do it at all!"
Are multi-task environments on PC's just talking dogs? Are
they an idea that the PC world is just not ready for? PC's
were designed as single-user devices. Both the hardware and
the operating system were designed for single programs which
own the machine. Moreover, an enormous number of existing
programs were written with that in mind. By now I've heard
quite a few problems with Desqview and I've heard even more
horror stories about Windows.
On the other hand, many people have bought these products. I
think I remember seeing somewhere that Quarterdeck has sold a
million copies of Desqview. My suspicion is that most users
fall into 2 camps: Those who are running a handful of carefully
chosen applications programs that are "well behaved" in such
an environment or those who are trying to do as I want to
do, and use it for general stuff including software development
and arbitrary commercial applications. I suspect that most of
the latter just resign themselves to odd crashes and collisions.
But I'm not sure I'm prepared to do that.
Perhaps it's unrealistic to expect to be able to run multiple programs
on PC's without worrying about them crashing into each other the way
we (usually) can on workstations and mini's. Perhaps it's a bit like
trying to fit wings to a car and fly it. Sure, it's been done, but
it's a tremendous kluge and most people would rather fly planes which
were designed as planes to begin with.
Someone wrote to me to say that I have unrealistically high
expectations for being able to apply the same standards to PC's
as I do to workstations; that PC's are single-user *micro's*,
after all.
In a sense this is true, but my new "micro" machine has more MIPS
and more RAM than the minicomputer my whole software *department*
shared at my last job! PC's are like a child who has suddenly
grown very big and very strong but still has the intellect and
emotions (software) of a child. This can make them very unruly.
---Peter
phil@pepsi.amd.com (Phil Ngai) (02/28/90)
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. | 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. | 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. | 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? -- Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!phil A PC without DESQview is like Unix without ^Z.
phil@pepsi.amd.com (Phil Ngai) (02/28/90)
In principle a 386 PC should be able to run DOS jobs in a
virtual 8086 and any crashes should not affect the other jobs.
In practice I do not know if DV does this. I think DV still
runs in real mode even on a 386. However, OS/2 R 2 is supposed
to use the virtual 8086 mode.
On a 286, of course, you have to cross your fingers.
--
Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!phil
A PC without DESQview is like Unix without ^Z.eddjp@althea.UUCP (Dewey Paciaffi) (02/28/90)
In article <48e591a9.20b6d@apollo.HP.COM> nelson_p@apollo.HP.COM (Peter Nelson) writes: > > Are multi-task environments on PC's just talking dogs? Are > they an idea that the PC world is just not ready for? PC's > were designed as single-user devices. Both the hardware and > the operating system were designed for single programs which > own the machine. Ouch. Please don't tell my 386 running UNIX or my 5 locally attached users this. Also please don't mention it to the users on my Novell LAN that access the 386 through the TCP Gateway. I told them they could all use it because it was multi-tasking... -- Dewey Paciaffi eddjp@althea.UUCP
nelson_p@apollo.HP.COM (Peter Nelson) (03/01/90)
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
nelson_p@apollo.HP.COM (Peter Nelson) (03/03/90)
eddjp@althea.UUCP (Dewey Paciaffi) posts...
:In article <48e591a9.20b6d@apollo.HP.COM> nelson_p@apollo.HP.COM (Peter Nelson) writes:
:>
:> Are multi-task environments on PC's just talking dogs? Are
:> they an idea that the PC world is just not ready for? PC's
:> were designed as single-user devices. Both the hardware and
:> the operating system were designed for single programs which
^^^^^^^^^^^^^^^^^^^^
:> own the machine.
:
:Ouch. Please don't tell my 386 running UNIX or my 5 locally attached
:users this. Also please don't mention it to the users on my Novell LAN
:that access the 386 through the TCP Gateway. I told them they could all
:use it because it was multi-tasking...
I thought is was clear from my discussion that I was talking about DOS
and the programs written to run under it which is causing the problem.
Programs written for UNIX or OS2 know that they're running under a
multitasking OS so they don't act like they own the machine.
Does the UNIX you are using have a DOS compatibility mode? If so,
can you run *ANY* DOS programs in it or only well-behaved ones?
How much support does your sytem require? Is most of the software
you run plug'n'play or do you need to have the sevices of a "guru"
(perhaps yourself) to port programs, resolve problems and so forth?
I am looking for an environment where I can buy a new piece of
software, run "setup", and then use it without having to worry
about weird interactions between it and the other application
software, the OS, the BIOS or the hardware. I don't want to have
to spend my time experimenting, tweaking, debugging, or calling
tech support. I want things to work out of the box! I paid my
bit-twiddling dues long ago; I built whole computers from scratch in
the 1970's and at one point I had the opcodes, in hex, for the
Intel 8080 memorized. I had articles about my creations in Byte in the
1970's. I want to graduate from that level of thinking and actually
*use* the computer for something, not spend my time f***ing around
with it. All my other high-tech hobbies (photo, video, audio, ham
radio) had a period in their history when doing them meant tinkering
and tweaking if you wanted things to work properly. Thankfully,
they all graduated to out-of-the-box reliability. With photography
this happened with the invention of roll film, with video it happened
with the advent of Beta and VHS. Someday it will happen with PC's;
I hope it's soon.
I actually have considered running some other operating system
besides DOS: UNIX and OS2 are the ones that come to mind.
The problem is, as everybody knows, that despite all the short-
comings of DOS as an operating system, there is an enormous
amount of commercially available, well-supported software written
for DOS, moderately priced, and designed for use on the PC hardware
platform. There's actually quite a bit of UNIX software out there
too, but little of it is designed to run in the PC environment
(this is especially a problem for graphics) and there's always
a certain amount of "porting" that must be done when moving software
from one machine to another.
---Peter
nelson_p@apollo.HP.COM (Peter Nelson) (03/06/90)
I've found another program I use frequently which crashes in
Desqview: Fastback Plus, the backup utility.
It runs all of its setup and estimate phases OK but then
when it goes to actually begin the backup it hits a "protection
violation". Desqview puts up a pad telling me so and
giving me one choice: Abort. Unfortunately, no amount of
clicking on the "Abort" actually DOES anything! If I do "alt"
and bring up the Desqview menu about *half* the time I can
close the window, the other half the menu does not respond
at all and I have to reboot. Interestingly, I seem to hit
this protection violation regardless of the protection mode I
run the Desqview window in. Also, the problem seems to exhibit
itself regardless of whether there are any other programs running
under Desqview; the only prerequisite is that Fastback be running
in a Desqview window. I have never had any problem running
Fastback outside of Desqview.
I'm running Fastback in a 535K window. The manual does not get real
specific about the significance of a protection violation except
to say that *some* programs which experience them are only doing
something harmless and adds ominously that the user can always
run such programs anyway and "hope for the best".
I realize, of course, that Fastback probably IS trying to access
some location it has no right to and that Desqview is only telling
me about it. But I would appreciate it if Desqview would handle
things a litle more gracefully and not lock up when an exception
like this occurs.
---Peter
PS- A new variation on graphics problems with Desqview: over
the weekend I was simultaneously running one of my Zortech C
graphics programs and Timeworks' Publish It! DTP program.
I noticed on two separate occasions (with a reboot in between)
that Desqview's menus, including their Change Program came
up almost unreadable: not only were the colors all messed
up, but there was a double image of all the text!! Every
character, including the diamond cursor character, had a little
echo of itself in a different color, one character position
to the left! Has anyone seen this with Desqview before?
I just started using Publish It! this weekend but it's a program
which does a lot of things and considering all the problems
I've had with simpler programs under Desqview, I'm a little
worried about running Publish It! in Desqview; does anyone
have any experience with this? Thanks in advance for any
comments.
fender@banana.ucsb.edu (Chen) (03/06/90)
In article <29312@amdcad.AMD.COM> phil@pepsi.amd.com (Phil Ngai) writes:
In principle a 386 PC should be able to run DOS jobs in a
virtual 8086 and any crashes should not affect the other jobs.
In practice I do not know if DV does this. I think DV still
runs in real mode even on a 386. However, OS/2 R 2 is supposed
to use the virtual 8086 mode.
DV runs in real mode, but it's qemm.sys that runs in protected mode,
then dv uses the qemm to use the expanded memory. If you notice, if
you try to run protected mode software while qemm.sys is installed,
but dv.com is not running, you'll get an error message saying you
already have protected mode software running.
My personal opinion: DV is good, but not great. My biggest problem
is running a program and having the video monitor make a clicking
noise, then blanking out, and crashing so hard that I have to hard
re-boot. The software reboot does not work, meanwhile the monitor is
whining at high pitch. Extra annoying. I re-setup DV, saying the
monitor should use synchronized access, and it seem to "minimize" the
problem. i.e. it doesn't happen as often, about once a week, and
un-reproducable.
Also, when running prodigy with DV, the screen colors are wrong. It
came up right only once, and then when I switched windows, it reverted
to the wrong colors.
I have successfully been logged in on Procomm, formatting a disk in
BigDos, and printing with WordPerfect all at the same time, which is
slightly impressive compared to losing with just DOS. Yet, it pales
in comparison to UNIX, which I use at school. DOS, DV, and
Window/386 have a long way to go until they're great products.
--
John Chen c/o Assoc. for Computing Machinery| CSIL-ize your life. Are you
University of California at Santa Barbara | using the best tools that you
Santa Barbara, Ca. 93107 | can??????????????keithe@tekgvs.LABS.TEK.COM (Keith Ericson) (03/06/90)
In article <29312@amdcad.AMD.COM> phil@pepsi.amd.com (Phil Ngai) writes: > In principle a 386 PC should be able to run DOS jobs in a > virtual 8086 and any crashes should not affect the other jobs. > In practice I do not know if DV does this. I dunno' about Desqview, but that's eggactly how VM/386 works. If I hit Ctl-Alt-Del (or any recognizable permutation :-) only the foreground virtual machine resets - the others don't even know what happened! If the foreground machine crashes - or goes into some kind of looping paroxysm - I can hot-key to another virtual machine and it's still alive and kicking. kEITHe
phil@pepsi.amd.com (Phil Ngai) (03/07/90)
In article <7026@tekgvs.LABS.TEK.COM> keithe@tekgvs.LABS.TEK.COM (Keith Ericson) writes: |In article <29312@amdcad.AMD.COM> phil@pepsi.amd.com (Phil Ngai) writes: | |> In principle a 386 PC should be able to run DOS jobs in a |> virtual 8086 and any crashes should not affect the other jobs. |> In practice I do not know if DV does this. | |I dunno' about Desqview, but that's eggactly how VM/386 works. If That is what I would expect VM/386 to do. Someone replied that DV/386 does too. I do not believe this for the following reasons. First, DV/386 is simply DV/286 packaged with QEMM-386. It's the same DV file that you run although it may be possible that it executes different code. Second, I have had plenty of crashes in DV/386 and if it were really a virtual 8086 machine I would expect much fewer. In summary, I believe that if you use DV/386, the only part which runs in protected mode is QEMM-386. And I'm not even sure about that. Someone told me that QEMM can do what it needs (to the MMU?) in real mode. But I don't really believe this either. -- Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!phil A PC without DESQview is like Unix without ^Z.
qz@maxwell.physics.purdue.edu (Qin Zhao) (03/07/90)
I am dreaming to do multitasting on PC, and heard Desqview is the choice. But I had many problems using it. I am using MS-DOS 4.01, and have QEMM386, and DEsqview installed on my 386SX machine. I would be very appreciated to anyone who can help me. Please E-mail to me if possible. My E-mail: qz@maxwell.physics.purdue.edu List of a few problem: a) I can not format a diskette in DV, either use DOS service, or in BIG DOS or small DOS(128K). b) After I open BIGDOS, it takes a lot of conventional memory, from 528k, to only 27K left I don't understand at all. What is BIGDOS, and how can it is so big. c) After I have used a Mouse-based program in BIGDOS and then quit the program, I lost my mouse cursor. ( I have a Logitech C9 serial mouse) So I have to use ALT key to pop up the menu, is this normal? d) Are there any books besides mannual talking about Desqview? I think the Mannual is too difficult to understand in some parts.
nelson_p@apollo.HP.COM (Peter Nelson) (03/09/90)
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
extensive discussions with Quarterdeck *before* buying the
product in which they gave me glowing descriptions of how
reliable and tolerant of misbehaved programs it is, I'm
afraid it appears that Quarterdeck is intentionally trying
to mislead the public by implying in their product is better
than it really is in this respect, although admittedly
they never said it will run "*any* DOS program".
It may also be true that some programs which seem to fail
under Desqview *could* be made to run under it theoretically
if we knew exactly how to configure it for that case. But
there's no *systematic* way to do this, you just have to try
a little of this and a little of that, and even Quarterdeck's
tech support has been unable to solve the riddle of my
Zortech C graphics programs crashing under Desqview.
I was relating my Desqview woes to a friend at Lotus who said
he's heard it before about Desqview and suggested I try a
product called VM-386. Does anybody know anything about
this product? I understand it doesn't do windows: I can live
without that; what I really want is to have multiple (2 is
probably sufficient) tasks running at the same time without
crashing into each other or doing anything else they wouldn't
do all by themselves. The main thing I want is NO hassles and
NO farting around tweaking things trying to get them to work.
He said VM-386 fits the bill. Does it? Who makes it? I
still have 60 days to get my money back on the Desqview.
---Peter