Conference bulova::decw_jan-89_to_nov-90

Re: .0

First of all, I assume you're using a 4-plane GPX.  I say that becausse you
talked about the screen background changing, which would only happen on a
4-plane system.

You can prevent VTX from changing the colormap by issue a SET TERMINAL/NOREGIS
command before running VTX.

Once you've run VTX and it's changed the colormap, you can restore your default
colors using a two-step process: first clear the window and then reset it; you
can do both of these things from the Commands menu (Clear Display and Reset
Terminal repectively).

There's no way to write-lock your colormap; sounds like a wish list item
for a future version (although hopefully the 4-plane support will improve to
the point where this won't be necessary).

				-- Bob

    This particular VTX application doesn't pay any attention to the
    "SET TERM/NOREGIS" command setting.  I've got a 4 plane GPX system
    and I've tried the ST/NR...  The screen still woofs until I reset
    it via the DECterm pulldowns.

An application that blindly charges ahead and does ReGIS operations without
first checking whether the terminal supports ReGIS has a bug in it.  Of course,
this doesn't help you at all with the immediate problem.

--PSW

I beg to differ with that opinion.

If a terminal is known to be level II conforming, I know that I can send
a ReGis string to it, and it will either use the string, or ignore it. 
So long as I know what the effect will be on my application of ignoring
the string, it's fine.  In this particular case, I know that the
non-ReGis terminals will display the textual data correctly, and the
ReGis terminals will display them in colors of my choosing via the ReGis
color map change commands.

That this program doesn't save the colors when entered and restore them
when exiting - that's a bug.
               ------

Perhaps SET TERM /NOREGIS should change the behavior of the DECTerm to
NOT interpret ReGis?  I'm not likely to make that recommendation -
because it violates my policy of opposing any back door communication
between the emulator and VMS.  SET TERM is intended to tell VMS what
your terminal IS, not what you would LIKE it to be.  Going in the
direction of allowing SET TERM to tell the "system" what you would LIKE
the terminal to be should be done via control sequences  (like SET
TERM/WIDTH=132 does), and we don't have one that turns off ReGis
processing.

Adding such a sequence makes sense to me, as does making it a Customize
option for any given instance of an emulator.

    
    Well Jeff, I'm guilty of looking at the VMS parameters :-) and in some
    ways it's neat to use the VMS settings as a "hint" (hey, real X11-ish
    :-) so (for instance) /NOREGIS/NOSIXEL might indicate that the user
    didn't really care about graphics - so don't do backing store...
    
    _Fred

The rules we gave to applications years ago were that they were to check the
specific characteristics, like REGIS, and not the "level" the terminal was.
The years of broken software because VT101 and VT102 weren't known by software
that supported VT100 taught us this lesson.

I agree with PSW, there is a bug in VTX.

jake

Re .6: that may or may not be necessary, depending on what you're trying to
do with things like Regis.

If the application "doesn't work right" on non-Regis terminals, then you have
to check the REGIS flag during startup.

However, if the application sends out Regis commands but doesn't mind if the
terminal doesn't know Regis (as may well be the case when you're using
Regis color commands) then it IS valid to send those commands unconditionally.
That's because correctly implemented terminals either execute the Regis
commands, or ignore them.  (VT100s of course did neither, but displayed
the Regis string as text -- which is a violation of the ANSI escape sequence
handling rules.)

I think VTX is an example of case 2, so I wouldn't necessarily agree this
is a "bug".

	paul

Who says that the terminal the user is using is necessarily ANSI-compliant, or
that it's implemented ANSI correctly?  You cite one such case that we produced
(the VT100).  That is the whole reason for the rule that applications should
check the characteristics bit before using a particular feature.  If the REGIS
terminal characteristics bit is off, the user and OS have indicated that they
do not want applications sending ReGIS commands to the terminal.  An application
that ignores this is in error.

--PSW

I think you are confusing "level" with "model".

VT100 applications broke on VT101's beacuse we didn't, at the time, have
a mature enough architecture of terminals to accomodate known upward
compatibility.  Without any know compatibility guarntees, applications
took the narrow route of testing for specific models.

We now have DECCRT (level 1) DECCRT2 (level 2), and know that all
DECCRT2 and higher level terminals follow some VERY well defined rules
for escape sequence processing.  (DEC STD 70 is rapidly turning white
these days.)  There is some inconsistent processing among the early
level 1 terminals, which is why you would still want to check.  for
level 2 (I think some level 1 terminals will incorrectly display the
text of a ReGis command string, but I'm not certain.)

Hmmm.  I'll accept .8 - the user told VMS that it didn't want
applications to send ReGis commands, and the application should have
complied.   Ignore .9.

    I believe  that  an  application  should  never  send a sequence to the
    terminal if the  VMS  characteristics  state  that  the device does not
    support the sequence. The problem with the early VT100s is only one of 
    the reasons.  Sometimes  the entity on the other end of the wire is not
    just a dumb terminal.   It may be a software regression test system, or 
    a terminal emulator that only supports  "level  n" and is sloppy in how
    it  handles  undefined  sequences.   Thus sending  the  a  "level  n+1"
    sequence may cause the emulator to turn to  mush.    If the application
    honors  the  terminal  characteristics,  then this situation will never
    occur.
    
    Also some guidelines that we follow:
    
    1. The VMS characteristics are the only place we check to determine the 
       device capabilities. If these are set wrong, then "SET TERM/INQ" is 
       broken  (unlikely)  or  the  user  has  intentionally set them to  a
       strange state. In any event, we believe them, and the user gets what 
       he asks for.
    
    2. Never ask the terminal  directly  for  characteristics.    This will
       destroy the user's typeahead behaviour.   Even if the application is
       trying to be smart and buffer  the  typeahead  internally,  this may
       still cause loss of data.  Consider  the  case  where  the  user has
       typed:
       		EXIT<cr>dir/full
       before your inquiry to the device gets procesed.    User  looses  an
       entire command - but not always.  FMS V1.1  got  severly  beaten  up
       over this problem.
    
    3. Never  send  a  Regis sequence unless the characteristics have REGIS
       explicitly set.
    
    4. Never send an eightbit control sequence unless EIGHTBIT is also set.
    
    5. Never  assume  that an eightbit terminal is also level-2.  The VT102
       emulator in the DEC/Rainbow is just one counter-example.  Notes, LSE
       and TPU make this mistake. Setting the terminal to eightbit and then
       running one of  these  utilities  cause  them to designate character
       sets which do not exist in a level-1x terminal.
    
    6. Never define the SHIFT-Fn  keys  unless explicitly directed to do so
       by the user. 
    
    7. Always write both the top  and  bottom  of a double-high line and in
       the top/bottom order. 
    
    8. Never scroll a scroll region that  has  a  double high line directly
       above  it  unless you  first set the double  high  lines  to  single
       width, then do the scroll, then reset the  double  high line.  Doing
       otherwise will risk invoking a firmware bug on many (but not all) of
       the VT100s.
    
    9. Always set the line width before trying to position  to  any  column
       beyond 40 (or 66). This is the clasical "column 40 disease".
    
    10. Others I'm sure that I've forgotten, expecially related to partial
        escape  sequences in the input.  And you don't even  want  to  know
        about all the read-verify hints and kinks...
    
    
    James 
    DECforms 
     

Re: .11

I'm starting to think that I don't like the way things have been designed
(but I'm not sure there's a good alternative).  It sounds incredibly difficult
to write a bullet-proof application.

>    I believe  that  an  application  should  never  send a sequence to the
>    terminal if the  VMS  characteristics  state  that  the device does not
>    support the sequence.

Not every application wants to be burdened with that kind of O/S dependency.
At best it means you need conditional compilation so that your program can
work on VMS as well as on other operating systems such as UNIX.  Unfortunately,
considering your later remarks, it seems like there's no choice: well-written
applications *have to be* O/S dependent.

> The problem with the early VT100s is only one of the reasons.

Wasn't the problem with VT100's just the opposite: programs tried to be
careful and checked to make sure they were dealing with a VT100 and ended up
getting burned when the VT101 and VT102 came out?

>  Sometimes  the entity on the other end of the wire is not
>    just a dumb terminal.   It may be a software regression test system,

That's a problem, isn't it?  Unless you can reproduce the right terminal
characteristics in the test system, the regression test system is useless
because the program won't behave the way it does on a real system.

>    1. The VMS characteristics are the only place we check to determine the 
>       device capabilities. If these are set wrong, then "SET TERM/INQ" is 
>       broken  (unlikely)

As a matter of fact I don't think it's unlikely at all.  VMS often lags
behind by a version or two in supporting the latest terminals.  (SET TERM/INQ
also rudely changes user preference characteristics such as the page size;
I'm not sure who to complain to about this.)
    
>       Consider  the  case  where  the  user has typed:
>       		EXIT<cr>dir/full
>       before your inquiry to the device gets procesed.

Thanks for pointing this out. Unfortunately this means that *every* report
should be handled by the terminal driver -- and we keep inventing new ones!

>    9. Always set the line width before trying to position  to  any  column
>       beyond 40 (or 66). This is the clasical "column 40 disease".
    
Could you explain this?  Why should this be necessary in a text editor, say,
if you aren't using double wide characters.

				-- Bob

>> The problem with the early VT100s is only one of the reasons.
>
>Wasn't the problem with VT100's just the opposite: programs tried to be
>careful and checked to make sure they were dealing with a VT100 and ended up
>getting burned when the VT101 and VT102 came out?


Actually should have been "VT1xxs" to make it a "class" problem of having 
only one bit to represent level 1 and level 1x capabilities.


>>    9. Always set the line width before trying to position  to  any  column
>>       beyond 40 (or 66). This is the clasical "column 40 disease".
>    
>Could you explain this?  Why should this be necessary in a text editor, say,
>if you aren't using double wide characters.

If the text editor is designed to not take over the whole screen - a request 
that TPU keeps getting - then it's possible that the viewport of the screen 
in which the editor will run may already have double wide/high text. The origin
of the text may be from a forms package - but that's not critical. The point is
that if you are sharing the screen, then you have to guard against the worst
case.

We've long maintained that there needs/needed to be an interface layer between
the character cell terminal and applications which provided true screen sharing
capabilities. Thus many of the issues that we constantly get hit with regarding
screen sharing between FMS, TPU, All-in-1 etc. would become moot.

Anyway, we probably should carry this discussion to the Terminals or DECterm
conference.

James

    As an FYI to the original complaint.

    The page in question has all the REGIS information coded in its display
    tetx so VTX isn't even aware that it is REGIS.  Poor application design.