readme

一个通讯程序源码

     support, you must, as root, chmod +rw all tty lines used by ecu.
     As of this writing, SCO operating systems are the only platform
     which ecuungetty supports.  The 'make install' does not do the
     chmods, because *you* should make the informed choice to do it.

10.  The gendial subdirectory contains some rigorous, yet
     experimental, SCO dialer programs for use with ecu, cu and uucico.
     They are currently undocumented and "as-is."  I have used each
     of them successfully at one time or another, but some have been
     modified since they were last proven to work.

     I use the T2500, Microcom 9624 and USR 2400 entry all the time.

     Make sure you like the modem options before using one of these
     dialers.  In particular, I enable remote access to Telebits.

11.  Make neat removes many temporary files that tend
     to accumulate over time. No make targets are removed.
     Make clean runs make neat and also removes all .o files.
     Make clobber runs make clean and also removes executables.

--------------------------------------------------------------------
Notes:

1.  KERMIT:

C-Kermit 5 (as of version 5A(179)) directly supports ECU's needs.
C-Kermit 5 is in beta testing as of this writing and appears to
be in excellent shape.  You will need a ~/.kermrc to set up the
desired characteristics.  I use:

set block 3
set win 3
set send packet-l 2048
set receive packet-l 2048
set file name literal
set file type bin
show

2.  SELECT(S) and CFLAGS "WORKING_SELECT"

ECU uses select() where possible for two purposes:
1. wait on a tty (comm line) read with timeout -and-
2. timeout (nap replacement).

If you have a working select, use -DWORKING_SELECT.
The Configure procedure does the job for you for systems I know about.

SCO XENIX V/386 Release 2.3.1 (and evidently 2.3.2) have a
broken-dead, yet fixable, BSD-style select() feature.  Also,
select() is missing from libc.a.  While ecu does not *require*
select(S), it is much more efficient to use it.  The x386sel
subdirectory in this release has information (thanks to
csch@netcs, ivar@acc, and ag@elgar) on how to fix the kernel and
to add select() to libc.a.  You'll have to add WORKING_SELECT to
config.local if you do this.

Select(S) is fully functional in SCO UNIX 3.2.0.  I am unsure of ODT
1.0/UNIX 3.2.1.  It is broken in ODT 1.1/UNIX 3.2v2.  It does work
in 3.2v4/ODT 2.0.

I found it in /usr/lib/libinet.a on the ISC system I used to
compile for ISC.  It works fine there.  I automatically put
WORKING_SELECT into the Makefile.

It works fine on the Sun and SVR4, naturally.

3.  SCO MULTISCREEN BUG

There has been a bug in the multiscreen driver for some time
wherein a MEDIA COPY (screen dump) sequence ("ESC [ 2 i") leaves
the "ESC [ 2" part "active".  When a screen dump (Cursor 5)
command is given, I do the screen dump, then send a "l" to the
screen to work around the bug ("ESC 2 [ l" unlocks the keyboard,
essentially a no-op).  If and when it gets fixed, you'll see an
"l" show up on your screen after a screen dump sequence.  To fix
this, comment out the
#define MULTISCREEN_DUMP_BUG
at the top of ecuscrdump.c.

The bug remains in place for every SCO product from XENIX 2.0.6
through UNIX 3.2v4.  It is a minor nuisance and there are a great
many other things they have fixed/improved in these years that
were much more important.

Note that from multiscreens, screen dump produces a dump of the
actual screen contents, including ecu-generated output.  When
using a non-multiscreen terminal, screen dump dumps only the
shared memory virtual screen as received from the host.

If, at a multiscreen, you wish a screen dump free of ecu output
"pollution," use Shift-Tab (BkTab) to redraw the screen, then
perform the screen dump.  If you are not on a multiscreen, then the
screen dump comes from the (sometimes inexact) screen memory
representation and this step is not necessary.

4. GCC

In case you didn't know, GCC is a great C compiler.  It generates
excellent code and gives excellent diagnostics and warnings.
There are more options available than for a Coup de Ville, so you
have to be careful if you get too fancy.  I should know -- I
think I may have done it.  With Configure and config.c, I have
tried to choose the best option set for ECU and it's utilities.
If you want to play around, you can place GCC_EXTRA_CFLAGS
definitions in a config.local file and experiment away.

I tried -pedantic and -ansi under SCO, but there are just too many
complaints about the development system header files:

  1. #ident not allowed in ANSI C (boo hiss on ANSI <again>)
  2. unterminated character constant in curses.h (an apostrophe
     in a -comment- threw gcc for a loop)
  3. bit fields not unsigned in machdep.h
  4. blah etc. etc.

I VERY reluctantly hacked my development system's header files so
I could exploit the more critical error checking, but I do not
recommend you do it for purposes of making ECU.  Hopefully since
I have done it and fixed what gcc reported, you don't have to.

On the Sun, you cannot use -ansi because of the whole way ioctl
2nd parameter defines are built (I refuse to demand you run gcc's
fixincludes to use my software).  Compilation proceeds with no
error, but few if any of your ioctls will work.  Also, with
-pedantic, you get one hundred gazillion complaints about text
after #else and #endif.  I hacked my compiler to omit that one
pedantic complaint and made a test run with -ansi and -pedantic.
As of version 3.15, I get no other warnings outside of some
funkiness in va_args.  With that exercise complete, I bid -ansi
and -pedantic adieu for a while with a good feeling about the
future should the ANSI KGB actually seize real power in Cyberdom.

Gcc's idea of prototype validity is just too much for me.  With
MSC ANSI, prototype arguments are tested at *reference* time not
*definition* time.  Thus with MSC it is convenient to define a
file with all the prototypes in it and include it everywhere.  To
do that with gcc, you'd have to include *every* header file you
ever use just to make sure structs and types referred to are
defined.

Other than all this, the code fares pretty well with -ansi
-pedantic I guess I am just not prepared for all the various
flavors of "ANSI" yet ...  and they grow more numerous ...  and
the throathold tightens on venerable code.

With the warnings I have enabled, you may get warnings about
variables possibly clobbered by longjmp.  Worry not.  You may get
warnings about /* in comments, but they will be from system
header files, not my code :-).

I have used gcc 1.40, 2.1 and 2.2.2 to compile ecu on SunOS and
SCO UNIX. 

5.  XTERMS

If you are using an xterm to run ecu,

1. the maximum geometry is 80x43
2. 4014 emulation is untested
3. you should use the following resources:

XTerm*titeInhibit:     true # enable screen clear functions normally
XTerm*curses:          true # curses bug fix

If titeInhibit fails to work (some versions which use terminfo as
their basis do fail), then remove the ti and te entries from
/etc/termcap.

The file models/funckeymap has keyboard definitions for a number
of xterm implementations.  Use kbdtest3 to determine what key
sequences are generated by each function key.  If a key produces
no output or ambiguous output (Home and End both produce the same
sequence), use xev to determine the keysym associated with the
keys in question.  Use xmodmap to map the keys to unique
sequences.  For instance, on the SunOS MIT server, IPX key
presses of Home and End produce:

Home:
KeyPress event, serial 13, synthetic NO, window 0xd00001,
    root 0x8006d, subw 0x0, time 2225786294, (124,70), root:(385,331),
    state 0x0, keycode 75 (keysym 0xffd8, F27), same_screen YES,
                                          ^^^
                                           |
                                           `--- name to use with xmodmap
    XLookupString gives 0 characters:  ""

End:
KeyPress event, serial 15, synthetic NO, window 0xd00001,
    root 0x8006d, subw 0x0, time 2225787104, (124,70), root:(385,331),
    state 0x0, keycode 119 (keysym 0xffde, R13), same_screen YES,
                                           ^^^
                                            |
                                            `-- name to use with xmodmap
    XLookupString gives 0 characters:  ""

Then, choose unique strings to map the keys to.  I generally use
the SCO function key sequences (described in the very first entry
in the distribution model/funckeymap).  Construct XTerm translations
for the chosen sequences.  An example for Home (F27) and End (R13)
is shown below.

XTerm*VT100*Translations: #override\
     <Key>F27:        string(0x1b) string("[H") \n \
     <Key>R13:        string(0x1b) string("[F") \n \
     Shift<Key>Tab:   string(0x1b) string("[Z")

Included in the above is a mapping for "backwards Tab," Shift Tab.
Most servers map Shift Tab to generate the same as unshifted Tab
(or not mapped at all).

Run kbdtest3 and see if all keys now produce a unique sequence.
If not, repeat the above process until you have each key producing
a unique sequence.

Sometimes, you just won't be able to get a particular key to work.
For instance, one X server I used refused to generate an event for
Shift Keypad 5 (Shift<Key>KP_5).  In these cases, you will have to
choose another key, perhaps a higher numbered function key.  Likewise,
if you are using a keyboard unaffected by the True Blue Path,
you may not have a key marked "Home" or "End" (I pity you :-> heh):
choose a replacement you are unlikely to need otherwise.

6. SCO UNIX MEMMOVE() AND GCC

Use of memmove has been eliminated.  See memmove/README for some
history.

7. FAS/i

For the brave, an instrumented version of FAS 2.08 is included
with this release for those who need driver instrumentation at
the cost of performance and portability.  It is not supported (Do
Not Contact Uwe Doering).  I am not at all interested in starting
a new tty faction.  Uwe has done a brilliant job of striking a
balance between compatibility and performance.  I only name this
thing FAS/i to show the derivation from FAS while marking it as
different.

8. EXCEL LOGFILE INTERFACE

The excel logfile utility posted to comp.sources.misc for ECU 3.0
remains compatible with this release of ECU.

9. KBDTEST3

This program is included to help you inspect your keyboard for
making funckeymap entries or for preparing you to ask for help
from me in getting your keyboard functional.

  cc -o kbdtest3 kbdtest.c
  run it, following the instructions

Once you have installed a new funckeymap, the ECU interactive
command "kbdtest" may assist in verifying it works.

I would appreciate your mailing me the output file (kbdtest3.out)
from each keyboard you try out regardless of what you do otherwise
(if your keyboard is not a SCO multiscreen or ISC virtual console).
This will assist me in making funckeymap entries for futures
releases.

-------------------------------------------------------------------------
This program, it sources, objects and utilities are placed in the
public domain.

Warren H. Tucker     [e-mail]    {gatech,emory}!n4hgf!wht
TuckerWare           [phone]
150 West Lake Drive
Roswell, GA 30075