I was originally attempting to individually respond each of your messages as
they came in, but I received so many responses (about 50) that that became
difficult, so let me express my sincere appreciation to all of you for your
comments here.

The overwhelming response (> 95%) was to go ahead and drop Windows 3.x support
and only support 95/98/NT. A few people suggested trying to support both with
two separate versions of QCTerm. And two friends suggested porting it to the
Mac, using RealBasic.

The latter two suggestions are the tough ones. I would really dislike having
to support two separate code sets and trying to keep them synchronized,
especially during a period of rapid evolution. If we should ever do such a
thing, it would only be after the Windows version was well stabilized.

One person did suggest, however, that we do put up the final version of the
16-bit QCTerm on the web, just before we convert it to 32-bit, and let people
use it as is, knowing that it will never again be improved. That seems like a
very reasonable proposal.

Another person suggested that Windows 3.x users shouldn't really be considered
at all, simply because they've had their machines for some time now and if
they needed a terminal emulator, they must have one. In that regard however,
it's important to understand that once we are finished with the standard
terminal emulation part of QCTerm, we intend on pushing it much further.

Several people mentioned the "non-competitiveness" factor in their responses.
I may have created a misleading impression in that regard. As it occurs, our
greatest lack of competitiveness occurs primarily on the Windows 3.x machines,
simply due to their correlated lack of horsepower. VB3 runs in a tokenized
mode (semi-compiled), thus if you're running QCTerm on a 486 50MHz machine, or
smaller, and running elaborate forms or a menuing system, QCTerm is too slow
to be competitive.

However, if you run the same code on a 200 MHz Pentium, you will see
absolutely no difference between QCTerm and Reflection in their
responsivities. The reason is the "ferryboat factor". While Reflection is
still running at an overall speed twice that of QCTerm in VB3, data packets
are arriving from the HP3000 at such a rate that Reflection simply gets to sit
around at wait longer between packet arrivals. QCTerm still tends to get there
in time, but perhaps just before the ferryboat is ready to leave.

However, even that statement should be explained a bit. Much of the way that
we programmed up QCTerm is such that it is simply calling one Windows API
routine after another. In this sort of code, VB3 is essentially as efficient
as C++ -- and in some routines, we're actually faster than Reflection, due
obviously to the algorithm chosen. It's only in code where all of the
computation must occur at a high-level, such as text parsing routines, that
VB3 slows down to be as much as 20 times slower than native mode code.

However, one question is: does this really matter? As processor speeds become
increasingly greater, as we push on towards 600 MHz machines in the $600 price
range, the practical differences between tokenized and compiled code become
increasingly less.

There is nothing about QCTerm that needs to be in 32-bit. In fact, there's
nothing that requires it to really be in 16-bit. All HP terminals run on 8-bit
processors. Our constraints with VB are these:

   VB3 - 16-bit only, tokenized code only, supports 3.x/95/98/NT, very tight
code

   VB4 - 16- or 32-bit, tokenized code only, can support 3.x/95/98/NT

   VB5 - 32-bit only, native mode compilable, no 3.x support

Based on your comments, what we're now leaning to do is stay on VB3 for until
we have the initial version of QCTerm reasonably well nailed down (perhaps
another six months or so) and then abandon VB3. We will, however, put the VB3
version on the web page so that it can be downloaded.

Nonetheless, to get a better idea of the real requirements are, I would
greatly appreciate your estimates as to the following:

1. For all PC-like devices that you believe have some reason to be connected
to the HP3000, how would you estimate the percentages, not only in your own
organization but all that you personally know of?

   ________ % 95/98/NT

   ________ % 3.x

   ________ % Macs

   _________% Unix workstations


2. Does anyone know for sure that 3.x systems are NOT Y2K compliant? If it's
not, perhaps all of this discussion is moot and 3.x will go away on its own.

3. What are the most common processor speeds in your PCs? What are the slowest
speeds you run? And how much longer do you anticipate running them?

Because the answers to these questions are of use to the entire group, I'll
post a summary.

Again, thanks much for any comments that you might have.

Wirt Atmar