Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!bingvaxu!leah!emb978 From: emb978@leah.Albany.Edu ( Eric M. Boehm) Newsgroups: comp.sys.ibm.pc Subject: Re: Request for Kermit 2.30. Summary: Docs for Kermit-MS 2.30, Part 1 of 6, exe to follow Message-ID: <574@leah.Albany.Edu> Date: 23 Jan 88 21:46:52 GMT References: <20064@amdcad.AMD.COM> Organization: The University at Albany, Computer Services Center Lines: 1005 Here are the docs for Kermit-MS 2.30, part 1 of 6, exe to follow. Eric M.Boehm EMB978@Leah.Albany.Edu EMB978@ALBNY1VX.BITNET ------------------------------------------------------------------------------- MS-DOS KERMIT USER GUIDE FOR THE IBM PC FAMILY, COMPATIBLES, AND OTHER MS-DOS SYSTEMS C. Gianone, F. da Cruz Columbia University Center for Computing Activities New York, NY 10027, USA J.R. Doupnik CASS and EE, Utah State University Logan, UT 84322, USA January 14, 1988 Copyright (C) 1981,1988 Trustees of Columbia University in the City of New York Permission is granted to any individual or institution to use, copy, or redistribute this document so long as it is not sold for profit, and provided this copyright notice is retained. 1. MS-DOS KERMIT -------- This document is formatted as an ordinary, plain text ASCII disk file, from SCRIBE text formatter source. Typeset copies are available from Columbia University. -------- Program: Joe R. Doupnik (Utah State University), with contributions by James Harvey (Indiana/Purdue University), James Sturdevant (A.C. Nielson Company), and many others (see History). Language: Microsoft Macro Assembler (MASM) Version: 2.30 Released: January 8, 1988 Documentation: Christine Gianone, Frank da Cruz (Columbia University), Joe R. Doupnik (Utah State University) Dedicated To: Peppi Kermit-MS Capabilities At A Glance: Local operation: Yes Remote operation: Yes Transfers text files: Yes Transfers binary files: Yes Wildcard send: Yes File transfer interruption: Yes Filename collision avoidance: Yes Can time out: Yes 8th-bit prefixing: Yes Repeat count compression: Yes Alternate block check types: Yes Terminal emulation: VT102, H19, VT52, Tektronix 4010 Communication settings: Speed, Parity, Flow Control, Handshake, Echo Transmit BREAK: Yes (and Long BREAK) IBM mainframe communication: Yes Transaction logging: No Session logging (raw download): Yes Raw upload: Yes Act as server: Yes Talk to server: Yes Advanced server functions: Yes Advanced commands for servers: Yes Local file management: Yes Command/init files: Yes Command macros: Yes Extended-length packets: Yes Local area networks: Yes (NetBIOS support) MS-Windows compatibility: Yes Attribute packets: No Sliding windows: No MS-DOS Kermit, or "Kermit-MS" (or MS-Kermit), is a program that implements the Kermit file transfer protocol for the entire IBM PC family, including the PS/2 series, IBM compatibles, and several other machines based on the Intel 8086 processor series (8088, 80286, 80386, etc) and the DOS operating system family (PC-DOS or MS-DOS, henceforth referred to collectively as MS-DOS or simply DOS). It is assumed you are acquainted with your PC and with DOS, and that you are familiar with the general ideas of data communication and Kermit file transfer. A very brief overview is given here, but for details consult the early chapters of the Kermit User Guide (of which this document is a chapter), or the book Kermit, A File Transfer Protocol, by Frank da Cruz, Digital Press (1987), order number EY-6705E-DP (phone 1-800-343-8321), which also includes background tutorials on computers, file systems, and data communication (including modems, cabling, etc). For further information about Kermit documentation, updates, lists of current available versions, and ordering information, write to: Kermit Distribution Columbia University Center for Computing Activities 612 West 115th Street New York, NY 10025 (USA) 1.1. System Requirements Kermit-MS version 2.30 runs in as little as 70K of memory (about 55K contiguous), but will occupy up to 120K, if it can be found, for extra screen rollback memory. Versions not using screen rollback memory will not require the additional space. It will also try to leave 24 Kbytes free for a second copy of COMMAND.COM which is needed for execution of certain commands. On the IBM PC family, Kermit-MS 2.30 performs almost complete emulation of the DEC VT-102 and Heath/Zenith-19 terminals at speeds up to 19,200 baud or greater, lacking only the VT102's smooth scrolling and (on some display boards) 132 column features. And as of version 2.30, Kermit-MS also performs Tektronix 4010 graphics terminal emulation on IBM PC family systems equipped with CGA, EGA, and Hercules graphics adapters, with either color or monochrome monitors. Much of Kermit's speed is accomplished by direct writes to screen memory, but this is done in a "TopView-aware" manner to allow successful operation in win- dowing environments like MS-Windows, DesqView, and TopView itself. Speed is also due to direct access of the serial port 8250 UART (Universal Asynchronous Receiver/Transmitter) chip, with buffered, interrupt-driven receipt of charac- ters and selectable XON/XOFF flow control. Full speed 9600 baud operation is possible on 4.77Mhz systems without flow control, but flow control is required on these systems for 19,200 baud or higher rates. The IBM PC version should also run on near-clones like the DG/1 that differ from true PCs only in their choice of UART; non-8250 UARTs are detected automatically, and slower non-interrupt driven Bios serial port i/o is used, in which case the top speed is in the 1200 baud range. On the IBM PC family, COM1 and COM2 are supported, and "hooks" are available for (inevitably nonstandard) COM3 and COM4 options. Kermit-MS 2.30 runs on the entire IBM PC family (the PC, XT, AT, PCjr, Portable PC, PC Convertible, PS/2) and compatibles (Compaq, VAXmate, Z150, etc), and there are also specially tailored versions for non-IBM-compatibles like the DEC Rainbow, NEC APC, Sanyo MBC, Victor 9000, HP-110, HP-150, HP Portable Plus, and others, plus a "generic DOS" version that should run (slowly) on any 8086-based MS-DOS machine. This document concentrates on the IBM version; some of the system-dependent capabilities described here may be lacking in the non-IBM ver- sions. See section 1.9 for features of different systems. KERMIT.EXE for the IBM PC family occupies about 86K of disk storage (the figure will vary for other versions). This can be reduced by about 15K if you run it through EXEPACK. MS-Kermit is not distributed in packed form, because problems have been reported on certain systems when this is done. So if you decide to pack it, make sure to keep an unpacked version available to fall back to in case of problems. 1.2. History Over the years, MS-Kermit has grown from a Kermit file transfer program that embodied a simple terminal emulator into a complex and powerful communication program that includes the Kermit file transfer protocol. As a result, the bulk of this manual is devoted to the communication features, rather than Kermit protocol operation. Skip ahead to the next section if you're not interested in the history of MS-Kermit. MS-DOS Kermit (like the Kermit file transfer protocol itself) is a product of the Systems Group of the Columbia University Center for Computing Activities, and it was one of the four original Kermit programs (with the CP/M, DEC-20, and IBM mainframe versions). It was initially written for the IBM PC with DOS 1.1 by Daphne Tzoar in 1981-1982, based largely on Bill Catchings's original CP/M 8080 assembler version. PC-Kermit (as it was called then) provided basic Ker- mit file transfer and VT52 emulation. Joellen Windsor of the University of Arizona added conditional assembly support for the Heath/Zenith-100 shortly thereafter, and soon after that Dave King of Carnegie-Mellon University added Heath-19 terminal emulation, and some patches to let the program run under the new DOS version, 2.0. During this era, the program version numbers went from 1.0 to 1.20. With the appearance in the marketplace of many new MS-DOS machines that were not compatible with the IBM PC, it became apparent that conditionally assembled code supporting each of these machines within a single monolithic source file was not the best way to organize the program. Therefore Daphne, along with Jeff Damens of Columbia, undertook to reorganize the program in a modular way, isolating system dependencies into separate files. The result was version 2.26, released in July 1984. It included support for the DEC Rainbow, the HP-150, the Wang PC, and generic MS-DOS, as well as for the IBM PC family and the H/Z-100. It also included many new features, like 8th-bit prefixing (code contributed by The Source Telecomputing), alternate block check selection, byte-count compression, server/client operation, access to local file and DOS operations, command macros, initialization and command files, screen rollback, key redefinition, and more. For the 2.26 release, the executable Kermit programs were encoded printably as ".BOO" files, designed by Bill Catchings as part of this effort. Release 2.27 was produced by Daphne and Jeff in December 1984. Unlike 2.26, it ran correctly on the new PC/AT under DOS 3.0, and included support for the NEC APC from Ron Blanford of Seattle, WA, and Ian Gibbons of the University of Hawaii, and for the TI Professional from Joe Smith of the Colorado School of Mines, plus some bug fixes and reorganization. 2.27 is the last version that runs under pre-2.0 versions of DOS. Version 2.28 (Daphne, Jeff, June 1985) added dynamic memory allocation to reduce disk storage for the .EXE file, and to allow the program to adjust it- self to the PC's memory size, plus the inevitable bug fixes (many of them con- tributed by Edgar Butt of the University of Maryland and Gregg Small of the University of California at Berkeley). During this period, support for ad- ditional MS-DOS systems was added by various people. In December 1985, a tape showed up at Columbia sent by Prof. Joe R. Doupnik of the Center for Atmospheric and Space Studies and EE Department at Utah State University. This tape contained version 2.28 modified to fully support the DOS 2.0 file system, and to which many new features had been added, notably the ability of the MS-DOS Kermit server to process various REMOTE commands (DIR, CWD, SPACE, etc). And at about the same time, a tape arrived from James Harvey of Indiana/Purdue University, who had changed Kermit's CONNECT command to emu- late the popular DEC VT100 terminal. This material was sent to Joe, who then laboriously fitted James's work into his own code, keeping the VT52 and H19 emulation alive as options, and upgrading the VT100 emulation to VT102 by ad- ding features such as line and character insertion and deletion. The result was version 2.29, released in May 1986. Soon after the release of 2.29, some disks were sent in by James Sturdevant of the A.C. Nielson Company, containing a full implementation of the Kermit script facility, as described in the Kermit book. This material was sent to Joe, who had by now become keeper of MS-DOS Kermit and had already begun work on version 2.30 by adding support for extended-length packets. Joe had been carrying on voluminous network correspondence (Thanks, BITNET!) with Columbia and with MS-DOS Kermit users and testers all over the world, giving birth to many new features, including Tektronix graphics terminal emulation, support for opera- tion over local area networks, support for 8-bit ASCII terminal connections and international character sets, ANSI printer control, and a redesigned, more powerful, more portable key redefinition mechanism. Version 2.30 was formally released on January 1, 1988, after many "alpha" and "beta" tests. Among the many contributors to this version are: Brian Holley and Joe Smith for the Tektronix emulation, Robert Goeke for the NEC AP3 support, Brian Peterson and Andreas Stumpf for the Victor 9000, Bob Babcock and Joe White for the Sanyos, Christopher Lent for the Wang PC, Jack Bryans for an Intel iRMX ver- sion, Jim Noble for the Grid Compass, Geoff Mulligan and others for the Zenith 100, and David Knoell for the special Rainbow edition. And thanks to Gisbert Selke, Jack Bryans, and others for proofreading drafts of this manual. And apologies to anyone we neglected to mention. Finally, please note that the program version number is not a whole number and a fraction; 2.30 is pronounced "two point thirty", and is not equal to 2.3. 1.3. Using MS-Kermit MS-DOS Kermit performs two major functions, terminal emulation and file trans- fer. File transfer can be done using either the Kermit file transfer protocol, or else (without error checking), ASCII or XON/XOFF capture and transmission methods. To use Kermit for "raw" uploading or downloading of files, see the descriptions of the LOG SESSION and TRANSMIT commands. Before you can transfer files with another system using Kermit protocol, you must first connect to it as a terminal, login if necessary, and start up a Ker- mit program there. The following example shows this process; the other com- puter is a Unix system, but the method is the same with most others. The parts you type are underlined (if this document was printed on a printer that can underline), and when you type a command, you terminate it with a carriage return, which you can't see in the example. The mysterious "^]c" is MS-Kermit's "escape sequence", which you enter by holding down the Control (Ctrl) key and pressing "]" (right square bracket), and then typing the letter C. The example assumes the MS-Kermit program is stored on disk as KERMIT.EXE. Program Dialog: Explanation: A>kermit IBM PC Kermit-MS V2.30 8 Jan 88 (program's greeing) Type ? for help Kermit-MS>set speed 1200 Set the right baud rate. Kermit-MS>connect Connect as a terminal. (Connecting to host, type ^]C to return to PC.) ATDT7654321 Dial the modem if necessary. CONNECT 1200 The modem tells you you're connected. Now you're talking to the Unix system. Type a carriage return to get its attention. Login: christin Login to the host. password: (Passwords normally don't echo.) % kermit Run Kermit on the host. C-Kermit>receive Tell it to receive a file. ^]c Escape back to the PC. Kermit-MS>send autoexec.bat Send a file. (The file is transferred...) Kermit-MS> Transfer complete, prompt reappears. In this example, the user types "kermit", and sees the program's herald and its prompt, "Kermit-MS>". Then she sets the appropriate communication speed ("baud rate"), connects as a terminal, issues a dialing command to a Hayes-like modem (you would skip this step if you had a direct connection), logs in to her ID on the Unix system which she has dialed, starts "C-Kermit" on the Unix system, tells it to receive a file, escapes back to the PC, and tells MS-Kermit to send a file. After the file is transferred, the user would normally connect back to the Unix system, exit from the Kermit program there, and log out: Kermit-MS>connect Connect again. (Connecting to host, type ^]C to return.) C-Kermit>exit % ^D Logout from Unix by typing Ctrl-D. ^]c Escape back to the PC. Kermit-MS>exit Return to DOS. To transfer a file in the other direction, simply exchange the "send" and "receive" commands above. That's the easiest and quickest way to use Kermit. If this simple scenario does not work for you, issue the MS-Kermit STATUS com- mand and look for any obvious incorrect settings (speed, parity), fix them with SET commands (described in Section 1.6.9), and try again. (IBM mainframe linemode connections have so many "different" settings, there's a special com- mand to do them all at once, "do ibm", which you would type as the first Kermit-MS command above.) If that doesn't help, read on. Many problems can crop up when you attempt to connect two unlike systems over a possibly hostile communication medium. And if you intend to be a frequent user of Kermit, there are many options you can take advantage of to adapt MS-Kermit to different sys- tems, improve its performance, and automate common tasks. 1.4. The MS-DOS File System The features of the MS-DOS file system of greatest interest to Kermit users are the form of the file specifications, and the formats of the files themselves. 1.4.1. File Specifications MS-DOS file specifications (in version 2.0 or later of DOS) are of the form DEVICE:\PATHNAME\NAME.TYPE where the DEVICE is a single character identifier (for instance, A for the first floppy disk, C for the first fixed disk, D for a RAM disk emulator) fol- lowed by a colon (":"), PATHNAME is up to 63 characters of identifier(s) (up to 8 characters each) surrounded by backslashes ("\"), NAME is an identifier of up to 8 characters, and TYPE is an identifier of up to 3 characters in length. Device and pathname may be omitted. The first backslash in the pathname may be omitted if the specified path is relative to the current directory. In the path field, "." means the current directory, ".." means the parent directory. Some DOS implementations (like Wang) may use slash ("/") rather than backslash as a directory separator. Pathname is normally omitted, but can be specified in all Kermit-MS commands (as of version 2.29). Device and directory pathnames, when omitted, default to either the user's current disk and directory, or to the current directory search path as specified in the DOS PATH environment variable, depending on the context in which the file name appears. When this document says that a file is searched for "in the current path," it means that Kermit-MS looks on the current disk and directory first, and if the file is not found, then the directories listed in the PATH environment variable are searched. If the PATH environment vari- able is empty, Kermit looks only at the current disk and directory. NAME.TYPE is sufficient to specify a file on the current disk and directory, and only this information is sent along by Kermit-MS with an outgoing file. The device, path, name, and type fields may contain uppercase letters, digits, and the special characters "-" (dash), "_" (underscore), "$" (dollar sign), "&" (ampersand), "#" (number sign), "@" (at sign), "!" (exclamation mark), "'" (single quote), "()" (parentheses), "{}" (curly braces), "^" (caret or circumflex), "~" (tilde), and "`" (accent grave). Normally, you should confine your filenames to letters and digits for maximum transportability to non-DOS systems. When you type lowercase letters in filenames, they are converted automatically to uppercase. There are no imbedded or trailing spaces. Other characters may not be included; there is no mechanism for "quoting" otherwise illegal characters in filenames. The fields of the file specification are set off from one another by the punctuation indicated above. The name field is the primary identifier for the file. The type, also called the extension or suffix, is an indicator which, by convention, tells what kind of file we have. For instance FOO.BAS is the source of a BASIC program named FOO; FOO.OBJ might be the relocatable object module produced by compiling FOO.BAS; FOO.EXE could be an executable program produced by loading FOO.OBJ, and so forth. .EXE and .COM are the normal suffixes for executable programs. MS-DOS allows a group of files to be specified in a single file specification by including the special "wildcard" characters, "*" and "?". A "*" matches any string of characters from the current position to the end of the field, includ- ing no characters at all; a "?" matches any single character. Here are some examples: *.BAS All files of type BAS (BASIC source files) in the current directory. FOO.* Files of all types with name FOO. F*.* All files whose names start with F. *.? All files whose types are exactly one character long, or have no type at all. Wildcard notation is used on many computer systems in similar ways, and it is the mechanism most commonly used to instruct Kermit to send a group of files. Users of Kermit-MS should bear in mind that other (non-MS-DOS) systems may use different wildcard characters. For instance VMS and the DEC-20 use "%" instead of "?" as the single character wildcard; when using Kermit-MS to request a wildcard file group from a Kermit-20 server, the DOS "?" must be replaced by the DEC-20 "%". 1.4.2. File Formats MS-DOS systems store files as streams of 8-bit bytes, with no particular dis- tinction among text, program code, and binary files. ASCII text files consist of lines separated by carriage-return-linefeed sequences (CRLFs), and this con- forms exactly to the way Kermit represents text files during transmission, so Kermit-MS has no need for a SET FILE TYPE BINARY command. But since a non- MS-DOS receiving system might need to make distinctions as to file type, you will probably have to issue SET FILE TYPE commands there if you are sending it non-text files. In transmitting files between Kermit-MS programs, regardless of file contents, the receiving MS-DOS system is equally capable of processing text, code, and data, and in fact requires no knowledge of how the bytes in the file are to be used. MS-DOS (unlike CP/M) knows the exact end of a file because it keeps a byte count in the directory, so one would expect no particular confusion in this regard. However, certain MS-DOS programs continue to use the CP/M convention of terminating a text file with a Control-Z character, and won't operate cor- rectly unless this terminating byte is present. Therefore, you should be aware of a special SET EOF option for both incoming and outbound files, described later. Non-MS-DOS systems may be confused by nonstandard ASCII files sent by Kermit-MS: - Files containing any of the 8-bit "extended ASCII" characters may need conversion (or translation) to 7-bit ASCII. - Files produced by word processing programs like Word Perfect or Word Star may contain special binary formatting codes, and could need con- version to conventional 7-bit ASCII format prior to transmission, using commonly available "exporter" programs. - Files created by word processors that store formatting data at the end of the file, after the Control-Z and before physical end, may re- quire special processing via SET EOF to strip the formatting data, lest they confuse non-MS-DOS recipients. - Spreadsheet or database files usually need special formatting to be meaningful to non-MS-DOS recipients (though they can be transmitted between MS-DOS systems with Kermit-MS). - BASIC programs are normally saved in a binary "tokenized" form. Use BASIC's ",a" SAVE option to save them as regular ASCII text, as in save"foofa",a In general, when attempting to transfer non-text files between MS-DOS and a different kind of system, consult the Kermit manual for that system. 1.5. Program Setup and Invocation The MS-DOS Kermit program can be run from any disk without any special instal- lation procedure. On hard disk systems, it is convenient to store the program in one of the directories listed in your DOS PATH, and it is often desirable to customize Kermit's operation to your communications and computing environment by creating an initialization file. Kermit-MS can be run interactively, from a batch file, or as an "external" DOS command. Commands consist of one or more fields, separated by "whitespace" -- one or more spaces or tabs. Upon initial startup, the program executes any commands found in the file MSKERMIT.INI in the current path. This initialization file may contain command macro definitions, communications settings for one or more ports, or any other Kermit-MS commands, and you may create it using any text editor capable of saving files in plain ASCII text format. Here is a sample: comment -- MSKERMIT.INI, MS-DOS Kermit initialization file comment -- Don't overwrite my files! set warning on comment -- Define macros for the systems I use... define unix set local-echo off,set par non,set flow xon,set timer off def ibm set par odd,set loc on,set hands xon,set flo none,set tim on def modem set port 2, set baud 1200 comment -- Define a macro for quickly adapting to noisy connections... def noisy set block-check 3, set send packet-length 40, set retry 20 comment -- I always start out by connecting to my UNIX system... set port 1 set baud 4800 do unix connect A different file may be substituted for MSKERMIT.INI by using "-f filename" on the DOS command line, e.g. kermit -f monday.ini The meanings of these commands will emerge below. For now, just note how you can use command files (and "macro definitions") to easily adapt MS-Kermit to widely differing communication environments. A more advanced initialization file is shown below in section 1.8. Interactive Operation: To run Kermit-MS interactively, invoke the program from DOS command level by typing its name, normally "kermit" (this means the program should be stored in your path with the name KERMIT.EXE). When you see the program's prompt, Kermit-MS> you may type Kermit commands repeatedly until you are ready to exit the program, as in the following example (which assumes there's already a Kermit "server" set up on the other end): A> A>kermit IBM PC Kermit-MS V2.30 8 Jan 88 Type ? for help Kermit-MS>set speed 19200 Kermit-MS>send foo.* The files are sent. Kermit-MS>get fot.* The requested files are received. Kermit-MS>exit A> Interactive commands are described in Section 1.6. Command Line Invocation: Kermit-MS may be invoked with command line arguments from DOS command level, for instance: A>kermit send peter.amy or A>kermit set port 1, set baud 9600, connect In this case, help and completion are not available (because the program that provides them won't start running until after you type the entire command line), and Kermit-MS will exit back to DOS after completing the specified com- mand or commands. Therefore, when invoked with command line arguments, Kermit-MS will behave as if it were an external DOS command, like MODE. Note that several commands may be given on the command line, separated by commas. This can't be done interactively or from TAKE command files. As of version 2.30, two new Kermit commands can be given on the DOS command line. First is the keyword STAY which prevents Kermit from exiting naturally when the last command has completed (unless, of course, EXIT or QUIT was among the commands). The second command is -F filename This means use the indicated filename as the initialization file rather than MSKERMIT.INI. The path will be searched for this file, if necessary. A space or tab must separate -F from the filename, and the F may be in upper or lower case. Example: kermit -f tuesday.ini, set port 2, do ibm, stay You can run Kermit with no initialization file at all by using the command kermit -f nul If -F is the only command line option, STAY is implied. Batch Operation: Like other MS-DOS programs, Kermit-MS may be operated under batch with command line arguments. If you invoke it without command line arguments, it will run interactively, reading commands from the keyboard and not the batch file. When it exits, batch processing will continue to the end of the batch file. Kermit-MS returns the "errorlevel" parameter used as program exit status. Present values are in the range 0 to 7 with three areas yielding success or failure reports for the entire Kermit session. The errorlevel values are: errorlevel Kermit session status 0 entirely successful operation 1 a Send command completed unsuccessfully 2 a Receive or GET command completed unsuccessfully 4 a REMOTE command completed unsuccessfully 3,5,6,7 combinations (addition) of the above conditions Note that failures are remembered for the whole session and are not canceled by a following successful operation of the same type. Thus, sending several files individually yields an errorlevel of 0 only if all the files were sent success- fully. The "errorlevel" parameter also applies to script commands where OUTPUT corresponds to SEND and INPUT to RECEIVE. An example of Batch invocation of Kermit is shown in Figure 1-3. Remote Operation: The MS-DOS CTTY command allows an MS-DOS system to be used from a terminal con- nected to its communication port. Such sessions must be conducted with great care, since many programs assume that they are running on the real console, and explicitly reference screen memory or keyboard scan codes. Kermit can be used in this manner too, but before you give it any file transfer commands, you must inform it that it is running in "remote mode" rather than its normal "local mode." Use the SET REMOTE ON command for this purpose, to prevent the file transfer display from being sent out the port. RAM Disk Operation: If you invoke Kermit frequently, and you have sufficient memory on your PC, you may find it convenient to copy Kermit and its initialization file to a RAM disk when you start your system. This allows Kermit to be started and used quickly and silently, with no disk operations. For instance, if you're using IBM's VDISK facility to create the RAM disk, you might put statements like this in your CONFIG.SYS file: DEVICE=VDISK.SYS 512 512 32 /e This assumes you have 512K of extended (/e) memory installed and VDISK.SYS is in the root directory of the boot disk. It creates a 512K RAM disk with 512K sector size and space for 32 directories in the extended memory, assigning it the disk letter of your first unused disk. And then in your AUTOEXEC.BAT file (assuming the RAM disk is disk D:)... COPY KERMIT.EXE D: >NUL COPY MSKERMIT.INI D: >NUL COPY COMMAND.COM D: >NUL SET COMSPEC=D:\COMMAND.COM PATH D:\; ... APPEND D:\; ... The PATH and APPEND commands allow DOS to find KERMIT.EXE, and Kermit to find MSKERMIT.INI and COMMAND.COM, on the RAM disk. If you use Kermit transfer files to your RAM disk, remember to copy those files to a real disk before you turn off the system. Use of MS-Kermit in Windowing Environments: Kermit-MS can operate within windowing environments like such as TopView, DESqview, and MS-Windows. It runs in an active window under MS-Windows, ac- cepts cut and paste material, talks with mice, and shrinks to an icon (a boxed "KER"). An MS-Windows .PIF file can be constructed for Kermit using the PIFEDIT program, supplied with Windows. Memory requirements should be listed as 90 to 128KB. It should be noted that Kermit does not modify the screen, keyboard, memory, COM1, or COM2 (!). Program switch and exchange should be marked as Text, and Close Window on Exit should be checked. This configuration will let you run Kermit with all the Windows features, but very slowly. To run at full speed under Windows, tell PIFEDIT that Kermit modifies the screen. Then you lose the Windows features (cutting, pasting, running the clock at the same time, etc), but you still get back to the Windows interface when you EXIT Kermit. Local Area Network Operation: MS-Kermit 2.30 is capable of using a serial port on another local area network (LAN) node, so long as that node is running an asynchronous communication serv- er and you have installed a device driver on your own PC that makes COM1 or COM2 i/o use the network server. This type of connection works because MS-Kermit 2.30 (but not earlier releases) on IBM PCs checks the selected port, COM1 or COM2, to see if it's a real 8250 UART chip, and if it isn't, Kermit uses only Bios calls for port i/o, and the network routes these through your network device driver. It may be necessary to turn off a real COM1 or COM2 device (with a switch or jumper on the board) to convince Kermit to use the Bios. This style of operation should be transparent to Kermit, except that not all asynchronous communications servers utilize this technique. As of version 2.30, the IBM PC version of Kermit can also communicate directly with another PC on a local area network through the IBM NetBIOS emulator dis- tributed with the LAN. In essence, the LAN substitutes for the serial port, modem, and other wiring. Kermit running on one user machine can transfer files with another Kermit also on the network much as if they were connected by modems, and Kermit can talk with some larger machines the same way. The impor- tant, and only, network command is SET PORT NET nodename which is described in the section on SET commands. Also see the SERVER command description, and (if you're interested) section 1.16.1 for a technical descrip- tion. Kermit can even communicate with some other computers, such as Unix systems, which accept logins via this remote pathway. The initial startup is the same as calling a mainframe and logging in except the command SET PORT NET nodename is used instead of SET PORT COM1. A connection is established with the first use of the communications circuit, such as CONNECT, REMOTE DIR, SEND, or other file transfer command, and terminated with the HANGUP command. 1.6. Kermit-MS Commands MS-DOS Kermit supplies most of the commands and features of "ideal" Kermit. Here's a summary: -F specify alternate init file name on DOS command line. BYE to remote server, exit from MS-Kermit. CLEAR serial port buffer. CLOSE log files and stop logging remote session. COMMENT For including comments in command files. CONNECT as terminal to remote system. CWD change local working directory. DEFINE a macro of Kermit-MS commands. DELETE local files. DIRECTORY listing of local files. DISABLE server recognition of selected commands. DO a command macro. ECHO a line of text on the screen. ENABLE server recognition of selected commands. EXIT from Kermit-MS. FINISH Shut down remote server. GET remote files from server. HANGUP the phone or network connection. HELP about Kermit-MS. INPUT specified string from serial port, for scripts. LOG remote terminal session and/or packets. LOGOUT remote server, don't exit from Kermit-MS. OUTPUT string out serial port, for scripts. PAUSE between commands. PUSH to MS-DOS command level. QUIT from Kermit-MS (same as EXIT). RECEIVE files from remote Kermit. REMOTE Prefix for remote file management commands. RUN an MS-DOS program or command. SEND files to remote Kermit. SERVER mode of remote operation. SET various parameters. SHOW various parameters. SPACE inquiry (about disk space). STATUS inquiry (about settings). STAY stay within Kermit after DOS command line invocation. TAKE commands from a file. TRANSMIT a file "raw" (no error checking). TYPE a local file on the screen. VERSION display Kermit-MS program version number. Not all of these commands are necessarily available on all MS-DOS systems, and some of the commands may work somewhat differently between DOS versions. A command keyword, such as SEND, RECEIVE, HELP, etc, may be abbreviated, so long as you have typed enough letters to distinguish it from other keywords that are valid in that position. For instance, you can type CLE for CLEAR and CLO for CLOSE. Several common commands also have special non-unique abbrevia- tions, like C for CONNECT, S for SEND, and R for RECEIVE. During interactive operation, you may edit the command you're currently typing using BACKSPACE to erase the character most recently typed, Ctrl-W to delete the most recent field, or Ctrl-U to delete the entire command. The editing characters may be used in any combination until the command is finally entered by typing RETURN (Carriage Return, Enter) or Ctrl-L. You may use the help ("?") and keyword completion (ESC) features freely while typing Kermit-MS commands. A question mark typed at almost any point in a com- mand produces a brief description, or "menu", of what is expected or possible at that point. ESC typed at any point, except in a local filename, will cause the current field to be filled out if what you have typed so far is sufficient to identify it, and will leave you in position to type the next field (or to type a "?" to find out what the next field is); otherwise, the program will beep at you and wait for you to type more characters. Kermit-MS recognizes only 7-bit ASCII characters when examining a Kermit com- mand line. The SET KEY and SHOW KEY commands can prompt for keyboard input and understand 8-bit characters but only at their interactive prompt. The SET KEY, INPUT, and OUTPUT commands accept "backslash number format" on the main Kermit command line. Thus, national characters which are full 8-bit codes can be ex- pressed on command lines in backslash number form (\ddd), provided the Kermit command itself can understand the form. Presently, INPUT, OUTPUT, ECHO, SET KEY, SET PROMPT, and DEFINE commands understand this notation. To enter characters in backslash number format, type a backslash ("\") followed by a number corresponding to the ASCII code for the character: \123 a decimal number (decimal is the default number base) \d249 a decimal number (also \D) \o177 an octal (base 8) number (also \O) \x0d a hexadecimal (base 16) number (also \X) Table 1-1 shows all of the 7-bit ASCII codes in decimal. Most Kermit commands understand backslash-ASCII codes, both imbedded within character strings, and alone, as when a single character or number is to be specified. Some Kermit-MS commands like GET, SHOW KEY, and SET KEY, may prompt for ad- ditional information on subsequent lines. If you have reached one of these prompts and then wish to cancel the command, you may type Control-C to get back to the main Kermit-MS> prompt. Summary of Kermit-MS command editing characters: SPACE Separates fields within the command. TAB Same as Space, and echoes as Space. You may also use Ctrl-I for Tab. BACKSPACE Deletes the character most recently typed. May be typed repeatedly to delete all the way back to the prompt. You may also use DELETE, RUBOUT, Ctrl-H, or equivalent keys. Ctrl-W Deletes the most recent "word", or field, on the command line. May be typed repeatedly. Ctrl-U Deletes the entire command line, back to the prompt. Ctrl-C Cancels the current command and returns to the "Kermit-MS>" prompt. Also, terminates execution of a TAKE command file. ESC If enough characters have been supplied in the current keyword to identify it uniquely the remainder of the field is supplied and the cursor is positioned to the next field of the command. Otherwise, a beep is sounded. ESC does not provide filename completion in version 2.30. ? Displays a brief message describing what may be typed in the cur- rent command field. Also, wildcard character for matching any single character in all but the first position of a filename. # Wildcard character for matching single characters in filenames. ------------------------------------------------------------------------------- Dec Name Ctrl Dec Char Dec Char Dec Char 0 NUL ^@ | 32 SP | 64 @ | 96 ` 1 SOH ^A | 33 ! | 65 A | 97 a 2 STX ^B | 34 " | 66 B | 98 b 3 ETX ^C | 35 # | 67 C | 99 c 4 EOT ^D | 36 $ | 68 D | 100 d 5 ENQ ^E | 37 % | 69 E | 101 e 6 ACK ^F | 38 & | 70 F | 102 f 7 BEL ^G beep | 39 ' | 71 G | 103 g 8 BS ^H backspace | 40 ( | 72 H | 104 h 9 HT ^I tab | 41 ) | 73 I | 105 i 10 LF ^J linefeed | 42 * | 74 J | 106 j 11 VT ^K | 43 + | 75 K | 107 k 12 FF ^L formfeed | 44 , | 76 L | 108 l 13 CR ^M return | 45 - | 77 M | 109 m 14 SO ^N shift out | 46 . | 78 N | 110 n 15 SI ^O shift in | 47 / | 79 O | 111 o 16 DLE ^P | 48 0 | 80 P | 112 p 17 DC1 ^Q XON | 49 1 | 81 Q | 113 q 18 DC2 ^R | 50 2 | 82 R | 114 r 19 DC3 ^S XOFF | 51 3 | 83 S | 115 s 20 DC4 ^T | 52 4 | 84 T | 116 t 21 NAK ^U | 53 5 | 85 U | 117 u 23 ETB ^W | 54 6 | 86 V | 118 v 22 SYN ^V | 55 7 | 87 W | 119 w 24 CAN ^X | 56 8 | 88 X | 120 x 25 EM ^Y | 57 9 | 89 Y | 121 y 26 SUB ^Z | 58 : | 90 Z | 122 z 27 ESC ^[ escape | 59 ; | 91 [ | 123 { 28 FS ^\ | 60 < | 92 \ | 124 | 29 GS ^] | 61 = | 93 ] | 125 } 30 RS ^^ | 62 > | 94 ^ | 126 ~ 31 US ^_ | 63 ? | 95 _ | 127 RUBOUT,DELETE Table 1-1: The US ASCII Character Set (ANSI X3.4-1977) ------------------------------------------------------------------------------- Equivalent to MS-DOS "?", but used in the first position of a filename only, so that "?" may be used to get help at the beginning of a filename field. RETURN Enters the command. On most keyboards, you may also use ENTER or Ctrl-M. Ctrl-L Clears the screen and enters the command. Liberal use of "?" allows you to feel your way through the commands and their fields. This feature is sometimes called "menu on demand" or "context sen- sitive help" -- unlike systems that force you to negotiate menus at every turn, menu-on-demand provides help only when it is needed. Command parsing is done through DOS calls. Kermit key redefinition does not apply at MS-Kermit command level. But ANSI.SYS or other external console drivers can be used for this purpose, for instance to assign ESC to the PC's backquote key (ANSI.SYS is the IBM-supplied extended screen and keyboard device driver, described in the IBM DOS Technical Reference Manual). Other console drivers available include ProKey, SuperKey, NANSI.SYS (a public-domain replace- ment for ANSI.SYS), and FANSICONSOLE. The notation used in command descriptions is as follows: Optional fields are in [square brackets], lists of alternatives are in {curly braces}, separated by commas. Parameters, such as numbers or filenames, are shown in italics (providing the printer is capable of printing italics), and in dialog examples user typein is underlined (on printers that can show it) to distinguish it from computer typeout. The following sections describe MS-Kermit's commands. Command descriptions may contain references to other commands that haven't been explained yet. You might find that this manual makes more sense on a second reading. 1.6.1. Program Management Commands "Program management" is a rubric for Kermit-MS commands like TAKE, EXIT, HELP, COMMENT, ECHO, and VERSION, that don't fall into any other category. HELP simply displays a short help message (the same one, in fact, that you would see if you typed a question mark in the same place). VERSION displays the MS-Kermit program version number, which you should know in case you are reporting bugs or seeking technical assistance. Other program management commands require a bit more explanation. The EXIT Command Syntax: EXIT or QUIT EXIT and QUIT are synonyms for each other. They cause MS-Kermit to return con- trol to DOS or whatever program invoked MS-Kermit. The specific actions taken are: - Close any open log or other files. - Close any open network connection. - Release all memory claimed by the program. - Disable interrupts for the currently selected communication device. - Terminate execution. The serial port RS-232 signals are left alone upon EXIT, so that modem connec- tions are not broken. Kermit-MS may be restarted with the connection intact. Use HANGUP to explicitly break a modem connection. The STAY Command Syntax: STAY The STAY command, if included among command line arguments, instructs MS-Kermit not to exit upon completion but rather to enter interactive mode, unless EXIT or QUIT was among the command arguments. STAY has no effect when entered in- teractively or from a TAKE file. The PUSH Command Syntax: PUSH PUSH is similar to EXIT, except it leaves MS-Kermit intact by invoking an MS-DOS command processor "under" Kermit-MS, either COMMAND.COM or whatever shell you have specified with COMSPEC (or SHELL, depending on the system) in your CONFIG.SYS file. You can return to Kermit-MS by typing the MS-DOS EXIT command, and you will find Kermit-MS as you left it, with all settings intact. The same function is invoked by the CONNECT escape-level command P. Example: Kermit-MS>push Push to DOS. Command v3.10 COMMAND.COM program herald. C>diskcopy a: b: Run a DOS program. DISKCOPY dialog here... C>dir b: More DOS commands... DOS session continues... C>exit When done, type DOS EXIT command. Kermit-MS> Back at Kermit. The TAKE Command Syntax: TAKE filespec The TAKE command gives you way a to collect MS-Kermit commands into a single file, so that you can execute many commands by typing a single (TAKE) command. TAKE instructs MS-Kermit to execute commands from the file that you specify. The current directory is searched for the file first, and then any directories listed in the PATH environment variable. The command file may include any valid Kermit-MS commands, including TAKE, but it cannot include characters to be sent to a remote host after a CONNECT command (use scripts for that, described below). Execution of a TAKE file may be cancelled by typing Control-C at the keyboard. An implicit TAKE command is executed upon the initialization file, MSKERMIT.INI (or another file specified in the "-f" command-line argument), whenever you start MS-Kermit. The MSKERMIT.INI file contains any commands you want to be executed each time you run Kermit. A sample is shown above, and a more am- bitious example is shown in section 1.8. Commands within TAKE files, unlike interactive commands, may include trailing comments, preceded by semicolons (if a real semicolon is needed in a command, express it as "\;" and it will not be mistaken for the start of a comment).