Wyse Winterm(tm) 5000 Network Terminal
Outdated material; included only for historical reference
(Note: Winterm is a trademark of Wyse Technology, Inc)
This review is going to have to be broken up into several parts:
there is just too much to cover all of it in one article.
Let me tell you first that from the time I first unpacked the
unit, and all through setting it up, configuring it, and beginning
to use it, I kept saying things like "Neat!", "Wow!", "Oh, good!".
I have setup and used the older WinTerms in a Citrix environment in
the past, and I've also used the NCD versions, so I've had some
experience with this kind of device, and this new model was full of
What is it?
It's a Winterm(tm).
A Network Terminal.
A Tarantella client.
It is all of that and more in a $699.00 (list price) box. That's
the price for the 5315SE model, to which you attach your own
monitor. The Local Boot PCMCIA card is another $199.00.
Physically, this is a small box designed for desktop or even wall or under-desk mounting. It took
me a while to understand that the extra hardware I received wasn't
necessary if I just wanted to set it up on my desk. Attaching that
hardware is explained in the on-line CD manual, but that, of
course, was the very last thing I looked at.
The backpanel has all the
connectors you need, even including headphone and microphone ports.
The PCMCIA slot is designed to accept a Local Boot Option card,
which means that it doesn't even have to be connected to the
network- it can boot up all by itself, and if attached to a modem,
can connect to an ISP for telnet, browsing, and POP3 email.
That was the first functionality I configured. After unpacking
the box and installing the local boot PCMCIA card, I connected all
my cables and turned it on. I used an old Dell monitor that is
pretty much retired from active use these days. I knew it wouldn't
be able to give me more than 640 x 480 resolution (the Winterm(tm)
supports up to 1024 x 768), but that would be OK for testing.
The terminal did have some trouble syncing up to that monitor,
and for a few seconds I thought I was going to have to haul
something better over, but the old monitor finally did come to
life. It takes just about a minute for the boot, and then presents
a desktop. I fooled around a bit, looking around the menus, and
checked out the online help built into the firmware. That was
pretty good, and it has a button for more help that will take you
to Wyse's web site if you are connected to the Internet. Of course,
if that's part of what you are having trouble configuring, that
option can't do you much good. I decided it was time to connect up
to my ISP and give this something to do.
I started by configuring one of the serial ports:
I screwed this up at first, because I misunderstood the "Dialout"
box. It's intended use is for phone systems where a "9" or other
string is required before dialing; you might use this to disable
It's also not obvious that you must choose "New" before filling
in anything; if you don't, you can't save what you typed. The
manual doesn't explain how much NVRAM is available for multiple
Other than that, there's not much too this. A phone number,
perhaps ATZ for initializion, and the normal ATDT as a dial
command, and it's pretty well ready to go. I did select hardware
handshaking because I knew I was going to use this for
Then it was on to configuring the actual connection. This time I
knew enough to hit "New" before trying to type anything. I chose
the serial connection I had previously defined, typed in my domain
and DNS server information, and then defined a login script using
the same chat style format you'd use for a uucp connection. My only
complaint about that is that the interface doesn't seem to allow
inserting new expect/send pairs; if you screw it up, you have to
delete and start over. Still, most chat scripts are pretty simple,
and once it is done you won't be coming back here very often,
except perhaps to change passwords, and editing individual lines is
simple, so I don't see this as a problem.
The rest of the configuration is straightforward, except that it
confusingly insists upon your filling in a Local Host name, which
has to be a name defined with an ip address in the Hosts table. If
your ISP has assigned you a static IP address, that's the address
you would associate with the name you put in that box. Yet you'd
also put that address in the Local IP address box, and if you have
checked off that the remote and local ip address will be provided
from the server (the ISP), it makes no sense to have to fill this
in. However, the software requires that you do so. This had me
confused for a while, but once I was satisfied that it would, in
fact, be ignored, I just filled in in with the name of my ISP's
To make the connection, I simply chose System->Serial
Networking, and then clicked "Connect" in the dialog box. One minor
gripe is that neither the status box nor the System messages show
much detail about what is happening; I'd like to see an option to
increase the level of detail for debugging.
However, in a very few seconds, I could see that my modem had
negotiated a PPP connection, and the status box confirmed that I
My first connection was through the Terminal application. This
offers the typical VT emulations, Wyse 50 and Wyse 60, and even SCO
Console. Nothing exciting there, but certainly all the basic
functionality you could need.
Next, I tried the email client, configuring it with my ISP's
POP3 server address. As there's no local storage, the client
doesn't delete messages automatically, and it also has to attach to
the server at least twice for each message: once to get the header,
once to retrieve it for viewing, and yet again if you want to
delete it. This is a little disconcerting on a dial-up link, but
would work nicely on a local network.
Finally, I tried the browser, and that's where I ran into my
first bit of trouble: it couldn't connect to anything. If I had
tried the browser first, I would have suspected something seriously
wrong, but as I knew that I had working PPP, this seemed strange,
yet the error was definitely tcp/ip related.
For lack of anything else I could do, I turned off Van Jacobsen
header compression, not really expecting this to fix anything.
However, after reconnecting with VJ turned off, the browser worked
The browser, by the way, is a Mozilla version, and does not
support Java. That limits its functionality rather severely, but
then again you don't have to run the builtin browser: this is,
after all, both an ICA client and an X-terminal, so once it's
connected to the network, you can run whatever you want.
And that configuration will have to be the subject of another
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2012-07-12 Tony Lawrence