I just put up a new version of QCTerm, Version 0.90m, dated May 15, 2001.
This version corrects a number of things. Among them are:

     o When we increased QCTerm's maximum serial connection speed to 256,000
bits/sec, we screwed up the serial connections' PAUSE functionality. This has
now been corrected. Our apologies.

     o This version now prints correctly when receiving the escape sequences
for log bottom, log top and most especially, record mode.

     o There are two Caps Lock modes defined for terminals (one is a regular
mode; the other is "teletype" mode). We're going to do away with teletype
mode and instead separate the Caps Lock functionality in this way: The
Esc&k<x>C sequence now sets Caps Lock globally (for the whole PC, including
setting the Caps Lock keyboard light). The second sequence, Esc&k<x>P, now
sets caps lock only for the current session and affects no other currently
executing application. If anyone has any strong opinions about this one way
or the other, we would certainly appreciate hearing them.

     o A few other minor pecadillos were corrected, and as always, I greatly
appreciate you reporting them.

     o However, the biggest change is that the executable file "qcterm.exe"
was name-changed to "qctmain.exe" and a small pre-loader program was written
to assume the name "qcterm.exe."

"Qcterm.exe" now runs for just an instant, ignites "qctmain.exe" and then
kills itself. The purpose of "qcterm.exe" is to insure that the necessary
OCX'es are properly installed and registered in the PC's registry. The
OCX'es, as COM objects, don't follow the same rational loading sequence that
the VBX'es and DLL's did, where we could insure that we were only running the
versions we wanted, from our own subdirectory, and therefore be sure that no
one else would interfere with our auxiliary library files -- or that we would
interfere with them.

While we could have accomplished this loading/registration procedure just
once, in a loader program, we decided to do it every time QCTerm is launched,
simply because one of you on this list reported that QCTerm had been working,
but stopped because someone (another HP3000 vendor, as it occurs), came in
behind us and registered older versions of the necessary OCX'es.

I've been receiving approx. one support email a day since we released the
last version of QCTerm, all asking the same question: some of my OCX'es out
of date. What do I do to correct it? This version is intended to try to
eliminate that question in a very smart and careful way. "Qcterm.exe" will
NOT overwrite an existing, registered OCX if it is equal or newer than the
minimum versions we require, but it will automatically repair the registry if
someone later loads older versions.

Further, we move the primary registration to the Windows/System folder (or
WinNT/System folder, depending on your OS). While it is possible to maintain
multiple registrations of different versions of a specific OCX in the
registry, for most of the versions of Windows that people are currently
running, only the first entry in the registry counts. That won't be true in
Windows ME, 2000 and XP, but what we're doing won't affect the
application-specific, "side-by-side" OCX registration that's coming.

All of this complexity associated with the registry was put in to eliminate
"DLL Hell", but I can't say that it was a step forward. The real cure for all
of this mess -- and has remained the proper cure from the very first days --
is to allow static linking (the equivalent of an RL's on the HP3000), where
the necessary code is statically bound into the application code itself.

Heed these words, my children: dynamic linking is a sin against God, Nature,
Man, and Computerdom, and is the root of all evil in the world. If you come
to care deeply about library versioning, the rules are simple: someone really
screwed things up during the design of the fundamental architecture.
Application-specific OCX registrations are nothing more than an unnecessary
complexification, a workaround in a weak attempt to try to recover some of
the advantages attendant to statically linked libraries.

Under any circumstance, I believe we have a clean and simple "fix" for the
OCX problem, one that won't do anyone any harm and yet make life much easier
for the innocent user.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *