Michael wrote:

> You can do a great deal with Reflection. Host-initiated operations
>  using Reflection Basic in Block mode can be tricky when you need
>  to get a response from the PC, though. I've used it to transfer
>  files, start PC programs, and control PC programs with DDE. You
>  can use it to wrap simple 3K operations in a GUI. A few
>  things are easier in RCL than in RBL or VBA, though.

Completely changing the topic from Reflection to QCTerm, Michael's response
echoes two questions I've received just yesterday from two different
correspondents, neither of whom I've answered yet.

The questions are: (i) regarding file transfer capabilities:

> I do not see in the documentation where QCTERM has any built-in file
>  transfer capability - presumably as part of your effort to keep the
product
>  affordable :).  I am guessing that leaves me with FTP, though I am not
>  enough of an FTP expert to know if that is true, and if true, just how I
>  should proceed from here.


and (ii) the programmatic execution of programs on the PC:

> PC command/program execution via Esc seq?

Let me say that we can easily make it so that QCTerm can do both, but if we
do, it will make anthrax-laced letters seem like child's play. If both
features were in QCTerm, it would be possible for a host-based program to
command the download of any sort of file, including executables, silently, in
the background, without the user's notice, and then once downloaded, have the
host program cause the execution of those files. Given this sort of
capability, any amount of havoc that you can imagine can be done.

My concerns about these capabilities are the continuing reason why we haven't
put either capability into QCTerm yet. I believe it would be safe to have one
or the other capability alone be in QCTerm (the host-program-driven download
of files into the PC, in background *or* the escape-sequence-driven execution
of programs on the PC), but certainly not both.

While the continuing conversation on this list seems to want these "advanced"
features in their terminal emulators, they do continue to concern me greatly.
Thus the question is: would you prefer to have (i) host-commanded file
downloads, silently, in background (we do that now with the sound and image
files in the van Gogh mode and it works very well), or (ii) the programmatic
execution of programs on the PC?

I would greatly appreciate any thoughts you might have on this subject.

Before I finish this note, allow me to outline my nightmare scenario: in this
situation, QCTerm and its van Gogh mode have become as popular as any of the
other freely downloadable "players." Indeed, it is merely one more player,
not unlike Windows Media Player, RealPlayer, Adobe Acrobat, etc. that people
download  for free and install on their machines. Similarly, web page links
that launch QCTerm have also become popular and common.

In this world, if both transparent file downloads and remote program
execution were in QCTerm, clicking on a hyperlink might not only launch a new
instance of QCTerm, the specific script associated with the hyperlink would
connect to a remote host somewhere in the world and as soon as signon was
completed, one or several files might be begun to be downloaded from the host
into the PC. All while this download is going on, the user is absorbed with
whatever diversion the host is presenting to QCTerm. Once the download is
complete, and the host would know when this occurred, the QCTerm-specific
escape sequences would be transmitted to launch the executable files just
downloaded, either now or perhaps a month from now, in the best Manchurian
Candidate fashion, long after any remembered association with the original
web page has been forgotten. At that point, the PC proceeds to wipe clean the
discs of all of the PCs it can reach, as well as its own.

If we put in everything that people seem to want in this regard, the above
scenario will not only be easy but guaranteed.

Wirt Atmar

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