Doug Greenup writes:

> >Wirt's amazingly low-priced and full-featured emulator! Works over
>  >wires, through walls and locked doors, and over oceans.

Doug lists a number of things that he believes are serious defects in QCTerm:

>  [QCTerm] won't even make Telnet connections?

Clearly, Doug has not been paying attention. Telnet works extremely well in
QCTerm, both in "standard" mode (the way that telnet is implemented in
Reflection and MS92) and "advanced" mode (a half-duplex mode that greatly
increases human perceptual satisfaction and cuts the packet count in half).

The only time that a user will generally run into trouble is when the
"advanced" mode is selected and the target HP3000 lies behind another box (a
UNIX firewall perhaps) that is not accurately relaying the telnet commands to
the HP3000. In such a case, all the user needs do is drop back to "standard"
mode. If QCTerm still won't work in those cases, neither will anything else.

There are several additional features that would siginificantly help the half-
duplex mode be even more efficient and more satisfactory to use -- and those
are being actively investigated.


>  QCTerm .4 Alpha does not script,

That's true. A scripting language can't be written until the basic terminal
emulator is completely finished.

> [It} does not have file transfer,

That's also true. We've considered file transfer a secondary priority item.
But it will come.

> [It] does not do NS/VT,

As I've mentioned before, I'm not sure that we will ever support NS/VT. The
modified telnet that we've been working on is nearly identically as efficient
as NS/VT, the real difference being that telnet is a universal standard -- and
unfortunately, NS/VT is not.

> [It] does not handle 132 worth a darn,

Please allow me to disagree vigorously with you on this point. We did design
132/200 column support differently than a standard terminal (or R1 or MS92)
does it. Rather than squish the characters down to make them look like Clint
Eastwood in a spagetti western put on TV, we left the characters in their
proper proportions by making the font size a little smaller and providing a
cinemascope look to the screen.

Before we went ahead with this design, because it would be "different" from
what people might expect, we genned up prototypes of both formats and asked
approx. a hundred people who happened to come through which format they liked
better: squished or cinemascope. Cinemascope won unamiously.

And we're still asking people. The latest askee was Ernest Hill, a member of
this list who normally resides in Saudia Arabia. Ernest was here Wednesday
night and got the standard treatment: an enchilada dinner, a tour, and then
two hours of tortuous grilling, comparing side-by-side the features of QCTerm
and Reflection to see which of the various features he liked better. On the
subject of 132 column display, Ernest, like everyone before him, voted for
cinemascope.

Clearly, we're eventually going to find someone (perhaps Doug) who doesn't
like this format, but you can blame Ernest (and all those who came before him
:-). And you can ask us for your money back.

> [It] does not support append forms,

I don't understand the "append" part of the comment, but QCTerm does support
forms.

> [It] does not handle em220,

That's true. DEC emulation has been considered a second priority item --
although I know that once we get it in, it will make QCTerm a "big seller"
with universities.

Now that the vast majority of the basic functions are in the emulator, putting
in a mode switch in escape processor will not be a great deal of trouble.

>  [It] does not work with Smith Gardner MACS package,

That comes as news to me. However, if anyone should find any program that the
emulator QCTerm does not work perfectly with, please let us know. If we have
your permission to dial into a dummy account on your machine where you can
recreate the problem, we can debug it relatively quickly.

If you have reservations about letting us dial in, there is a debug sequence
in QCTerm that allows a recording of all incoming and outgoing communications
traffic, regardless of the transport medium. The QCTerm-specific sequence to
turn communications logging on is:

     Esc&k12345X

and

     Esc-

to turn it off. When you're in debug mode, the communications panel at the
bottom of the screen lights up in red. The log file is c:\aics\temp\debug.txt.
If you would e-mail us that output (and possibly a fax or e-mail of your
screen), we can see precisely what caused the problem.

> [It] does not run on Macintosh, does not run on Dos, does not support Java,

That's all true -- and probably always will be.

> [It] does not allow for any keyboard remapping (Block mode ENTER is not the
ENTER key)

Doug is absolutely correct: the block mode ENTER key is not the RETURN key.
They are completely separate functions. We've hard-assigned the F12 to be the
block mode ENTER key. F12 is a convenient place for it -- and if you miss and
hit an adjacent key, none of them do you much, if any, harm.

However, based on user comments received, primarily from Ted Ashton, the
numeric pad ENTER key will be allowed to be defined as an auxillary block mode
ENTER key. Look for that in the next release (currently scheduled for Monday).

>does not support passthrough printing on NT or Windows 95!

That's also true at the moment. Passthrough printing (generally used for
PostScript and PCL graphics) is clearly a second-level priority, but we
outselves need it as much as anyone, so that won't be much longer in coming.

Standard screen printing, however, works quite nicely in QCTerm, better I
believe than in Reflection (unfortunately, I've never seen a copy of MS92's
output).


>  MiniSoft 92 installed in over 6,000 HP3000 sites sells for as
>  little as $59.00/copy (educational/non-profit pricing) or $79.00/copy (for
>  the rest of us) over here in the U.S. and we feature a toll-free 800 number
>  for support (works from anywhere in the world) included with the license.
>  One or two support calls to AICS long distance (assuming you can get a hold
>  of them) and you have burned up the savings, especially from South Africa.

>  Frankly with the state of this ALPHA .4 product you will be making a quite
a
>  few tech calls!

Actually, so far only one person has called. Everyone else has corresponded by
e-mail -- and those correspondences have come from all over the world -- and
all have been answered in just a few hours. Support is something we take very
seriously. However, let me say, that if you're in the US, I would appreciate
it if you would call rather than e-mail us a description of your problems.
Voice conservations tend to carry an immensely greater amount of information
that does a succession of e-mails.

Our numbers are:

    (505) 524-9800 and (800) AICS-INC


>  I am sure AICS will eventually achieve some level of functionally and
>  reliability.

Doug may have missed the original conversations regarding letting QCTerm go in
stages. No one is more picky that I am about quality and reliability. In the
voting that occurred regarding whether to let QCTerm go in incremental stages
or hold it until it was completely done, the vote was again unamimous to
release it in stages. Ordinarily, we shield our products from inappropriate
criticism by releasing them to only a small group of intense users -- and
refine them over and over again until we know of absolutely no errors in their
behaviors -- before we release them to the general public.

Because QCTerm is a free product -- and because having it be used by so many
people at once is to our advantage -- we changed our mind for this one
instance, based partly on the vote here on the list, and partly on the fact
that we should be able to get the errors out of QCTerm all that much faster.
But the downside of such an approach are clearly the inevitable
misunderstandings, such as Doug's.

Finally, Ted Ashton wrote:

> > Also it would
> >  be nice to be able to set QCTerm to go away when I logoff.
>
>I can handle having it not go away, it's a minor thing.  I found it
irritating,
>though, that when, upon discovering that it wasn't going to disappear on it's
>own, I hit ALT-F4 (the usual Windows sequence to make things go away) it
>refused to leave.

QCTerm's terminal emulator is programmed as a "child" form. The "parent" is
the opening screen (the petroglyphs). ALT+F4 works there, as it does on any
parent form, but it doesn't work when only a child form is visible.

We did program up CNTL+Q, Macintosh-like, as a way to quit the terminal
emulator and return to the main screen (from where, you can type ALT+F4 if you
wish). We also programmed up the close box as a direct quit, for those who
don't want to perform two operations.

The reason that QCTerm is being programmed in this manner is there will be a
number of similar child forms that branch from the parent, the terminal
emulator being just one of them.

Some time ago, I was in a meeting with Steve Cooper at HP in Cupertino where
Steve said that the single item holding the HP3000 down was its dowdy terminal
interface. Steve's comment made a substantial impression on me (like much of
what he has to say).

Rather than wait for someone else to solve the problem that universally
bedevils us all, I thought we might as well do it. It wouldn't be all that
expensive. I originally allocated $150,000 to build a better interface and
simply give it out to everyone at no charge. So far we're about 40% done and
have spent only about $40,000, so we're well under budget, if not time.

Clearly, no one will be forced to use any of this. I doubt that QCTerm will
ever be as fully featured as Reflection -- but there are substantial
advantages in keeping a product as simple as possible. Each additional
configurable item increases the probably that someone will get it a little
screwed up -- and increase the support costs for us all. QCTerm -- and the
coming screens -- will simply be available for your use if you wish to take
advantage of them.

Wirt Atmar