Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!FTP.COM!jbvb From: jbvb@FTP.COM ("James B. Van Bokkelen") Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: Sources for Telnet/FTP Servers for DOS and OS/2 Message-ID: <9104161246.AA04464@ftp.com> Date: 16 Apr 91 12:46:38 GMT Sender: rwh@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 28 ...I never have understood the network vendors reluctance to provide a full suite of TCP/IP software for PCs under DOS. For every client application there should be a server application.... What you think is reluctance is actually inability. Unless you have a 386 processor, it is simply impossible to build something that can trap every possible way an application might write to the PC's screen or read from the keyboard, so that *all* applications can be run from the Telnet server. The two extant academic efforts will probably work with 60-70% of available DOS applications. With a lot of work, and a long learning curve, you could probably get that up to 85-90%, but I have no interest in shipping something that might be returned as unusable by 1 customer in 10. A second problem is the Telnet Network Virtual Terminal model, which doesn't map cleanly to the PC's directly addressable display memory and keyboard hardware. If the application displays a bright violet on green smiley-face, or goes into graphics mode on your EGA, what do you tell the real or simulated VT100 on the other end to print? What does the user have to type when the application is looking for Alt-LeftShift? Carbon Copy and PC/Anywhere have their own proprietary datastream, designed to handle the PC's capabilities,, and the job is simpler because both client and server are PCs. If you want to do a good mapping with public protocols, you're probably going to wind up with X... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901