[comp.binaries.ibm.pc.d] Dosgate - is this new?

mjj@stda.jhuapl.edu (Marshall Jose) (06/27/89)

I'm having difficulty appreciating the value of "dosgate".  Isn't the
PC-DOS command "CTTY" adequate for this purpose?  I've had to use
it when I was debugging screen drivers, and it worked quite well.

The only advantage I can see (from reading Keith's description) is
that dosgate will accept commands from both COM: and keyboard, and send
responses to both COM: and screen.

Is there something I'm missing?

Marshall Jose  WA3VPZ
mjj@aplvax.jhuapl.edu  ||  ...mimsy!aplcen!aplvax!mjj

dschuetz@umd5.umd.edu (David Schuetz) (06/28/89)

In article <1722@aplcen.apl.jhu.edu> @aplvax.jhuapl.edu:mjj@stda.jhuapl.edu (Marshall Jose) writes:
>I'm having difficulty appreciating the value of "dosgate".  Isn't the
>PC-DOS command "CTTY" adequate for this purpose?  I've had to use
>it when I was debugging screen drivers, and it worked quite well.
>
>The only advantage I can see (from reading Keith's description) is
>that dosgate will accept commands from both COM: and keyboard, and send
>responses to both COM: and screen.


Well, that's about all it does, I think (accepts commands from both COM: and
keyboard).  I am surprised by the size of the posting (it's five articles,
so it must be big, right?) for what it does.  In the FidoNet BBS Community,
we have had a couple of programs that do the same thing for about two years
or so now.... GATEWAY and IBMAUX1 both do the same thing as dosgate...and I 
think they both support ansi output as well (though it has been a while since
I used these).  

But believe me, the "only advantage" you refer to is very important to 
Sysops who wish to be able to drop to DOS remotely, or who wish to let
their users run ouside programs while still allowing "snooping" at the

console....these are a hot item.


David Schuetz
University of Maryland
dschuetz@umd5.umd.edu

rbono@necis.UUCP (Rich Bono) (06/28/89)

In article <5061@umd5.umd.edu>, dschuetz@umd5.umd.edu (David Schuetz) writes:
> In article <1722@aplcen.apl.jhu.edu> @aplvax.jhuapl.edu:mjj@stda.jhuapl.edu (Marshall Jose) writes:
> >I'm having difficulty appreciating the value of "dosgate".  Isn't the
> >PC-DOS command "CTTY" adequate for this purpose?  I've had to use
> >it when I was debugging screen drivers, and it worked quite well.
> >
> >The only advantage I can see (from reading Keith's description) is
> >that dosgate will accept commands from both COM: and keyboard, and send
> >responses to both COM: and screen.
> 
> 
> Well, that's about all it does, I think (accepts commands from both COM: and
> keyboard).  I am surprised by the size of the posting (it's five articles,
> so it must be big, right?) for what it does.  In the FidoNet BBS Community,
> we have had a couple of programs that do the same thing for about two years
> or so now.... GATEWAY and IBMAUX1 both do the same thing as dosgate...and I 
> think they both support ansi output as well (though it has been a while since
> I used these).  
> 
> But believe me, the "only advantage" you refer to is very important to 
> Sysops who wish to be able to drop to DOS remotely, or who wish to let
> their users run ouside programs while still allowing "snooping" at the
> 
> console....these are a hot item.
> 

Here is why DOSGATE was developed:

1) To allow the system to be used from either the console or the serial
   port  AT THE SAME TIME.  This means that both ports can see what is
   happening.  This also allows the local console to HELP the remote user.

2) DOSGATE can (it is an option) disable echoing of the remote user's
   keystrokes to support HALF DUPLEX communications lines.  This allows
   the system to be used on a wider range of end user equipment.  Primary
   design goal was to allow the operation of the PC via the Amateur Radio
   Packet Switching Network.  This Network allows end users over a wide
   geographic area (New England for example) to have access the the system.
   This option is does not have to be turned on to allow standard full
   duplex operation.

3) DOSGATE was designed so that the REMOTE USER does NOT require ANY special
   software.  This allows remote users the ability to use the system regardless
   of the type of terminal they are using.  Users with Comodore 64's, Mac's,
   VT-100's, PC's, AT's, Timex sinclairs, Radio Shack model 100's, (etc...)
   can access the system.   I considered installing the ability to completely
   run *ANY* software remotely on the PC, but this would limit the remote users
   to only those who have the proper software.

4) DOSGATE "knows" when a remote users first connects, and disconnects.  This
   allows special programs to be executed upon connection, and disconnection.
   This could be for ANY purpose.  Examples are provided, ie: simple email,
   and setting up the system so a remote user always starts at a specific
   directory on the desired drive.

5) The DOSGATE package appears so "large" because a lot of "extra" utilities
   have been provided.  These utilities allow one to "create" a usable
   system that has some of the property of a BBS.  For example, a user connects
   and is informed if mail is waiting for him.  Startup (welcome) text is sent
   to the user.  A simple expandable help utility is also provided.
   If you don't want all the "fluff" then you ONLY need the DOSGATE.EXE device
   (about 12K in size).

6) With DOSGATE, the remote users are NOT EXECUTING a BBS type of program, but
   actually using DOS the same as the local console is.  DOSGATE provides NO
   security system.  If you need security, you can design your system to
   provide as much or as little security as you need.

7) With DOSGATE, the local console has control over the remote user.  You
   can disable/enable the remote user at will.  Or enter a "chat" mode
   right in the middle of executing any program, to help the remote
   user if they need it.

8)  DOSGATE also provides a simple (AKA dumb) terminal emulator to allow
    you to configure your modem or Packet TNC without having to revert to
    other packages.

Overall, DOSGATE was designed with the KISS engineering principal.  That is,
keep it simple and flexible.   DOSGATE can be used for many purposes, from
having a remote terminal in the basement, allowing access to your system
at work (even if the system has a network tied to it), to "building" a
powerfull system that can be used by remote users over a phone line or the
Amateur Radio Packet Switching Network.

My system allows access via the Amateur Radio Network.  A local club
keeps various databases online.  Members can "connect" and find out other
members phone number, etc.  We also have an electronic  Callsign database
online that allows one to find others (simiar to an online phone book).
There are programs to allow users to calculate positions of various
satelites in real time, and games that can be played.  Other utilities
include online exam generators to allow Amateur Radio Operators to create
simulated FCC/VEC exams for studying purposes.  And there is the simple
email system that allows everyone to stay in touch with each other.
Users find this system different.  Instead of just doing the typical
download of software, and trying to determine what will run on their
computers (not to mention... no danger of virus attacks!), there are many
services available for them to use.

	Hope this answers some questions,

	Rich Bono, Author of DOSGATE

 
-- 
 /**************************************************************************\
 * Rich Bono (NM1D)    If I could only 'C' forever!!    rbono@necis.nec.com * 
 * (508) 635-6303         NEC Information Systems       NM1D @ WB1DSW-1     * 
 \**************************************************************************/

det@hawkmoon.MN.ORG (Derek E. Terveer) (07/11/89)

In article <1722@aplcen.apl.jhu.edu>, mjj@stda.jhuapl.edu (Marshall Jose) writes:
> I'm having difficulty appreciating the value of "dosgate".  Isn't the
> PC-DOS command "CTTY" adequate for this purpose?  I've had to use
> it when I was debugging screen drivers, and it worked quite well.

Depends on what version of dos you are using.  The only one that appears to
work is 3.3.  Doesn't work on 2.11, 3.1, 3.11, 3.2, or 3.21.  Each of these
DOS-en documents ctty differently (as well as command.com), if at all.  All of
the above dos-en hang the systems involved.  What version of dos were you
using? (does pc-dos have version numbers?)

Imagine writing code that is supposed to work across all dos-en >2.1 !!!
-- 
Derek Terveer 	    det@hawkmoon.MN.ORG || ..!uunet!rosevax!elric!hawkmoon!det
		    w(612)681-6986   h(612)789-8643

"A proper king is crowned" -- Thomas B. Costain