prove@batcomputer.UUCP (01/24/87)
A few months ago I bought an AST Premium pack eems card that came with a copy of desqview. There was a serious problem with the installation of desqview that others contemplating a similar move may want to know about. The disk came with an install program, which loads all of the software into the appropriate places and appends a few lines to the config.sys and autoexec.bat files. Running this the first time worked ok. However, I decided to change a few of the parameters (partitioning the memory into ems and eems parts, etc) and the "safest" way seemed to be running install again. Wrong! The result of this 2nd installation was a trashed hard disk. About 20 files were cross-linked. Just to make sure I zapped the cross-linked files and tried again: more cross-linked files. Is this some kind of insidious copy protection? Luckily I had make a backup shortly before and did not lose anything but time. Has anyone out there had a similar experience with this stuff? I could find no mention of an installation limit of one in the docs. After that I installed an older version of desqview by hand and have had no problems with it. I can no longer live without it. The multitasking is nice (I got the card and desqview so that I could use a Definicon 68020 in the background, works well) and it makes procomm much more useful by allowing the redefinition of all the keys. A welcome surprise was the fact that CED works normally in a desqview window (but the process must be set so that it can't be swapped to disk). It does not require a mouse or 80586 to be effective, and applications are not required to do their own multitasking management (unlike MS windows). It will even clear out a hung program at times by ripping it out of memory, avoiding a system reset. But: backup the target drive before installing it. Roger Ove prove@tcgould.tn.cornell.edu 14004@ncsavmsa.bitnet prove@uiucvmd.bitnet
prove@batcomputer.UUCP (01/24/87)
In article <2110@batcomputer.tn.cornell.edu>, prove@batcomputer.tn.cornell.edu (Roger Ove) writes: > > A few months ago I bought an AST Premium pack eems card > that came with a copy of desqview. There was a serious problem with > the installation of desqview that others contemplating a similar > move may want to know about. The disk came with an install program, > which loads all of the software into the appropriate places and > appends a few lines to the config.sys and autoexec.bat files. Running > this the first time worked ok. However, I decided to change a few > of the parameters (partitioning the memory into ems and eems parts, > etc) and the "safest" way seemed to be running install again. Wrong! > The result of this 2nd installation was a trashed hard disk. About 20 Now after checking I recall that the problem was with the 2nd install of the AST memory management software, which has nothing to do with desqview. Desqview has always worked normally, except for the fact that the EEMS version (xdv.com) crashed my machine (it is a pc's limited turbo), which was predicted in the docs for some machines. Sorry about the slander, Quarterdeck. Roger Ove prove@tcgould.tn.cornell.edu 14004@ncsavmsa.bitnet prove@uiucvmd.bitnet
phil@sci.UUCP (01/31/87)
In article <2110@batcomputer.tn.cornell.edu>, prove@batcomputer.tn.cornell.edu (Roger Ove) writes: > > A few months ago I bought an AST Premium pack eems card > that came with a copy of desqview. There was a serious problem with > the installation of desqview that others contemplating a similar > ...The result of this 2nd installation was a trashed hard disk. About 20 > files were cross-linked. Most program install scripts have nasty problems if not done in a plain vanilla environment. it is always best to try and avoid them. re comment on use of CED, and similar programs, with Desqview: CED works fine even if the dos window is sawpped or put in background IF you invoke CED in EACH dos window rather than just once before starting up DV (once before startup couses no problems inside DV and multiple invokations seems to cause no problem). I put CED and other similar stuff that would otherwise be in AUTOEXEC.BAT in a script that runs whenever a DOS window is invoked. One think DV can't seem to do is pass the ENVIRONMENT variables that you have set (other that PATH etc) to a DOS window. Anyone know how to work around this?
prove@batcomputer.UUCP (02/07/87)
In article <1312@sci.UUCP>, phil@sci.UUCP (Phil Kaufman) writes: > re comment on use of CED, and similar programs, with Desqview: CED works fine > even if the dos window is sawpped or put in background IF you invoke CED in > EACH dos window rather than just once before starting up DV (once before > startup couses no problems inside DV and multiple invokations seems > to cause no problem). I put CED and other similar stuff that would otherwise > be in AUTOEXEC.BAT in a script that runs whenever a DOS window is invoked. My system is very flakey when I let windows with CED running get swapped out. Usually the crash comes when another task is exited and the CED window is being swapped back in. Intermittent tho. I just did about 20 swaps and had no problems, but when I tried to get a dir listing the machine died. No problems when I only swap pure dos windows. The thing that puzzles me is that it does not crash every time. I assume CED traps the kbd interrupt, and that when desq swaps it out it redefines it (else instant crash). When desq swaps the task back is it smart enough to revector the interrupt? I guess it does or CED would no longer function.... Does anyone know how desq manages such things? > One think DV can't seem to do is pass the ENVIRONMENT variables that you have > set (other that PATH etc) to a DOS window. Anyone know how to work around this? I usually define the environment in a little bat file loaded when the window is opened (the one where CED is invoked) because I don't know how to make the environment big enough for all of the sets anyway (no config.sys to enlarge it). Anyone know how to enlarge the environment space of a window?