Category : Communication (modem) tools and utilities
Archive   : DOSGAT16.ZIP
Filename : DOSGATE.DOC

Output of file : DOSGATE.DOC contained in archive : DOSGAT16.ZIP
º º
º \ º
º \ º
º \_ Remote operation of MS-DOS º
º º
Copyright (c) 1987

Rich Bono, NM1D
7 Redfield Circle
Derry, New Hampshire 03038

This document describes DOSGATE version 1.6

DOSGATE is a system which allows an industry standard MS-DOS computer
to be controlled via an RS-232 serial port. The port is considered to
be a remote user. The traditional console of the machine is still in
complete control and can supervise and disable/enable the remote user
at will. There is a simple 'Chat' mode that may be entered from the
console to allow 'talking' with the remote user to give assistance or
instructions. In addition to chat mode, there is a simple terminal
emulator to allow control of a modem or other device connected to the
serial port.

The remote user may be connected directly with an RS-232 terminal,
via a modem over telephone lines, or with a TNC for remote operation
via radio!

The local console may still be used for any software
that normally runs. The remote user is capable of running any
software that calls only MS-DOS (int 21h) system calls. Any software
that by-passes MS-DOS and interfaces with the BIOS or directly with the
hardware for I/O will not be usable by the remote user.

This version of DOSGATE is being distributed as SHAREWARE. You are
allowed to use DOSGATE on a trial basis for a limited period of time.
After the trial period, you must register your use of DOSGATE with the
author. Remember, DOSGATE is NOT in the public domain, and as such it
is NOT free software.

If you find DOSGATE helpful in anyway, or you wish to promote
further improvements to DOSGATE, please send an apropriate amount
to the author at the above address. If you send $20.00 or more,
you will be be placed on the update list.

The author would like to hear from anyone with comments or
suggestions concerning DOSGATE or other projects.

Currently tested with :


Versions 3.2, 3.3, 4.00, 4.01

Remote user connection devices:

Kantronix KAM (version 2.82 through 2.85)
Kantronix KPC-2 (version 2.82 or 2.85)

DOSGATE is implemented as an MS-DOS installable device driver.

Also implemented is a simple terminal emulator which allows one
to communicate with the serial port.

To use the terminal emulator, execute DOSGATE at the DOS

The terminal emulator has one command:

ALT-X - exits the terminal emulator and returns to MS-DOS.

Device driver installation instructions:

DOSGATE has but four runtime commands:

ALT-D will toggle the remote user on and offline. A message
is sent to the console and the remote user to inform about
the change.

ALT-T will toggle the 'terminal' function on/off. A message
is output to confirm the change in mode. This terminal is
only to be used for simple configuration commands to or from
the TNC or modem.

ALT-C will toggle the 'chat' function on/off. A message is
output to both the console and the remote user to inform
about the change. Use this mode to 'talk' to a remote user
that is connected to the system.

DOSGATE should be installed as any other MS-DOS device
driver. It also provides for various options.

CONFIG.SYS should contain the line:


This causes the following default options:

Remote user disabled,
Remote user with echo,
1200 baud,
No handshaking,
No Carrier Detect logic
No SET USER= logic

The following options are available at boot time . . .

/R - Remote user enabled at boot time

/E - Disable ECHO of remote users keystrokes
This is useful if the remote users'
terminal has local echo.

/2 - Selects COM2 for DOSGATE else COM1 is used

/C - Carrier Detect logic, will do the following when

CD goes TRUE: - Issue CTRL-C, 'START', CR
CD goes FALSE: - Issue CTRL-C, 'END', CR

Be SURE that your interface cable supports
the Carrier Detect Line!!!

Remote user must be enabled!

This allows the programs 'start' & 'end' to be
executed as remote users come and go.

/U - Sets the environment variable USER to the ID of
the user from the TNC status message.
If no TNC status message, user enters CR, and
then receives a 'Login:' prompt. The user's
input is stored in the USER environment.
Note: FORCES the /C switch on (see above).

/Bxx - selects baud rate (default is 1200 baud)
(No parity, 8 bits, 1 stop bit)
currently supported baud rates:
/B96 - 9600 baud
/B12 - 1200 baud
/B30 - 300 baud
/B11 - 110 baud

/H - Enables hardware handshaking - Must have DSR & CTS
to be able to transmit to remote. Be sure that
the interface cable supports these lines!

/A - Absorb LF's that follow CR's to remote.
this is useful if the remote users terminal
automatically does a CR/LF upon receiving a CR.

/P - Enables Packet radio specific options
Remote user enabled at boot time
Remote user Echo disabled
Absorb LF's following CR's to remote
Enable hardware handshaking
Carrier detect logic enabled
SET USER= logic enabled

for example:

DEVICE=DOSGATE.EXE /R /E - Start remote user enabled, and
absorb (disable) ECHO to the
remote user.

DEVICE=DOSGATE.EXE /P - Start DOSGATE for packet radio
operation (see '/P' above).

DOSGATE should be the only device driver installed for the CON:
device. This means DO NOT install an ANSI.SYS device driver when
the DOSGATE driver is installed!!!

Note: At this time, DOSGATE does not support ANSI escape sequences
to the local console. ANSI escape sequence support may be implemented
in a later version (Be sure and register if you desire this). Escape
sequences will work on a remote terminal if it understands them.

When used as a terminal emulator DOSGATE allows the choice of baud
rate to be used.

ie: DOSGATE /b96 - This would start the terminal emulator using
9600 baud over COM1 (default is 1200 baud).

Environment variables are used to assist MS-DOS programs executing
in the DOSGATE environment. The currently defined evironment is:

USER - Set by DOSGATE driver to the ID of the user.
Used by DOSMAIL functions and START.EXE.

DRIVES - Used by END.EXE, must be set by AUTOEXEC.BAT

Note: The path environment variable should NOT point
to a directory that the DOSGATE.EXE driver is
stored, and the remote user should NOT be able
to stumble across the DOSGATE.EXE file. If the
user attempted to execute the DOSGATE driver, he
would start the terminal emulator feature of the
DOSGATE.EXE driver, and hang the system! Keep
the DOSGATE.EXE driver in a hidden directory!

The additional programs, "START.EXE", "END.EXE", "DISC.EXE" are
used for helping with managing the user in DOSGATE.

With this version:

START - Can be invoked automatically
(see '/C' parameter above).

START will:

1: Open the file 'user.log' in the directory
specified by the environment 'MSG', and write
the contents of the environment 'USER' to that file.

2: Look for a file called "WELCOME.DOC" and
output it to the user. This can be to give the
user instructions when he first connects.

3: Invoke 'READ /c' to report if the user has any mail.

Note: START.EXE can be replaced by a program of your
own that performs any functions that you desire
to be done when the user first "connects" (see

END - Can be invoked automatically
(see '/C' parameter above).

END will look in the environment for the
'DRIVES' parameter. This is used to set each
drive to its ROOT ('\') directory, and also to
leave the machine with the default drive set as
indicated. This is used to insure that the
next user will come into DOSGATE at the same
place each time, and not where the last user
left off.

DRIVES should be set in AUTOEXEC.BAT as follows:


This would set each drive (A:, B:, C:, and D:) to its
root directory, and also set the default drive to
C: (the first drive specified will be the default

Note: END.EXE can be replaced by a program that you
supply to perform any functions that you
desire to happen when the user 'disconnects'.

If the 'sysop' desires some other functions to be performed
when a user first connects to DOSGATE, just create your own
program (or batch file) to perform the desired actions, it
must be named START (.EXE, .COM or .BAT).
The END (.EXE, .COM, or .BAT) program is called when a user
disconnects. This may also be replaced. If the 'sysop'
desires nothing to be done for connect/disconnect, and will
not be using mail, then the 'CD' logic may be disabled. If
the 'sysop' desires connect action, but nothing upon
disconnect, then simply replace the END program with one
that does nothing.

DISC - Must be invoked manually.

At this time, DISC will

wait 3 seconds,
issue 3 control-C's,
wait 3 seconds.
issue 'DISC' [CR],
issue 'TRANS' [CR]

This is to place the TNC in command mode, issue
a disconnect request, then place the TNC back into
TRANSPARENT mode until the disconnect is complete.
The user may use this command to have DOSGATE initiate
the disconnect.

Compatibility with DOSGATE:

The general rules for programs that can be run under DOSGATE are
fairly simple, not keeping to the rules may simply cause confused
users, or could cause the system to HANG!

1 - Any program that affects the serial port that DOSGATE is using
for the remote user will probably cause the computer to hang!
DOSGATE is using the serial port with interupts ON, and will
not tolerate other programs touching the serial port hardware.

2 - Any program that does not do its I/O through DOS (int 21h) calls
will by-pass the remote user. This means that the remote user
will probably be able to start such a program, and all may appear
normal on the local console, but the computer may appear dead as
far as the remote user is concerned.

3 - Any program that issues ANSI escape sequences may work for the
remote user (if his terminal supports the proper escape sequences),
but (with the current version of DOSGATE) will not work correctly on
the local console.

4 - Programs that output massive amounts of data may run slow.
Remember that any data that is output to the remote user is limited
in speed by the serial port, (1200 baud is about 120 characters per
second, this means that is will probably take more than 16 seconds
to output 1 screen worth of data).

5 - At this time, if the remote user sends too much data to DOSGATE
and the current program cannot keep up with the user, some data may
be lost. There is output hardware handshaking (CTS).

Special notes for TNC users:

There are various TNC parameters that are very important for
succesful use of DOSGATE. DOSGATE is not very smart as far as the
TNC is concerned. This is not an accident or an afterthought!
Since DOSGATE performs NO TNC COMMANDS then is should be compatible
with virtually ALL TNCs that have a few minor qualifications.


1 - Have its RS-232 Data Carrier Detect (DCD, pin 8) go
true when a user connects, and go false when a
user disconnects. This also means the your
RS-232 cable must include the DCD line. Most
cables designed for a modem have all the nessary
lines (also important is the CTS and DSR line).

2 - Be set to go into 'TRANSPARENT' mode when the user
connects, and return to 'command' mode when the
user disconnects.
For Kantronix TNCs:

The following settings are also desirable:

CHECK 10 - Or some other value (not 0)
DAYTIME xxxxxxxxxxxx (set to correct time)

3 - Be set to allow only ONE user to connect at a time.
USERS 1 (note: KAM & KPC4 set 'USERS 0' to
be sure only one user at a
time can connect)

4 - Issue a '*** CONNECTED to CALL xxx' message terminated with
a Carriage Return when the user first connects. Where
CALL is the id of the user who connects and xxx can
be other information such as the date/time. The syntax
of this message is crutial to the operation of the user
id logic of DOSGATE. Every space and the case of the
characters (up to the CALL) is very important. If
DOSGATE does not find this message when a user logs in
it will prompt the user to input his id.

5 - Be set for hardware handshaking. At this time, DOSGATE
only supports hardware handshaking. This does not mean
that DOS's XOFF handshaking will not work.

DOSGATE hints:

DOSGATE does not perform any machine protection. This means
that if a remote user decides to erase a file or format your hard disk
he WILL be able to do so!!! Unless you take steps to insure that he
is unable to perform these dasterdly deeds! If you can trust ALL
remote users, then you need not be concerned with this. Although(!),
if you are allowing the general public access to your machine, then
you may want to do the following:

Create 'Hidden' directories which contain programs or data
that you don't want the casual user to stumble across. Note:
this is not a foolproof method and most 'intelligent' DOS
users may be able to find the hidden directories.

Set the Read Only attribute on any files that you don't want to
be easily erased and don't leave any programs on the system to
allow the remote user to change file attributes.

Do NOT keep a copy of your format (or any similarly dangerous
software) ANYWHERE on your machine.

Aquire a copy of CED (or other similar DOS extention) to
allow you to remove or rename internal DOS commands so that
the remote user cannot DELete files, set the PATH, or look
at environment variables. I use CED and map commands that
I don't want the user to perform to a non existant command,
this way when the user types the command DEL *.*, instead
of the prompt "are you sure? ", he is greeted with the message
"Invalid command or file name"! After trying a few destructive
commands, the user gives up, thinking that they have all been

Keep only software that ok for remote users to gain access to
on the machine. This way, if a user does destroy something,
it will not be anything important.

You also may NOT want to leave any compilers around! This
will keep a *smart* user from connecting to your machine
and writing a simple program while online to destroy the
contents of your disks!!!

MS-DOS is a trademark of Microsoft Corporation

  3 Responses to “Category : Communication (modem) tools and utilities
Archive   : DOSGAT16.ZIP
Filename : DOSGATE.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: