OS/2 Shareware BBS: 2 BBS/02-BBS.zip/tdb005m.zip/status.doc

Text File | 1995-07-10 | 4KB | 89 lines

 The current feature list of Telnet Door as of version 0.05m WIDE BETA is:

Now has options to run without any local display or by displaying all text
except for BEL characters (^G) and nasty ANSI sequences.

Binary mode supported (send and receive).

Sysop can take over from the user.

Uses IBM's TCP/IP system.

Can be operated as a simple telnet program (if you don't like IBM's telnet).

Supports logging all output to a file.

Multi-threaded and uses no polling.

32 bit.

Uses practically no CPU time, it should run 8 high speed lines on a 386 easily.

Supports running a debug file which can be used to give me information on
errors that occur on your system and of features in TELNET daemons on remote
systems which aren't yet supported by my program.

Can be run from a DOS BBS.  If you are running DOS BBS software under OS/2 it
should now be possible to call an OS/2 batch file from the DOS session to run
my Telnet Door and use it to connect to the Internet.  This is not a usage of
my program that I can provide any great level of support for, but I have added
some features to make it easier to do (some BBSs were already running in this
way so I just made it easier for them).



  Current bug list is:

    Some of the enhanced VT100 terminal settings don't work in local mode, due
to differences between OS/2's ANSI terminal and VT100.  Everything works fine
for the remote end as long as they have a VT100 terminal.  Some of these
sequences will be filtered out from display if you use the O=Q option.
   This problem means that OS/2 Warp will interpret some of the commands send
out by the latest Linux distribution to mean that the screen size is to be
changed.  So it will put the window into 40x25 mode.  A simple work-around for
BBS usage (assuming you don't want to just turn the console off) is to have
the batch file/REXX program which calls TELDOR do a "mode CO80" after running
TELDOR, this is for cases where the O=Q option doesn't work adequately.

   Telnet Door automatically sets the terminal type to VT-100 if the
DORINFO1.DEF specifies ANSI graphics.  This is the only teminal type that is
currently supported.  However it does use all binary transmission so after
telnetting in to the remote system you will be able to change the terminal
type appropriately (IE the initial login prompt may not be displayed properly,
but after logging in you can use the TERM environment variable and "stty" to
change things after that).  Most host systems seem to ignore the fact that
Telnet Door tells them the terminal type anyway.

   My Linux system defaults to the "stty" setting "-opost" which means that it
sends bare line-feeds without carriage return characters when I login to it.
So after logging in it is necessary to run "stty opost" to correct this.  If
you are the system administrator of the system you are using my program to
login to then making "stty opost" the first line of your "/etc/profile" file
should solve this (it worked for me).
   A user of my program named Trevor Lampre devised a patch for the in.telnetd
from Linux to make "opost" the default characteristic.  I will mail it to you
on request.



      Planned features are:

Sysop chat mode.

  To write my own emulating library for VT100/VT200.
  Directly support VT100/VT200 terminal emulations in all ways.
  Supporting function keys via doorway mode.

   The above 3 features will all be implemented when I implement termcap
settings for terminal types.

Using TELNET controls for environment settings and all terminal settings.



    Future plans that won't necessarily be part of the base package:

   I have written an OS/2 terminal server and it will be going in to beta in
the near future.  Contact me now if you are interested in a Terminal Server for
OS/2.