Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!hellgate.utah.edu!cc.usu.edu!jrd From: jrd@cc.usu.edu (Joe R. Doupnik) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: TELNET daemon for MS-DOS anyone? Message-ID: <1991Jun19.204430.48165@cc.usu.edu> Date: 20 Jun 91 02:44:29 GMT References: Newsgroups: <9106191238.AA20987@ftp.com> Organization: Utah State University Lines: 37 In article , 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 >>}} 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.