ckcplm.txt

C-Kermit源码。是使用串口/Modem和网络通讯的程序

GROUP 0:

Library functions, strictly portable, can be used by all modules on all
platforms.  CKCLIB.H, CKCLIB.C.

GROUP 1:

The Kermit protocol kernel.  The filenames start with CKC.  C means that these
files are supposed to be totally portable C, and are expected to compile
correctly on any platform with any C compiler.  "Portable" does not mean the
same as as "ANSI" -- these modules must compile on 10- and 20-year old
computers, with C preprocessors, compilers, and/or linkers that have all sorts
of restrictions.  The group 1 modules do not include any header files other
than those that come with Kermit itself.  They do not contain any library
calls (like printf) or any system calls (like open, close, read, write).
Files:

  CKCSYM.H - For use by C compilers that don't allow -D on the command line.
  CKCASC.H - ASCII character symbol definitions.
  CKCSIG.H - System-independent signal-handling definitions and prototypes.
  CKCDEB.H - Originally, debugging definitions.  Now this file also contains
	     all definitions and prototypes that are shared by all modules in
             all groups.
  CKCKER.H - Kermit protocol symbol definitions.
  CKCXLA.H - Character-set-related symbol definitions (see next section).

  CKCMAI.C - The main program.  This module contains the declarations of all
  the protocol-related global variables that are shared among the other
  modules.

  CKCPRO.W - The protocol module itself, written in "wart", a lex-like
  preprocessor that is distributed with Kermit under the name CKWART.C.

  CKCFN*.C - The protocol support functions used by the protocol module.

Group 1 modules may call upon functions from Group 3 modules, but not from
Group 2 modules (with the single exception that the main program invokes the
user interface, which is in Group 2).  (This last assertion is really only a
conjecture.)

GROUP 1.5

Character set translation tables and functions.  Used by the Group I protocol
modules, but may be specific to different computers.  (So far, all character
character sets supported by C-Kermit are supported in CKUXLA.C and CKUXLA.H,
including Macintosh and IBM character sets).  These modules should be
completely portable, and not rely on any kind of system or library services.

  CKCXLA.H - Character-set definitions usable by all versions of C-Kermit.
  CK?XLA.H - Character-set definitions for computer "?", e.g. U for UNIX.

  CK?XLA.C - Character-set translation tables and functions for computer "?",
  For example, CKUXLA.C for UNIX, CKMXLA.C for Macintosh.  So far, these are
  the only two such modules.  The UNIX module is used for all versions of
  C-Kermit except the Macintosh version.

  CKCUNI.H - Unicode definitions
  CKCUNI.C - Unicode module

  Used for file transfer (SEND, RECEIVE, GET, REMOTE, etc), TRANSMIT,
  CONNECT, etc.

Here's how to add a new file character set.  Assuming it is based on the
Roman (Latin) alphabet.  Let's call it "Barbarian".  First, in CK?XLA.H,
add a definition for FC_BARBA (8 chars maximum length) and increase
MAXFCSETS by 1.  Then, in CK?XLA.C:

  . Add a barbarian entry into the fcsinfo array.
  . Add a "barbarian" entry to file character set keyword table, fcstab.
  . Add a "barbarian" entry to terminal character set keyword table, ttcstab.
  . Add a translation table from Latin-1 to barbarian: yl1ba[].
  . Add a translation table from barbarian to Latin-1: ybal1[].
  . Add a translation function from Barbarian to ASCII: xbaas().
  . Add a translation function from Barbarian to Latin-1: xbal1().
  . Add a translation function from Latin-1 to Barbarian: xl1ba().
  .  etc etc for each transfer character set...
  . Add translation function pointers to the xls and xlr tables.

Other translations involving Barbarian (e.g. from Barbarian to Latin-Cyrillic)
are performed through these tables and functions.  See CKUXLA.H and CKUXLA.C
for extensive examples.

To add a new Transfer Character Set, e.g. Latin Alphabet 9 (for the Euro
symbol)...

In ckcxla.h:
 . Add a TC_xxxx definition and increase MAXTCSETS accordingly.

In ck?xla.h (since any transfer charset is also a file charset):
 . Add an FC_xxxx definition and increase MAXFCSETS accordingly.

In ck?xla.c:
 . Add a tcsinfo[] entry.
 . Make a tcstab[] keyword table entry.
 . Make an fcsinfo[] table entry.
 . Make an fcstab[] keyword table entry.
 . Make a tcstab[] keyword table entry.
 . If necessary, make a langinfo[] table entry.
 . Make entries in the function pointer arrays.
 . Provide any needed functions.

In ckcuni.h:
 . (to be filled in)

In ckcuni.c:
 . (to be filled in)


GROUP 2:

The user interface.  This is the code that communicates with the user, gets
her commands, informs her of the results.  It may be command-line oriented,
interactive prompting dialog, menus and arrow keys, windows and mice, speech
recognition, telepathy, etc.  The user interface has three major functions:

1. Sets the parameters for the file transfer and then starts it.  This is done
by setting certain (many) global variables, such as the protocol machine start
state, the file specification, file type, communication parameters, packet
length, window size, character set, etc.

2. Displays messages on the user's screen during the file transfer, using the
screen() function, which is called by the group-1 modules.

3. Executes any commands directly that do not require Kermit protocol, such
as the CONNECT command, local file management commands, parameter-setting
commands, etc.

If you plan to imbed the Group 1 files into a program with a different user
interface, your interface must supply an appropriate screen() function, plus a
couple related ones like chkint() and intmsg() for handling keyboard (or
mouse, etc) interruptions during file transfer.  The best way to find out
about this is to link all the C-Kermit modules together except the CKUU*.O
and CKUCON.O modules, and see which missing symbols turn up.

C-Kermit's character-oriented user interface (as opposed to the Macintosh
version's graphical user interface) consists of the following modules.
C-Kermit can be built with an interactive command parser, a command-line-
option-only parser, a graphical user interface, or any combination, and it
can even be built with no user interface at all (in which case it runs as a
remote-mode Kermit server).

  CKUUSR.H - Definitions of symbols used in Kermit's commands.

  CKUUSR.H, CKUUSR.C, CKUUS2.C, CKUUS3.C, CKUUS4.C, CKUUS5.C, ... -
  Kermit's interactive command parser, including the script programming
  language.

  CKUUSY.C - The command-line-option parser.

  CKUUSX.C - Functions that are common to both the interactive and
  command-line parsers.

  CKUCMD.H, CKUCMD.C - The command parsing primitives used by the
  interactive command parser to parse keywords, numbers, filenames, etc,
  and to give help, complete fields, supply defaults, allow abbreviations
  and editing, etc.  This package is totally independent of Kermit, but
  does depend on the Group 3 functions.

  CKUVER.H - Version heralds for different implementations.

  CKUSCR.C - The (old, uucp-like) SCRIPT command.
  CKUDIA.C - The DIAL command.  Includes specific knowledge of many
             types of modems.

  CK?CON.C - The CONNECT command.  Terminal connection, and in some
             cases (Macintosh, OS/2, etc) also terminal emulation.
             NOTE: As of C-Kermit 6.1, there are two different CONNECT
             modules for UNIX: ckucon.c -- the regular, portable version
             -- and ckucns.c, a new version that uses select() rather
             than forks so it can handle encryption.  ckucns.c is the
             preferred version; ckucon.c is not likely to keep pace with
             it in terms of upgrades, etc.  However, since select() is
             not portable to every platform, ckucon.c will be kept
             indefinitely for those platforms that can't use ckucns.c.
             NOTE: SunLink X.25 support is available only in ckucon.c.

  CK_CRP.* - Modules having to do with authentication and encryption.
  CKUAT*.*   These are not part of the general distribution since they
             contain code and algorithms that are restricted by USA
             export law.

For other implementations, the files may, and probably do, have different
names.  For example, the Macintosh graphical user interface filenames start
with CKM.  OS/2 uses the CKUCMD and CKUUS* modules, but has its own CONNECT
command in CKOCON.C.  And so on.

Here is a brief description of C-Kermit's "user interface interface", from
CKUUSR.C.  It is nowhere near complete; in particular, hundreds of global
variables are shared among the many modules.  These should, some day, be
collected into classes or structures that can be passed around as needed;
not only for purity's sake, but also to allow for multiple simultaneous
communication sessions and or user interfaces.

The ckuus*.c modules depend on the existence of C library features like fopen,
fgets, feof, (f)printf, argv/argc, etc.  Other functions that are likely to
vary among operating systems -- like setting terminal modes or interrupts --
are invoked via calls to functions that are defined in the system-dependent
modules, ck?[ft]io.c.  The command line parser processes any arguments found
on the command line, as passed to main() via argv/argc.  The interactive
parser uses the facilities of the cmd package (developed for this program, but
usable by any program).  Any command parser may be substituted for this one.
The only requirements for the Kermit command parser are these:

1. Set parameters via global variables like duplex, speed, ttname, etc.  See
   ckcmai.c for the declarations and descriptions of these variables.

2. If a command can be executed without the use of Kermit protocol, then
   execute the command directly and set the variable sstate to 0.  Examples
   include 'set' commands, local directory listings, the 'connect' command.

3. If a command requires the Kermit protocol, set the following variables:

   sstate                             string data
     'x' (enter server mode)            (none)
     'r' (send a 'get' command)         cmarg, cmarg2
     'v' (enter receive mode)           cmarg2
     'g' (send a generic command)       cmarg
     's' (send files)                   nfils, cmarg & cmarg2 OR cmlist
     'c' (send a remote host command)   cmarg

   cmlist is an array of pointers to strings.
   cmarg, cmarg2 are pointers to strings.
   nfils is an integer.

   cmarg can be a filename string (possibly wild), or
      a pointer to a prefabricated generic command string, or
      a pointer to a host command string.
   cmarg2 is the name to send a single file under, or
      the name under which to store an incoming file; must not be wild.
      If it's the name for receiving, a null value means to store the
      file under the name it arrives with.
   cmlist is a list of nonwild filenames, such as passed via argv.
   nfils is an integer, interpreted as follows:
     -1: filespec (possibly wild) in cmarg, must be expanded internally.
      0: send from stdin (standard input).
     >0: number of files to send, from cmlist.

The screen() function is used to update the screen during file transfer.
The tlog() function writes to a transaction log (if TLOG is defined).
The debug() function writes to a debugging log (if DEBUG is defined).
The intmsg() and chkint() functions provide the user i/o for interrupting
file transfers.

GROUP 3:

System-dependent function definitions.  All the Kermit modules, including the
command package, call upon these functions, which are designed to provide
system-independent primitives for controlling and manipulating devices and
files.  For UNIX, these functions are defined in the files CKUFIO.C (files),
CKUTIO.C (communication devices), and CKUSIG.C (signal handling).

For VMS, the files are CKVFIO.C, CKVTIO.C, and CKUSIG.C (VMS can use the same
signal handling routines as UNIX).  For OS/2, CKOFIO.C, CKOTIO.C, CKOSIG.C
(OS/2 has its own signal handling).  It doesn't really matter what the files
are called, except for Kermit distribution purposes (grouping related files
together alphabetically), only that each function is provided with the name
indicated, observes the same calling and return conventions, and has the same
type.

The Group 3 modules contain both functions and global variables that are
accessed by modules in the other groups.  These are now described.

(By the way, I got this list by linking all the C-Kermit modules together
except CKUTIO and CKUFIO.  These are the symbols that ld reported as undefined)

A. Variables:

char *DELCMD;
  Pointer to string containing command for deleting files.
  Example: char *DELCMD = "rm -f ";  (UNIX)
  Example: char *DELCMD = "delete "; (VMS)
  Note trailing space.  Filename is concatenated to end of this string.
  NOTE: DELCMD is used only in versions that do not provide their own
  built-in DELETE command.

char *DIRCMD;
  Pointer to string containing command for listing files when a filespec
  is given.
  Example: char *DIRCMD = "/bin/ls -l "; (UNIX)
  Example: char *DIRCMD = "directory ";  (VMS)
  Note trailing space.  Filename is concatenated to end of this string.
  NOTE: DIRCMD is used only in versions that do not provide their own
  built-in DIRECTORY command.

char *DIRCM2;
  Pointer to string containing command for listing files when a filespec
  is not given.  (currently not used, handled in another way.)
  Example: char *DIRCMD2 = "/bin/ls -ld *";
  NOTE: DIRCMD2 is used only in versions that do not provide their own
  built-in DIRECTORY command.

char *PWDCMD;
  Pointer to string containing command to display current directory.
  Example: char *PWDCMD = "pwd ";
  NOTE: PWDCMD is used only in versions that do not provide their own
  built-in PWD command.

char *SPACMD;
  Pointer to command to display free disk space in current device/directory.