dxpc Change Log

This is dxpc version 3.9.2

3.9.2 Release:

Improved pidfile handling code contributed by jay Berkenbilt.

3.9.1 Release:

Fix assertion failure on 64-bit architectures using LZO 2.0+.

Clean up harmless compiler warnings in ClientMultiplexer and ServerMultiplexer.

3.9.0 Release:

Re-implemented EncodeBuffer/DecodeBuffer to use considerably less CPU and
very slightly improve compression.

Builds with LZO 2.0 release.

Compiles under the Mingw environment to create native Win32
binaries.

Added dxpcssh sample script courtesy of Wicher Minnaard.

Added dxpc.spec file contributed by Daniel Mealha Cabrita.

Fixed some small memory leaks and potential buffer overruns.

Indented all sources.

3.8.2 Release:

Made configure script check for <iostream> or <iostream.h> and use whichever
is available, which enables building with gcc 3.2; minor cleanups to configure
script.

3.8.1 Release:

Patched to compile properly on Digital Unix (workaround for buggy DEC
compiler).

Cleaned up various signed/unsigned and similar errors; now compiles cleanly
with "gcc -ansi -pedantic -Wall".

Added -b option to force backing store; originally by Ken Raeburn,
integrated with 3.8.0 by Albert Ting.

Changed license to BSD license.

3.8.0 Release:

Minor syntax fixes:  string constant was split over a line in main.C
(non-gcc compilers don't like this); added #include stdlib.h to
EncodeBuffer.C; removed unnecessary virtual attribute from
Compresser::compressBuffer and Decompresser::decompressBuffer; made
FILL_POLY_MAX_POINTS unsigned to get rid of some signed/unsigned mismatches;
updated copyright notice and man page.

Beta 4:

Performance optimizations in EncodeBuffer and in the EncodeBuffer/Compresser
and DecodeBuffer/Decompresser interfaces.

Removed (#if'd out) unused EncodeBuffer::encodeByte method.

Initialize ServerChannel::decompresser to NULL when -i0 flag is used to
disable image compression (fixes segfault problem when using -i0).

Beta 3:

configure script now supports --with-lzo-lib option to specify path to
LZO library (in case it is in a non-standard location).

Updated usage command, which was sorely out of date.

Added -D option to specify display on server side; takes precedence over the
DISPLAY evironment variable.

Added proxy port to lock file name, making it possible to run multiple
processes on the same unit on different proxy ports.

Changed default image compression level to 999.

Beta 2.1:

Now compiles under Cygwin32 environment for Windows 95/NT targets. No other
changes.

Beta 2:

Added X_GetAtomName fix proposed by Ken Raeburn <raeburn@raeburn.org>.
Now works properly with emacs 20.3. See source level changes section below
for details.

configure script works on machines with broken cc (like Solaris-x86),
tests for lzo library, and detects DXPC_ACCEPT_IS_SIZE_T more reliably.

Beta 1:

This release consists of dxpc-3.7.0 with support for LZO bitmap image
compression hacked in. This significantly helps bitmap-happy applications
such as Netscape.

Two fixes contributed by Alexander Elkins (aoe@fc.hp.com) are also included;
see source level changes section below for details.

This has currently been tested on Solaris-x86 and FreeBSD platforms; ymmv.

dxpc-3.8.0 is not backward compatible with any previous version.

User level changes:

dxpc now accepts the new option -i[n] for image compression. [n] is the
image compression level; higher levels offer better compression at the cost
of greater CPU and memory utilization (mostly on the client proxy). Valid
values for [n] are:

0 : No compression (except for the very limited compression supported in
    3.7.0). In other words, behaves like 3.7.0 (but is still incompatible
    with it...)

1 : LZO lzo1x_1 compression; very fast, low CPU and memory use, reasonable
    compression. This is the default and recommended value.

2-9: LZO lzo1c_... variant compression algorithms. lzo1c_2 actually seems to
     be worse than lzo1x_1...

99: LZO lzo1c_99 algorithm. Slow, but pretty good compression. NB: I have
    seen a couple of unexplained crashes when using this level. Not
    recommended.

999: LZO lzo1x_999 compression. Slow (but fast enough to feed a 128K ISDN
     link when hosted on a Pentium II/300 without maxing out the
     processor), but good compression.

I recommend -i999 for most applications unless you have a very slow CPU;
you are welcome to experiment with the other variants, but they are
mostly there for experimental purposes.

NB: the -i parameter is only valid on the dxpc instance which is accepting
the connection. This is usually the client proxy, but the -w flag changes it
to the server proxy. This proxy will communicate the compression level to
the other end at startup, eliminating problems with differing compression
levels.

Source level changes:

Building dxpc now requires the lzo compression libraries, available from
http://wildsau.idv.uni-linz.ac.at/mfx/lzo.html.

The passing of the -i option is handled by tacking a parameter on after the
version number sent at startup. Note that despite the comment to the
contrary in the code, this is only sent one way, from the proxy accepting
the connection to the initiator.

Compression is indicated in the stream by a 1-bit compression indicator
sent following the compressed X_PutImage parameters and preceding the bitmap
data. Note that is present even with -i0, so dxpc 3.8.0 with the -i0 flag is
actually (very slightly) worse than dxpc-3.7.0.

Files changed:

Compresser.[CH]    : new files; client proxy support for compressing
		     X_PutImage messages; Cygwin32 hackery.
Decompresser.[CH]  : new files; server proxy support for decompressing
		     X_PutImage messages; Cygwin32 hackery.
main.C:		   : Handle new -i command line option; clean up -w support
		     slightly; Cygwin32 hackery.
ClientChannel.C    : create and call Compresser instance if necessary;
		     Alexander Elkins fix #1; Cygwin32 hackery.
ServerChannel.C    : create and call Decompresser instance if necessary;
		     Alexander Elkins fix #1; Ken Raeburn fix; Cygwin32
		     hackery.
Constants.H        : bump version number.
SequenceNumQueue.C : Alexander Elkins fix #2.
Xproto-cygwin.h	   : new file; hacked up version of X11R5 Xproto.H required
		     for building under Cygwin32 environment.
configure.in	   : added AC_LANG_CPLUSPLUS to prevent failure on machines
		     with broken cc (Solaris x86); added tests for lzo
		     library; fixed ugly hack for determining size of
		     accept()'s third parameter (thanks to Jim Meyering);
		     added test for Cygwin32.

Note: if I was a really good OO designer type guy, I would have created a
CompressionFactory class that instantiated the Compresser and Decompresser
instances appropiately. Since I am lazy and don't forsee extending this to
include other compression algorithms, this is left as an exercise for the
reader.

Fix descriptions from Alexander Elkins (diffs refer to release 3.7.0):

Fix #1: These are context diffs showing a fix to set scanlinePad_ in the
ClientChannel and ServerChannel classes to the correct value which is
received in byte 33 not byte 32 of the X server's first reply.  The
symptom of this defect is that the data sent by the PutImage request is
invalid and the lower portion of the image displayed looks like white noise.
This was initially observed to occur when displaying the xv X client through
dxpc to WRQ's Reflection X server running on an NT Workstation for which
bitmap-format-scanline-unit is 8 and bitmap-format-scanline-pad is
32.  The defect did not manifest itself on HPUX Workstations for which
bitmap-format-scanline-unit is 32 and bitmap-format-scanline-pad is
32.

-> diff -C 3 dxpc-3.7.0/old/ClientChannel.C
dxpc-3.7.0/new/ClientChannel.C
*** dxpc-3.7.0/old/ClientChannel.C Fri Jun 13 20:36:02 1997
--- dxpc-3.7.0/new/ClientChannel.C Thu Oct 22 14:24:09 1998
***************
*** 1444,1450 ****
      imageByteOrder_ = outputMessage[30];
      bitmapBitOrder_ = outputMessage[31];
      scanlineUnit_ = outputMessage[32];
!     scanlinePad_ = outputMessage[32];
      firstReply_ = 0;
    }
    else
--- 1444,1450 ----
      imageByteOrder_ = outputMessage[30];
      bitmapBitOrder_ = outputMessage[31];
      scanlineUnit_ = outputMessage[32];
!     scanlinePad_ = outputMessage[33];
      firstReply_ = 0;
    }
    else
-> diff -C 3 dxpc-3.7.0/old/ServerChannel.C
dxpc-3.7.0/new/ServerChannel.C
*** dxpc-3.7.0/old/ServerChannel.C Fri Aug 29 17:40:37 1997
--- dxpc-3.7.0/new/ServerChannel.C Thu Oct 22 14:24:34 1998
***************
*** 75,81 ****
        imageByteOrder_ = buffer[30];
        bitmapBitOrder_ = buffer[31];
        scanlineUnit_ = buffer[32];
!       scanlinePad_ = buffer[32];
        firstReply_ = 0;
        encodeBuffer.encodeValue((unsigned int) buffer[0], 8);
        encodeBuffer.encodeValue((unsigned int) buffer[1], 8);
--- 75,81 ----
        imageByteOrder_ = buffer[30];
        bitmapBitOrder_ = buffer[31];
        scanlineUnit_ = buffer[32];
!       scanlinePad_ = buffer[33];
        firstReply_ = 0;
        encodeBuffer.encodeValue((unsigned int) buffer[0], 8);
        encodeBuffer.encodeValue((unsigned int) buffer[1], 8);

Fix #2: This is a context diff showing a fix for the push function in the
SequenceNumQueue class. When the is queue expanded, the old entries were
improperly copied to the new memory space resulting in reply sequence
numbers not being found in the queue.
Sometimes dxpc would crash, sometimes it would abort, always killing the
X server as well.
We saw this happen when a large number of XAllocColor requests were sent.

-> diff -C 3 dxpc3.7.0/old/SequenceNumQueue.C
dxpc3.7.0/new/SequenceNumQueue.C
*** dxpc3.7.0/old/old/SequenceNumQueue.C      Tue Oct 20 16:28:05 1998
--- dxpc3.7.0/old/new/SequenceNumQueue.C      Tue Oct 20 16:28:17 1998
***************
*** 39,45 ****
      for (int i = startIndex_; (unsigned int) i < length_; i++)
        newQueue[i - startIndex_] = queue_[i];
      for (int i1 = 0; (unsigned int) i1 < startIndex_; i1++)
!       newQueue[i1 + startIndex_] = queue_[i1];
      delete[]queue_;
      queue_ = newQueue;
      startIndex_ = 0;
--- 39,45 ----
      for (int i = startIndex_; (unsigned int) i < length_; i++)
        newQueue[i - startIndex_] = queue_[i];
      for (int i1 = 0; (unsigned int) i1 < startIndex_; i1++)
!       newQueue[i1 + length_ - startIndex_] = queue_[i1];
      delete[]queue_;
      queue_ = newQueue;
      startIndex_ = 0;

Fix description from Ken Raeburn (diffs refer to version 3.7.0):

To: dxpc@mcfeeley.cc.utexas.edu
Cc: "Albert L. Ting" <alt@artisan.com>,
        Roderick Schertler <roderick@argon.org>
Subject: Re: DXPC and Emacs 20.3
References: <18362.905628421@eeyore.ibcinc.com>
<13818.52242.39296.479928@lamb.artisan.com>
<19972.905636479@eeyore.ibcinc.com>
From: Ken Raeburn <raeburn@raeburn.org>
Date: 07 Oct 1998 15:55:16 -0400
In-Reply-To: Roderick Schertler's message of "Sat, 12 Sep 1998
17:41:19 -0400"
Message-ID: <tx1ogrorvtn.fsf@raeburn.org>
Lines: 116
X-Mailer: Gnus v5.6.27/Emacs 19.34
Reply-To: dxpc@mcfeeley.cc.utexas.edu
Sender: owner-dxpc@mcfeeley.cc.utexas.edu
X-Listprocessor-Version: 8.2.07 -- ListProc(tm) by CREN

I didn't see any followup mail on this on the dxpc list (maybe I
accidentally deleted something, but I didn't see any list archive
mentioned on the web site), and I was kinda bored last night, so I
looked into it.

With the test program included in Roderick's message, I didn't get an
empty string, I got a truncated font name, only 16 characters when it
should've been 63.  That certainly seems like a dxpc bug.  The patch
below seems to fix that.  The 2-byte "name length" that was being read
from the GetAtomName reply was being used as the number of bytes, but
offset 4 has a 4-byte count of words (name plus padding, so divide by
4 rounding up), not a 2-byte count of bytes.  If the byte orders were
different, the result could well be a zero, explaining the empty
string.

I don't know what the emacs patch was, but if it was checking for
0-length font names, it may not be adequate, depending on how the name
is used after that.  You may be getting non-unique prefixes back
instead.  IMHO the right fix may be to request the name of some atom
that emacs has interned, and die with an error if it's not correct,
maybe referring the user to docs in the source tree for fixing this
bug.  Unless emacs never actually needs to know the font names, in
which case it should never ask.

So now this test program runs okay for me (atom name is
-Misc-Fixed-Medium-R-SemiCondensed--13-120-75-75-C-60-ISO8859-1), and
emacs-20.3 properly fetches three font names, but then emacs seems to
hang for me.  Without dxpc, everything's okay.

I have some "xmon" dumps I'll start looking over, of
emacs-20.3-with-dxpc and emacs-20.3-without-dxpc and
emacs-20.2-with-dxpc, to see how they differ, unless someone has good
ideas where to start.

As far as I can tell from the 20.3+dxpc dump alone, Emacs seems to
think it's mapped its windows and written text into them, but the X
server and/or window manager don't see it that way.  I've seen the
MapWindow requests etc, but the window doesn't appear, and the window
manager hasn't even created a frame window to act as parent to the
emacs window.

--- ServerChannel.C~    Sat Aug 22 01:44:50 1998
+++ ServerChannel.C     Wed Oct  7 05:50:16 1998
@@ -144,7 +144,7 @@
            break;
          case X_GetAtomName:
            {
-             unsigned int nameLength = GetUINT(buffer + 4, bigEndian_);
+             unsigned int nameLength = GetUINT(buffer + 8, bigEndian_);
              encodeBuffer.encodeValue(nameLength, 16, 6);
              const unsigned char *nextSrc = buffer + 32;
              clientCache_.internAtomTextCompressor.reset();

8/18/1999, Kevin Vigor (kvigor@ascend.com)

3.7.0 (Septmber 7, 1997)

Added compression for CloseFont, ConvertSelection, CreateNotify,
DeleteProperty, FreeColors, FreeCursor, GetAtomName, ListFonts,
ReparentNotify, SelectionClear, SelectionRequest, and QueryBestSize messages

Improved compression slightly for ChangeGC, CreateGC, CreateWindow,
ConfigureWindow, and FillPoly requests

Improved the text compression slightly (lengthened the context for
next-character prediction, added logic to use 1st-order predictive
model if 3rd-order model hasn't been built yet (helps improve prediction
during startup))

Added detection of the "accept requires a size_t third arg" OSes in
the autoconf configure script (using the original logic from dxpc-3.3.0)

Fixed a bug in ServerCache.C that was introduced in 3.6.1 (which was a beta
only release).

3.6.0 (May 26, 1997)

Improved compression for various X messages:
  - PolyFillRectangle
  - AllocNamedColor
  - LookupColor
  - KeyPress
  - KeyRelease
  - ButtonPress
  - ButtonRelease

3.5.0 (February 27, 1997)

Changed checking of version numbers so that it prints out both numbers
(local and remote) to aid in resolving version problems.

Added ability to fork and run as a daemon process (-f cmdline option).
(Thanks to Brian Williams (epabcw@epa.ericsson.se) for the idea.

Added ability to have the client initiate the connection to the server.

Also, -k cmdline option will search for a daemonized dxpc and send it
SIGTERM.

Many documentation fixes related to changes implemented in 3.3.1 (an
unreleased version, whose changes didn't make it into the docs for 3.4.0).

dxpc got a mailing list!  To subscribe, send a message with a blank
subject to listproc@mcfeeley.cc.utexas.edu with the words
	sub dxpc yourfirstname yourlastname
in the body of the message.

3.4.0 (November 14, 1996)

New maintainer: Zachary Vonler (lightborn@mail.utexas.edu)

dxpc now has a home page:
  http://ccwf.cc.utexas.edu/~zvonler/dxpc/

Implemented exchange of version numbers when connection between client and
server is first established so that in the future people won't have
problems trying to run incompatible versions.

Server and client switched cmdline args, so that the client needs no
parameters, and the server needs the hostname of the remote machine.

No change history is available for versions prior to 3.4.0.