MinTTY "vs" rxvt (was Re: MinTTY 0.3.3)

Charles Wilson cygwin@cwilson.fastmail.fm
Sun Jan 11 23:33:00 GMT 2009


Andy Koppe wrote:
> How about just providing Start Menu shortcuts for all installed
> terminals in a "Cygwin" folder, much like Yaakov has done in MinTTY's
> cygports package? The user could always copy them to more easily
> accessible places as needed, or just rely on the recently-used list.

That could work, too -- and wouldn't require setup.exe changes. But it
requires action on the part of the cygwin maintainers of terminals,
like...err. Oh, yeah. me.

>>> Or just switch rxvt to the regular X11 version w/o all the libW11
>>> hackery?
> 
> Bypassing the X protocol by implementing Xlib directly on Win32 does
> seem rather a good idea in principle at least. How come it hasn't been
> used more widely?

There have been several efforts over the years. All have failed AFAICT.
The most widely used version -- the libW11 distributed with rxvt on both
cygwin and msys -- is extremely limited in functionality. It supports
ONLY enough of X to satisfy the very minimal demands of rxvt.

See, the whole reason rxvt was created, on unix, in the first place was
as a replacement for xterm that *didn't* use the Xt toolkit.  rxvt used
Xlib -- and only Xlib -- directly. Thus, it was considered "faster" and
more "lightweight" (whether that is or was actually true is another
question).  It also used only a small subset of the calls in the Xlib
library (maybe 5%) -- so a suitable libW11 was smaller and simpler to
write.  However, that library is mostly useless for anything more
demanding -- which is why only rxvt uses it.

Other, more comprehensive efforts [1], also seemed to die off for one
reason or another: including mine.  It's rather hard to "widely use"
something that is incomplete and broken. <g>

--
Chuck

[1] Here's a copy of some of the documentation I put in the libW11 ITP,
several years ago. The section concerning XCB is new.

Taxonomy of libW11:
============================================================

ntxlib (1992 : unknown)
----------------------------------------------------------
ftp://ftp.microsoft.com/developr/drg/UNIX-to-Windows/Ports/Xlib
Very rudimentary.

rxvt's W11 component (1999 : SteveO)
----------------------------------------------------------
This was derived from ntxlib by SteveO and absorbed in modified
form into rxvt-2.7.x. This version is what allows rxvt to work
in "native windowing mode" for both cygwin and MinGW/MSYS.

The original version has disappeared from the web, but the wayback
machine has it: http://web.archive.org/web/*/http://www.io.com/~bub/rxvt

(Oldest available source code 03 Jun 2001):
http://web.archive.org/web/20030625063023/http://www.io.com/~bub/dnload/rxvt-2.7.2-6-src.tar.gz

(Matching binary 03 Jun 2001):
http://web.archive.org/web/20030625063023/http://www.io.com/~bub/dnload/rxvt-2.7.2-6.tar.gz

rxvt is part of the official cygwin distribution, so current source
code can be obtained from the cygwin mirrors. Try
http://mirrors.kernel.org/sources.redhat.com/cygwin/release/rxvt/

rxvt's W11 is tightly tied to SteveO's wrapper system which allows
rxvt to use either W11 or X11 depending on the DISPLAY variable. This
is possible because rxvt uses very little of X11's capabililty;
rxvt-W11 provides maybe 5% of the functionality of X11.
The drawback of rxvt-W11 is that the wrapper code must be compiled-in
to the client, and the W11 "x11-ish" header must be used. You can't
compile against 'stock' X11 headers and just link to the rxvt-W11
library, nor simply "drop in" a libW11 DLL in place of the X11 xlib DLL.
That's the goal of the projects below.

NOTE: mrxvt -- a tabbed version of rxvt -- also supports/uses/includes?
this version of libW11.  This guy:
http://www.nabble.com/libW11-enabled-mrxvt-0.5.4-20080913-td19483005.html
who further modifies mrxvt to work with chinese encodings, has also
modified rxvt-W11 to support that. He has not yet published those
changes. Because he distributes this modified libW11.dll -- which is
linked against cygwin -- it falls under the GPL and he needs to do
publish those patches, but I haven't tried to contact him about that.

libW11 [SourceForge version] (2001 : Don Becker "psyon" )
----------------------------------------------------------
This project was derived from rxvt-W11, with the intention of being
a simple drop-in replacement for the Xlib DLL. Development has
stalled, and the most recent version doesn't actually work -- the
primary developer did a CVS dump of his current state when he
abandoned the project. Too bad his 'current state' was broken:
"I haven't gotten everything from the old code into the
new code yet. I'm implementing as needed right now."
But that never happened.

Thus, the most recent official version that actually works dates
back to Dec 2001. Some have had luck with the Jan 2005 version but
I'm not one of them.

http://libw11.sourceforge.net/
https://sourceforge.net/projects/libw11/

I don't believe the design decision to "replace" cygX11-6.dll
with a DLL of the same name with libW11 internals was a good one,
because it means your entire X11 installation would be forced to
use libW11 -- even though libW11 is FAR from complete. Thus,
most of your apps will break. Thus, I believe it is better to
compile this library into its own, distinct, DLL and deliberately
link a custom (native-windowing-mode) version of your app to
libW11 instead of libX11. The downside of my approach is you do
not have access to the toolkits, (e.g. cygXt still uses cygX11, and
there is no cygXt-W11). However, as most of those add-on libraries
did NOT, in fact, work properly with W11 under them, this is no
big loss in my opinion.

Architecturally, libW11 is compiled using a custom set of local
header files, that basically contain just those parts of the official
X11 headers necessary to compile libW11 itself. These local headers
are NOT installed. Instead, client apps should use the official
headers, but simply link against libW11.

That is, -I/usr/X11R6/include -L/usr/lib/W11

Unlike the rxvt-W11 version, this library spawns a message handling
thread which intercepts all Windows messages, converts them into
XEvents, and then feeds those XEvents to the client app's message
loop. (The rxvt-W11 version had no separate thread. Instead,
it provided a hook where the client app could insert a handler into
the rxvt-W11 library's message loop. This deviation means that
application code must be modified from its pure-X version to work
properly with rxvt-W11).

libW11 [free.fr version] (2005 : Samuel Vinson "samuelv")
----------------------------------------------------------
This version is a cooperative fork of libW11-sourceforge. One of
the participants added a lot of functionality and re-architected the
the include files. However, Sam's changes were based on the
libW11-sourceforge code BEFORE Don did his CVS dump. So merging is/was
going to be quite tedious -- and few of Sam's changes made it into
the sourceforge CVS before Don abandoned the project. There was also a
difference of opinion in architecture, which caused some friction.

http://libw11.free.fr/
http://libw11.free.fr/downloads/index.html

Sam's version retains the old rxvt-W11 message handling: no extra
threads, but apps must explicitly "hook" in. One interesting change
is the use of "real" X11 headers. Sam's code has pristine copies
of the X11 headers needed to build his libW11 -- but ONLY those
that are actually needed by his code. Thus, rather than cut-n-paste
specific function and type declarations into custom headers, Sam
copies entire headers from the official x.org include files.

Unfortunately, Sam's code does not appear to be complete either.

libW11 [cygwin version] (2006 : Charles Wilson)
----------------------------------------------------------
ALSO not complete. Based on libW11-sourceforge, with mods derived
from libW11.free.fr and rxvt-W11, as well as custom changes.

The starting point for this version was the (broken) 20050610
CVS snapshot from sourceforge. Thus, it uses the separate-thread
model for Windows Message conversion. It retains the customized
local header files. However, it incorporates color handling from
free.fr, and pixmap handling from rxvt-W11.

At present, all test code appears to work, including an xlib-only
PNG viewer. Additionally, an xlib-only XPM viewer also appears to
work (not the sxpm provided with the xpm distribution; that requires
Xt).

Finally, a partially working version of rxvt-2.7.10 is possible
using this library. Known failures:
   * no clipboard support
   * 100% CPU usage
What works:
   * colors, text, command I/O
   * background pixmap
   * "inheritPixmap" pseudo-transparentcy [partial: scaling incorrect]

So, at present, rxvt-2.7.10 using libW11 is a step backwards from
rxvt-2.7.10 using its own bundled W11. However, it is my hope that
with assistance, libW11 may eventually surpass that version, and
even provide sufficient support for a native-windowing rxvt-unicode.

XCB windows port
----------------------------------------------------------
Recently, X.org changed the underlying design of the libX11
implementation, so that it now represents a thin API-compliant wrapper
around an underlying XCB (X protocol C Binding) library.  Thus, an
alternative solution to the above libW11 is to instead create an XCB
library that directly targets the Win32 graphics subsystem. Then, link
the (wrapper) libX11 (renamed libW11) against this libXCBw32gdi library.
Presumably this would be easier than a non-XCB-based libW11, because XCB
is smaller and simpler -- and presumably easier to port.

There have been (MAYBE: [*]) two public efforts to to this:
Jeetu Golani
http://lists.freedesktop.org/archives/xcb/2008-May/003538.html
Michael DOUBEZ
http://lists.freedesktop.org/archives/xcb/2008-May/003522.html

But those patches were never accepted upstream, and doubtless need many
changes before working with current XCB.

[*] I haven't look at the patches, at all. It is unclear what either of
these two authors means by "native win32 port":
  (1) a standard port of the library so that it compiles on win32, but
still implements the X protocol and thus requires a running X-server to
actually display the stuff, or
  (2) an library *called* XCB that is API-compliant to the "real"
libXCB, but rather than formatting messages and handling the
communication with a (local? remote?) Xserver, instead directly calls
the Win32 graphics subsystem.
If 1), then this is no big deal IMO: Colin Harrison provides those (for
a fee) over at http://www.straightrunning.com/XmingNotes/.  On cygwin,
we already have that, as well: cygxcb-1.dll is a port of the XCB library
that runs on windows, but "needs" an Xserver. If 2), then it's a pretty
big deal -- but as I said above, even then the patches will need work to
operate correctly with current XCB.


IMO, a libW11 port based on a win32-native libXCB in the (2) sense,
above, with as many associated X libraries recompiled and relinked and
verified working as possible -- and RENAMED so as not to conflict with
existing cygX* libs -- would be a nice Google SoC project for someone.
Obviously this would be easier if done in the cygwin arena rather than
truly "native" (e.g. mingw) land.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list