ckubwr.txt

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

  3.0.1. Interrupt Conflicts

   [ [109]Top ] [ [110]Contents ] [ [111]Section Contents ] [ [112]Next ]

   PCs are not the best platform for real operating systems like Unix.
   The architecture suffers from numerous deficiencies, not the least of
   which is the stiflingly small number of hardware interrupts (either 7
   or 15, many of which are preallocated). Thus adding devices, using
   multiple serial ports, etc, is always a challenge and often a
   nightmare. The free-for-all nature of the PC market and the lack of
   standards combined with the diversity of Unix OS versions make it
   difficult to find drivers for any particular device on any particular
   version of Unix.

   Of special interest to Kermit users is the fact that there is no
   standard provision in the PC architecture for more than 2
   communication (serial) ports. COM3 and COM4 (or higher) will not work
   unless you (a) find out the hardware address and interrupt for each,
   (b) find out how to provide your Unix version with this information,
   and (c) actually set up the configuration in the Unix startup files
   (or whatever other method is used). Watch out for interrupt conflicts,
   especially when using a serial mouse, and don't expect to be able to
   use more than two serial ports.

   The techniques for resolving interrupt conflicts are different for
   each operating system (Linux, NetBSD, etc). In general, there is a
   configuration file somewhere that lists COM ports, something like
   this:

  com0    at isa? port 0x3f8 irq 4      # DOS COM1
  com1    at isa? port 0x2f8 irq 3      # DOS COM2

   The address and IRQ values in this file must agree with the values in
   the PC BIOS and with the ports themselves, and there must not be more
   than one device with the same interrupt. Unfortunately, due to the
   small number of available interrupts, installing new devices on a PC
   almost always creates a conflict. Here is a typical tale from a Linux
   user (Fred Smith) about installing a third serial port:

     ...problems can come from a number of causes. The one I fought with
     for some time, and finally conquered, was that my modem is on an
     add-in serial port, cua3/IRQ5. By default IRQ5 has a very low
     priority, and does not get enough service in times when the system
     is busy to prevent losing data. This in turn causes many resends.
     There are two 'fixes' that I know of, one is to relax hard disk
     interrupt hogging by using the correct parameter to hdparm, but I
     don't like that one because the hdparm man page indicates it is
     risky to use. The other one, the one I used, was to get 'irqtune'
     and use it to give IRQ5 the highest priority instead of nearly the
     lowest. Completely cured the problem.

   Here's another one from a newsgroup posting:

     After much hair pulling, I've discovered why my serial port won't
     work. Apparently my [PC] has three serial devices (two comm ports
     and an IR port), of which only two at a time can be active. I
     looked in the BIOS setup and noticed that the IR port was
     activated, but didn't realize at the time that this meant that COM2
     was thereby de-activated. I turned off the IR port and now the
     serial port works as advertised.
    ________________________________________________________________________

  3.0.2. Windows-Specific Hardware

   [ [113]Top ] [ [114]Contents ] [ [115]Section Contents ] [ [116]Next ]
   [ [117]Previous ]

   To complicate matters, the PC platform is becoming increasingly and
   inexorably Windows-oriented. More and more add-on devices are "Windows
   only" -- meaning they are incomplete and rely on proprietary
   Windows-based software drivers to do the jobs that you would expect
   the device itself to do. PCMCIA, PCI, or "Plug-n-Play" devices are
   rarely supported on PC-based Unix versions such as SCO; Winmodems,
   Winprinters, and the like are not supported on any Unix variety (with
   [118]a few exceptions). The self-proclaimed Microsoft PC 97 (or later)
   standard only makes matters worse since its only purpose to ensure
   that PCs are "optimized to run Windows 95 and Windows NT 4.0 and
   future versions of these operating systems".

   With the exception noted (the Lucent modem, perhaps a handful of
   others by the time you read this), drivers for "Win" devices are
   available only for Windows, since the Windows market dwarfs that of
   any particular Unix brand, and for that matter all Unixes (or for that
   matter, all non-Windows operating systems) combined. If your version
   of Unix (SCO, Linux, BSDI, FreeBSD, etc) does not support a particular
   device, then C-Kermit can't use it either. C-Kermit, like any Unix
   application, must access all devices through drivers and not directly
   because Unix is a real operating system.

   Don't waste time thinking that you, or anybody else, could write a
   Linux (or other Unix) driver for a Winmodem or other "Win" device.
   First of all, these devices generally require realtime control, but
   since Unix is a true multitasking operating system, realtime device
   control is not possible outside the kernel. Second, the specifications
   for these devices are secret and proprietary, and each one (and each
   version of each one) is potentially different. Third, a Winmodem
   driver would be enormously complex; it would take years to write and
   debug, by which time it would be obsolete.

   A more recent generation of PCs (circa 1999-2000) is marketed as
   "Legacy Free". One can only speculate what that could mean. Most
   likely it means it will ONLY run the very latest versions of Windows,
   and is made exclusively of Winmodems, Winprinters, Winmemory, and
   Win-CPU-fans (Legacy Free is a concept [119]pioneered by Microsoft).

   Before you buy a new PC or add-on equipment, especially serial ports,
   internal modems, or printers, make sure they are compatible with your
   version of Unix. This is becoming an ever-greater challenge; only a
   huge company like Microsoft can afford to be constantly cranking out
   and/or verifying drivers for the thousands of video boards, sound
   cards, network adapters, SCSI adapters, buses, etc, that spew forth in
   an uncontrolled manner from all corners of the world on a daily basis.
   With very few exceptions, makers of PCs assemble the various
   components and then verify them only with Windows, which they must do
   since they are, no doubt, preloading the PC with Windows. To find a
   modern PC that is capable of running a variety of non-Windows
   operating systems (e.g. Linux, SCO OpenServer, Unixware, and Solaris)
   is a formidable challenge requiring careful study of each vendor's
   "compatibility lists" and precise attention to exact component model
   numbers and revision levels.
    ________________________________________________________________________

  3.0.3. Modems

   [ [120]Top ] [ [121]Contents ] [ [122]Section Contents ] [ [123]Next ]
   [ [124]Previous ]

   External modems are recommended:

     * They don't need any special drivers.
     * You can use the lights and speaker to troubleshoot dialing.
     * You can share them among all types of computers.
     * You can easily turn them off and on when power-cycling seems
       warranted.
     * They are more likely to have manuals.

   Internal PC modems (even when they are not Winmodems, which is
   increasingly unlikely in new PCs) are always trouble, especially in
   Unix. Even when they work for dialing out, they might not work for
   dialing in, etc. Problems that occur when using an internal modem can
   almost always be eliminated by switching to an external one. Even when
   an internal modem is not a Winmodem or Plug-n-Play, it is often a
   no-name model of unknown quality -- not the sort of thing you want
   sitting directly on your computer's bus. (Even if it does not cause
   hardware problems, it probably came without a command list, so no Unix
   software will know how to control it.) For more about Unix compatible
   modems, see:

  [125]http://www.idir.net/~gromitkc/winmodem.html

   Remember that PCs, even now -- more than two decades after they were
   first introduced -- are not (in general) capable of supporting more
   than 2 serial devices. Here's a short success story from a recent
   newsgroup posting: "I have a Diamond SupraSonic II dual modem in my
   machine. What I had to end up doing is buying a PS/2 mouse and port
   and install it. Had to get rid of my serial mouse. I also had to
   disable PnP in my computer bios. I was having IRQ conflicts between my
   serial mouse and 'com 3'. Both modems work fine for me. My first modem
   is ttyS0 and my second is ttyS1." Special third-party multiport boards
   such as [126]DigiBoard are available for certain Unix platforms
   (typically SCO, maybe Linux) that come with special platform-specific
   drivers.
    ________________________________________________________________________

  3.0.4. Character Sets

   [ [127]Top ] [ [128]Contents ] [ [129]Section Contents ] [ [130]Next ]
   [ [131]Previous ]

   PCs generally have PC code pages such as CP437 or CP850, and these are
   often used by PC-based Unix operating systems, particularly on the
   console. These are supported directly by C-Kermit's SET FILE
   CHARACTER-SET and SET TERMINAL CHARACTER-SET commands. Some PC-based
   Unix versions, such as recent Red Hat Linux releases, might also
   support Microsoft Windows code pages such as CP1252, or even Latin
   Alphabet 1 itself (perhaps displayed with CP437 glyphs). (And work is
   in progress to support Unicode UTF8 in Linux.)

   Certain Windows code pages are not supported directly by C-Kermit, but
   since they are ISO Latin Alphabets with nonstandard "extensions" in
   the C1 control range, you can substitute the corresponding Latin
   alphabet (or other character set) in any C-Kermit character-set
   related commands:

  Windows Code Page    Substitution
   CP 1004              Latin-1
   CP 1051              HP Roman-8

   Other Windows code pages are mostly (or totally) incompatible with
   their Latin Alphabet counterparts (e.g. CP1250 and Latin-2), and
   several of these are already supported by C-Kermit 7.0 and later
   (1250, 1251, and 1252).
    ________________________________________________________________________

  3.0.5. Keyboard, Screen, and Mouse Access

   [ [132]Top ] [ [133]Contents ] [ [134]Section Contents ] [ [135]Next ]
   [ [136]Previous ]

   Finally, note that as a real operating system, Unix (unlike Windows)
   does not provide the intimate connection to the PC keyboard, screen,
   and mouse that you might expect. Unix applications can not "see" the
   keyboard, and therefore can not be programmed to understand F-keys,
   Editing keys, Arrow keys, Alt-key combinations, and the like. This is
   because:

    a. Unix is a portable operating system, not only for PCs;
    b. Unix sessions can come from anywhere, not just the PC's own
       keyboard and screen; and:
    c. even though it might be possible for an application that actually
       is running on the PC's keyboard and screen to access these devices
       directly, there are no APIs (outside of X) for this.
    ________________________________________________________________________

  3.0.6. Laptops

   [ [137]Top ] [ [138]Contents ] [ [139]Section Contents ] [
   [140]Previous ]

   (To be filled in . . .)
    ________________________________________________________________________

  3.1. C-KERMIT AND AIX

   [ [141]Top ] [ [142]Contents ] [ [143]Section Contents ] [ [144]Next ]
   [ [145]Previous ]

   SECTION CONTENTS

  3.1.1. [146]AIX: General
  3.1.2. [147]AIX: Network Connections
  3.1.3. [148]AIX: Serial Connections
  3.1.4. [149]AIX: File Transfer
  3.1.5. [150]AIX: Xterm Key Map

   For additional information see:
     * [151]http://www.emerson.emory.edu/services/aix-faq/
     * [152]http://www.faqs.org/faqs/by-newsgroup/comp/comp.unix.aix.html
     * [153]http://www.cis.ohio-state.edu/hypertext/faq/usenet/aix-faq/to
       p.html
     * [154]http://aixpdslib.seas.ucla.edu/
     * [155]http://www.rootvg.net (AIX history)
     * [156]ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/part1
     * [157]ftp://mirrors.aol.com/pub/rtfm/usenet-by-hierarchy/comp/unix/
       aix

   and/or read the [158]comp.unix.aix newsgroup.
      ______________________________________________________________________

    3.1.1. AIX: General

   [ [159]Top ] [ [160]Contents ] [ [161]Section Contents ] [ [162]Next ]

   About AIX version numbers: "uname -a" tells the two-digit version
   number, such as 3.2 or 4.1. The three-digit form can be seen with the
   "oslevel" command (this information is unavailable at the API level
   and is reportedly obtained by scanning the installed patch list).
   Supposedly all three-digit versions within the same two-digit version
   (e.g. 4.3.1, 4.3.2) are binary compatible; i.e. a binary built on any
   one of them should run on all others, but who knows. Most AIX
   advocates tell you that any AIX binary will run on any AIX version
   greater than or equal to the one under which it was built, but
   experience with C-Kermit suggests otherwise. It is always best to run
   a binary built under your exact same AIX version, down to the third
   decimal place, if possible. Ideally, build it from source code
   yourself. Yes, this advice would be easier to follow if AIX came with
   a C compiler.
      ______________________________________________________________________

    3.1.2. AIX: Network Connections

   [ [163]Top ] [ [164]Contents ] [ [165]Section Contents ] [ [166]Next ]
   [ [167]Previous ]

   File transfers into AIX 4.2 or 4.3 through the AIX Telnet or Rlogin
   server have been observed to fail (or accumulate huge numbers of
   correctable errors, or even disconnect the session), when exactly the
   same kind of transfers into AIX 4.1 work without incident, as do such