ckuins.txt

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

     SHOW FILE and see what it says about this.  If it is too short, there
     could be some problems at runtime.  To correct, look in ckcdeb.h to
     see how the symbol CKMAXPATH is set and make any needed adjustments.

  g. Send a file to your new Kermit program from a different Kermit program
     that is known to work.  Is the date/timestamp of the new file identical
     to the original?  If not, adjustments are needed in zstrdt() in
     ckufio.c.

  h. Go to another computer (Computer B) from which you can send files to
     C-Kermit.  Connect Computer B to the computer (A) where you are testing
     C-Kermit.  Then:

  i. Send a file from B to A.  Make sure it transferred OK and was created
       with the the right name.

  j. Send a file from B to A, specifying an "as-name" that is very, very
     long (longer than the maximum name length on computer A).  Check to
     make sure that the file was received OK and that its name was truncated
     to Computer A's maximum length.  If not, check the MAXNAMLEN definition
     in ckufio.c.

  k. Tell C-Kermit on Computer A to "set receive pathnames relative" and
     then send it a file from Computer B specifying an as-name that contains
     several directory segments:

       send foo dir1/dir2/dir3/foo

     Check to make sure that dir1/dir2/dir3/foo was created in Computer A's
     current directory (i.e. that three levels of directories were created).

  l. Repeat step k, but make each path segment in the pathname longer than
     Computer A's maximum name length.  Make sure each directory name, and
     the final filename, were truncated properly.

  m. Type Ctrl-C (or whatever your UNIX interrupt character is) at the prompt.
     Do you get "^C..." and a new prompt?  If instead, you get a core dump
     (this shouldn't happen any more) "rm core" and then rebuild with
     -DNOCCTRAP added to your CFLAGS.  If it did work, then type another
     Ctrl-C.  If this does the same thing as the first one, then Ctrl-C
     handling is OK.  Otherwise, the SIGINT signal is either not getting
     re-armed (shouldn't happen) or is being masked off after the first time
     it is caught, in which case, if your UNIX is POSIX-based, try rebuilding
     C-Kermit with -DCK_POSIX_SIG.

  n. Type Ctrl-Z (or whatever your UNIX suspend character is) to put C-Kermit
     in the background.  Did it work?  If nothing happened, then (a) your
     version of UNIX does not support job control, or (b) your version of
     C-Kermit was probably built with -DNOJC.  If your session became totally
     frozen, then you are probably running C-Kermit on a UNIX version that
     supports job control, but under a shell that doesn't.  If that's not the
     case, look in the congm() and psuspend() routines in ckutio.c and see if
     you can figure out what's wrong.  If you can't, rebuild with -DNOJC.

  o. Give a SET LINE command for a dialout device, e.g. "set line /dev/tty00".
     If you got some kind of permission or access denied message, go read
     Section 10 and then come back here.

  p. After giving a successful SET LINE command, type "show comm" to
     see the communication parameters.  Do they make sense?

  q. Type "set speed ?" and observe the list of available speeds.  Is it
       what you expected?  If not, see Section 2 of ckccfg.txt.

  r. Give a SET SPEED command to change the device's speed.  Did it work?
       (Type "show comm" again to check.)

  s. Try dialing out: SET MODEM TYPE <whatever>, SET LINE <whatever>, SET
     SPEED <whatever>, DIAL <phone-number>.  If it doesn't work, keep
     reading.  After dialing, can you REDIAL?

  t. If your version was built with TCP/IP network support, try the TELNET
     command.

  u. Transfer some files in remote mode on incoming asynchronous serial
     (direct or modem) connections, and on incoming network (telnet, rlogin,
     terminal server) connections.  If you get lots of errors, try different
     SET FLOW settings on the remote Kermit program.

  v. Establish a serial connection from C-Kermit to another computer (direct
     or dialed) and transfer some files.  If you have network support, do the
     same with a network connection.

  x. If your version was built with fullscreen file transfer display support,
     check that it works during local-mode file transfer.  Also, check
     C-Kermit's operation afterwards: is the echoing funny?  etc etc.  If
     there are problems, see Section 4.

  y. If your version was built with script programming language support,
     TAKE the ckedemo.ksc file to give it a workout.

  z. Does C-Kermit interlock correctly with UUCP-family programs (cu, tip,
     uucp, etc)?  If not, read the section DIALING OUT AND COORDINATING WITH
     UUCP below.

  A. Modem signals...  Give a SET LINE command to a serial device and then
     type the SHOW MODEM command.  If it says "Modem signals unavailable in
     this version of Kermit", then you might want to look at the ttgmdm()
     routine in ckutio.c and add the needed code -- if indeed your version of
     UNIX provides a way to get modem signals (some don't; e.g. modem signals
     are a foreign concept to POSIX, requiring politically incorrect
     workarounds).

     If it says "Modem signals unavailable", then it is likely that the API
     for getting modem signals is provided, but it doesn't actually do
     anything (e.g. ioctl(ttyfd,TIOCMGET,&x) returns EINVAL).

     In any case, it still should be able to manipulate the DTR signal.  To
     test, SET LINE <name-of-dialout-device>, SET MODEM NONE, and HANGUP.
     The DTR light should go out momentarily.  If it doesn't, see if you can
     add the needed code for your system to the tthang() routine in ckutio.c.

     If your version of Kermit has the SET FLOW RTS/CTS command, check to
     see if it works: give Kermit this command, set your modem for RTS/CTS,
     transfer some files (using big packet and window sizes) and watch the
     RTS and CTS lights on the modem.  If they go on and off (and Kermit does
     not get packet errors), then it works.  If your version of Kermit does
     not have this command, but your version of UNIX does support hardware
     flow control, take a look at the tthflow() command in ckutio.c and see
     if you can add the needed code (see the section on HARDWARE FLOW
     CONTROL below).

     (And please send back any added code to the author, so that others can
     benefit from it and it can be carried forward into future releases.)

  B. If C-Kermit starts normally and issues its prompt, echoing is normal,
     etc, but then after returning from a CONNECT session, the prompt no
     longer appears, try rebuilding with -DCKCONINTB4CB.


8. REDUCING THE SIZE OF THE EXECUTABLE PROGRAM IMAGE

  a. Many of C-Kermit's options and features can be deselected at compile
     time.  The greatest savings at the least sacrifice in functionality is
     to disable the logging of debug information by defining NODEBUG during
     compilation.  See the ckccfg.txt file for further information.

  b. Use shared libraries rather than static linking.  This is the default
     on many UNIX systems anyway.  However, executables built for dynamic
     linking with shared libraries are generally not portable away from the
     machine they were built on, so this is recommended if the binary is for
     your use only.

  c. Most UNIX systems have a "strip" command to remove symbol table
     information from an executable program image.  "man strip" for further
     information.  The same effect can be achieved by including "-s" among
     the link flags when building C-Kermit.

  d. SCO, Interactive, and some other UNIX versions have an "mcs" command.
     "mcs -d wermit" can be used to delete the contents of the ".comment"
     section from the executable program image.

  e. Many modern optimizers can be instructed to optimize for space rather
     than execution efficiency.  Check the CFLAGS in the makefile entry,
     adjust as desired.


9. UNIX VERSIONS

There are several major varieties of UNIX: Bell Laboratories Seventh Edition,
AT&T System V, Berkeley Standard Distribution (BSD), and POSIX.  Each has
many, many subvarieties and descendents, and there are also hybrids that
exhibit symptoms of two or more varieties, plus special quirks of their own.

Seventh edition versions of C-Kermit include the compile-time option -DV7 in
the CFLAGS string in the makefile entry.  Various V7-based implementations are
also supported: -DCOHERENT, -DMINIX, etc.

AT&T-based versions of UNIX Kermit include the compile-time option -DATTSV
(standing for AT&T UNIX System V).  This applies to System III and to System V
up to and including Release 2.  For System V Release 3, the flag -DSVR3 should
be used instead (which also implies -DATTSV).  This is because the data type
of signal() and several other functions was changed between SVR2 and SVR3.
For System V Release 4, include -DSVR4 because of changes in UUCP lockfile
conventions; this also implies -DSVR3 and -DATTSV.

For BSD, the flag -BSDxx must be included, where xx is the BSD version
number, for example BSD4 (for version 4.2 or later, using only 4.2 features),
-DBSD41 (for BSD 4.1 only), -DBSD43 (for 4.3 or later), -DBSD29 (BSD 2.9
for DEC PDP-11s).  BSD44 is BSD4.4, which is the basis of FreeBSD,
NetBSD, OpenBSD, BSDI, and others, and which contains many POSIX features.

For POSIX, include the flag -DPOSIX.  POSIX defines a whole new set of
terminal i/o functions that are not found in traditional AT&T or Berkeley
implementations, and also defines the symbol _POSIX_SOURCE, which is used
in many system and library header files, mainly to disable non-POSIX features.

Note (circa 1997): In order to enable serial speeds higher than 38400 bps,
it is generally necessary to add -DPOSIX (among other things), since the older
terminal APIs can not accommodate the new speeds -- out o' bits.  But this
often also means wholesale conversion to POSIX APIs.  In general, just try
adding -DPOSIX and then see what goes wrong.  Be wary of features
disappearing: when _POSIX_SOURCE is defined, all sorts of things that were
perfectly OK before suddenly become politically incorrect -- like reading
modem signals, doing hardware flow control, etc.  POSIX was evidently not
designed with serial communication in mind!

Case in point: In UnixWare 7.0, #define'ing POSIX causes strictness clauses
in the header files to take effect.  These prevent <sys/time.h> from defining
the timeval and timezone structs, which are needed for all sorts of things
(like select()).  Thus, if we want the high serial speeds, we have to
circumvent the POSIX clauses.

Similarly in SCO OpenServer R5.0.4 where, again, we must use the POSIX APIs to
get at serial speeds higher than 38400, but then doing so removes hardware
flow control -- just when we need it most!  In cases like this, dirty tricks
are the only recourse (search for SCO_OSR504 in ckutio.c for examples).

For reasons like this, UNIX implementations tend to be neither pure AT&T nor
pure BSD nor pure POSIX, but a mixture of two or more of these, with
"compatibility features" allowing different varieties of programs to be built
on the same computer.  In general, Kermit tries not to mix & match but to keep
a consistent repertoire throughout.  However, there are certain UNIX
implementations that only work when you mix and match.  For example, the
Silicon Graphics IRIX operating system (prior to version 3.3) is an AT&T UNIX
but with a BSD file system.  The only way you can build Kermit successfully
for this configuration is to include -DSVR3 plus the special option -DLONGFN,
meaning "pretend I was built with -DBSDxx when it's time to compile
file-related code".  See the "iris" makefile entry.

9.1. Standards

In edits 166-167, C-Kermit was heavily modified to try to keep abreast of new
standards while still remaining compatible with old versions of C and UNIX.
There are two new standards of interest: ANSI C (as described in Kernighan and
Ritchie, "The C Programming Language", Second Edition, Prentice Hall, 1988)
and POSIX.1 (IEEE Standard 1003.1 and ISO/IEC 9945-1, 1990, "Portable
Operating System Interface").  These two standards have nothing to do with
each other: you can build C-Kermit with a non-ANSI compiler for a POSIX
system, or for a non-POSIX system with with an ANSI compiler.

9.1.1. POSIX

POSIX.1 defines a repertoire of system functions and header files for use by C
language programs.  Most notably, the ioctl() function is not allowed in
POSIX; all ioctl() functions have been replaced by device-specific functions
like tcsetattr(), tcsendbreak(), etc.

Computer systems that claim some degree of POSIX compliance have made some
attempt to put their header files in the right places and give them the right
names, and to provide system library functions with the right names and
calling conventions.  Within the header files, POSIX-compliant functions are
supposed to be within #ifdef _POSIX_SOURCE..#endif conditionals, and non-POSIX
items are not within these conditionals.

If C-Kermit is built with the -DPOSIX flag, it attempts to configure itself
for a pure POSIX environment.  It defines _POSIX_SOURCE, it calls only
POSIX-defined functions, and it includes POSIX-defined header files.

If Kermit is built with -D_POSIX_SOURCE but not -DPOSIX, C-Kermit must be
built with one of the -DBSD or -DATTSV flags (or one that implies them), but
still uses only the POSIX features in the system header files.  This allows
C-Kermit to be built on BSD or AT&T systems that have some degree of POSIX
compliance, but still use BSD or AT&T specific features.

If Kermit is built with neither -D_POSIX_SOURCE nor -DPOSIX, the functions and
header files of the selected version of UNIX (or VMS, etc) are used according
to the CFLAGS Kermit was built with.

The POSIX standard does not define anything about uucp lockfiles.  "make
posix" uses NO (repeat, NO) lockfile conventions.  If your POSIX-compliant
UNIX version uses a lockfile convention such as HDBUUCP (see below), use
the "posix" entry, but include the appropriate lockfile option in your KFLAGS
on the "make" command line, for example:

   make posix "KFLAGS=-DHDBUUCP"

POSIX.1 also lacks certain other features that Kermit needs.  For example:

 - There is no defined way for an application to do wildcard matching of
   filenames.  Kermit uses the inode in the directory structure, but POSIX.1
   does not include this concept.  (Later POSIX revisions include functions
   named (I think) glob() and fnmatch(), but these functions are not yet in
   Kermit, and might not be appropriate in any case.)

 - There is no POSIX mechanism for sensing or controlling modem signals,
   nor to enable RTS/CTS or other hardware flow control.

 - There is no select() for multiplexing i/o, and therefore no TCP/IP.

 - There is no way to check if characters are waiting in a communications
   device (or console) input buffer, short of trying to read them -- no
   select(), ioctl(fd,FIONREAD,blah), rdchk(), etc.  This is bad for CONNECT
   mode and bad for sli