Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU From: Ralf.Brown@B.GP.CS.CMU.EDU Newsgroups: comp.sys.ibm.pc Subject: Re: MKS vi 3.1 versus Desqview 2.25 Message-ID: <2590d7f4@ralf> Date: 21 Dec 89 12:17:40 GMT Sender: ralf@b.gp.cs.cmu.edu Organization: Carnegie Mellon University School of Computer Science Lines: 27 In-Reply-To: <19433@watdragon.waterloo.edu> 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.