From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30161 invoked by alias); 11 Jan 2009 22:56:37 -0000 Received: (qmail 30152 invoked by uid 22791); 11 Jan 2009 22:56:36 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: sourceware.org Received: from out1.smtp.messagingengine.com (HELO out1.smtp.messagingengine.com) (66.111.4.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 11 Jan 2009 22:56:05 +0000 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 468F2209395 for ; Sun, 11 Jan 2009 17:56:03 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 11 Jan 2009 17:56:03 -0500 Received: from [192.168.1.3] (user-0cej09l.cable.mindspring.com [24.233.129.53]) by mail.messagingengine.com (Postfix) with ESMTPSA id B093A1C8EA; Sun, 11 Jan 2009 17:56:02 -0500 (EST) Message-ID: <496A78FF.8030603@cwilson.fastmail.fm> Date: Sun, 11 Jan 2009 23:33:00 -0000 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: MinTTY "vs" rxvt (was Re: MinTTY 0.3.3) References: <20090111040508.GA8342@ednor.casa.cgf.cx> <496A54F6.7020107@cwilson.fastmail.fm> <496A646C.7080504@gmail.com> In-Reply-To: <496A646C.7080504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2009-01/txt/msg00305.txt.bz2 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. -- 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/