ttl@sti.fi (Timo Lehtinen) (06/16/91)
Does anyone know of a telnet daemon for MS-DOS. For any TCP
implementation (PC-NFS, PC/TCP, ...) ?
What I would like to do is telnet login to an MS-DOS box
get the DOS "console" redirected to my remote session and
be able to initiate a "make" on an NFS-mounted directory
containing the sources for our project...
Please answer via email if possible.
Thanks!
Timo Lehtinen
____/ ___ ___/ / Kivihaantie 8 C 25
/ / / SF-00310 HELSINKI, Finland
____ / / / Phone: +358 0 1399 0151, +358 49 424 012
Stream Technologies Inc. Fax: +358 0 1399 0154
______/ __/ __/ X.400: C=fi,A=fumail,P=inet,O=sti
--
____/ ___ ___/ / Kivihaantie 8 C 25
/ / / SF-00310 HELSINKI, Finland
____ / / / Phone: +358 0 1399 0151, +358 49 424 012
Stream Technologies Inc. Fax: +358 0 1399 0154gordon@FTP.COM (Gordon Lee) (06/19/91)
From: Timo Lehtinen
Subject: TELNET daemon for MS-DOS anyone?
What I would like to do is telnet login to an MS-DOS box
get the DOS "console" redirected to my remote session and
be able to initiate a "make" on an NFS-mounted directory
containing the sources for our project...
Sounds like what you really want is something like rexecd, since
all you want to do is fire off a make. rexecd would be much simpler
to implement than a telnetd.
}} Gordon Lee FTP Software Inc
}} voice: (617) 246-0900 26 Princess St
}} fax: (617) 245-7943 Wakefield, MA 01880nice1.ne.rpi.edu (Y. Danon) (06/20/91)
In article <9106191238.AA20987@ftp.com> gordon@FTP.COM (Gordon Lee) writes: > > From: Timo Lehtinen > Subject: TELNET daemon for MS-DOS anyone? > > What I would like to do is telnet login to an MS-DOS box > get the DOS "console" redirected to my remote session and > be able to initiate a "make" on an NFS-mounted directory > containing the sources for our project... > >Sounds like what you really want is something like rexecd, since >all you want to do is fire off a make. rexecd would be much simpler >to implement than a telnetd. > >}} Gordon Lee FTP Software Inc >}} voice: (617) 246-0900 26 Princess St >}} fax: (617) 245-7943 Wakefield, MA 01880 > I would like a telnet deamon too, this will allow me to run program on the pc from a remote site. If this can also be combined with a program like CarbonCopy
jrd@cc.usu.edu (Joe R. Doupnik) (06/20/91)
In article <xn+l46q@rpi.edu>, nice1.ne.rpi.edu (Y. Danon) writes: > In article <9106191238.AA20987@ftp.com> gordon@FTP.COM (Gordon Lee) writes: >> >> From: Timo Lehtinen >> Subject: TELNET daemon for MS-DOS anyone? >> >> What I would like to do is telnet login to an MS-DOS box <items removed> >>}} Gordon Lee FTP Software Inc >>}} voice: (617) 246-0900 26 Princess St >>}} fax: (617) 245-7943 Wakefield, MA 01880 >> > > I would like a telnet deamon too, this will allow me to run program on the pc from > a remote site. If this can also be combined with a program like CarbonCopy ------------------------------ Hmmm. I wonder if folks know what they are asking for with a PC/DOS based telnet daemon. Let's see. To remove all opinion I suggest a simple test. Plug a terminal (remember those things?) in to the serial port of a PC and tell DOS CTTY COM1. That's as good as Telnet is every going to be, usually Telnet is only 7-bits wide. Ok, now run some nice application and see how far that terminal can go (an inch or two). Why? Because the DOS application is not written to run via stdin/stdout, no way, but that's all one gets with Telnet. And why is the latter the case? Performance, features, staying in business with the first two (performance, features). Carbon Copy, PC Anywhere, etc don't behave this way. They are DOS market programs present to make money performing well. What they do is trap the screen on one machine and repeat the changed contents on the other and ditto the other way for keystrokes. All this is at the internal detail level of the PC where programs expect to find things below the Bios. Special encoding is needed to make sense of the streams going each way. They could use IP as a transport provider but I doubt there is a market for it. Try the test and see what I mean about stdin/stdout being insufficient. Then, because it's a nice summer, how about writing a Carbon Copy clone with IP as the packet mover? Joe D.
madams@ecst.csuchico.edu (Michael E. Adams) (06/20/91)
In article <1991Jun19.204430.48165@cc.usu.edu> jrd@cc.usu.edu (Joe R. Doupnik) writes: >To remove all opinion I suggest a simple test. >Plug a terminal (remember those things?) in to the serial port of a PC and >tell DOS CTTY COM1. That's as good as Telnet is every going to be, usually >Telnet is only 7-bits wide. Ok, now run some nice application and see how >far that terminal can go (an inch or two). Why? Because the DOS application >is not written to run via stdin/stdout, no way, but that's all one gets with >Telnet. > Joe D. I thought this was worth reposting. Still, I wonder how long the "net" will remember what was learned here today? Thanks Joe for typing out the words ONE MORE TIME ;-) (___) | Michael E. Adams (o o) | Custom Computer Programming /-------\ / | P.O. Box 5027 / | ||O | Chico, California 95927-5025 U.S.A. * ||,---|| | ~~ ~~ | Internet: madams@cscihp.ecst.csuchico.edu No BULL bandwidth |
jbvb@FTP.COM ("James B. Van Bokkelen") (06/20/91)
Sounds like what you really want is something like rexecd, since
all you want to do is fire off a make. rexecd would be much simpler
to implement than a telnetd.
There is a freeware (copyrighted) REXECD (written for our PC/TCP Dev Kit
libraries) in source form on vax.ftp.com
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901rcstack@rwa.urc.tue.nl (Harry Stox) (06/20/91)
In article <1991Jun19.204430.48165@cc.usu.edu> jrd@cc.usu.edu (Joe R. Doupnik) writes: > Hmmm. I wonder if folks know what they are asking for with a PC/DOS >based telnet daemon. Let's see. To remove all opinion I suggest a simple test. >Plug a terminal (remember those things?) in to the serial port of a PC and >tell DOS CTTY COM1. That's as good as Telnet is every going to be, usually >Telnet is only 7-bits wide. Ok, now run some nice application and see how >far that terminal can go (an inch or two). Why? Because the DOS application >is not written to run via stdin/stdout, no way, but that's all one gets with >Telnet. Or: Let's look at DOORway, which does the very same thing as Carboncopy (at least for text screens) and enables you to use a VT100 at the other end. It works like charm, so incorporating such a scheme into a telnet server for DOS wouldn't be such a bad idea after all. -Harry -- ============================================================================= Email: Internet: rcstack@urc.tue.nl Bitnet: rcstack1@heitue5 Computer Association STACK, Computing Centre RC 1.82, Eindhoven University of Technology, POBox 513, 5600 MB Eindhoven, Holland.
JENIK%CSPUNI12@PUCC.PRINCETON.EDU (honza kostal) (06/22/91)
On Wed, 19 Jun 91 18:56:45 GMT <pcip-request@UDEL.EDU> said: >I would like a telnet deamon too, this will allow me to run program on the pc > from >a remote site. If this can also be combined with a program like CarbonCopy One way to run a program on remote pc i in use DOORWAY. This is program whitch run your required program as chield, and scaning screen and keyboard. All changes on screen and keystrokes are send to local pc. On local pc use TELIX communication program in doorway mode (press ALT =). In this way running programs whitch writing directly to videoram, yuo can use Fkeys etc... DOORWAY and TELIX are availiable from simtel, directory TELIX (of course!) and BBS (or BBSDOORS ?). TELIX workinf only throught serial port, DOORWAY use FOSSILL driver (int14 replacement). Honza Kostal, JENIK @ CSPUNI12 . BITNET, 2:420/12.0 @ FIDONET.
steve@JOHNSON.JVNC.NET ("Steven L. Johnson") (06/22/91)
"Joe R. Doupnik" <swrinde!sdd.hp.com!caen!hellgate.utah.edu!cc.usu.edu!jrd@ucsd.edu> writes in article <1991Jun19.204430.48165@cc.usu.edu> ------------------------------ [stuff deleted] > Carbon Copy, PC Anywhere, etc don't behave this way. They are DOS >market programs present to make money performing well. What they do is >trap the screen on one machine and repeat the changed contents on the other >and ditto the other way for keystrokes. All this is at the internal detail >level of the PC where programs expect to find things below the Bios. Special >encoding is needed to make sense of the streams going each way. They could >use IP as a transport provider but I doubt there is a market for it. > Try the test and see what I mean about stdin/stdout being insufficient. >Then, because it's a nice summer, how about writing a Carbon Copy clone with >IP as the packet mover? > Joe D. Right idea, but incorrect in one detail that may make the project somewhat easier. The detail: PC-Anywhere does not have to use special encoding to make sense of the stream. It can use the terminal protocols like VT-200, Wyse-60, or a user defined type (roll your own protocol!). Also it can direct this stream to the serial port, or INT 14 redirector, or IPX. The IPX protocol is proprietary, but could get the stream to a gateway PC (also a function of PCA) whose serial port could be connected to a Telnet terminal server. On the other hand given that PCA can but a defined terminal stream over a defined software interface (INT14), the software-only solution might only have to provide the INT14<->TCP/IP/TELNET link. It's my understanding that existing products like TNGLASS only generate outgoing telnet sessions from the PC. If it could accept an incoming telnet session as well (or modified to do so) then this could be a solution. If I'm correct, then it would not be necessary to clone PCA, and the fact that it could be driven by a simple VT-xxx over telnet stream might expand the usefulness to the point that it was worth the effort. Comments? -Steve
mcr@Sandelman.OCUnix.on.ca (Michael Richardson) (06/24/91)
In article <532@johnson.jvnc.net> steve@JOHNSON.JVNC.NET ("Steven L. Johnson") writes: >to a Telnet terminal server. On the other hand given that PCA can but >a defined terminal stream over a defined software interface (INT14), the >software-only solution might only have to provide the INT14<->TCP/IP/TELNET >link. It's my understanding that existing products like TNGLASS only >generate outgoing telnet sessions from the PC. If it could accept an >incoming telnet session as well (or modified to do so) then this could be >a solution. Waterloo TCP's TCPPORT allows incoming connections. -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so little time. HOME: mcr@sandelman.ocunix.on.ca Bell: (613) 237-5629 Small Ottawa nodes contact me about joining ocunix.on.ca!
erick@sunee.waterloo.edu (Erick Engelke) (06/24/91)
mcr@Sandelman.OCUnix.on.ca (Michael Richardson) writes: > steve@JOHNSON.JVNC.NET ("Steven L. Johnson") writes: >>to a Telnet terminal server. On the other hand given that PCA can but >>a defined terminal stream over a defined software interface (INT14), the >>software-only solution might only have to provide the INT14<->TCP/IP/TELNET > > Waterloo TCP's TCPPORT allows incoming connections. > When I first wrote TCPPORT, I supported incomming connections. Of course I hadn't gotten around to adding TELNET options at that point. Not the options you pick, the options the computers negotiate. I think you would have to make a new version of the program to correctly handle those options. I think my TELNETD program reduces dependancy on PCA and supporting it though that grotesque int 14 interface. Erick -- ---------------------------------------------------------------------------- Erick Engelke Watstar Computer Networks Network Developer University of Waterloo Erick@Development.Watstar.UWaterloo.ca (519) 885-1211 Ext. 2965