dhinds@portia.Stanford.EDU (David Hinds) (03/01/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. > QEMM puts an 80386 PC in virtual 86 mode. It is reasonably good at insulating things, but occasionally gets confused if you use unsupported hardware. So, for example, I can use super VGA software in DV, but if I try to ctrl-alt-del from an extended mode, DV is sometimes unable to restore the video card to a reasonable state. It will always recover when my ethernet drivers hang, though, which is nice because my PC/IP software is less than perfect. The virtual 8086 mode is crucial for all of QEMM's memory mapping functions, because the 80386's memory management can only be played with in protected mode. QEMM is the protected-mode supervisor for DV. - David Hinds dhinds@popserver.stanford.edu
bbesler@vela.acs.oakland.edu (Brent Besler) (03/03/90)
I have found Desqview 386 to be OK, but it is very handy to have a hardware
reset switch handy when using it. I have found that any parameters on the
device=qemm.sys line in my config.sys file causes a "Internal Stack Overflow
System Halted" error which is only recoverable by a hardware reset. I have
a Jameco 386/20 board with an AMI bios running IBM DOS 3.31. Removing
everything from the config.sys files and autoexec.bat files except the
qemm line still causes crashes if any parameters are on it. Has anyone out in
netland experiences such problems with Desqview. With no parameters QEMM and
Desqview work fine. I would like to use DV to load TSR programs into high
memory, but the requires the RAM parameter on the qemm.sys line in config.sys.
Brent H. Besler
gary@dvnspc1.Dev.Unisys.COM (Gary Barrett) (03/03/90)
> > 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. . . . > > 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. > I'm a bit confused. Are you limiting yourself to DOS on a PC? PCs can of course run UNIX, just like those workstations you mention. And now that we have VGA, graphics capabilities are beginning to challenge the big boys. Then there are, of course, all those "PCs" acting as multi-user LAN servers. But that's another story. PCs are just software containers. -- ======================================================================== Gary L. Barrett My employer may or may not agree with my opinions. And I may or may not agree with my employer's opinions. ========================================================================
boyer@iuvax.cs.indiana.edu (Charles David Boyer) (03/06/90)
nelson_p@apollo.HP.COM (Peter Nelson) writes: > I've found another program I use frequently which crashes in > Desqview: Fastback Plus, the backup utility. ... Yes, I have also found this to be true. It is not very surprising when you consider the things that both programs try to do (i.e. take over the machine). My advice is to forget FB and DV together. Dave Boyer boyer@iuvax.cs.indiana.edu
boyer@iuvax.cs.indiana.edu (Charles David Boyer) (03/09/90)
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. This is unfortunate. It is the price to be paid to get the best performance from such a configurable tool (under a limited operating system). 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. David Boyer I hope you reach nirvana with VM-386.
dhinds@portia.Stanford.EDU (David Hinds) (03/09/90)
In article <4913c88c.20b6d@apollo.HP.COM>, nelson_p@apollo.HP.COM (Peter Nelson) writes: > > 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. Given Desqview's enormous installed base, is it any surprise that "many" people have had problems with it, given the extreme heterogeneity of DOS programs and environments? I consider it to be amazingly good at doing what seems at first to be a truly impossible task. Think about trying to write an operating system-level product to insulate a vast and unknown set of programs from doing bad things to a vast and unknown set of possible hardware configurations, when the programs expect to be able to do as they please. > > 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. > Despite Desqview's (I think unavoidable) weaknesses, I would be surprised to hear of another program that does a better job of doing these things. I haven't used VM-386, but it claims to be completely bulletproof. This level of protection is certainly possible on a 386 system operating in Virtual 86 mode. However, I think you will find that this degree of protection limits the sorts of programs and hardware that can be supported. There will be programs that fail under VM-386; it simply guarantees that they won't bring down the rest of the system. I'll bet that far fewer programs run under VM-386 than can be (admittedly) "tweaked" to run under Desqview. From what I remember about your Zortech C graphics program problem, the 386 was trapping a protection violation of unknown origin. So, the program was executing instructions that violate the privileges given to a Virtual 86 task. Desqview normally traps these violations and performs an appropriate action, if it can tell what the program was trying to do. For example, all DOS and BIOS calls, as software interrupts, cause protection violations in V86 mode, and Desqview (or QEMM, actually) has to temporarily take control before invoking the requested DOS service. If Desqview is virtualizing screen I/O, all accesses to display memory cause protection violations. Depending on how you set the "protection level" option, other sorts of actions can cause faults, including direct access to I/O ports via IN and OUT instructions, or even some innocuous-looking attempts to manipulate the flags register. I would be surprised if VM-386 could recover from the Zortech program faults; though they will not crash the system, I bet they won't run successfully. -David Hinds dhinds@popserver.stanford.edu
larry@nstar.UUCP (Larry Snyder) (03/11/90)
In article <48f4c22d.20b6d@apollo.HP.COM>, nelson_p@apollo.HP.COM (Peter Nelson) writes: > > 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 run 386/ix on a 25 mhz '386 and have VP/ix installed. I have yet to come across a DOS program which could not be made to run on my machine - but then I didn't try *everything* -- The Northern Star Public Access Unix Site, Notre Dame, Indiana USA uucp: iuvax!ndmath!nstar!larry internet: larry@nstar USR HST 219-287-9020 * PEP 219-289-3745 * Hayes V9600 219-289-0286
doug@ozdaltx.UUCP (Doug Matlock) (03/11/90)
I must disagree with the DESQview bashing that has occurred on the net recently. While I do not use DESQview in a user environment, we are developing DESQview specific applications at work. DESQview has performed admirably and I will continue to develop successful applications in it. BTW, our applications are turnkey systems for clients. The latest sold for several $100,000 per year. The client's IBM rep was most impressed that we got so much performance from DESQview: he thought nothing less than OS/2 would do. -- Doug. "If you want Peace, work for Justice."
nelson_p@apollo.HP.COM (Peter Nelson) (03/12/90)
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
nelson_p@apollo.HP.COM (Peter Nelson) (03/13/90)
dhinds@portia.Stanford.EDU (David Hinds) posts... > Given Desqview's enormous installed base, is it any surprise that >"many" people have had problems with it, given the extreme heterogeneity >of DOS programs and environments? I consider it to be amazingly good at >doing what seems at first to be a truly impossible task. Right. This is what's referred to as a "talking dog", i.e., it doesn't matter *how well* it does it; it's a wonder that it can do it at all! My complaint with Desqview is that they didn't make clear how many limitations their program has, even when I directly asked them about this! I was aware of the difficulties in what Desqview is trying to do so I told them up front that many of the programs I run use graphics, that they are not commercial applications but rather programs written in C or C++, and that the few commercial applications I DO use are disk utilities and backup programs, both of which mess around with the hardware. Two different people at Desqview said, in effect, "no problem". > From what I remember about your Zortech C graphics program problem, >the 386 was trapping a protection violation of unknown origin. So, the >program was executing instructions that violate the privileges given to >a Virtual 86 task. You're confusing this with some other problem. Under Desqview, the Zortech graphics routines merely hang the machine at random intervals or scribble randomly all over the screen or cause other programs (including Desqview when it goes into graphics mode) to screw up in dramatic ways. But even with protection mode set to [3] I got no messages from Desqview when all this was going on. I did, however, get lots of messages from Desqview about *other* programs, including many DOS commands when I had protection mode > 0. ---Peter
nelson_p@apollo.HP.COM (Peter Nelson) (03/13/90)
doug@ozdaltx.UUCP (Doug Matlock) posts... >I must disagree with the DESQview bashing that has occurred on the net >recently. While I do not use DESQview in a user environment, we are >developing DESQview specific applications at work. DESQview has performed ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >admirably and I will continue to develop successful applications in >it. I think if Doug reads his posting he'll see the flaw in his complaint, but I've highlighted with "^^^" to help. *Nobody* is questioning that Desqview runs applications WRITTEN FOR IT perfectly well. The manual goes into considerable detail about how to write "Desqview aware" code. And this is great if you are writing in assembler or have other means to control the way your programs allocate and use system resources at runtime. MY complaints about Desqview are compeletely orthogonal to this. I'm talking about running completely "Desqview oblivious" commercial apps or programs I wrote using C compilers which do whatever they want to at runtime. ---Peter
thomasr@cpqhou.UUCP (Thomas Rush) (03/13/90)
In article <492837f4.20b6d@apollo.HP.COM>, nelson_p@apollo.HP.COM (Peter Nelson) writes: > > MY complaints about Desqview are compeletely orthogonal to this. I'm > talking about running completely "Desqview oblivious" commercial apps > or programs I wrote using C compilers which do whatever they want to ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > at runtime. > > ---Peter Ahh-hahhhh! Whoooeey! Hah-hah-hah! Gee, stop, you're killing me! hee-hee. Ohhh-ho-ho! Whooo! thomas.
doug@ozdaltx.UUCP (Doug Matlock) (03/15/90)
Yes, I do realize that you were talking of DESQview oblivious applications. Otherwise, I would not have been so careful to describe my applications as DESQview specific. Further, Quarterdeck sells a very nice C-Language API for DESQview, so you can easily incorporate DESQview awareness or specificity into your C-code (which I understand is the source of the most serious difficulties you are experiencing). In short, we simply have not experienced difficulties with off-the-shelf DOS applications (such as Excel, Word Perfect, ProComm etc...) running under DESQview along with the DESQview specific applications we develop in-house. Another viewpoint. -- Doug. "If you want Peace, work for Justice."
fender@fig.ucsb.edu (Chen) (03/20/90)
I've been having problems with DV/386 (so what else is new) When I have the protection level set on anything higher than 1, I get an error with MS Works, Prodigy, and few others where they are trying to access or write to memory location 0000:0???. I have a few of the locations written down at home, but I don't have them with me now. Is it trying to change video modes? It says that the memory location is not in the program space and that it is a violation. Any clues? -- John Chen c/o Assoc. for Computing Machinery| Yow! Am I graduating yet? University of California at Santa Barbara | What if your entire existance Santa Barbara, Ca. 93107 | was just a virtual reality?
Ralf.Brown@B.GP.CS.CMU.EDU (03/20/90)
In article <4370@hub.UUCP>, fender@fig.ucsb.edu (Chen) wrote: }I've been having problems with DV/386 (so what else is new) When I }have the protection level set on anything higher than 1, I get an }error with MS Works, Prodigy, and few others where they are trying to }access or write to memory location 0000:0???. I have a few of the }locations written down at home, but I don't have them with me now. Is }it trying to change video modes? It says that the memory location is }not in the program space and that it is a violation. Unless you need the higher protection to catch a program that is trashing your system, you should keep the protection level at 0, since higher levels cause a considerable slowdown (all that checking can really eat up CPU cycles). Locations 0000:04?? are indeed BIOS data areas, including video mode info. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 "How to Prove It" by Dana Angluin Disclaimer? I claimed something? 16. proof by cosmology: The negation of the proposition is unimaginable or meaningless. Popular for proofs of the existence of God.