🚀 go-pugleaf

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.