RMTCTL - A remote control utility using Async Professional
Copyright (c) 1993 TurboPower Software
May be used freely as long as due credit is given
2/93 1.01 - added DCD monitor to reboot if DCD dropped
- added PortOK function to re-init port after
running another communications program like
FXO or DSZ.
--- Overview --------------------------------------------------------
RMTCTL is a utility program that allows remote users to dial into the
machine running RMTCTL and take control of that machine. RMTCTL moves
incoming serial data to the keyboard buffer so that it appears to
applications that data was typed at the keyboard. RMTCTL keeps track
of what is currently being displayed by the application and transmits
that data back to the remote to keep the remote's display up to date.
RMTCTL does not have any facilities for controlling a modem or
answering calls. It's designed to be run as a shell from a BBS or
similar application. Once started, RMTCTL opens the specified com
port, installs its interrupt service routines for monitoring
interrupts 8 and 10, and then EXECs the requested program. The remote
user can then do just about anything they like (short of invoking
TSRs) as though they were sitting in front of the host machine.
Throughout the rest of this document we'll use the term "host" or
"host machine" when referring to the machine running RMTCTL and
"remote" or "remote machine" when referring to the program calling
into the host.
RMTCTL is designed to be compiled and run as a DOS real mode program
only (no DPMI or Windows support). RMTCTL consumes about 50K of DOS
memory before executing the child program.
--- Requirements ----------------------------------------------------
RMTCTL requires a 9600 BPS modem. Well, it doesn't physically require
a 9600 BPS modem but you'll find any speed under that unbearably slow.
Even at 9600 BPS it can take several seconds to completely update the
remote screen. In the worst case, where every byte and attribute on
the host screen changed, it could take up to 8 seconds to refresh the
remote screen. That rarely happens, though, and RMTCTL employs a few
optimizations to minimize the amount of data it needs to transmit to
the remote. Even so, a typical operation in your favorite
editor will likely require 3 to 4 seconds to draw the new page.
RMTCTL expects to be run as a shell from another program that has
already established a modem or direct connection with the remote user.
If you specify a baud rate on the RMTCTL command line, it will open
the specified port at that baud rate. If you don't specify a baud rate
RMTCTL will open the port and use whatever baud rate the port is
currently set to. The latter is more typical since you'll want RMTCTL
to use whatever speed the parent program was using. The former is
handy for direct connects or in those cases where you are running
RMTCTL directly (not through a shell).
RMTCTL requires a full screen communications program at the remote
end. "Full screen" means the entire 80x25 screen space must be
available for displaying incoming data. Some communications programs,
including Async Professional's own SIMPCOM and OOPCOM don't provide
for this. Most mainstream programs, like Mustang Software's QModem,
do. This archive includes a small, simple Async Professional program
called RTERM that also does.
RMTCTL requires that the remote communications program support ANSI
terminal emulation since RMTCTL sends ANSI sequences to control cursor
and text placement as well as color control.
And finally, the remote communications program must provide, in some
fashion, a "doorway" mode of sending keystrokes. While in doorway mode
the remote communications program must transmit scan/key codes for all
extended keys. RMTCTL uses these scan/key codes to assure that, for
example, pressing on the remote machine gets properly seen as
on the host machine.
The supplied RTERM program operates in doorway mode all the time. It
sends scan/key codes for all extended keys except =, which it
reserves as its exit command. If you want to run a program that uses
the = key itself you'll need to change RTERM to use some other
RTERM relies on a modified version of the Async Professional APANSI
unit called APANSIF. APANSIF uses FastWrite to update the screen; this
is slightly faster than the runtime library's Write, plus it avoids
the automatic scroll when the host requests a write to the last byte
of the screen (column 80, row 25).
--- BIOS vs. Block Mode ---------------------------------------------
RMTCTL has two modes of operation: BIOS and block mode. In BIOS mode,
RMTCTL monitors what the host machine sends to its display by trapping
calls to BIOS interrupt 10. Whatever the host machine displays, RMTCTL
transmits unmodified to the remote machine. This is the proper mode to
use while working in DOS and when using programs that write to
standard output like "file find" utilities, compression programs like
LHA and so on.
Unfortunately, BIOS mode isn't sufficient for applications that don't
write to the screen using interrupt 10. Any application that has a
sophisticated user interface (editors, database managers,
spreadsheets, etc.) writes directly to screen memory. When in BIOS
mode, RMTCTL will miss all of those screen writes and the remote user
will just be staring at a blank screen. That's where block mode comes
When in block mode RMTCTL saves an image of the host machine display
and constantly compares its saved image against the physical display.
Whenever it detects a difference it transmits the difference to the
At each clock tick, RMTCTL starts from the top of the screen and
checks each line to see if it may have changed. If a line has changed
RMTCTL formats a command string (of ANSI commands and screen data) and
sends it to the remote. By default, RMTCTL won't update more than two
lines per clock tick (controlled by LinesPerTic). The major reason
behind this is that the process of comparing lines, building a command
string, and stuffing it in the output buffer consumes a fair amount of
time. Trying to update entire screen in one clock tick could take far
longer than 55 milliseconds, preventing the next clock tick from
occurring. Worse yet, it would consume all of the host machine's
resource such that whatever process is updating the screen gets
lengthened as well. This extends the overall time required to update
just the host screen -- thereby extending the time it takes to update
the remote as well.
If large portions of the local screen have changed it's going to take
several seconds to update the remote screen anyway so there's no sense
trying to do it all during one clock tick. It's better to let the host
machine complete its updates as quickly as possible so RMTCTL ends up
sending fewer new lines to the remote.
Although it works, block mode tends to be rather slow when working at
the DOS prompt. So, you'll probably want to switch back and forth
between the two modes as switch between applications and the DOS
command line. By default, ^U toggles between the two modes. You can
change the toggle command with the /T command line parameter.
RMTCTL always starts in BIOS mode.
--- Using RMTCTL ----------------------------------------------------
Use RMTCTL as follows:
RMTCTL [options] where options are:
/B BaudRate Baudrate [no default]
/C # Comport number [1..8]
/T C BIOS/BlockMode toggle key [default = ^U]
/P PgmName Program to EXEC [default = C:\COMMAND.COM]
If a baud rate is specified RMTCTL uses that baud rate. Additionally,
when RMTCTL exits it resets the baud rate to whatever it was
previously and drops the modem control signals. If a baud rate is not
specified the port is opened using the existing baud rate and the
modem control signals are not dropped when the program exits. When
running RMTCTL from a BBS you will most likely *not* want to specify a
Specify which com port number to use.
Specify the control character that toggles between BIOS and block
mode. The ^U character is used by default. You may want to change it
if one of the applications you wish to run needs the ^U key itself. C
should be any character from A to Z. The case doesn't matter and you
shouldn't include the ^.
Specify the program name to execute. If you don't specify a program
name RMTCTL executes whatever program is specified by the COMSPEC
environment variable (usually, the full path name of COMMAND.COM).
Monitor the data carrier detect (DCD) modem signal and reboot the
host machine if DCD is dropped. Use this option whenever a modem
is used by the host. Typically, you will also want your "host" program
to be included in your AUTOEXEC.BAT file so that the host program is
restarted after the reboot.
--- Transferring Files -------------------------------------------------
While the major goal of RMTCTL is to allow you to remotely control a
host machine, you may also find it convenient for transferring files
from the host machine to your machine. RMTCTL itself does not provide
any facilities for transferring files, nor does RTERM. However, it is
possible to transfer files between the host and the remote using the
* The remote program must support file transfer protocols or allow
you to shell to a program that does.
* You must have a file transfer program like FXO or DSZ somewhere on
the host machine.
* You must know what com port RMTCTL is using.
1. Make sure RMTCTL is in BIOS mode.
2. Locate, on the host and remote, the files you wish to transfer.
3. From the remote run the file transfer program (FXO or DSZ)
specifying the current port used by RMTCTL and any other required
parameters. If you are using FXO do *not* specify the baud rate;
instead, let FXO use whatever baud rate the com port is set to.
FXO /c 1 /z /t e:\*.*
uses FXO to transmit all files in subdirectory e:\ from the host
to the remote.
4. Start the file transfer at the remote program. Note that when
using Zmodem many communications programs will automatically
detect that a Zmodem transfer was started at the host and go
immediately into file transfer mode. If not, you'll need to do it
manually using whatever commands are required by your
5. When the file transfer is over you may need to press to
get the host prompt back.
Obviously, while the file transfer is taking place RMTCTL will not be
updating the remote screen since the file transfer program is now in
control of the communications port. RMTCTL detects that another
program has taken over the port by constantly comparing its serial
port ISR vector to the currently installed vector. If the vectors are
different RMTCTL does nothing.
RMTCTL counts on the file transfer program replacing the RMTCTL vector
when it exits. If it doesn't there's really nothing RMTCTL can do
about it and the host will appear to be hung. You're only choice at
this point is to hang up and let the host machine reboot.
When RMTCTL does detect that its vector has been replaced it
re-initializes the UART and makes sure its interrupt line is enabled.
While this is taking place any data sent from the remote to the host
will be lost. Additionally, any screen updating done by the host may
not get sent to the remote -- which is why you'll probably need to
press after the file transfer.
We've tested this procedure only with FX and FXO. However, any
well-behaved file transfer program should work. It must be a command
line program, though. A "full-screen" or general purpose
communications program will take over the com port and, therefore,
RMTCTL won't be able to transmit its prompts to the remote.