noren@dinl.uucp (Charles Noren) (10/18/88)
I need to be able to remotely control application software on
an IBM PC/XT and PC/AT (running DOS). Is there just a simple
DOS command to do it? Do I need to write interrupt handlers to
"fake-out" the keyboard remotely and pass the output back through the
serial port? I'm assuming (dangerous :-)) fairly well behaved
applications that go through DOS or the BIOS. Are there tricks
to poorly behaved applications? Finally, is there software
(source preferably), commercial, PD, shareware -- that does
this sort of thing (with phone numbers and/or addresses)?
Thanks.
--
Chuck Noren
NET: ncar!dinl!noren
US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
Denver, CO 80201-1260
Phone: (303) 971-7930karl@ddsw1.MCS.COM ([Karl Denninger]) (10/18/88)
With regards to "remote control": You can do it for free by typing "CTTY COMx:". After executing this command, your console is redirected to the serial port named. Note that to get back to the normal console, you can execute a CTTY command with no argument, or reboot. Also -- programs which do direct screen & keyboard I/O (ie: don't use the BIOS calls), or anything which tries to go into graphics mode won't work. To do this, you need a package such as Carbon Copy (tm). There are many of these available, most require two copies (they check serial numbers, and won't work with themselves), and they are a little expensive.... Other than that they do work.
jmj@mhuxu.UUCP (J. M. Johnson) (10/19/88)
In article <757@dinl.mmc.UUCP>, noren@dinl.uucp (Charles Noren) writes: > I need to be able to remotely control application software on > an IBM PC/XT and PC/AT (running DOS). Is there just a simple > DOS command to do it? Do I need to write interrupt handlers to I just did this a couple of nights ago. If what you want to do is control your PC from a remote terminal try this: C> CTTY COM1 this redirects all CON: i/o through COM1. I was running my computer with a TRS-80 PC2 Pocket Computer this way just for shits and gigles. Typing: CTTY CON from the remote terminal returns i/o to normal channels. -- Life's just a game, you fly a paper plane, there is no end. - TBA J. M. Johnson, AT&T Bell Laboratories, Reading, PA ...!att!mhuxu!jmj
jxh@cup.portal.com (Jim - Hickstein) (10/19/88)
Remote control of a PC over the serial port to another PC or even simply to a VT-100 can be accomplished by a program called pcAnywhere. We just put it on the bench a few days ago, and have been suitably impressed by its features and speed. We use it as a stopgap solution to having a multi-user application (a network management console). It has limitations, of course, but is generally worthwhile. It is made by: Dynamic Microprocessor Associates, Inc. 545 Fifth Avenue New York, NY 10017 USA The "worldwide distributor" is: EKD Computer Corp. 770 Middle Country Road P.O. Box Y Selden, NY 11784 USA (516) 736-0500 or get it from a retail software outfit (I think we got this one from Egghead). Frankly, I haven't had much time to play with it, but at first blush it seems OK. My application is not exactly well-behaved, in that I hook the BIOS INT 16H keyboard vector to filter out ctrl-C and ctrl-Break before they (sometimes) get to DOS and wreck my screen. I thought that might be a poser, but pcAnywhere took it in stride. They seem to have done their homework (no pun intended, honestly). It feels as though it is of the class of programs that, like some debuggers, get fixed immediately and improved rapidly because the programmers use them constantly. I suspect the developer of pcAnywhere lives quite some distance from work. :-) -Jim Hickstein jxh@cup.portal.com ...!sun!portal!cup.portal.com!jxh
ads4@tank.uchicago.edu (adam david sah) (10/19/88)
I know for a fact that there are Public Domain remote PC programs available o{t to mention shareware/freeware BBs programs (which all have Drop to DOS...)
I have several (none of which I use, of course- I run a BBs...) BASE-PC.ARC and some others...
They exist, to be sure.
-A.Sah'88cpp90221@dcscg1.UUCP (Duane L. Rezac) (10/19/88)
From article <8466@mhuxu.UUCP>, by jmj@mhuxu.UUCP (J. M. Johnson): }}In article <757@dinl.mmc.UUCP>, noren@dinl.uucp (Charles Noren) writes: }} I need to be able to remotely control application software on }} an IBM PC/XT and PC/AT (running DOS). Is there just a simple }} DOS command to do it? Do I need to write interrupt handlers to } } I just did this a couple of nights ago. If what you want to do is control } your PC from a remote terminal try this: } } C> CTTY COM1 } } this redirects all CON: i/o through COM1. I was running my computer with a } TRS-80 PC2 Pocket Computer this way just for shits and gigles. } } Typing: CTTY CON from the remote terminal returns i/o to normal channels. } -- } Life's just a game, you fly a paper plane, there is no end. - TBA } } J. M. Johnson, AT&T Bell Laboratories, Reading, PA ...!att!mhuxu!jmj The above method will work for programs that use the DOS screen and keyboard routines. If the program usees it's own custom routines, Watch out!!! CTTY may have strange results. ( I know from experience.. when I tried to run DBASEIII remotly using CTTY, it promply locked up my system, and I had to reach for the big red switch :-( -- +-----------------------+---------------------------------------------------+ | Duane L. Rezac |These views are my own, and NOT representitive of | | dsacg1!dcscg1!cpp90221|my place of Employment. | +-----------------------+---------------------------------------------------+
palowoda@megatest.UUCP (Bob Palowoda) (10/20/88)
From article <757@dinl.mmc.UUCP>, by noren@dinl.uucp (Charles Noren): > I need to be able to remotely control application software on > an IBM PC/XT and PC/AT (running DOS). Is there just a simple > DOS command to do it? Do I need to write interrupt handlers to > "fake-out" the keyboard remotely and pass the output back through the > serial port? I'm assuming (dangerous :-)) fairly well behaved > applications that go through DOS or the BIOS. Are there tricks > to poorly behaved applications? Finally, is there software > (source preferably), commercial, PD, shareware -- that does > this sort of thing (with phone numbers and/or addresses)? Someone has uploaded a Public Domain Program to my bbs that claims to be a "Carbon Copy" software clone. Carbon Copy is a commercial piece of software when run on two pc's can run even the most ill behaved software. I haven't had a chance to run it myself but breezed through the docs and the setups are similiar to the CC software. The name of it is "tandem31.arc" and is located in the msdos_comm files area. The bbs number is 415-656-9386. ---Bob -- Bob Palowoda Work: {sun,decwrl,pyramid}!megatest!palowoda Home: {sun,pryamid}aeras!grinch!legends!fiver!palowoda BBS: (415)656-9386 2400/1200 Voice:(415)656-9384
ads4@tank.uchicago.edu (adam david sah) (10/21/88)
You mentioned that DBIII locked up with CTTY COMn. That's because most word processors, database managers, graphics programs, speadsheets,. etc all write directly to the screen in order to speed things up (BIOS writes are slow). This is why you cannot have Doors on a BBs running word processors (wouldn't it be nice to be able to write that stupid ________ (fill it in...) off line???) It didn't lock it up, it only couldn't send anything to you... Try it instead with something that doesn't write to the screen (i.e. PCMoria, or Hack, etc etc etc. They will all work (and make great BBs doors.) -A.Sah'88
ray@micomvax.UUCP (Ray Dunn) (10/26/88)
In article <[75.1]karl@ddsw1.comp.ibmpc> karl@ddsw1.MCS.COM ([Karl Denninger]) writes: >With regards to "remote control": > >You can do it for free by typing "CTTY COMx:". After executing this >command, your console is redirected to the serial port named. > >Note that to get back to the normal console, you can execute a CTTY >command with no argument, or reboot. Also -- programs which do direct >screen & keyboard I/O (ie: don't use the BIOS calls), or anything >which tries to go into graphics mode won't work. Should say "which don't use the *DOS* calls". Only DOS calls can be redirected (e.g. INT 21). BIOS calls (e.g. INT 10) cannot. There is *no* support for display and keyboard redirection in the BIOS. CTTY is of limited value because of the very common useage of direct display output for text, and, of course, all graphics output is direct. Even BASIC doesn't go through DOS, and ansi.sys almost certainly doesn't get invoked if loaded (haven't tried it). Unfortunately (or perhaps naturally, because of the PC's architecture) there is no current satisfactory general solution to a "remote" control terminal. There is perhaps a niche hardware product opportunity here, but it probably is only relevant in a pure alpha-numeric mode, a minority market. -- Ray Dunn. | UUCP: ..!philabs!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090
del@Data-IO.COM (Erik Lindberg) (10/29/88)
In article <1340@micomvax.UUCP> ray@micomvax.UUCP (Ray Dunn) writes: >In article <[75.1]karl@ddsw1.comp.ibmpc> karl@ddsw1.MCS.COM ([Karl Denninger]) writes: > >Unfortunately (or perhaps naturally, because of the PC's architecture) there >is no current satisfactory general solution to a "remote" control terminal. > >There is perhaps a niche hardware product opportunity here, but it probably >is only relevant in a pure alpha-numeric mode, a minority market. Depends on what you mean by "satisfactory". There are, in fact, a couple of commercial products that allow full remote access of a PC by modem, even for character graphics *and* direct screen writes. I don't know if they can handle graphics as well, but I wouldn't be surprised. One of the products is even CALLED "Remote". These products work by hanging off the timer iterrupt and maintaining a copy of the screen for comparison. Every <user defined> period the program wakes up, compares the screen with its copy, and sends the differences out the serial port. The companion program, running on the local PC, interprets the difference data and displays. Input is accepted from either keyboard, and of course the function and keypad keys, even action of the shift keys, is transmitted across the serial port. In fact, the only "unsatisfactory" thing about this setup is the speed at which it runs: slowly. There was a review of this setup in PC-Rag a long time ago. They tested it with several programs that did not- so-nice things with the hardware and it seemed to work ok. Notably Lotus 123 seemed to work just fine. -- del (Erik Lindberg) uw-beaver!tikal!pilchuck!del