changes

一个通讯程序源码

Changes since 3.20 release

==> Patch 1

1992-09-14-04:05-hdbintf.c-wht@n4hgf-rcvr process was not going away reliably 
1992-09-13-12:52-ecutty.c-wht@n4hgf-add tty_is_scoterm 
1992-09-13-12:52-ecuicmd.c-wht@n4hgf-show tty_is_scoterm during stat 
1992-09-13-12:52-ecu.h-wht@n4hgf-add tty_is_scoterm 
1992-09-13-02:05-ecuicmhist.c-wht@n4hgf-redisplay escape prompt on error exit 

ALERT: Something is happening to make ODT 2.0 scoterms go CPU
open-loop and unresponsive to anything but a kill -9.  I will be
looking into this, but if anyone beats me to it, please let me
know what you find ASAP.  Thanks.

1.  The receiver process was not being killed during dialing when
ECU was invoked with "ecu directoryentry".  Dialing was not
possible until you interrupted the program and tried again.  This
has been fixed.  This boo-boo crept as part of some cleanup work
(smile) just before posting.

2.  An <scoterm> indication has been added to the stat command
output.  This is a start on the debugging effort of the scoterm
problem that had to be put off for the critical nature of item 1.

3.  After the history function displays "no interactive commands
saved", you are still in command mode.  There was no visual hint
to let you know that.  Then you could type, thinking you were
sending to a remote, when in fact you were feeding the text to
the command line.  Now, ECU redisplays the escape prompt to show
you are still in command mode.

4.  Typos in the README and README 3.20 were fixed.

5.  This file was added.

==> Patch 2

1992-09-15-18:52-ecutty.c-wht@n4hgf-left some debug code in patch01 dammit 

6. Remove debug code from _setcolor().

==> Patch 3

1992-09-17-06:27-ecuicmd.c-wht@n4hgf-add <7-bit kbd> to stat 
1992-09-17-05:33-mapkey/README-wht@n4hgf-0xE0 should read 0xE1
1992-09-17-05:16-ecuxkey.h-wht@n4hgf-finally, 0xE1-0xFA as promised in 3.10  
1992-09-16-14:13-ecunumrev.c-wht@n4hgf-add M and F version qualifiers 
1992-09-16-13:54-ecuusage.c-wht@n4hgf-add fkmap usage 
1992-09-16-13:33-funckeymap.c-wht@n4hgf-add fkmap -l name 
1992-09-16-13:29-termecu.h-wht@n4hgf-add TERMECU_UNRECOVERABLE 
1992-09-16-13:29-ecusighdl.c-wht@n4hgf-add TERMECU_UNRECOVERABLE text 
1992-09-15-18:52-ecutty.c-wht@n4hgf-left some debug code in patch01 dammit 

7.  Information on tty "Device busy" errors and color support
have been added to README.Q-and-A.  Obsolete information was
removed.

8. The -l switch was added to the fkmap commands:
       fkmap -l <name>
The -l form reads an entire funckeymap definition matching <name>
from ~/.ecu/funckeymap (if not found there, in a file by the same
name in the library directory).  This form behaves exactly
in the same manner as the command line switch -F.
Due to the drastic nature of this command, if it fails to
execute properly, ECU terminates itself.  Note that
improper use of this form of the command can still render
ECU an albatross (with Home unrecognizable).

9.  The original high-bit character space assignments for Alt-A
through Alt-Z that I chose for ECU made good sense ...  to a
parochial American.  Michael Traub <emory!btcs.bt.co.uk!traub>
sets me straight, but mapkey/README was incorrect.  Each hex
value was off by one.

10.  If the console has parity enabled, the interactive stat
command now reports <7-bit kbd>.  Knowing this can be important
if you are using Alt-[A-Z].  Or if you are trying for some kind
of unlikely tandem 8-bit transparent path (telnet to a box, run
ecu to call home, login, use ECU there to talk to your amateur
radio PK-232/MBX TNC over 14 MHz AMTOR to the UK to a Kantronics
TNC hooked to an SCO box, login, make an ECU call to a certain
Universal Import-Export ...  uh, hi -- I seem to have dozed off).

11.  At least one ISC SVR3 user had a Devices entry with the
modem control ",M" suffix I thought was only used in SVR4 UUCP.
The suffix presence is now detected on all platforms.

12. ecusea.c had two fcntl.h inclusions.  XENIX could not
handle this.

==> Patch 4

13. [e-mail] (Jeff Johnson) suggested a change
in the SVR4 LCK.. logic, stating that the use of <sys/sysmacros.h>
is deprecated.

> Here is an excerpt from my <sys/sysmacros.h>:
> 
>    WARNING: The device number macros defined here should not be
>    used by device drivers or user software.  Device drivers
>    should use the device functions defined in the DDI/DKI
>    interface (see also ddi.h).  Application software should make
>    use of the library routines available in makedev(3).  A set of
>    new device macros are provided to operate on the expanded
>    device number format supported in SVR4.  Macro versions of the
>    DDI device functions are provided for use by kernel proper
>    routines only.  Macro routines bmajor(), major(), minor(),
>    emajor(), eminor(), and makedev() will be removed or their
>    definitions changed at the next major release following SVR4.

14. On some systems, the video attributes were not reverted to
"normal" after some reverse video or underlined strings (e.g,
"[interactive mode]").

15. I removed the Metro Link pts support.  This was quite obsolete
since only very early Metro Link software used pts'.

16.  FAS 2.10 users are getting SIGUSR1 sent to the transmitter.
I suspect this is a bug in FAS evoked by the kill(getty,SIGUSR1)
performed by ecuungetty, but I am have no real clue.  This needs
resolving, but I have little time right now.  This patch adds
signal(SIGUSR1,SIG_IGN) to eliminate the problem.

17. Console xon/xoff support has been added.  EMACS users
lament the loss of ^S/^Q.  (I personally consider it evolution
in action :->).  A new inetractive and a new procedure
command have been added  Also, the status is reported by
the interactive stat command.

   conxon on  - honor xon/xoff locally
   conxon off - pass ^S/^U to remote

If you turn conxon off, there will be no local software flow control
so you probably need hardware flow control for proper operation.
Refer to the rtscts command descriptions for more information
(I pray you are using a tty driver that supports the kind
of hardware flow control your modem requires).

18.  The procedure file transfer commands did not get
rearranged to look for the file transfer programs in the
ecu library directory.

19. Chains of else statements may fail to operate properly
in certain arrangements.  The known failure was fixed.