Open sourcing of VMS: bad precedent set
JF Mezei
IBM decided to decline the offer, offering a number of various
reasons/excuses to not do so. (some speculate there are some proprietary
Microsoft code in there).
My guess is that since VMS is in the same boat as OS/2 (nearlty
abandonned proprietary OS), perhaps we should push for individual
products being open sourced.
(I would start with DECterm and TPU. )
DECterm, being a proper implementation of the VT standards with most of
the VT bells and whistles (except tracing of control characters) would
be a great donation to the open source world, replacing Xterm which is
really really basic.
TPU might not displace much in terms of EMACS users, but it would enable
VMS customers to feel far mroe comfortable with newer platforms,
especially since it has both character cell and GUI versions.
Thomas Dickey
> DECterm, being a proper implementation of the VT standards with most of
> the VT bells and whistles (except tracing of control characters) would
> be a great donation to the open source world, replacing Xterm which is
> really really basic.
too little, too late - DECterm doesn't support UTF-8
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Arne Vajhøj
> JF Mezei <jfmezei...@vaxination.ca> wrote:
>> DECterm, being a proper implementation of the VT standards with most of
>> the VT bells and whistles (except tracing of control characters) would
>> be a great donation to the open source world, replacing Xterm which is
>> really really basic.
>
> too little, too late - DECterm doesn't support UTF-8
If it were open sourced (which I do not find likely to happen, but
let us assume) then would it be hard to add ?
Arne
Thomas Dickey
It'd be a fair-sized chunk of work to do (a few months for someone working
at it).
madcrow
Given it's likely role of emulating terminals where full compliance
with real VT specs is needed, it would never NEED to do UTF-8. There's
not many "legacy systems" that use Unicode after all...
Arne Vajhøj
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> Thomas Dickey wrote:
>>> JF Mezei <jfmezei...@vaxination.ca> wrote:
>>>> DECterm, being a proper implementation of the VT standards with most of
>>>> the VT bells and whistles (except tracing of control characters) would
>>>> be a great donation to the open source world, replacing Xterm which is
>>>> really really basic.
>>> too little, too late - DECterm doesn't support UTF-8
>
>> If it were open sourced (which I do not find likely to happen, but
>> let us assume) then would it be hard to add ?
>
> It'd be a fair-sized chunk of work to do (a few months for someone working
> at it).
In my view that means possible if there is a real demand for
the feature.
Arne
John E. Malmberg
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> Thomas Dickey wrote:
>>> JF Mezei <jfmezei...@vaxination.ca> wrote:
>>>> DECterm, being a proper implementation of the VT standards with most of
>>>> the VT bells and whistles (except tracing of control characters) would
>>>> be a great donation to the open source world, replacing Xterm which is
>>>> really really basic.
>>> too little, too late - DECterm doesn't support UTF-8
>
>> If it were open sourced (which I do not find likely to happen, but
>> let us assume) then would it be hard to add ?
>
> It'd be a fair-sized chunk of work to do (a few months for someone working
> at it).
It might be more useful to add the stuff that is missing to xterm and
port xterm to VMS.
Fred Kleinsorge has posted before that the DECterm code has some special
stuff to make the display update better. Maybe he could give some
pointers on how to do this with xterm.
-John
wb8...@qsl.network
Personal Opinion Only
JF Mezei
> It might be more useful to add the stuff that is missing to xterm and
> port xterm to VMS.
NO !
For one thing, there is no longer any development (or very little) for
DECwindows on VMS. The message is quite clear from the onwer of vMS that
VMS isn't for interactive use.
Secondly and more importantly, DECterminal would provide a lot of value
to the world community by providing a complete VT emulation, scolling bars.
Since DEC developped the VT standard, making DECterm available would
further increase Digital's long lasting legacy to the world and make
even the young ones know that it was Digital that developped it.
> Fred Kleinsorge has posted before that the DECterm code has some special
> stuff to make the display update better. Maybe he could give some
> pointers on how to do this with xterm.
If I recall, it was about what X routines were used to draw the stuff.
They were using a lower level call to X to draw glyphs instead of the
higher level calls to draw chartacters with attributes.
Also, wasn't DECterm available on Tru64 too ? If so, it would mean that
the code inside wouldn't be *too* tied to VMS.
Giroud, Bernard
> The supporters of OS/2 had petitioned IBM to make OS/2 open source.
>
> IBM decided to decline the offer, offering a number of various
> reasons/excuses to not do so. (some speculate there are some proprietary
> Microsoft code in there).
>
> My guess is that since VMS is in the same boat as OS/2 (nearlty
> abandonned proprietary OS), perhaps we should push for individual
> products being open sourced.
>
> (I would start with DECterm and TPU. )
>
>
> TPU might not displace much in terms of EMACS users, but it would enable
> VMS customers to feel far mroe comfortable with newer platforms,
> especially since it has both character cell and GUI versions.
I strongly second that. I really miss my own extensions on the other
platforms...
--
Bernard Giroud
Phillip Helbig---remove CLOTHES to reply
<jfmezei...@vaxination.ca> writes:
> My guess is that since VMS is in the same boat as OS/2 (nearlty
> abandonned proprietary OS), perhaps we should push for individual
> products being open sourced.
I seriously doubt that open-sourcing VMS, or parts of it, will improve
the situation for anyone, except those who want the code for their own
purposes. The success of open-source stuff elsewhere, rightly or
wrongly, is driven by anti-commercialism. The operating system which
even has the dollar sign as the default prompt character is NOT
something which anti-commercial types will be interested in.
Yes, some stuff is not being developed much anymore. But it would take
even MORE effort to get stuff which has been changed by an open-source
community to get integrated into, and tested with, VMS. Leaving it out
and letting the user use it if he wants to would take away one of the
big advantages of VMS.
HP still makes money from VMS, lots of it. Why should they open-source
it?
JF Mezei
> Yes, some stuff is not being developed much anymore. But it would take
> even MORE effort to get stuff which has been changed by an open-source
> community to get integrated into, and tested with, VMS.
Since VMS is no longer developped in many of its areas, there is no
expectation that any open sourced portions would see the improvemenst
back to VMS. But they would benefit the rest of the world instead of
being abandonned, burried and forgotten.
Since DECterm is a "best of class" terminal emulator, far better thn
Xterm, it would be a shame to see it just forgotten and burried.
> Leaving it out
> and letting the user use it if he wants to would take away one of the
> big advantages of VMS.
Allowing the world to benefit from DECterm doesn't affect VMS' remaining
technological advantages.
And since HP is not interested in the long term success and development
of VMS, allowing as many parts of VMS to go out to the rest of the world
would at least allow parts of VMS/Digital to survive after HP kills it.
> HP still makes money from VMS, lots of it. Why should they open-source
> it?
Because DECterm and TPU are parts of VMS that HP is not interested in.
HP clearly doesn't see any VMS technologies as advantages. It dumped
clusteing in favour of Veritas for HP-UX, and it most certaintaly isn't
going to port DECterm or TPU to HP-UX. Both products have been made
"mature" a very long time ago. They are in the same gang as FMS and so
many other utilities.
To HP, donating DECterm and TPU to the world community would not deprive
HP of any code/technology that HP values.
Phillip Helbig---remove CLOTHES to reply
<jfmezei...@vaxination.ca> writes:
> > HP still makes money from VMS, lots of it. Why should they open-source
> > it?
>
> Because DECterm and TPU are parts of VMS that HP is not interested in.
With all due respect, this is simply rubbish. There are lots of paying
customers who use DECterm and TPU. They might not be interested in
continued development---they might even prefer the "no development,
never change a running system, if it ain't broke don't fix it"
mentality---but they certainly use it. DECterm and TPU are part of what
they are paying for. People with support contracts can get bugs fixed.
> HP clearly doesn't see any VMS technologies as advantages. It dumped
> clusteing in favour of Veritas for HP-UX, and it most certaintaly isn't
> going to port DECterm or TPU to HP-UX. Both products have been made
> "mature" a very long time ago. They are in the same gang as FMS and so
> many other utilities.
Initially, DECnet Phase IV and FMS were not going to be ported to
Itanium. Customer pressure changed that.
> To HP, donating DECterm and TPU to the world community would not deprive
> HP of any code/technology that HP values.
Define "values". I would say they value that which makes them profit,
and that includes VMS and parts of VMS even if they are relatively
static.
JF Mezei
> mentality---but they certainly use it. DECterm and TPU are part of what
> they are paying for. People with support contracts can get bugs fixed.
MPE was also profitable, and people were paying support contracts. But
on Sept 7 2001, when Carly unveiled her wedding plans, MPE was put on
the chopping block. Same for Tru64.
People at higher levels like Staller/Livermore/Hurd only look at
Powerpoint level of detail. If they see a dwonward curve in number of
customer, or a downward curve in profits, or a downward curve on "return
on investment", then they will decide that the product no longer has a
viable future and will act to get rid of it.
They may not kill VMS like they did Alpha MPE or Tru64. But reducing
development staff, preventing marketing to the world and telling ISVs to
move off VMS is not a sign of HP really wanting those remaining profits
generated by VMS to continue forevere (and certaintly not grow).
The valiant staff such as Sue are doing their dardnest within the VMS
group to counter the negative direction set by upper management and
hoping to prove upper management wrong by showing good results despite
upper management's attempts otherwise.
Remove a few key champions (such as Sue) from the VMS group, and you
might see VMS go downhill very fast.
In the end, those champions (I'll assume Sue isn't alone in this) are
fighting an uphill battle, swimming against the current. And in the end,
HP top magement are the ones who set the direction of that current. They
have decided that VMS has no strategic long term importance. They have
mentioned to the media many times already -- and it is now a consistant
message -- that they only care about the installed base, hoping to
capture a good portion of them whe they migrate off VMS.
The move by Cerner is an indication that HP wants to quicken the pace of
the slow winding down of VMS.
> Initially, DECnet Phase IV and FMS were not going to be ported to
> Itanium. Customer pressure changed that.
When HP's instincts are to not port anything unless there is customer
pressure, it says a lot about HP's true desires. A company like Apple or
Microsoft will actively try to expand their market and actively develop
NEW applications. HP is more than happy to kill any VMS product unless
there is too much resistance from the remaining customers.
On May 7th 2002, when they finally announced that VMS wouldn't be killed
(but also included the famous Stallard memo), they committed to
continuing the Compaq "Plan of Record". In other words: continued the
Curly policy of trying to kill VMS. Because in the end, that is what it
was all about. Many here know how close Culry came to killing VMS a year
before he killed Alpha.
When a company has a well established policy of ignoring a product,
refusing the fact that a product could be far more profitable if
marketed, it means that the company is convinced that the product has no
long term future and it isn't worth doing anything to shore it up.
Consider that many VMS staff here agreed with the opinion that
advertising VMS wouldn't yield good enough results. (despite the short
lived VMS renaissance that happened as a result of Marcello convincing
Curly to not kill VMS and give it a chance, that renaissance turned
negative growth into nearly double digit growth in about 6 months, proof
that advertising was at the time still quite effective for VMS).
The fact that VMS isn't yet officially dead is only testament to the
amount of momentum it had back in the 1980s and despite all the brakes
put on it since then, it isn't dead yet. Those brakes have absorbed
almost all the inertia now, and there really isn't much left.
Just because Gartner's schedule for VMS' demise was wrong doesn't give
VMS eternal life. It is a false sense of security to base the future of
VMS on the fact that it has survived all those attacks in the last
decades. The first couple of bullets may not have instantly killed VMS,
but eventually, it will have lost enough blood to no longer be viable.
And I feel (unfortunatly) that VMS has now reached that point.
With the disapearance of the medical business, it doesn't leave much.
Consider stock exchanges: HP owns both Tandem and VMS. With OMX' future
in question, HP will be tempted to move VMS based exchanges to Tandem.
It does't make much sense for HP to continue to spend money on 2
competing systems. It would be more profitable if the stock exchanges
were all on the same system. Same customers and half the development costs.
> Define "values". I would say they value that which makes them profit,
> and that includes VMS and parts of VMS even if they are relatively
> static.
To HP, the remaining value of VMS is as a back end system. User
interface on VMS is not a value for HP. They keep on bragging about web
based system management. (aka: Windows explorer as the user interface on
Windows).
So the various user interface applications on VMS could be donated as
open source without changing any value HP still sees in VMS.
Lets face it, the only real asset VMS has left is the clustering. And HP
was quite clear that it wasn't worth porting it to anything since
Veritas was good enough.
FredK
I do not recall any request from any customer for UTF-8 support on DECterm.
Sheesh. Most of the world uses crappy VT100+ emulators from Microsoft. Is
the ANSI standards stuff for terminals still active? Has UTF-8 replaced
ISO Latin-1?
"John E. Malmberg" <wb8...@qsl.network> wrote in message
news:OAUlj.729$v.51@attbi_s22...
FredK
if you exclude VMS keyboard support - which isn't really a function of the
terminal emulator as much as a keyboard driver issue.
DECterm is a descendent of the VWS emulator, which in turn was a descendent
of the Pro300 VT200 emulator. It is a VT400+ emulator - meaning it was
never certified as a VT500 IIRC. The UNIX varient dxterm is roughly the
same original emulation base as DECterm IIRC.
DECterm doesn't draw glyphs. It draws text using X11 functions to draw text
using standard font sets. There are no "higher level functions to draw text
wth attributes". X11 provides a graphics context for setting the
foreground/background colors and different routines for text that sets the
background as part of text output. Nor does X11 provide for other
attributes such as blinking.
xterm is mostly junk written by people with only a hazy idea of ANSI
standards at best. But like PCterm - they didn't really care much about
compliance with a standard.
"JF Mezei" <jfmezei...@vaxination.ca> wrote in message
news:47981d4c$0$16240$c3e...@news.astraweb.com...
FredK
pinnacle of terminals - with the advent of non-terminal GUIs
(Windows/Mac/Browsers/etc) - what is the point? Sure DECterm/dxterm could
be open sourced for Linux I suppose... but I don't see some huge demand or
requests streaming in that would make it worth going through the hoops to
create a Linux version and all the red tape it would involve to give up the
intellectual property.
"madcrow" <madcrow...@gmail.com> wrote in message
news:8d17a76e-af83-473e...@f10g2000hsf.googlegroups.com...
Sue
> Phillip Helbig---remove CLOTHES to reply wrote:
>
> > mentality---but they certainly use it. DECterm and TPU are part of what
> > they are paying for. People with support contracts can get bugs fixed.
>
> MPE was also profitable, and people were paying support contracts. But
> on Sept 7 2001, when Carly unveiled her wedding plans, MPE was put on
> the chopping block. Same for Tru64.
>
> People at higher levels like Staller/Livermore/Hurd only look at
> Powerpoint level of detail. If they see a dwonward curve in number of
> customer, or a downward curve in profits, or a downward curve on "return
> on investment", then they will decide that the product no longer has a
> viable future and will act to get rid of it.
>
> They may not kill VMS like they did Alpha MPE or Tru64. But reducing
> development staff, preventing marketing to the world and telling ISVs to
> move off VMS is not a sign of HP really wanting those remaining profits
> generated by VMS to continue forevere (and certaintly not grow).
>
> group to counter the negative direction set by upper management and
> hoping to prove upper management wrong by showing good results despite
> upper management's attempts otherwise.
>
> might see VMS go downhill very fast.
>
Dear Folks,
You know how much I care for you and for VMS. We just had and
Ambassadors meeting where Martin Fink called in. And while I value
the fact that at most every posting on COV the future of VMS is
discussed. We do have a roadmap which includes hardware and software
futures. in the last 6 months we have had more press than ever
before. Based on your request we had Martin Fink on Customer call,
more technical web casts than ever before. We are moving forward and
at the point we are just another one of the OS's in HP. We want to be
judged on our merit.
Reality.
We are a business, we are not free, our engineers are (in my opinion)
the best in the industry hence deserve a pay check.
What do you want?
Do not flame me. Do not give me un realistic statments like
advertising, its not going to happen. Give me something, me Sue can
do. And I will do my best to do it. Tell me where the problem is and
I will try and find someone to fix it. I know your job depends on VMS
so does mine.
JF Mezei
> You know how much I care for you and for VMS.
[font size=5000] Yes [/font]
> We do have a roadmap which includes hardware and software
> futures.
So did Alpha on 24-JUN-2001.
Road maps change. Changes can be subtle, progressive or radical (as in
the case of Alpha). The attitude of the vendor towards a product is far
more indicative of the vendor's true commitment to that product.
> Based on your request we had Martin Fink on Customer call,
I take it that from HP management's point of view, C.O.V. is the only
place where there are complaints about how HP is mishandling VMS ?
I take it that people like Stallard and Livermore tell Hurd to dismiss
complaints sent to him as complaints from weirdos ?
I take it upper managemenent are told that real VMS customers are
perfectly happy with the way HP is handling VMS ?
> Do not flame me.
Our hopes would be that you would act as a router to send the flames to
the right people within HP. None of the flames are aimed at you. I think
people genuinely love you and really appreciate your devotion to VMS.
> Do not give me un realistic statments like
> advertising, its not going to happen.
When you say "unrealistic", do you mean that it is not within your
powers to get advertising done, or that it is unrealistic to expect HP
to change their mind and start advertising VMS ?
John E. Malmberg
> xterm already has been ported to OpenVMS as far as I remember.
That does not surprise me. I may go looking for it.
The PERL on VMS self test for UTF-8 handling sends out a sequence that
locks up a DECTerm.
I do recall you posting before something about special code in DECterm
to support screen updates. I think it was for smooth scolling.
> I do not recall any request from any customer for UTF-8 support on DECterm.
> Sheesh. Most of the world uses crappy VT100+ emulators from Microsoft. Is
> the ANSI standards stuff for terminals still active?
Pretty much. It seems that the PUTTY emulator terminal program has
become the most popular one for LINUX and Windows, having both support
for SSH and being free.
The big drawback for Putty so far for me is a lack of support to emulate
the missing LK keys from a PC keyboard.
But it is open source, so it is possible for anyone to customize it.
The other popular program is called screen, which allows the controlling
terminal to detach and reattach to a session. One big difference
between it and disconnectable terminals is that with screen, the session
keeps on running while disconnected while screen buffers the output.
> Has UTF-8 replaced ISO Latin-1?
In the UNIX/LINUX world, it appears so.
Open Source programs ported from LINUX are now assuming that the
terminals are ANSI and UTF8, and also that the filenames can be in UTF-8.
Forster, Michael
Why would the average CIO be savy or aware of VMS abilities and strength?
Arne Vajhøj
> FredK wrote:
>> Has UTF-8 replaced ISO Latin-1?
>
> In the UNIX/LINUX world, it appears so.
>
> Open Source programs ported from LINUX are now assuming that the
> terminals are ANSI and UTF8, and also that the filenames can be in UTF-8.
With .NET then Windows is also moving towards UTF-8.
There are good drivers for it in the increasingly importance
of the asian markets.
Arne
FredK
Ah, a new non-ANSI xterm extension. My guess is that the sequence it sends
is another one of those badly broken OSC type sequences that xterm allows to
be terminated with a BELL character. The same reason that the sequence that
changes the banner text hangs.
Neither DECterm (or VWS for that matter) or xterm does real "smooth"
scrolling, which on a VT100 was a scanline at a time. Both implement a form
of "jump" scrolling where multiple lines of text can update at once during
scrolling instead of a single line at a time. The main difference between
the two is that the amount of jump can be controlled on DECterm (the batch
count) where on xterm there is no means to limit it - a batch count as large
as the terminal line count is the same thing. Under that situation doing
something like TYPE of a file to a screen can result in a few lines being
output, everything in the middle skipped, and the last screen being
displayed. The main limitation to DECterm and xterm is that unlike the VWS
emulator - it only works in the UP scroll direction (linefeed/index) and not
in the DOWN scroll direction (reverse index). So editing scrolls fast down
through the file and slow up through the file. With systems and graphics
being so fast today, this isn't usually a huge issue anymore.
This "screen" thing sounds interesting. But it is the type of thing that is
only possible if you have someone to work full time on it (as a job or
hobby). It isn't clear how useful (multi-session terminal capability) these
days where serial connections are less likely to be the norm, and TELNET is
more common - so just have multiple terminal windows.
Missing LK keys need a combination of both support in the emulator, and
support in the driver. The keys need to be handled by the driver and handed
up to the emulator, and the emulator has to be capable of knowing what they
are. Usually scancodes are converted by the driver (or in the X11 case in
Xlib) to some normalized input codes - so the codes have to get out of the
driver and there needs to be knowledge of how to map them.
I'll scratch around a little on the UTF-8 question, but the best thing is to
see customer requests come in so it can be prioritized. I guess I should
not be suprised that the UNIX world has remained wedded to some type of
terminal input.
"John E. Malmberg" <wb8...@qsl.network> wrote in message
news:67bnj.4622$9j6.4294@attbi_s22...
FredK
a requirement for web pages and even e-mail.
On Windows, "terminal" emulation is a rarity - unless the user is
interacting with a legacy UNIX/VMS application. The basic Windows command
window is a PCterm (a modified VT100). There is at least a couple JAVA
based terminal emulations for embedding inside a web browser (also simple
VT100-like emulation). I am suprised that it has made its way into some
terminal emulators.
"Arne Vajhøj" <ar...@vajhoej.dk> wrote in message
news:479d4479$0$90276$1472...@news.sunsite.dk...
Roger Ivie
> The basic Windows command
> window is a PCterm (a modified VT100).
No, it's not. The basic Windows command line does not process escape
sequences AT ALL. You HAVE to use the Windows API to do stuff.
--
roger ivie
ri...@ridgenet.net
FredK
like:
utf8_mode = (strcmp(nl_langinfo(CODESET), "UTF-8") == 0);
or
char *s;
int utf8_mode = 0;
if (((s = getenv("LC_ALL")) && *s) ||
((s = getenv("LC_CTYPE")) && *s) ||
((s = getenv("LANG")) && *s)) {
if (strstr(s, "UTF-8"))
utf8_mode = 1;
}
to check for UTF-8 encoding.
They were not swift enough to invent a VT-like terminal query to find out if
the emulator is UTF-8 capable. It sounds like the applications in question
are simply assuming UTF-8 is available on the emulator.
From a quick look at the DECterm code, the control sequence (suprise, they
actually did register one!) <esc>%G is ignored - so my guess is that the
terminal 'hang' is a result of a subsequent byte in the UTF-8 stream that is
encoding a non-ASCII character with a multi-byte character. The encoding
for these characters seem to fall into the ANSI C1 control set.
As to the degree of difficulty in merging UTF-8 into a VT400/500 terminal
emulator... that is hard to say. There is multi-byte support for Kanji -
which means it is possible that some basic groundwork has been done (16-bit
fonts). The incoming byte stream would need a UTF-8 handler to seperate out
the non-graphic data to feed to the ANSI parser, and the variable sized
graphic character input normalized either into a 16-bit quantity or an
attribute that shifts the encoding for the character correctly.
Not trivial. Not brain surgery. Some significant work just from the point
of view that the "core" terminal emulation logic hasn't been extensively
changed in something like 15 years. Probably simpler all around for those
Linux/UNIX applications to just find/update a recent xterm port.
"FredK" <fred....@dec.com> wrote in message
news:fnkogo$d2p$1...@usenet01.boi.hp.com...
FredK
"Roger Ivie" <ri...@ridgenet.net> wrote in message
news:slrnfprrva...@stench.no.domain...
Thomas Dickey
> Ah, a new non-ANSI xterm extension. My guess is that the sequence it sends
> is another one of those badly broken OSC type sequences that xterm allows to
> be terminated with a BELL character. The same reason that the sequence that
> changes the banner text hangs.
xterm's done that for almost 20 years
(probably because 8-bit clean connections weren't that common).
Since it's been there for a while, it's not something to remove.
Thomas Dickey
> xterm is mostly junk written by people with only a hazy idea of ANSI
> standards at best. But like PCterm - they didn't really care much about
> compliance with a standard.
glad to see your comments. too bad they're worthless.
regards.
FredK
news:13ps1nm...@corp.supernews.com...
> FredK <fred....@dec.com> wrote:
>
>> Ah, a new non-ANSI xterm extension. My guess is that the sequence it
>> sends
>> is another one of those badly broken OSC type sequences that xterm allows
>> to
>> be terminated with a BELL character. The same reason that the sequence
>> that
>> changes the banner text hangs.
>
> xterm's done that for almost 20 years
> (probably because 8-bit clean connections weren't that common).
> Since it's been there for a while, it's not something to remove.
>
1) String Terminator doesn't require an 8 bit form, it can be a 2-byte
sequence.
2) Using BELL as a terminator isn't compliant with the ANSI parsing rules
3) xterm will (now at least) accept it
4) Old UNIX applications still send BELL
Phillip Helbig---remove CLOTHES to reply
<jfmezei...@vaxination.ca> writes:
> Consider stock exchanges: HP owns both Tandem and VMS. With OMX' future
> in question, HP will be tempted to move VMS based exchanges to Tandem.
Why? You seem to be assuming that exchange running VMS = OMX. This is
not necessarily true.
FredK
> FredK <fred....@dec.com> wrote:
>
>> xterm is mostly junk written by people with only a hazy idea of ANSI
>> standards at best. But like PCterm - they didn't really care much about
>> compliance with a standard.
>
> glad to see your comments. too bad they're worthless.
>
You know, xterm post-dates the VT500. It was filled with "escape" sequences
that are illegal.
PCterm's parser was so loosely written and poorly documented, that some
random guys web page that told *incorrectly* what the escape sequences
were - became so widespread that I had to convince <redacted, let's say a
very important industry leader> why their software was sending the incorrect
sequences and screwing up real VTxxx emulators.
You might not think it is "junk" - and I'll admit that xterm has
incrementally improved over time. But having paid my dues and spent time
writing terminal emulation and defining and negotiating *legal*
escape/control sequences - I am yet to be convinced that the initial coders
knew much about terminals. xterm and PCterm were hacks of varying levels of
correctness when released into the wild, and didn't always follow the rules.
FredK
>
>> xterm is mostly junk written by people with only a hazy idea of ANSI
>> standards at best. But like PCterm - they didn't really care much about
>> compliance with a standard.
>
> glad to see your comments. too bad they're worthless.
>
> regards.
>
My apologies the slam.
For what it's worth, I stopped doing terminal emulation in the late 1980's,
having written the core logic that eventually was taken and ported to X11 as
DECterm/dxterm - so my opinion on xterm is heavily colored by it's state
back then.
Even though I haven't done terminals in 20 years - I continue to get people
complaining to me about applications that do bad things - because they use
non-ANSI sequences invented by xterm - or mangled by PCterm users.
As I said in another post, xterm has incrementally improved over time. The
general limitations of this kind of (free) code is that it is only as good
as who writes/maintains it and how much time and energy they have to devote
to it. I had an equally low opinion of the VT100 emulator that my code
replaced - it was written by a guy who programmed it using the VT100 users
guide.
FWIW - From a terminal architect standpoint, UFT-8 capability should be
something that should be inquired from the terminal by an application before
it attempts to use it. Using C locale functions/environment variables
doesn't tell you what is on the other end of the wire.
JF Mezei
> Even though I haven't done terminals in 20 years - I continue to get people
> complaining to me about applications that do bad things - because they use
> non-ANSI sequences invented by xterm - or mangled by PCterm users.
How easy was it for those people to get official VT escape sequences
from DEC back then ?
The VT220 basic sequences were documented in the manuals. But I recall
Frank da Cruz requiring informal relationship with individuals within
DEC to get those extra sequences not published.
DEC should have worked to evolve the ANSI standard to include the dec
private sequences into the standard.
On OS-X, XTERM appears to be a really basic X-only application. Its
scroll bars are more primitive than a 1984 macintosh. No menu bar for
various functions. Is that the case for all Xterms ? Or would Xterms
built on platforms that provide X middleware (such as motif,
kde/whatever) provide a richer graphical environment ?
Also, remember that DECTERM supports SIXEL and REGIS. (and I suspect
tektronix). It has a superior UI to xterm, and superior terminal
emulation. It would be worth it for the world to benefit from it.
Sue
> Suewrote:
unrealistic - Advertising does not happen at the Business Unit. So
Martin and Ann do not decide HP advertising, and (not positive about
this) not even Scott may have input. So to keep asking the question
is a lot like asking me why someone is not in the World Cup. You can
ask, but its not going to help.
Our hopes would be that you would act as a router to send the flames
to
> the right people within HP. None of the flames are aimed at you. I think
> people genuinely love you and really appreciate your devotion to VMS
Thank you very much for the kind words I only hope that I live up to
them. Please do consider this. I do forward issues that have real
examples with real names. I do not forward flames from people with no
names and no real email address that have not purchased anything. I
would look like a lunatic and I am already viewed as a little off
center (ok way off center) when it comes to the VMS Customers. I
really do not need any help.
From what I can tell everyone wants to help, but they need details.
For example, if you have a services issue. I need the log number and
the date and time and if possible who you spoke to.
DO NOT POST this information
Sue
Thomas Dickey
> My apologies the slam.
thanks
> For what it's worth, I stopped doing terminal emulation in the late 1980's,
> having written the core logic that eventually was taken and ported to X11 as
> DECterm/dxterm - so my opinion on xterm is heavily colored by it's state
> back then.
> Even though I haven't done terminals in 20 years - I continue to get people
> complaining to me about applications that do bad things - because they use
> non-ANSI sequences invented by xterm - or mangled by PCterm users.
iirc, aside from the legacy sequences as noted (and from vt100's non-ANSI),
xterm's additions have been with an eye on the relevant standards.
> As I said in another post, xterm has incrementally improved over time. The
> general limitations of this kind of (free) code is that it is only as good
> as who writes/maintains it and how much time and energy they have to devote
> to it. I had an equally low opinion of the VT100 emulator that my code
> replaced - it was written by a guy who programmed it using the VT100 users
> guide.
> FWIW - From a terminal architect standpoint, UFT-8 capability should be
> something that should be inquired from the terminal by an application before
> it attempts to use it. Using C locale functions/environment variables
> doesn't tell you what is on the other end of the wire.
I suppose so, but none of the systems on which it's been implemented appear
to have provisions for negotiation (and the related escape sequences overlook
that detail). It could be added, but I'm not sure anyone would use it.
JF Mezei
> unrealistic - Advertising does not happen at the Business Unit. So
> Martin and Ann do not decide HP advertising, and (not positive about
> this) not even Scott may have input.
Sue, lets say the above came from someone higher up in HP and the Wall
Street journal were to quote the above in a business story that came to
the conclusion that HP was not interested in growing its proprietary BCS
products (aka anything based on that IA64 contraption).
How would Hurd react to it ? How would all the BCS customers react to it ?
What you are saying confirms that the refusal to allow VMS to grow comes
from very high up within HP.
Now, consider what IBM has done with regards to open sourcing. It wanted
to leverage the PR value of donating certain technologies which gave IBM
a instant image of being player in the open source community. Sun
followed with open sourcing SOlaris.
If HP has no intentions to grow its proprietary systems, it should do
the same as IBM and start donating a lot of stuff to open source
community and allow HP to gain credibility in the linux world.
> examples with real names. I do not forward flames from people with no
> names and no real email address that have not purchased anything.
A company should be more concerned about why it loses customers than why
it keeps them.
Sue
You are reading way more into this than I intended. Advertising comes
from the Advertising group we are an engineering group. If you want
changes to VMS let us know and we will do our best to do it.
I am not nor never have claimed to be a great marketing person (though
I do know a few) and I know zero in Advertising. And I can tell you
for a fact the advertising people are not in our group.
I do not know what the corp folks think since I can not read their
minds. I do know that folks have been trying to bury us for year and
we still have a long term road map. Every indication we have is
support from HP and I can say that after 3 companies. It is up to
folks if they belive it or not. That said there is still a flat earth
society.
sue
John E. Malmberg
> According to a brief search, applications should first be doing something
> like:
>
> utf8_mode = (strcmp(nl_langinfo(CODESET), "UTF-8") == 0);
>
> or
>
> char *s;
> int utf8_mode = 0;
>
> if (((s = getenv("LC_ALL")) && *s) ||
> ((s = getenv("LC_CTYPE")) && *s) ||
> ((s = getenv("LANG")) && *s)) {
> if (strstr(s, "UTF-8"))
> utf8_mode = 1;
> }
>
> to check for UTF-8 encoding.
I will look to see if I can find where a check is not being made. The
code to query terminal information in Perl on VMS looks like it could
use some work.
> They were not swift enough to invent a VT-like terminal query to find out if
> the emulator is UTF-8 capable. It sounds like the applications in question
> are simply assuming UTF-8 is available on the emulator.
That was my assumption. But using xterm or putty was intended to work
around that issue instead of fixing it.
> From a quick look at the DECterm code, the control sequence (suprise, they
> actually did register one!) <esc>%G is ignored - so my guess is that the
> terminal 'hang' is a result of a subsequent byte in the UTF-8 stream that is
> encoding a non-ASCII character with a multi-byte character. The encoding
> for these characters seem to fall into the ANSI C1 control set.
Thanks for the hint.
> As to the degree of difficulty in merging UTF-8 into a VT400/500 terminal
> emulator... that is hard to say. There is multi-byte support for Kanji -
> which means it is possible that some basic groundwork has been done (16-bit
> fonts). The incoming byte stream would need a UTF-8 handler to seperate out
> the non-graphic data to feed to the ANSI parser, and the variable sized
> graphic character input normalized either into a 16-bit quantity or an
> attribute that shifts the encoding for the character correctly.
>
> Not trivial. Not brain surgery. Some significant work just from the point
> of view that the "core" terminal emulation logic hasn't been extensively
> changed in something like 15 years. Probably simpler all around for those
> Linux/UNIX applications to just find/update a recent xterm port.
That was my thought exactly, since my needs are only for my home hobby
systems.
John E. Malmberg
> Ah, a new non-ANSI xterm extension. My guess is that the sequence it sends
> is another one of those badly broken OSC type sequences that xterm allows to
> be terminated with a BELL character. The same reason that the sequence that
> changes the banner text hangs.
>
> Neither DECterm (or VWS for that matter) or xterm does real "smooth"
> scrolling, which on a VT100 was a scanline at a time. Both implement a form
> of "jump" scrolling where multiple lines of text can update at once during
> scrolling instead of a single line at a time. The main difference between
> the two is that the amount of jump can be controlled on DECterm (the batch
> count) where on xterm there is no means to limit it - a batch count as large
> as the terminal line count is the same thing. Under that situation doing
> something like TYPE of a file to a screen can result in a few lines being
> output, everything in the middle skipped, and the last screen being
> displayed. The main limitation to DECterm and xterm is that unlike the VWS
> emulator - it only works in the UP scroll direction (linefeed/index) and not
> in the DOWN scroll direction (reverse index). So editing scrolls fast down
> through the file and slow up through the file. With systems and graphics
> being so fast today, this isn't usually a huge issue anymore.
Ok. I have not noticed an issue with DECTerms there, so probably xterm
will be ok there.
> This "screen" thing sounds interesting. But it is the type of thing that is
> only possible if you have someone to work full time on it (as a job or
> hobby). It isn't clear how useful (multi-session terminal capability) these
> days where serial connections are less likely to be the norm, and TELNET is
> more common - so just have multiple terminal windows.
Screen is not intended for multi-session.
Screen is used for session recovery for when your network connection or
the system running the terminal emulator goes down.
It buffers the screen output while disconnected, and repaints the screen
on connection. It only provides support for VT100 escape sequences.
I have not yet looked at the source to see how hard it would be to port
to VMS.
> Missing LK keys need a combination of both support in the emulator, and
> support in the driver. The keys need to be handled by the driver and handed
> up to the emulator, and the emulator has to be capable of knowing what they
> are. Usually scancodes are converted by the driver (or in the X11 case in
> Xlib) to some normalized input codes - so the codes have to get out of the
> driver and there needs to be knowledge of how to map them.
It appears that Windows/XP and probably VISTA keyboard drivers support
all having an LK series keyboard. PowerTerm was able to detect and use
the keys on several plain vanilla XP systems that I tried. Reflections
(at least my ancient version) seems to require a special helper file,
which does not appear to be available for any more for my version.
I have not had a chance to see what it would take to get putty to use an
LK keyboard.
D Gillbilly
wrote:
<snip>
>
>Dear Folks,
>
>You know how much I care for you and for VMS. We just had and
>Ambassadors meeting where Martin Fink called in. And while I value
>the fact that at most every posting on COV the future of VMS is
>discussed. We do have a roadmap which includes hardware and software
>futures. in the last 6 months we have had more press than ever
>before. Based on your request we had Martin Fink on Customer call,
>more technical web casts than ever before. We are moving forward and
>at the point we are just another one of the OS's in HP. We want to be
>judged on our merit.
>
>Reality.
>We are a business, we are not free, our engineers are (in my opinion)
>the best in the industry hence deserve a pay check.
>
> What do you want?
>
>Do not flame me. Do not give me un realistic statments like
>advertising, its not going to happen. Give me something, me Sue can
>do. And I will do my best to do it. Tell me where the problem is and
>I will try and find someone to fix it. I know your job depends on VMS
>so does mine.
Sorry for taking so long to post up.
At first I didn't realize that this was a victory.
>We want to be judged on our merit.
Reading between the words (in this and other recent posts), I get the
feeling that the OpenVMS BU has gained some additional control over it's
own destiny.
Control.
Isn't that one of biggest problems in industry?
Lack of control?
Congratulations on a job well done (even if I am wrong).
Is it still too early to try to encourage schools, developers, or companies
to take another look at OpenVMS?
OpenVMS may currently be lacking in modern features, but it also is lacking
in a lot of the modern problems.
The lack of developers is the ONLY THING that can kill OpenVMS.
(Even the Vendors couldn't kill it (if they were even trying))
Duane
(too small to be big, too big to be small)
Disclaimer:
Due to circumstances beyond my control, I now work for a company that has
the absolute minimum number of people required to sell and support OpenVMS
applications. As I have alluded in a number of posts, *I* am the biggest
threat to my customers. I'm just describing my job to point out that there
is a big empty gap between my situation and the enterprise. .
But I am a optimistic realist.
I can always achieve nothing by doing nothing.
==================================================
**** What does the WooWoo DooDoo. ****
I was hired by two researchers that were intent on providing computing
power to a disadvantaged industry segment. At the time, they had a rack of
Gandalf technology connecting remote Canadian sites to a hopped up and over
worked PDP 11/70 (RSTS/E). I was new and had explicit instructions not to
use any unnecessary CPU to do my job (we were selling cycles and storage at
the time). I had to spend my days writing code, compiling overnight and
hoping that in the morning I had something to test.
Timesharing taught me how to manage multiple applications for multiple
customers on the same machine. Toolkits full of modules were developed just
to squeeze the most we could into memory.
On the VAX, overlays were easily turned into libraries that turned into
shareable images. They also grew comfortable with providing remotely
managed applications in non-technical (and sometimes hostile) environments.
An integrated security/authentication domain eased management tasks.
Additional authentication provided exceptional auditor compliance. The
customer bought or leased the equipment and for a monthly fee, my company
handled the details.
These are also the hardware years.
I enjoyed working on the network gear.
The Alpha brought a big slowdown to the growth. The bigger customers (that
were more easily influenced by internal IT sources) got cold feet and
bailed (or at least are still trying). For the rest, I immersed myself into
R&D projects (being a writeoff is actually job security) while working with
our customers to maintain flexible environments capable of meeting all the
current business demands and regulations. A non reliance on *industry
standard* services meant we never lost control of the office. (Thanks
PATHWORKS (Advanced Server (SAMBA (gulp))))
Control can provide stability AND allows the users to enjoy (?) the *user
experience* that they unfortunately have been brainwashed to expect.
I'm still on the fence over the I-Box (but liking it more and more). I
think the Management Processor offers the most hope of helping me black box
my OpenVMS appliances. But I'm too busy working to have much I-Box fun
right now.
And the future???
I don't yet know where I fit into the present.
Seems to me that I have been going the wrong way all these years.
And whenever I look at the industry, all I ever see is the push towards the
*next big thing* (or is that away from the *last big mistake*).
I can't tell if I am way behind or if I am way ahead.
Anyway, just don't try to do this yourself.
If you are thinking of trying to deploy an OpenVMS solution, get some
quality professional consultation (Now available!). The lessons that they
have learned and the mistakes that they can help to avoid will go a long
way to ensuring that you can develop applications that are designed to last
longer than the latest fad.
<snip or to last longer than an ink cartridge>
=============================================
?Humor?
A Salute To The Niche!
Too bad small business was such a niche market. :-(
But what if it was a big niche? :-)
What if to an auditor, small companies all looked the same? :-)
What if there was an operating system that was currently only niche. :-(
But what if it was niche in a lot of industries! :-)
Would that make it General Purpose? :-)
Is that a good rank to have? :-)
Where can I sign up? :-)
=============================================
Laughing
Here am I
Laughing inside
Cuz I don't know much
About these times...
Neil Osborne 54-40
I wonder what he would think if he found out that a small business nobody
was using his song for inspiration to try and convince big business that
big business already has the technology to help small business escape
*industry (sub)standard* big business?
Hopefully he would laugh.
I think I need to lighten up anyway.
Time for a change in tactics.
What!
A strategy?
Yup, I'm gonna make someone laugh before I give up!
===============================================
To the choir:
Thank you for your tolerance as I tried to reach the congregation.
Is everyone prepared for Critical Mass?