dougs@videovax.tv.tek.com (Doug Stevens) (12/07/89)
------ Just got my new version of vi from MKS (version 3.1). It's extremely nice, but whenever I run it under Desqview, the cursor moves to the top line of the screen and then marches to the right at about 1 character per second; there is no response to any of the commands. My only option is to close the window. I'm running on an NEC Powermate 386 (16 Mhz) under DOS 3.2. The behavior is the same even when I remove every TSR in the system. Old vi (version 2.3b) works fine. Am I doing something wrong in Desqview? I've tried practically every option imaginable, but if you've seen this problem and can suggest a solution, I would be eternally grateful (or at least until tomorrow).
bazavan@hpcilzb.HP.COM (Valentin Bazavan) (12/12/89)
I am having the same problem with MKS vi 3.1 running under Desqview on a Hewlett-Packard Vectra (286). I hope to be proved wrong, but I suspect that there is no user solution. Some change made in the new vi conflicts with Desqview. Valentin Bazavan
k4bnc@cbnewsh.ATT.COM (john.a.siegel) (12/14/89)
In article <9620003@hpcilzb.HP.COM>, bazavan@hpcilzb.HP.COM (Valentin Bazavan) writes: > > I am having the same problem with MKS vi 3.1 running under Desqview > on a Hewlett-Packard Vectra (286). I hope to be proved wrong, but I > suspect that there is no user solution. Some change made in the new vi > conflicts with Desqview. > > Valentin Bazavan This sounds similar to a problem I had with a somewhat earlier version of VI running on a 80386 machine. When the dvp option was set to virtualize the symptoms were as described in the original article. With this option off VI runs properly. I suspect in this case that VI is using instructions not included in the virtual 8086 mode. I don't know how to relate this to a 80286 based machine but maybe it will give someone an idea for a solution.
jaswal@s.cs.uiuc.edu (12/20/89)
I don't know if you tried this already, but ... I had a very similar problem with the old MKS and Desqview 2.x on an XT. If I told DV that the application wrote directly to the screen (or something like that) then vi would march across the top line and beep each time. So I changed the option to say that it didn't write directly to the screen and that worked. You'd think that anything that could run under the latter option would do so under the former, since the former is designed for ill-behaved programs. But apparently, vi checks for DV, assumes that the latter option is set and (mis-)acts accordingly. Vijay
ggdavis@crocus.waterloo.edu (Greg Davis) (12/21/89)
In article <213400077@s.cs.uiuc.edu> jaswal@s.cs.uiuc.edu writes:
V>I had a very similar problem with the old MKS and Desqview 2.x on
V>an XT. If I told DV that the application wrote directly to the screen
V>(or something like that) then vi would march across the top line
V>and beep each time. So I changed the option to say that it didn't
V>write directly to the screen and that worked. You'd think that anything
V>that could run under the latter option would do so under the former,
V>since the former is designed for ill-behaved programs. But apparently,
V>vi checks for DV, assumes that the latter option is set and
V>(mis-)acts accordingly.
From what I can tell this is what happens. MKS Vi checks for desqview
and desqview gives vi the screen address. Vi then writes to the screen
address that desqview has returned, but since desqview is set so that
it is expecting vi to write directly to the screen instead of where
desqview told vi the screen is, it does something strange. It appears
to be printing vi's clear screen sequence which happens to be \040\007
(space followed by white on black character attribute). Vi is writing
this to where desqview claims the screen to be, but desqview is
interpreting these writes as printing \040\007 which will be a space
followed by BEL so that is why the cursor moves one space then beeps
and keeps doing this for the entire screen.
So what is the moral of the story? Desqview should return the correct
address of where the program should write to in both modes. It seems
kind of brain-damaged tell an appliction that the screen is at an
address which you shouldn't write to.Ralf.Brown@B.GP.CS.CMU.EDU (12/21/89)
In article <19433@watdragon.waterloo.edu>, ggdavis@crocus.waterloo.edu (Greg Davis) wrote: >In article <213400077@s.cs.uiuc.edu> jaswal@s.cs.uiuc.edu writes: >V>I had a very similar problem with the old MKS and Desqview 2.x on >V>an XT. If I told DV that the application wrote directly to the screen >V>(or something like that) then vi would march across the top line >V>and beep each time. So I changed the option to say that it didn't >V>write directly to the screen and that worked. You'd think that anything > >From what I can tell this is what happens. MKS Vi checks for desqview >and desqview gives vi the screen address. Vi then writes to the screen >address that desqview has returned, but since desqview is set so that >it is expecting vi to write directly to the screen instead of where >desqview told vi the screen is, it does something strange. It appears No, DV does just what you would expect: it returns the address of the physical screen memory. However, strange effects can happen if the program insists on treating the physical screen memory as a virtual screen (I just fixed such a bug in one of my programs recently). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 FAX: available on request Disclaimer? I claimed something? "How to Prove It" by Dana Angluin 13. proof by reference to inaccessible literature: The author cites a simple corollary of a theorem to be found in a privately circulated memoir of the Slovenian Philological Society, 1883.