ckcplm.txt

KERMIT工具 这在办公室下载不了,很多人都没有载不到.

          routines.

   Terminal State
          Reading from the keyboard with conxxx() routines and writing to
          the communications device with ttxxx() routines AND vice-versa.

   When in local mode, the console and communications device are
   distinct. During file transfer, Kermit may put up a file-transfer
   display on the console and sample the console for interruption
   signals.

   When in remote mode, the console and communications device are the
   same, and therefore there can be no file-transfer display on the
   console or interruptions from it (except for "in-band" interruptions
   such as ^C^C^C).

   [ [39]Contents ] [ [40]C-Kermit ] [ [41]Kermit Home ]
    ________________________________________________________________________

  4.A. Group A: Library Functions

   Library functions, strictly portable, can be used by all modules on
   all platforms: [42]ckclib.h, [43]ckclib.c.

   (To be filled in... For now, see [44]Section 3.1 and the comments in
   ckclib.c.)

   [ [45]Contents ] [ [46]C-Kermit ] [ [47]Kermit Home ]
    ________________________________________________________________________

  4.B. Group B: Kermit File Transfer

   The Kermit protocol kernel. These files, whose names start with "ckc
   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 B modules do not
   include any header files other than those that come with Kermit
   itself. They do not contain any library calls except from the standard
   C library (e.g. printf()). They most certainly do not contain any
   system calls. Files:

   [48]ckcsym.h
          For use by C compilers that don't allow -D on the command line.

   [49]ckcasc.h
          ASCII character symbol definitions.

   [50]ckcsig.h
          System-independent signal-handling definitions and prototypes.

   [51]ckcdeb.h
          Originally, debugging definitions. Now this file also contains
          all definitions and prototypes that are shared by all modules
          in all groups.

   [52]ckcker.h
          Kermit protocol symbol definitions.

   [53]ckcxla.h
          Character-set-related symbol definitions (see next section).

   [54]ckcmai.c
          The main program. This module contains the declarations of all
          the protocol-related global variables that are shared among the
          other modules.

   [55]ckcpro.w
          The protocol module itself, written in "wart", a lex-like
          preprocessor that is distributed with Kermit under the name
          CKWART.C.

   [56]ckcfns.c, [57]ckcfn2.c, [58]ckcfn3.c
          The protocol support functions used by the protocol module.

   [59]Group B modules may call upon functions from [60]Group E, but not
   from [61]Group D modules (with the single exception that the main
   program invokes the user interface, which is in Group D). (This last
   assertion is really only a conjecture.)

   [ [62]Contents ] [ [63]C-Kermit ] [ [64]Kermit Home ]
    ________________________________________________________________________

  4.C. Group C: Character-Set Conversion

   Character set translation tables and functions. Used by the [65]Group
   B, protocol modules, but may be specific to different computers. (So
   far, all character character sets supported by C-Kermit are supported
   in [66]ckuxla.c and [67]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.

   [68]ckcxla.h
          Character-set definitions usable by all versions of C-Kermit.

   ck?xla.h
          Character-set definitions for computer "?", e.g. [69]ckuxla.h
          for UNIX, [70]ckmxla.h for Macintosh.

   [71]ck?xla
          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.

   [72]ckcuni.h
          Unicode definitions

   [73]ckcuni.c
          Unicode module

   Here's how to add a new file character set in the original
   (non-Unicode modules). 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), again in the "old" character-set modules:

   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.

   As of C-Kermit 7.0, character sets are also handled in parallel by the
   new (and very large) Unicode module, ckcuni.[ch]. Eventually we should
   phase out the old way, described just above, and operate entirely in
   (and through) Unicode. The advantages are many. The disadvantages are
   size and performance. To add a character to the Unicode modules:

   In ckcuni.h:

          + (To be filled in...)

   In ckcuni.c:

          + (To be filled in...)

   [ [74]Contents ] [ [75]C-Kermit ] [ [76]Kermit Home ]
    ________________________________________________________________________

  4.D. Group D: 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 one provided is command-and
   prompt, with the ability to read commands from various sources: the
   console keyboard, a file, or a macro definition. 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, FTP client commands, etc.

   If you plan to imbed the [77]Group B, 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).

   [78]ckucmd.h
   [79]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 [80]Group E functions.

   [81]ckuusr.h
          Definitions of symbols used in Kermit's commands.

   ckuus*.c
          Kermit's interactive command parser, including the script
          programming language: [82]ckuusr.c (includes top-level keyword
          tables); [83]ckuus2.c (HELP command text); [84]ckuus3.c (most
          of the SET command); [85]ckuus4.c (includes variables and
          functions); ckuus[567].c (miscellaneous);

   [86]ckuusy.c
          The command-line-option parser.

   [87]ckuusx.c
          User interface functions common to both the interactive and
          command-line parsers.

   [88]ckuver.h
          Version heralds for different implementations.

   [89]ckuscr.c
          The (old, uucp-like) SCRIPT command

   [90]ckudia.c
          The DIAL command. Includes specific knowledge of many types of
          modems.

   Note that none of the above files is actually Unix-specific. Over time
   they have proven to be portable among all platforms where C-Kermit is
   built: Unix, VMS, AOS/VS, Amiga, OS-9, VOS, etc etc. Thus the third
   letter should more properly be "c", but changing it would be too
   confusing.

   ck?con.c, ckucns.c
          The CONNECT command. Terminal connection, and in some cases
          (Macintosh, Windows) also terminal emulation. NOTE: As of
          C-Kermit 7.0, there are two different CONNECT modules for UNIX:
          [91]ckucon.c -- the traditional, portable, fork()-based version
          -- and [92]ckucns.c, a new version that uses select() rather
          than forks so it can handle encryption. ckucns.c is the
          preferred version for Unix; 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_*.*, ckuat*.*
          Modules having to do with authentication and encryption. Since
          the relaxation of USA export laws, they are included with the
          general source-code distribution. Secure C-Kermit binaries can
          be built using special targets in the standard makefile.
          However, secure prebuilt binaries may not be distributed.

   For other implementations, the files may, and probably do, have
   different names. For example, the Macintosh graphical user interface
   filenames start with "ckm". Kermit 95 uses the ckucmd and ckuus*
   modules, but has its own CONNECT command modules. 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