Simtel MSDOS - Coast to Coast/simteldosarchivecoasttocoast2.iso/windows3/pcucp15.zip/relnotes.doc

Text File | 1994-01-30 | 20KB | 429 lines

Pcucp 1.10 Beta#15
----------------------------------------------------------------------

When realizing the modifications in Beta#14 I also managed to
create a genuine bug which caused the connect time size setting
not to work properly. This has now been corrected.

The unix-end has been slightly modified.


Pcucp 1.10 Beta#14
----------------------------------------------------------------------

The procedure for setting up Terminal(0) at connection time has
been slightly modified in order to reset the scroll limits of
the terminal to its current size. This should remove the effect
of the initial terminal always being apparently 80x24 after
connection on some systems which set the scroll margins for
the size 80x24 upon login.


Pcucp 1.10 Beta#13
----------------------------------------------------------------------

A bug had found its way into the serial driver code I modified
with Beta#12. This caused 9600 bps to be used instead of 19200
bps. This has now been corrected.


Pcucp 1.10 Beta#12
----------------------------------------------------------------------

To my surprise I found that support for speeds 38400 and 57600 bps
exists in the standard Windows 3.1 com-driver. The syntax for the
related system call to set to these speeds is a bit different from
the usual, however, and so these speeds could not be used until now
that the code has been modified to regocnize these as special cases.
Pcucp now also recognizes speeds 115200, 128000 (115200 is in fact
identical to 128000) and 256000, though the standard com-driver
seems not to accept these. Although the speeds 128000 and 256000
seem rather strange they are mentioned in the API 3.1 documentation.

There was a bug in the handling of the numeric keypad keys (with
NUMLOCK on), this has now been corrected and so the numeric keypad
should (again?) work as usual.


Pcucp 1.10 Beta#11
----------------------------------------------------------------------

The terminal emulation has been modified. As a result, Pcucp
should now work with programs like gopher and lynx, which
seem to utilize some of the vt100-control codes in an unusual
(but not neccessarily erratic) way. Also, multiple screen
attribute combinations should work now.


Pcucp 1.10 Beta#10
----------------------------------------------------------------------

Adding NUMLOCK as a shift-key for KEY was not a good idea after
all : existing keyboard settings needed to be written both with
and without NUMLOCK if they were to be emitted whether NUMLOCK is
active or not. Hence NUMLOCK has been removed from the KEY
arguments.

Configuration keywords have been added to enable specifying the
colors in Pcucp windows. (See CONFIG.DOC for details.)


Pcucp 1.10 Beta#09
----------------------------------------------------------------------

Some new keys have been defined for the KEY-keyword. It seems,
however that Windows does not allow combining NumLock to other
shift-keys.

A bug which prevented unix-hosts with long (>~25) names to
establish connection has been corrected.


Pcucp 1.10a Beta
----------------------------------------------------------------------

This is the first release of Pcucp 1.10 Beta for wider distribution.
That is, this version may be made publicly available in ftp servers
and the like without restrictions. This is even encouraged.

The former versions of Pcucp 1.10 beta, were accidentally marked
for Windows 3.1 or later only. This has now been corrected, since
Pcucp should work with Windows 3.0 too.

The window update code has been slightly modified so that selecting
an area is not affected by the update optimization (see #05 below).

A fair warning : Originally I was planning to use some variation
of the user supported software scheme for Pcucp. I still might, if
I get some practical problems solved.


Pcucp 1.10 Beta#08
----------------------------------------------------------------------

A bug was corrected in the escape sequence translation code of
the configuration file parser. The bug caused uppercase characters
to be mapped to lowercase after a hex escape. This modification
affects both the dos and unix end. Other slight modifications have
been incorporated to the unix end as well. These should enable
better error recording when opening a pseudo terminal for a new
shell fails.

The windows now scroll during Edit selection. This enables
selecting larger areas than the current window size. Combining
Shift to selecting may still be more convenient when the areas
are substantially larger than the window size.

The priorization algorithm for terminal windows has been slightly
modified. Now a terminal not only gets a higher priority with
input focus, but also is deprived that priority when focus is
lost to any window. The former behavior left the related channel
priorized when the focus moved to a non-terminal window.

The configuration examples in config.doc have been replaced with
configuration file templates from which various configurations
can be selected by commenting lines in/out. The dos/Windows template
is readily available from the extracted package (PCUCP.CFG), while
the unix template is included in the source file package (PCUCP##.TAR).

I recommend the program wdial (1.00) for dialing in the Windows-
environment. This should be available (e.g.) at :

  garbo.uwasa.fi:/windows/comm/wdial100.zip
  WSMR-SIMTEL20.Army.Mil:/msdos/widows3/wdial100.zip


Pcucp 1.10 Beta#07
----------------------------------------------------------------------

The initial terminal window is now faked a resize at connection
time in order to make it behave identically with terminal windows
open after connection.

Pressing Shift when starting an Edit selection now resumes the
previous selection. This can be used to select areas larger
than the current window size.

Empty lines within the selected area are now copied on the
clipboard with Edit/Copy. The former code skipped such lines.

The binary initialization file format has changed. Therefore, you
may get an error message during initialization. In this case the
former size and position settings are lost. On the next run
(with the same configuration file) Pcucp should operate normally.

I'm planning to release this version (as 1.10a Beta) for wider
distribution, provided that no severe bugs are found.


Pcucp 1.10 Beta#06
----------------------------------------------------------------------

Two new configuration keywords are introduced with this version.

AUTOWRAP controls the autowrap feature. Note that autowrap is now
enabled by default. Earlier versions had it disabled, since some
programs wouldn't work correctly with autowrap enabled. My
impression is that autowrap on should be the default for a real
vt100.

SCRBUFSIZE controls how much memory is allocated for the display
buffer in each (terminal) window. The bigger the buffer the more
lines fit in the scrollback buffer (then again, the bigger the
buffer, the greater the cpu overhead when scrolling ..).

As screen buffers up to 32k were introduced, a bug caused by
16-bit int oveflow was discovered and corrected.

Pcucp now stores window size and position information in a
(binary) file in PCUCPDIR. The file name is same as the name of
the configuration file, but with INI-suffix. The idea is that
Pcucp should now 'remember' where you had each window and how big
they were last time you used pcucp.

Ctrl+Ins and Shift+Ins now operate as shortcuts to Copy and Paste.

The unix-end has been slighty modified. It does no longer set a
default size (80x24) when initializing a new pty, but relies on
the dos end to report the window size right after opening a new
shell. Sometimes it seemed that this default setting was delayed
enough to replace the size reported by the dos end. In practice
this means that 1.01 and older versions of Pcucp may get a pty
with exotic size setting. So, if you are using an older dos end
you should add something like "stty rows 24 columns 80" in e.g.
your .cshrc in order to ensure correct size setting.


Pcucp 1.10 Beta#05
----------------------------------------------------------------------

The window update code has been hacked further. Now the update
is (in effect) aborted as new data arrives from the line. This
results in better performance in screen content transfer, that
is, maximum line usage can be maintained even when text is
flooding on a large terminal window. A side effect is, of course,
that a large screen may not be completely updated until input
from the line ceases. (So the look and feel is again a bit more
'xtermish' :-) The realization of this feature is a bit crude
and may be replaced with something smarter in the future.


Pcucp 1.10 Beta#04
----------------------------------------------------------------------

The window update code has been modified and some bugs have been
corrected. As a result the update should now be considerably faster.


Pcucp 1.10 Beta#03
----------------------------------------------------------------------

The windows now retain their contents when resized. I tried to
realize this in 'xtermish' fashion.

A bug in the window update code has been corrected. This should
make the update slightly faster.


Pcucp 1.10 Beta#02
----------------------------------------------------------------------

By the restriction of distribution in the copyright notice in
read.me I want to limit the distribution of the beta versions
to a small number of users until the software has been proven
to be reasonably robust. So, please don't put this in a ftp-
server or the like (for now).

New features since 1.01 :

  - resizeable windows
  - scrollback buffer
  - copy & paste

These features are functional, but need some refining.

The limit of four terminal windows has been lifted with the
new version.

I'm not quite sure whether moving the document files to the
form of on-line help is actually worthwhile. I presume that an
user of this program has to be at such an level of expertice
that there is not much need of help at run-time : the problems
merely lie in setting up the program, which is probably too
much for a total novice anyway. Don't get me wrong, I don't
mean to look down on a novice user. I would have automated
the setup procedure if I knew how to make it foolproof. It
seems, however, that there is no getting away from the fact
that setting up a program like this simply requires knowledge
about (at least) the basics in modem communications. Users
having this knowledge are not likely to be novices.

The configuration file semantics are intact from 1.01 (as is
config.doc) and there should be no need to change existing
configuration files at this point. New keywords are likely
to be introduced in future.

1.10 requires the unix-end to be recompiled. The new unix-end,
however should be downward compatible with 1.00 and 1.01, that
is, the old dos ends can be used with it.

As you have probably noted, there is no plain-dos executable
for 1.10 at this point. At least this will have to wait until
the Windows-version is about complete and it will probably have
only a subset of the new features. The same goes (only stronger)
for things like versions of Pcucp for other systems and the like.

Comments, bug reports (and proposed fixes) are welcome. Note,
however, that I might not be able to answer personally.

  Jouni Leppäjärvi - [e-mail]

(BTW - If you have tried to reach me with email recently
(~15.5 - 15.6.93) you might want to try again. Quite a
lot of mail had accumulated during that time, but I managed
to corrupt some of it as an indirect result of an recent
os upgrade ..)


Known problems
----------------------------------------------------------------------

If the unix-host is under heavy load, Pcucp might not get a change
to run often enough to keep line usage 100 % and so performance is
degraded. Giving Pcucp a higher priority should help. This should
be no actual problem, since Pcucp uses the CPU in short bursts at
(relatively) long intervals and so most of the CPU time would be
free for other processes. The hard part here is that you need to
convince your unix-operator to do this for you :-)

Note that even in 386 Enchanced mode Pcucp's performance in file
transfer is severely degraded if a dos application is executing
in the foreground. In standard (and real) mode Pcucp is completely
stopped when a dos application is used. In 386 enchanced mode it
seems to help to have the dos-box windowed instead of full screen.
Modifying the Windows background priority or the dos-box foreground
priority should also help, as should a shorter minimum timeslice.

It seems that transfering files in both directions at once
causes a performance hit. This is due to the fact that ACK-
packets race with the constantly flowing data packets and thus
an unnecessary delay is generated between sending data packets.
So far, I haven't been able to figure out an actual fix for
this (without compromising the interactive nature of the packet
protocol).

For some reason file transfer from the pc-end is somewhat slower
than that from the unix-end. The only reason I can think of is
that the unix-end's response time is somewhat longer than that of
the pc-end. This is actually true for the posix/sysv-versions
since the sleep time between polls is constant (100 ms) and
longer than that in the pc-end (55 ms). The bsd-version with
the 'synchronized sleep' realized with select() should fix this,
but it seems not to (?).

In a typical case the connection to the unix-host is realized
trough a device that connects to the pc trough a serial line
and to the unix-host trough a local network. In the following
discussion such a device is known as a 'bridge'. The unfortunate
thing about bridges is that they are not likely to be 8-bit-clean
and hence BITCODE must be used to deal with them, which decreases
the effective line speed. Also, the bridge usually not only
distorts the data but also takes special actions on some character
codes such as C-s, which might cause any output from the bridge
to the pc to stop until a C-q is received by the bridge. Also, there
might be a 'bridge escape' code which causes 'dropping back' to the
bridge prompt from the unix-session. These are (more or less) useful
in the usual case, but not too nice for a Pcucp user, since any
special action like this causes the connection to be effectively
severed. BITCODE helps to keep out of trouble most of time, but it
can't help such special codes not to be generated by line errors.
This is where the configuration setting SALVSTR comes in. This string
is sent over the communications when the remote end has stopped
responding in order to command the bridge to resume a broken session.
Of course, this might not be enough to salvage the connection in all
cases (or maybe not with all bridges either), but it is a simple measure
which should be useful in most (?) cases.

When SALVSTR was introduced I also had to make sure that any packets
echoed by the bridge when a connection is broken would not be seen as
valid packets coming from the remote end. This was done by modifying
the packet checksum algorithm in a way depending on the string returned
by the gethostname() function. Since this function is emulated in the
pc-end by returning 'PC', an unix-host named 'PC' will not work with
pcucp.


A design overwiev - how it works
----------------------------------------------------------------------

Logically, Pcucp divides the serial connection to separate
channels, which are used for shells and file transfer. This
is realized trough a packet protocol that splits the data
stream to be transfered into chunks of suitable size - 'packets'.
In addition to the actual data, some control fields are included
to each packet. Most importantly, these enable data validation
in the receiving end. In case the validation fails, e.g. due
to a line error, the broken packet is resent from the remote
end until it arrives intact. The packets also carry information
about their destination channel. So, the packet protocol
effectively realizes multiple reliable logical channels on a
single unreliable serial data stream.

As soon as a packet is received and validated, an anknowledge
(ACK) is sent to the remote end. After receiving the ACK the
remote end knows that the current packet has been successfully
transfered and so it can proceed to the next. If there is no
ACK for the packet within a time limit, then the current packet
is resent periodically until an ACK arrives. Note that this
strategy also allows the ACK to be lost, provided that the
receiving end is prepared to ignore duplicates of a packet.
(This is realized by including a cyclic sequence number into
the control fields of a packet.)

The procedure described above works as such, but it tends to
waste a fraction of the line capasity, since the transmitting
end has to wait idle until the ACK arrives (or the time limit
expires). This can be corrected by using a 'sliding window'
scheme, that is, sending more packets while waiting for the
ACK for the current one. The 'sliding window' scheme realized
in Pcucp uses a window size of two, that is, it sends (only)
the following packet while waiting for the ACK for the current
packet.

The ACK wait time before resending a packet is somewhat longer
than the expected time, since resending packets when not needed
would cause a severe performance hit. This results in poor
performance on noisy lines. (This is, however, inherently
related to all packet protocols, since in case of an error an
entire packet is lost. A bigger window size would help, but
in the same time compromise the interactive nature of pcucp.)

The packet protocol has a special packet type with fixed data
size. This offers a saving of 1-2 bytes in the packet header.
This saving is considerable on low communications speeds.
Because the size of the packet is fixed, the fixed packet size
definition must agree on both ends or Pcucp won't work. While
PACKETSIZE in configuration file specifies the 'optimum' packet
size it also specifies the fixed packet size.

Because of the fact that in most cases the serial link to the
unix-host is not 8-bit-clean, that is, some characters more
or less mysteriosly change, totally disappear or cause special
effects, Pcucp has the ability of using only a restricted range
of the 256 (=byte) codes available. This is realized through an
algorithm that codes and decodes between 8-bit bytes and the
restricted set. BITCODE keyword in configuration file specifies
how the bytes are to be converted. Since this totally changes
the interpretation of the line data, BITCODE definitions must
agree in both ends for Pcucp to function at all.

A non-elegant feature of the unix-end is that the program polls its
file descriptors sleeping between polls. The elegant way, I think,
would be select(). But since I want to keep the most of the source
modules common for both the unix- and the dos-end, this is a
virtually impossible approach. The change is not even motivated by
excessive CPU load : In fact, my experience suggests that the program
is practically a zero load thing when idle. (Currently, the bsd-version
of Pcucp actually uses select(), but not in the orthodox way.)