Xref: utzoo comp.sources.d:3041 comp.binaries.ibm.pc.d:1497
Path: utzoo!utgpu!watmath!clyde!att!rutgers!rochester!rit!ritcsh!sic
From: sic@ritcsh.UUCP (Eric A. Neulight)
Newsgroups: comp.sources.d,comp.binaries.ibm.pc.d
Subject: Re: Remote control of PC via modem
Keywords: I hope I cancelled the first attempt properly....
Message-ID: <229@ritcsh.UUCP>
Date: 2 Dec 88 20:28:54 GMT
References: <4652@phoenix.Princeton.EDU>
Reply-To: sic@ritcsh.UUCP (Eric A. Neulight)
Organization: /etc/organization
Lines: 50

In article <4652@phoenix.Princeton.EDU> mfryba@phoenix.Princeton.EDU () writes:
>I have a problem, and am getting a little exasperated by now....
>
>I want to remotely control a AT via the modem port.  I don't want the
>graphics (just tty), so I can do this from any machine.  I've looked at
>various communications programs (mskermit,BitCom, etc..) and have yet to
>find one that will do.  "Answering capability" is a joke with most of
>them, since they all require someone at the keyboard still.  I mean
>REMOTE control: this thing is going to be operating a telescope 500
>miles from the lab.  I don't relish the idea of writing a device driver
>from scratch.  What do people who run BBS's do?  I have MKS Toolkit and
>all languages of import, so a variety of methods are open once I figure
>out how to address the COM port to control the modem (Hayes-compatible).

The best (and most user transparent and simple to use) package I have
seen is written and sold by a company called "Robec" based in Horsham, PA.
The name of the package is "SoloCom" and allows you to do just about
anything but change floppies from the remote location.
  A few for-intances ...
      file transfers in the background (while you are doing something else)
      auto call/answer.
      chat mode.
      printer redirection from remote.
      enable/disable remote display and keyboard.
      remote reboot.
      do DOS things locally while still connected to remote.
      very fast (works at any baud rate your PCs can mannage.)
      fully configurable.
      password and license protection (if you wish).

It sounds to me like you want to get at the actual guts of the
package.  Not just control a program which is running on the remote
end, but actually interfacing to the packages low level communications
protocol.  SoloCom uses some sort of fully packetized protocol with
full error detection and retry.  Supposedly, in a future release, they
intend to allow user programs to send/receive their own packets
via some user interface calls.

Sorry if all this seems disjoint, but I am banging this out in a hurry
and going from memory.

Check it out.

==============================================================================
CLAIMER:  Well -- I wrote it!                       Eric Alan Neulight
"Nothing is Impossible -- Just Impractical."      Electrical Engineering
"For every Lock, there is a Key."                 Computer Science House
"INSANITY is just a state of mine."         Rochester Institute of Technology
    BITNET: EAN4762@RITVAX         UUCP: ...!rutgers!rochester!rit!ritcsh!sic
==============================================================================