RBcomm is a lean and mean DESQview-aware
comm program by Ralf Brown. Freeware.
Main features of v3.45: .
* runs in as little as 47K .
* DESQview-aware to minimize CPU usage; .
provides some extra features under DV .
* 250-number dialing directory .
* ANSI/VT102, VT52, AVATAR/0 emulations .
* seamless file transfers using DSZ, etc.

RBcomm is a lean and mean DESQview-aware
comm program by Ralf Brown. Freeware.
Main features of v3.45: .
* runs in as little as 47K .
* DESQview-aware to minimize CPU usage; .
provides some extra features under DV .
* 250-number dialing directory .
* ANSI/VT102, VT52, AVATAR/0 emulations .
* seamless file transfers using DSZ, etc.
Changes since v3.41

Bugfixes:
OPEN_LOG inside a MULTI now works properly.

BREAK inside a MULTI will now work for all re-compiled macro files

Selecting [W]rite from the scrollback screen will no longer present
the dialing directory file as the default destination

When dialing a list of numbers, the correct item is deleted from the
list on a successful connect (previously, the *following* item was
deleted)

Enhancements:
more efficient screen updates under DESQview will allow RBcomm to
handle higher speeds on incoming data before invoking flow control
(at the cost of increased jerkiness when it is spending most of
the available CPU time handling incoming characters)

by request: increased number of COM port definitions in the
configuration from four to eight

by request: WHENI command which is identical to WHEN except that it
ignores the case of the characters in the string to be matched.

new command: EVERY
similar to DELAYED, but repeats execution indefinitely

the receive buffer size is now adjustable. A larger buffer may
give better performance at high speeds, while a smaller buffer
will save memory.

Known problems:
You may need to run RBcomm via LOADFIX if your DOS's low-memory use
is sufficiently small. This will be corrected in the next release,
but I didn't have time to make the necessary internal changes
which will completely avoid the problem.

I've been experiencing occasional lockups when returning to RBcomm
from a file transfer. This started in RBcomm 3.41 when I upgraded
QEMM from 7.04 to 7.50 and appears to be related to a known hardware
bug in my Pentium's "Neptune" chipset's 16550 emulation.
Unfortunately, nothing I've tried has completely fixed the trouble.