Columbia Kermit/kermit.zip/e/v14.5

Internet Message Format | 2020-01-01 | 34KB

From cmg  Mon Sep 16 16:32:45 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA20318; Mon, 16 Sep 91 16:32:45 EDT
Date: Mon, 16 Sep 91 16:32:44 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #5
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 16 Sep 1991        Volume 14 : Number 5

Today's Topics:

               MS-DOS Kermit 3.11 is Released!
         New Second Edition of "Using MS-DOS Kermit"
        Kermit, TCP/IP, Packet Drivers, and the Future
           Adding TCP/IP Features to MS-DOS Kermit

Digest submissions may be sent to [e-mail] or
[e-mail].  Requests for addition to or deletion from the
Info-Kermit subscriber list should be sent to [e-mail] or
[e-mail].  These messages must be of the form:

  SUBSCRIBE I-KERMIT <your-personal-name>    (To start a subscription)
  UNSUBSCRIBE I-KERMIT                       (To cancel a subscription)
  REGISTER I-KERMIT <your-personal-name>     (To correct your name)

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  All files in these
directories should be transferred in text (ASCII) mode.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/aanetw.hlp (AANETW.HLP on KERMSRV).  To order by mail, request a
complete list of Kermit versions and an order form from Kermit Distribution,
Columbia University Center for Computing Activities, 612 West 115th Street,
New York, NY 10025 USA.

----------------------------------------------------------------------

Date: Mon, 16 Sep 1991 14:00:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.11 is Released!
Keywords: MS-DOS Kermit 3.11, TCP/IP, MCGA, Dialing Directory, Windows 3.0

This is to announce the final release of MS-DOS Kermit 3.11 from Professor
Joe R. Doupnik of Utah State University, and a new Second Edition of the
documentation, "Using MS-DOS Kermit" (see message below).

The major new feature of version 3.11 is its built-in support for
TCP/IP networking, adapted from parts of the Waterloo TCP package from Erick
Engelke of Waterloo University in Ontario.

Also included are script language improvements that allow for a much
improved DIAL command that can use a plain text file as a dialing directory,
and VT220 emulation to fill the gap between VT102 and VT320.  And finally, a
last-minute, down-to-the-wire improvement: support for high-resolution
Tektronix graphics on the PS/2 Model 25 and 30 MCGA video adapter.  Give the
command SET TERMINAL GRAPHICS VGA to use it (otherwise Kermit thinks the
MCGA is a CGA, and uses low-resolution graphics).

TCP/IP NETWORKING

Why add TCP/IP to Kermit?  Many people use both network and serial
connections, and until now had to switch between a Telnet program (which
doesn't support serial connections) and Kermit (which didn't support Telnet
connections).  For file transfer, the TCP/IP FTP protocol, while fast, does
not support many of Kermit's advanced features.  Kermit offers you features
not found in Telnet and FTP: a script programming language, flexible key
mapping, macros, international character set translation, and VT320
and Tektronix 401x terminal emulation.  Perhaps most important of all, now
you have a single application program and a common user interface for both
serial and network communication.

Kermit's TCP/IP and TELNET implementation takes up only about 30K of
additional program space.  It runs only over Ethernet-style packet drivers
(see Joe's article below) available from your network board vendor, or via
anonymous FTP from Clarkson University, host sun.soe.clarkson.edu
[128.153.12.3], cd pub/ka9q, use "type binary", get the appropriate zip, arc,
zoo, etc, files, use PKUNZIP, PKXARC, or ZOO on your PC to unpack them, read
the files READ.ME, MANIFEST.DOC, and INSTALL.DOC, and take it from there.
Copies are also available on watsun.cc.columbia.edu in kermit/packet-drivers
(source and documentation) and kermit/packet-drivers-bin (PC binaries).

Kermit supports downloading of its network parameters from BOOTP and RARP
servers, making it possible for all users of a corporate or campus network to
have the same initialization file -- a big plus for network managers.  Keep
your network information in a central database, rather than spread around on
scattered PC hard disks and diskettes!

Kermit's TELNET implementation automatically negotiates TELNET protocol
parameters such as local echoing, so connecting to a linemode TELNET server
(such as found on an IBM mainframe) works automatically.  However, Kermit
does not include built-in 3270 terminal emulation, so it is not (yet) a
replacement for tn3270.  But, it can be used with reverse telnet terminal
servers connected to IBM 7171 or other 3270 protocol converters.

Contrary to expectations, Kermit *can* make TCP/IP connections from within a
Microsoft Windows 3.0 Enhanced Mode window.  Kermit does not support multiple
simultaneous TCP/IP sessions, and the fact that you can run it under Windows
is not, unfortunately, an escape clause to this rule.  The packet driver only
allows one one application per protocol; this also means, for example, you
can't use Kermit and (say) NCSA telnet at the same time for TCP/IP
connections.  However, you can still have multiple copies of Kermit running,
as long as each one is using a different communication method, or a different
serial port.

Read the new help and beware files for more information about TCP/IP.

DIALING DIRECTORY AND MODEM SUPPORT

Kermit's new dialing directory is an ordinary plain-text file that Kermit's
DIAL macro searches using Kermit's new OPEN, READ, and CLOSE commands.  To
take advantage of this new feature, make sure you get a copy of the new
sample initialization file, MSKERMIT.INI, as well as the Hayes modem dialing
script program, MSIHAY.SCR (which you must rename to HAYES.SCR).  A sample
dialing directory is available as MSIDIA.TXT (which you must rename to
DIALUPS.TXT).

Kermit can also manage other types of modems besides Hayes.  Two steps are
necessary: (1) change the definition of the "_modem" variable in
MSKERMIT.INI, and (2) write a dialing script program for your modem, to
substitute for HAYES.SCR.  An example is provided for the IBM/Siemens/Rolm
CBX data phone (ROLMphone) in the file MSIROLM.SCR (which you should rename
to ROLM.SCR).  Readers are encouraged to develop scripts for other kinds of
modems and dialing methods, following the conventions used in HAYES.SCR and
ROLM.SCR, and send them in to us for distribution.

NEW FILES:

Internet anonymous ftp    EARN/BITNET
watsun.cc.columbia.edu    KERMSRV@CUVMA   Description

  GENERAL FILES

 kermit/a/mskerm.hlp       MSKERM HLP      Help file (plain text)
 kermit/a/mskerm.bwr       MSKERM BWR      "Beware File" (bugs & limitations)
 kermit/a/mskermit.ini     MSKERMIT INI    Sample initialization file
 kermit/a/mskermit.pch     MSKERMIT PCH    Sample patch file
 kermit/a/msidia.txt       MSIDIA TXT      Sample dialing directory file
 kermit/a/msihay.scr       MSIHAY SCR      Hayes modem dialing script
 kermit/a/msirolm.scr      MSIROLM SCR     ROLMphone dialing script

  EXECUTABLES

 kermit/bin/msvibm.exe     (none)          Executable Kermit program for IBM PC
 kermit/bin/msvibm.pif     (none)          Microsoft Windows 3.0 PIF file
 kermit/a/msvibm.boo       MSVIBM BOO      BOO-encoded .EXE file for IBM PC
 kermit/bin/msvgen.exe     (none)          Generic MS-DOS exectable
 kermit/a/msvgen.boo       MSVGEN BOO      BOO-encoded .EXE for generic DOS

  SOURCE FILES

 kermit/a/ms*.asm, ms*.h   MS* ASM, MS* H   Microsoft assembler source files
 kermit/a/msn*.*           MSN* *           C-language network source files
 kermit/a/msv*.lnk         MSV* LNK         Linker command files
 kermit/a/msv*.mak         MSV* MAK         Makefiles for "make"

All MS-DOS 3.11 IBM PC Kermit files have been removed from the test
directories, kermit/test/ms*.* on watsun and T:MS* * on KERMSRV.

The ".boo" files for each version are .EXE files encoded in a printable
ASCII format, suitable for BITNET, e-mail, and other nontransparent modes of
transmission.  You can decode the boo-files back into .EXE files using any
of the MSBPCT.* programs available in kermit/a/msbpct.* or MSBPCT * from
KERMSRV.  See msbaaa.hlp for details.

For a detailed description of the MS-DOS Kermit file naming conventions, see
the file msaaaa.hlp (MSAAAA HLP).  The MS-DOS Kermit implementations for
non-IBM compatibles (except the generic DOS version) have not yet been
upgraded to 3.11 level -- volunteers?

Once again, thanks to Joe for his skill, generosity, patience, dedication,
perserverence, and endurance (we're running out of adjectives for Joe!) in
putting this new MS-DOS Kermit version together and sharing it with us.  And
thanks to the beta testers who sent in such prompt and detailed reports of
problems so Joe could fix most of them so quickly!

------------------------------

Date: Mon, 16 Sep 1991 13:00:00 EDT
>From: Frank da Cruz <[e-mail]>
Subject: New Second Edition of "Using MS-DOS Kermit"
Keywords: MS-DOS Kermit 3.11, Using MS-DOS Kermit

MS-DOS Kermit 3.11 is accompanied by a brand-new revised and expanded Second
edition of Christine Gianone's book, "Using MS-DOS Kermit", Digital Press,
Bedford, MA, USA (1991), order number EY-H893E-DP, Digital Press ISBN
1-55558-082-3, Prentice Hall ISBN 0-13-952276-X.  The book includes a
5.25-inch 360KB MS-DOS Kermit 3.11 diskette.  The US single-copy price is
$34.95, up $5.00 from the first edition (not bad for 100 extra pages and 6
months work).  To order, call (USA, toll free) 1-800-343-8321.  It is also
available from Kermit Distribution at Columbia University and in software
stores and computer bookstores (where you'll recognize it easily by its new
purple cover).

A German language edition, "MS-DOS Kermit -- das universelle
Kommunikationsprogramm, Einfuehrung und Referenz", is published by Verlag
Heinz Heise GmbH & Co KG, Hannover, Germany, ISBN 3-88229-006-4, translated
by Gisbert W. Selke (proprietor of the Old Curiosity Shop from Info-Kermit
V14 #4), 5.25-inch 360KB diskette included, with many of the text files
translated into German, price 69 DM.

The new edition describes all the new features of version 3.11, including
everything that was added in versions 3.01, 3.02, and 3.10.  It has a new
chapter on local area networks (including TCP/IP); a new appendix with a
complete technical description of Kermit's terminal emulator with tables of
all the escape sequences recognized and sent by Kermit in both text and
graphics mode; expanded descriptions of many of Kermit's features, including
printer control and the script programming language, including the new
dialing directory features; an improved index.  There are also new
instructions for running Kermit under Windows and DesqView, for using LK250
keyboards, and there are many new tables, including one for Cyrillic
character sets.  The new book remains an excellent introduction (Einfuehrung)
for the novice, and it is now an even more complete reference (Referenz) for
the expert.

The first edition of "Using MS-DOS Kermit" was received with unanimous
approval by the critics.  Some samples from the book reviews:

"...one of the finest user guides, commercial, shareware, or otherwise, that
this reviewer has had the pleasure of reading."
  - Tom Nichol, Link-Up, July/August 1990 (p.8)

"An excellent introduction to computer communications, [Using MS-DOS Kermit]
explains in simple but intelligent language how to set up and get going."
"Must-read for PC buffs..."
  - Anne M. Russell, Working Woman, September 1990 (p.94)

"While the book is aimed at nontechnical readers, I highly recommend it to
all technical personnel in the computing field, particularly those who
abhore software manuals."
  - William Oblitey, ACM Computing Reviews, V32 #6, June 1991, pp.283-284

Both the English and German versions of the Second Edition should be
available in late September or early October.  Every copy sold helps support
the Kermit development and distribution effort, so don't be shy!

------------------------------

Date: Mon, 9 Sep 1991 20:38 MDT
>From: Joe Doupnik <[e-mail]>
Subject: Kermit, TCP/IP, Packet Drivers, and the Future

Release 3.11 of MS-DOS Kermit for IBM-PCs and compatibles opens a new
communications channel for Kermit: many hundreds of thousands of machines
around the world attached to the cooperative Internet network.  The lingua
franca of that channel is the TCP/IP protocol suite, including the Telnet
interactive protocol.  This is networking with a capital "N".

We have received many requests for Kermit to "talk over the Ethernet" to
other machines.  The impression held by those unfamiliar with the mysterious
art of communications is that one simply puts individual bytes on the
Ethernet much as we do with ordinary RS232-C wires.  Alas, the opposite is
true so it might be worthwhile reading the few paragraphs on this technical
matter.  Even if you know the Packet Driver story from my Novell activities
skim it for a repeat performance now underway with PD + NDIS + ODI.  After
that I'll mention some items about how Kermit handles Telnet.

Ethernet, Token Ring, and similar network transport systems are party lines
carrying traffic for many machines and using many different protocols.  To
keep the traffic flowing to the right places without ambiguity, the data --
our information -- is wrapped in administrative red tape with From: and To:
addresses and much more.  These ensembles are called packets or frames, and
their rules of construction and manipulation are aptly named protocols, not
unlike the Kermit protocol itself.

IP is one protocol, TCP is a higher-level protocol that uses IP as a shipping
agent.  Novell has the SPX and (shipping agent) IPX protocols, and so on.
Fortunately each of these can share the communications wire, time-sharing the
party line, with the others because they obey the same rules for primitive
addressing in the outermost wrapping of the packet or frame.  That's about
all they have in common: they drive on the same side of the road and they
recognize traffic lights.

The Internet is a massive voluntary interconnection of machines around the
world.  So not only do we have local addressing to do, but we have to be able
to send and receive packets through gateways to distant lands.  Interestingly,
with TCP/IP we, as people, typically use the names of the machines, but on
the wire only a numerical identification is employed.  So behind the scenes
name server machines have to quietly tell our program the number of the host
whenever we use the name.  We say NETLAB.USU.EDU but on the wire this machine
is known as 129.123.1.11, a 32-bit quantity.  As you might imagine, each
protocol has its own distinct rules about names and numbers, as if the other
protocols did not exist.  More alchemy.

What we see so far is that sending data bytes over Ethernet involves a lot of
busy work preparing packets in just the right format, with the address of
both sender and receiver and other vital administrative detail.  The wire can
carry a large variety of these packets.  This means each machine hears all
the packets, the network adapter board filters out all but those addressed to
the itself (and the broadcasts), and the machine must have code to pick out
the packets it wants and to wrap/unwrap (encode/decode) the interior shipping
instructions particular to the protocol it understands.  Serial RS232-C links
avoid all of this because there is only one machine at each end.

This brings us to a very local problem to be solved.  Our PC might wish to
use several protocols simultaneously.  For example, a NetWare (or StarGROUP
or PATHWORKS) file server is used to provide file service and we also want to
use TCP/IP Telnet to log onto a remote machine in Logan, Utah (Logan is
always "remote", no matter how close to it one may be).  That means both IPX
and IP need to share the Ethernet (or Token Ring, etc) communications board,
or we will need a board per protocol.  Thus the problem is: what hardware or
software will we need to use two or more protocols simultaneously?

Until a couple of years ago the solution to the problem was to purchase a
network adapter board for each protocol in each client machine.  Software of
one protocol attached to a board and knew how to converse with it (that's a
ticklish job known as being a device driver).  Pretty soon there were lots of
different boards, and one needed to buy software tailored for each one.  In
many cases, with only one board we had to reconfigure and reboot one's PC in
order to switch among different networking applications.

FTP Software Inc. of Wakefield, MA, USA, a vendor of PC-based TCP/IP
programs, soon went bananas trying to write drivers for each new Ethernet
board on the market.     They wisely decided that what was needed was a small
piece of code, called a Packet Driver, which did all the board-specific
functions yet provided a standardized interface (a virtual board) to the
application software.  They wrote the Packet Driver (PD) Specification, made
it public, and suggested that board makers write their own Packet Drivers so
that FTP Inc and other software houses could get on with their primary task
of creating useful communications programs (see John Romkey's recent article
in BYTE magazine).

More came of this than they may have realized.  Two aspects make Packet
Drivers very popular.  One is that the programs are tiny, only about 2.5KB,
and "relatively easy" to write.  Thus software vendors can provide a PD
interface as yet one more choice of board and save many tens of thousands of
dollars of development effort per product per year, per vendor.  That was
FTP's intention too: save internal resouces.  We benefit by lower software
production costs.

The second benefit is greater from the perspective of users (vs vendors).
That is, the PD specification permits several protocols to call upon it, the
owner of a single board, and each receives only the packets it wants.  The
requesting program thinks it owns a whole board.  So a user can run several
non-competing protocol stacks (networking software systems) at the same time,
each asking for different kinds of packets, yet using only one physical
network adapter.  For example, Kermit can send a file from a Novell file
server to a TCP/IP host, using a single Ethernet board.  Now we are getting
somewhere!

The demand for Packet Drivers became large quickly.  Individuals around the
world started writing them because board vendors were too slow.  Russel
Nelson, then at Clarkson University, established a clearing house for
user-written Packet Drivers and made them available at no charge.  Oh boy,
free and available now, available even across the network via anonymous FTP.
A personal observation is that the general public, or at least a broadly
based non-commercial group, is needed to make a standard take root and
prosper; individual companies have their own territory and traditions to
contend with.

In the interests of completeness I need to mention two roughly similar
systems that arose after Packet Drivers.  The first is NDIS, Network Driver
Interface Specification, by 3Com and Microsoft.  NDIS performs the same
functions as a Packet Driver, and a few more.  NDIS programs are entirely
commercial endeavors at present and all are much much larger than Packet
Drivers.  The most recent addition to the business is Novell's Open Datalink
Interface, ODI, also commercial presently and sized between PDs and NDIS.
ODI includes more features that the other two.  NDIS is used by Lan Manager
systems (DEC PATHWORKS, AT&T StarGROUP, 3Com 3+Open, and others); ODI is used
only by Novell NetWare at this time.  It appears that all three will live
side by side for some time to come.  But what about this side by side stuff;
didn't we just solve that for the network adapter case?

Now a new question arises: Can I run TCP/IP with a Packet Driver interface for
the program (say Kermit) together with AT&T StarGROUP together with NetWare?
Golly, will demands ever end?  The answer is: it can be done, easily!  FTP
Software, again, wrote a small program called DIS_PKT, and I expanded on their
effort with a program of the same name.  DIS_PKT sits on top of NDIS and
provides a Packet Driver interface for programs that want to communicate this
way, and it allows NDIS-style programs to use NDIS simultaneously.  Dan
Lanciani of Harvard has a preliminary program called ODIPKT that lets Novell's
ODI material sit on top of a Packet Driver, and Don Provan of Novell has
another named PDEther.  These little programs are given the trade name of
"shims", and for many of us they are worth their weight in gold (saved from
buying more LAN adapters, which if you recall, is where we came in).

Well, that was an educational diversion.  Back to TCP/IP in MS-DOS Kermit.
TCP/IP is a mature protocol with many many features.  Telnet is a protocol
sitting on top of TCP/IP which provides an error-checked terminal-like
communications pathway to a host.  The software to implement Telnet, and TCP,
and IP is complicated and normally fairly large.  Erick Engelke at the
University of Waterloo, Ontario, Canada, wrote a TCP/IP kernel which was
small enough to be considered for inclusion within Kermit itself, rather than
relying on programs such as NET14 and TNGLASS coupling to exterior TCP/IP
programs.  Much work later we accomplished the goal of embedding Telnet plus
TCP plus IP plus a good Packet Driver interface within Kermit, for an overall
cost of roughly 30KB increase of program size.  That's a bargain, folks.

Kermit includes procedures to talk with name servers to do that translation
of host names to numbers.  It has procedures for Kermit to learn its own
Internet address from servers of such things, via the BOOTP and RARP
protocols.  BOOTP can also supply name server addresses, a gateway address,
and so on.  Name resolution, etc, is all automatic from the user's
perspective, and based on the nuts and bolts discussion above it had better
be automatic!  The performance of built-in Telnet is much greater than the
alternative of coupling to an exterior TCP/IP program via BIOS Interrupt 14H,
and of course it is far faster than a serial RS232-C connection.

All connections require a communications program pay attention to the wire
very frequently.  LAN connections on Ethernet or Token Ring require even
closer than normal attention because packets arrive at incredible rates and
will jam up in the LAN adapter unless the communications program lends a
hand.  So Kermit has a small invisible background procedure to run the Telnet
code while Kermit itself sits at the command prompt or is sleeping while you
are shelled to DOS.  This reduces the clutter of fresh packets when Kermit is
not actively seeking them directly and it keeps the host happy.  By the way,
for the benefit of network managers, Kermit does not send only one data byte
in an individual IP network packet.  It gathers as many bytes as will fit
before a timer expires and exports few network packets.  A network monitor
shows Kermit file transfer activity to look much like FTP file transfers.  I
tried to make Kermit be nice to networks, and to their managers.

Another issue concerns running Kermit's Telnet path while in Windows 3.  The
technical problem is the Packet Driver calls on Kermit when each new packet
arrives, but Windows may move Kermit about in memory and thus the call goes
to the wrong spot (Uh-Oh time).  There is a simple solution.  Using the PIF
editor for a KERMIT.PIF file find the box labeled "Lock Application Memory"
in the Advanced Options section.  Check it.  That says don't move Kermit in
memory.  The nice consequence is Kermit is able to run in a window of
Enhanced Mode, and it will continue to run even when reduced to an icon.

Having Kermit use Telnet for local or long distance communication across
existing networks raises some interesting points.  The usual file transfer
program for TCP/IP work is FTP, File Transfer Protocol.  Those who use it
will tell you it is quick but not exactly smart nor user-friendly.  The
Kermit file transfer protocol is slower because it is designed for the worst
case situation of going from point A to B by many methods.  So FTP is faster
than Kermit-to-Kermit file transfers on a fast link.

But: Kermit can use many kinds of links whereas FTP can't, Kermit can
transfer the file time-and-date stamp, it can skip individual files or stop
the entire group of files when you wish during a big transfer, it can do
character-set to character-set transfers for international language
documents, it can rename files to avoid destroying originals, and so on.  The
process of moving information, not just raw bytes, is more advanced in Kermit
than in FTP.  In addition, Kermit is driven by user feedback and we respond
quickly.  FTP is not about to change much in the near future; what you have
now is what you will have several years from now.  Kermit's advanced features
are negotiated between any two Kermits so they always work even if one
program is five years older than the other, and runs on a vastly different
machine than the local PC.

It has been stated many times that there is a Kermit implementation for
almost every kind of computer in this world; the size of the Columbia
University Kermit archive supports it.  These programs are written by
individuals, volunteers, on a not-for-profit basis (costs usually are born by
them too).  New features appear at the rate which we, the volunteers, can
create them; the Kermit Project at Columbia exercises overall control so
matters remain coherent across Kermit software programs.

The popularity of Kermits, their responsiveness to the "marketplace" (i.e.,
the users), and their ability to work together between almost any pair of
machines makes Kermit an good vehicle for advancing the state of the art of
information exchange across communications channels.  Kermit is not wedded to
one communications method or protocol; it uses serial ports and MS-DOS Kermit
uses most of the commercially available networking channels.

However, adding new features costs: in time, money, and energy of talented
and experienced writers.  Each major addition, say adding 3270 emulation or
advanced Tektronix graphics support to MS-DOS Kermit, becomes a significant
project lasting months to years.  We are accomplishing with few people (who
by the way have regular full time jobs and careers other than Kermit) what
commercial software houses do with larger full-time paid staffs.  Thus major
advances need the support of the entire community, particularly from
commercial and government enterprises that benefit so heavily by not having
to pay hundreds of dollars per program per copy per year for connectivity.
Some companies have been very helpful by providing boards, software, or
complete operating environments.  Those contributions are much appreciated
and needed.  A firmer long-term basis is required so we can plan and
implement the strategically meaningful advances.

Kermit software has saved the corporate, government, and academic sectors
countless millions of dollars in its first ten years of existence.  As the
sophistication and demands of computer users grow, so too does the complexity
of the programming task.  If Kermit is to continue fill your needs and save
you money over the next ten years, let's hope some of the well-endowed
corporations and agencies that have done so well by our efforts will think
about supporting them in the future.

Additional features that many of you are requesting -- more ASCII terminal
emulations, multiple host sessions, 3270 emulation, ReGIS graphics, Tektronix
41xx and 42xx graphics, full integration with Windows 3.0, a fancy
menu-driven user interface with internationalized locales, etc -- each of
these is a massive project requiring additional dedicated programming staff
if these features are to be available in a timely fashion.  I ask for your
understanding when I say that these can't be provided in one or two releases.
The existance of strong requests is our reward that we are doing a good job
as you see it.

------------------------------

Date: Mon, 09 Sep 1991 18:18:46 EDT
>From: Erick Engelke <[e-mail]>
Subject: Adding TCP/IP Features to MS-DOS Kermit

Connectivity has come to mean much more than the RS-232 wires and modems
that webbed our offices in recent years.  Today's networks are connected
using a plethora of incompatible networking hardware, systems software and
hardware platforms.  But under the TCP/IP family of Internet protocols, all
these barriers melt away.  The newest version of MS-DOS Kermit is capable of
dealing with these intelligent, high-performance networks just as easily
as it has worked over other communication media for years.

The Waterloo TCP (WATTCP) code was developed at the University of Waterloo to
simplify creation or adaptation of TCP/IP-based utilities.  It uses a simple
and well defined application programmer's interface (API) based on a loose
adaptation of BSD networking functions.  The TCP portions actually execute
off the application program's stack.  This unusual practice simplifies
development and testing by allowing the application and the network functions
to all coexist in the same task.

One of the first applications written to demonstrate the capabilities of
WATTCP was a little program called TCPPORT which let Kermit or most other
communications programs be used as a TELNET client.  Although it seemed to be
merely an academic achievement and totalled less than 100 lines of 'C' code,
I started getting a growing quantity of mail from the masses who needed the
capabilities of MS-DOS Kermit in a TELNET package.  The most common reasons
cited were Kermit's international character support, its unmatched emulation
capabilities, and Kermit file transfers to machines not supporting FTP.

Within days I received a brief message from Frank da Cruz (C-Kermit author)
who had found the program and tried it with relative success.  To anyone
foolish enough to actually implement a TELNET client, there are hundreds of
documents (RFCs) which are required reading and nearly one hundred of them are
pertinent specifically to TELNET.  After much reading you must start the
eternal process of testing your version with everyone else's implementation.
One of the known problems TCPPORT had was the ability to crash some VMS
systems running poor but common TCP/IP implementations.  Frank's experience
from C-Kermit quickly resolved these and other problems.

By this time, Joe (author of MS-DOS Kermit) and Christine Gianone (Important
Kermit Person) had entered into our mail conversations and we started
discussing how we might incorporate the functionality of TCPPORT right into
MS-DOS Kermit.  MS-DOS Kermit had always packed an enormous number of
features into a pretty small package, but we felt we could add TELNET
capabilities without increasing the executable by more than thirty kilobytes.
This was a small cost for the enormous benefits.  It also a hard promise to
keep - we had overlooked some hidden data areas.

As soon as he had time, Joe dove right into the project and scrutized every
line of my code.  Since I had only started the WATTCP project about seven
months earlier, there were a number of areas which had not been fully tested
or which were incomplete.  During the Kermit-ization process, I mostly gave
advice and concentrated on the TCP core section while Joe did an amazing
amount of work in adapting and occasionally rewriting my efforts to fit his
needs.  He also acted coordinator, so we did not have to remember what
everyone else was doing.

Some of the features of my original code were of little use to MS-DOS Kermit,
so it became sort of a WATTCP-Lite, actually consuming less than twenty-five
kilobytes of the final Kermit executable.  Despite the occasional
simplification, we kept the API identical to the documented WATTCP API,
allowing us to keep our efforts coordinated for future revisions.

The process of perfecting the TELNET features was greatly simplified by the
Internet itself.  Whenver we were told of problems TELNETting to a particular
computer, we could KERMIT/TELNET there ourselves and solve the problems
without additional help.  In fact, we used Kermit to transfer updates to each
other.  This also allowed us to tune the long-distance capabilities which are
essential to a TELNET program.

The final product has the benefit of Frank, Christine, obviously Joe, and the
many volunteers whose efforts were too numerous to list.  This distributed
group of people has once again brought MS-DOS Kermit to the leading edge by
adding to its description: an excellent TELNET program.

Erick Engelke
WATTCP Architect
Faculty of Engineering
University of Waterloo
Waterloo, Canada

------------------------------

End of Info-Kermit Digest
*************************