Conference bulova::decw_jan-89_to_nov-90

    Subject:  xterm
    
    When the only X was X10, we offered to provide the Unix people the
    source to a VT200 emulator - no interest, Unix didn't do 8-bit.  We
    had it done (externally ported) anyway (it was known as yterm).  Well,
    there still is very little interest in the Unix community for an
    8-bit terminal, but it *is* in DEC's and DECwindows interest that
    there be one so that the mythical heterogeneous networked environment
    can become more real... so there is DECterm.
    
    Now, there out of necessity has to be some specific criteria that
    DECterm must meet, like conforming to the VSRM and not being available
    in source format (which is why the question of it being in VAX-C or
    ANSI-C is irrelevant).  These restrictions do not exist in xterm, it
    conforms to ANSI specifications and to the VSRM only where it's
    convenient and it's sources are available for anyone to modify to
    taste (in fact there are quite a number of variants of this code
    around).
    
    As I said earlier, xterms advantage is in it's size.  It's small.  But
    the only speed advantage is probably in startup, not in performance.
    The code that DECterm is based on can generate 20,000 characters per
    second non-scrolled on a pVAX in it's VWS incarnation, and over 10,000
    on DECwindows.  The scrolling speed advantage is only an illusion, with
    batch scrolling enabled, DECterm should easily match the scrolled
    rates.
    
    The Unix community seems to like xterm, great - let's give it to 'em.
    Let's *not* try to replace it, you'll never satisfy the people who
    currently use and love xterm with DECterm equivalents...
    
    Support?  Nah, let's put together a kit with Ultrix and VMS
    implementations of the apps from the MIT tape and whatever else we
    have laying around as "demo" software.  Give it to Decus, include a
    copy with the DECwindows kit.
    
    Subject:  DECterm/Lite
    
    Check with Chuck Guldenschuh in VAX/ELN.  I seem to recall that they
    were looking for exactly this, and may have already done it or started
    it.  I think it's not so much removing ReGIS or other big chunks like
    that (though you could seperate ReGIS out into a seperate sharable
    image that DECterm image merges if ReGIS is asked for...), but rather
    making a X11 version of it as opposed to a DECwindows version - that's
    probably where a lot of the overhead comes from (though I have no
    evidence to back that up).
    
    Subject: TEK
    
    Well, I've asked this pointed question too often.  The VWS kit in SDC
    (or SSB, whatever) that ships in mid-month has both TEK4014 *and* a
    TEK4125 bundled as standard emulators.  I've been made aware of the
    reasons that DSG wants to sell one, but I think it's a bad idea for
    the DECwindows program.  And it does make us look like we don't all
    work for the same company.
    
    And the idea that to get the simple 4014 emulator means that you must
    use xterm or buy a big and complicated 4125 emulator is also a bit silly.
    

    I use xterm rather than DECterm for two reasons:
    
    - memory size (client side and also server side: starting DECterm
    creates 24 windows, xterm 9)
    
    - xterm makes it easier to customize fonts and colors on the command
    line
    
    I do find some of the *imperfections* in xterm's VT emulation
    irritating (mainly when using ALL-IN-1). Speed is not an issue. Lack of
    multinational characters is irritating but as Fred says Ultrix was very
    slow to become 8-bit clean. 
    
    Bob M.'s complaints are the first I've heard about non-VT100 functions
    in xterm. What are they and what do people use them for? 
                         
    Also, why are extended escape sequences on a terminal a bigger sin than
    the extended language features in VAX Pascal or VAX Fortran? Seems to
    me if your terminal emulator supports extra escape sequences that
    aren't in somebody's standard, they can be ignored except in the rare
    case of a buggy application that erroneously sends those sequences and
    gives surprising results. 

    
    Lack of color and font customization is a big DECterm weakness.
    
    I don't know what the "OSC" sequences Bob was talking about are, but
    the last variant of xterm I looked at did things like use the VT100
    interlace SM/RM to enable and disable the mouse.  But one of its bigger
    problems was that the way it did mouse input was to send an invalid
    escape sequence (well, I guess that insures no conflicts!) followed
    by the coordinate, followed by a return.  Generating such a sequence
    while in ANSI mode isn't a very polite or legal thing to do... an
    application with a escape sequence parser (like say, DCL) will choke
    with a BAD ESCAPE error and will have to have exception logic to
    handle it...  it *does* make it simple stupid for the run-of-the-mill
    application to handle mouse input - which is why it's done that way
    I suppose.
    
    

Re: .2, .3

xterm has a set of OSC functions (i.e. sequences that start with <ESC>]) that
are terminated with ^G instead of with <ESC>\.  If you send an xterm-style
OSC sequence to an ISO-compliant terminal (or emulator, such as DECterm) any
further output will be considered part of an unterminated OSC sequence, i.e.
it will be ingnored.

On VMS you can get a "lean and mean" DECterm by creating a "DCL Command" window
from FileView.  I don't think there's an equivalent on Ultrix yet, and it
looks like the DCL window will go away in FileView V2 in favor of a
full-blown DECterm window.

What I don't understand about shipping xterm on our kits is: how can we
do this if the software doesn't meet DEC quality standards?  Don't Ultrix
users care whether the software they use is supported or not?  Is every
customer willing to edit the source if they don't like the way xterm works?

				-- Bob

>What I don't understand about shipping xterm on our kits is: how can we
>do this if the software doesn't meet DEC quality standards?  Don't Ultrix
>users care whether the software they use is supported or not?  Is every
>customer willing to edit the source if they don't like the way xterm works?

Because many of our customers already know xterm.  They are used to it and,
rightly or wrongly, prefer it.  I normally use xterm for the following reasons:

1) no title bar.  The title bar eats valuable screen real estate that I could
be using for text.

2) I hate blinking cursors.

3) Ability to use different fonts.

>Don't Ultrix users care whether the software they use is supported or not?

Some do, but many don't.  Most customers copy Unix applications off of USENET
or the Internet and use them routinely.  They are usually good quality and
happen to meet the cusomter needs.

Do users of DECUS software care whether the software they use is not supported?
Probably not.  It the same thing.

>Is every customer willing to edit the source if they don't like the way
>xterm works?

No.  But they can always use dxterm ig they don't like xterm.  Or they can fix
it themselves if they have sources.  It's giving the customer more flexibility
in establishing their working environment.

>>> ... It's giving the customer more flexibility in establishing their 
>>> working environment ...


I'll not disagree that I should be able to customize my work enviroment
so that it suits my purposes, but I do want to make a comment about how 
"unsupported" applications interact with layered products. If every user
expected that he could open up his terminal emulator (or any other product)
for the purposes of changing something that did not suit him, it would be
impossible for DEC to provide layered products like FMS, TDMS, and DECforms.

We depend and demand that the terminal on the other end of the wire be VSRM
compliant. If it's not, then we won't work correctly. We don't demand that it
be Digital-supplied, we'll work on third party products IFF they implement
their product correctly. ANSI X3.64 and its relatives are the standards that
define the protocol by which the client (FMS in our case) talks to its server
(the terminal). Admittedly its a very simple device control protocol, but that's
exactly what it is. There is a syntax, there is a request ordering specified
and there is a defined action for each request that is presented to the 
device. Changing an escape sequence on a whim, or as xterm has done, defining
a non-standard terminator for a control sequence has a serious impact on how
supportable the device is. It is the same as changing the X11 protocol in an
uncompatible (non-extension) manner. 

So from the perspective of layered products, xterm is an aberation that should
be supported only if convienent. And since xterm has so flagrantly violated the
rules of behaviour, my personal opinion is that we should ignore it.

Customers and layered products developers have implicit agreements which 
allow the layered product developers to build their programs. The customer
agrees to provide an environment that matches the layered product's requirement.
The layered product agrees to use only the specified capabilities. Standards are
the means of formalizing this customer/provider relationship. It is exactly what
the ANSI X3.64 and X11 standards represent.

I also believe strongly that no customer is willing to risk his entire company
on software for which he has no supported - either he will develop the expertese
in house to support his effort, or he will turn to a software/hardware vendor.
Our job is then to make it easier for him to do the later - especially for 
Digital supplied solutions. Adopting the rigid position that we do not 
support non-standard devices helps to ensure that we will succeed. In the end
we wind up building quality products and not toys.

James

RE: .4

>What I don't understand about shipping xterm on our kits is: how can we
>do this if the software doesn't meet DEC quality standards?

Simple:  you put it on a separate media volume that has a warning label on it 
that says the software is unsupported and not covered by the usual warranties.
This is further stated in the SPD and the documentation.  Customers who don't
want to take the risk don't have to use it.

--PSW

This (following) argument is being repeated ad-nauseum in this conf:

> I also believe strongly that no customer is willing to risk his entire company
> on software for which he has no supported.

No competantly managed enterprise is willing to ``risk [his] entire company'' on
*ANY* single software product whether supported or not!  In terms of such
a risk, support is largely irrelevant for the simple reason that the supplier
of the ``support'' has different priorities/goals/plans than the purchaser.
A basic law of business is that of not ``putting all of your eggs in one
basket''.  Much more salient issues in ``risk-the-company'' decisions are:
  - What is the probability that the supplier will deliver what he
    promised, when he promised it?
  - If the supplier doesn't, will we be able to successfully sue him?
  - What is plan ``b'' if the supplier fails to deliver?

 - either he will develop the expertese

> Adopting the rigid position that we do not 
> support non-standard devices helps to ensure that we will succeed. In the end
          ^^^^^^^^^^^^^^^^^^^^
> we wind up building quality products and not toys.

If what you say is true, then the entire philosophy behind the first 30
(or so) years of DIGITAL was a formula for failure.  Actually, DIGITAL has
*always* provided supported *ways* to include ``non-standard'' whatever!
It is only recently that I have seen (heard) DECies wearing blinkers and
shouting ``if it ain't invented here it don't exist!''.

    
    Get real.  The risk here is as much to DEC as it is to the customer. 
    We cannot distribute software as "supported" that we do not feel we can
    support.  We also must take into account the "risk" associated with
    the distribution of software that we have not in some way certified as
    meeting some minimum level of reliability.  As you point out, there
    can be legal implications in selling the software as "supported".
    
    This isn't to say we should block the way for users to obtain the
    software should they wish to use it, just that we cannot be responsible
    for it's use.  Which is why it would be nice to get a kit of public
    domain software for X11 ported to VMS and made available through some
    channel (as a DEMO kit, DECUS, the MIT tape, etc).
    
    Or certify xterm by the terminal firmware QA group and make whatever
    changes that are needed to make the code reliable, standard and
    supportable.  Since this is unlikely without some changes that xterm
    users might not like...