I put up a new version of QCTerm this afternoon. The current version is 0.55,
dated June 11, 1998. It may be downloaded from:

     http://www.aics-research.com/qcterm/

If you're already using QCTerm, all that you need do is download the file and
unzip it. If you are using QCTerm for the first time, it is recommended that
you print the instructions that you'll find on the web page and follow them
carefully.

Version 0.55 corrects several problems that were found in the forms mode. A
number of users from all over the world were instrumental in locating several
pecadillos and your assistance in finding these defects is greatly
appreciated. If you were one of the people reporting errors and your reported
defect was not corrected, please write back and tell us so. We wouldn't have
let this release go if we didn't think we had corrected all of the reported
problems (but to be absolutely honest, some of the reports were a little hard
to decipher; we assumed that some of the reports were reporting the same
errors that others were reporting).

In that regard, we truly appreciate you pointing out any errors in the code.
Perfection is the minimum quality standard we're aiming for -- and you all are
the only way we're going to get there.


RECENT DECISIONS ON
FUTURE DESIGN DIRECTIONS

Dec Terminal Emulation

We have decided (and like all decisions, it's not cast in stone) that we will
not support a DEC terminal emulation. The reasons are severalfold: (i) there
are a great number of free (or very low-cost) DEC terminal emulators available
on the web immediately available for downloading, (ii) there are very few HP &
DEC heterogeneous users (the primary users of DEC terminals in an HP world are
universities and there are not many of those), and (iii), the relevancy of
Digital is on the downslope, particularly so to HP3000 shops. Given these
three reasons, but most especially (i), there is no reason for us to expend
developmental hours on something that will be of minimal or no value to most
users.

File Transfer

We have decided not to put a compression algorithm into QCTerm in the same
manner as it is present in Reflection. The far better tack seems to be to put
the compression/decompression routine on the HP3000 so that labeled files
(including datasets and/or databases) can be compressed as a set into an
"archive" and transferred to the PC as straight binary files, where they will
not be decompressed.

The residency of a labeled file on the PC is, by definition, only temporary, a
waystation. The files can then be transferred to the second HP3000 at no
additional cost, at maximum speed, where they will be decompressed back into
their original formats.

The same is true for binary file transfer. If the file transfer target is the
PC on which QCTerm resides, and the HP3000 is instead acting as the
waystation, then the better approach is to WinZip, gzip, etc. the file(s) into
a self-extracting file that can be executed when once transferred from the
HP3000 to the PC, exactly as we're doing now with the self-extracting
executable that you download from the QCTerm webpage.

Attempting to further compress an already compressed file, which frequently
occurs using WRQ's current methodology, does not generate any further
compression. Indeed, most often, it simply makes the file larger and thus
slower to transfer, not counting all of the additionally expended CPU cycles
used in a fruitless task.

Our Current Goals

Our current intention is to first create a perfect emulator of a 700/92
terminal (which we nearly have at this point, minus the decision to support
DEC terminal emulation). Once that is completed, we intend on then greatly
increasing the attractiveness and usability of the forms mode, including
definable text colors, background wallpapers, and the inclusion of bit mapped
logos and images directly into the forms. There is no reason at all why
ancient VPLUS forms cannot be quite pleasant to look at -- and still be
completely compatible with current code.

We also intend on creating an off-shoot of our QueryCalc Display Terminal that
will allow for the easy and attractive presentation of graphics and fixed text
in a browser-like ancillary screen to QCTerm.

The methodology to use both of these extensions to the terminal will be
explained in detail on the web pages once we have them fully designed and
implemented. And, as you should expect, there will be no charge of any kind
associated with these additional behaviors.

Interfacing a terminal to an IMAGE database is a lot easier than interfacing a
web browser. There are no message files, no process-to-process links, no OLE,
no DDE. QCTerm will work no differently than any terminal interface did 30
years ago. However, if we do our job right, it should look very nice.

Our intention is to have most (or all) of this done by the end of the year --
including the part that you won't see, the QueryCalc Display Terminal (unless
you're a QC customer). Of course, all of these dates are subject to the new
and entirely modern and wholly flexible Atmarian calendar.

Wirt Atmar