Wouldn't it be great to be able to take my favorite X-clock/file-browser/calculator and run it on any computer?
- anonymous
You can't play if you don't hack.
- even more anonymous
Intro. | License | Ingredients | Cookbook | Efficiency | Platforms | Misc.
pTk sub-directory is a modified version of Tk4.0p3 It has been modified to call "glue" functions rather than use libtcl.a - so it is completely independant of TCL. A goal is to have pTk directory and its library usable from perl/Tcl/LISP/c++/python etc. - perl is 1st. There are still serious snags with the others.So the stated goal is to eventually port to other languages.
How about the more modest goal of porting the Tk extension to perl5 to the widest variety of platforms (other than Un*x)? That is the issue that this document attempts to address. Please note that this document is a collection of rumours and slightly out of date material - please exercise extreme caution in the use of the information contained herein. For more up-to-date information subscribe to the ptk@lists.stanford.edu mailing list, by sending the message:
subscribe ptk joe@somewhere.com (Joe User)to Majordomo@lists.Stanford.EDU.
[BTW, There are no "answers" here - mostly pointers to other sources of useful information. I'm afraid you still have a lot of work to do :-)]
Nick Ing-Simmons has already mentioned the steps involved in such a port
Perl is copywritten by Larry Wall. Here I am reproducing a copywritten statement from the Camel (pp 433):
Perl is copyrighted, and is thus not in the public domain -- it's just freely available and freely redistributable (q.v.).Perl is covered by a couple of licenses (GPL and Artistic). Here is the README file that comes with perl5.002. There is also the Artistic file that comes with perl5.002. Anyone seriously considering working toward the advancement of perl ought read those files carefully, very carefully.
Nick Ing-Simmons' nik@tiuk.ti.com ptk and assorted code is covered by copyright notices too:
Copyright (c) 1995 Nick Ing-Simmons. All rights reserved. This package is free software; you can redistribute it and/or modify it under the same terms as Perl itself, with the exception of the files in the pTk sub-directory which have separate terms derived from those of the orignal Tk4.0 sources and/or Tix. See pTk/license.terms for details of this Tk license, and pTk/Tix.license for the Tix license.Anyone seriously considering working toward the advancement of perl/Tk ought read all the files mentioned thus far carefully.
Does your platform's C implementation (compiler & linker) support dynamic linking? If so that would be a plus, but it is not necessary. Having a C compiler (or a C++ compiler that can reasonably handle C) is necessary. If all you have is a C++ compiler that may be OK since a great many C++ compilers can pretend that they are C compilers.
ANSI-ness is not as big a deal as you might imagine. If you wind up building everything (including libX11 and perl) using your C compiler then everything ought to work even if your compiler is not ANSI compliant. It is a great idea (you _must_?) build Tk using the same compiler that you used to build perl. If you are lucky enough to be able to use MakeMaker with your perl then the correct C compiler will be invoked from the Makefile when you type the make command.
Here are some interesting excerpts from X Window System C Library and Protocol Reference by Robert W. Scheifler, James Gettys, Ron Newman, Al Mento, and Al Wojtas (© 1988 MIT and DEC ISBN 1-55558-012-2):
The X Window System, or X, is a network-transparent window system...that was designed at MIT.Please note that while much X documentation refers to "X toolkits" (e.g. Xt, Xm, Xmu, etc.) such toolkits are typically front ends to C subroutine libraries. Hence those "toolkits" are typically called from some other compiled language (which is usually C or C++). Tcl/Tk and Perl/Tk are a bit more than mere "toolkits" in that they allow access to a good deal of Xlib functionality via the other languages (Tcl and Perl respectively). [BTW there also is a Lisp version of Xlib that you need not concern yourself with in an attemp to port Perl/Tk.]
...
It runs under ... several operating sytems.
...
Xlib is a C subroutine library that applications programs (clients) use to interface with the window system by means of a stream connection.
Take a look at "Getting X" from the folks who write and maintain it. They (the X consortium) also have a page on Writing Portable X Code which is a must read document. You should probably check out the Xlib man pages too.
Perl/Tk can be built on Unix platforms under X11 R5, R6, and R6.1. I do not know if it has been built with prior releases.
The critical Xlib files include: the sharable image libX11.a (or libX11.so, or LIBX11.EXE, or whatever name.extension your system uses for this type of file), and the header file Xlib.h (as in #include <Xlib.h>).
make - Maintains up-to-date versions of target files and performs shell commandsOn Unix platforms the standard make utility uses a Bourne shell type syntax for carrying out compiling and linking of (usually complicated) source code. There is also a GNU make utility called gmake - has it been ported to your platform? Does your C compiler have "project files"? (These are equivalent to Makefiles.)
On VMS there is a commonly used MMK utility that uses a DCL shell syntax.
I would presume that a MacMaker could use AppleScript(?), a DOS|WIN|OS/2 maker would use a CMD *.BAT file (or Rexx?), etc.. On the microcomputers there are also commercial C compiler IDE's that do the equivalent of make with .c and .h code typically using "project files". (You might want to disentangle yourself from the non-transportability and awful licensing issues involved with these IDE's though.)
How good is your platforms' port of perl5? MakeMaker? Basically will:
perl Makefile.PL"work" on your platform (i.e. create the right type of Makefile [or equivalent])? This question involves the platform specificity of the Extutils::MakeMaker module. Note that there are MM_Unix.pm, MM_OS2.pm, and MM_VMS.pm modules to help on those platforms. To help develop MM_foo.pm on your Foonix platform, consider subscribing to the MakeMaker mailing list makemaker@franz.ww.tu-berlin.de.
Can your platforms' perl port turn .xs into .c and .h? In other words is your h2xs and xsubpp working? Either of these perl utilites may require some modification for use on your system. With modern perl's one can make very effective use of statements like the following within the perl code:
use Config; if $Config{osname} eq 'VMS' { # VMS stuff goes here }
Your perl5 Autoload utility should be working too (if your C compiler does dynamic linking). How about ExtUtils::Mkbootstrap?
How about the xmkmf program or the
patch program? They would be
useful (but are not necessary).
The previously mentioned gmake program
would be useful on any system. It may have been ported to yours.
Of course dealing with file distribution can be a portability problem in its own right. Perl code is typically distributed from CPAN sites via binary mode ftp of *.tar.gz files. Hence you need: ftp, tar, and gunzip. Note that the gunzip program is different from unzip and different from pkunzip.
perl Makefile.PL make make test make installBut of course, some ports do lose (or gain) a little in the translation. On systems whose C-compiler only supports static linking making the static version (perhaps via "make tkperl" after "make" and before "make test") would be great too.
The first of these build steps (perl Makefile.PL) is the MakeMaker step and strictly speaking is not necessary if you can figure out an alternative means of quickly putting together a Makefile (or project file, or whatever) for not only this version of Perl/Tk but all subsequent versions. (In other words hacking away with a text editor to come up with a Makefile for Tk-versionX to compile means that anyone making use of your port of Perl/Tk will be stuck with -versionX, meanwhile everyone else will have moved on to -versionX+1). On Unix systems the Makefile.PL script that comes with the Tk module calls the myConfig perl script to query the computer (actually the xmkmf program) about where it's Xlib libraries and headers are. So where on your system is libX11.a (or libX11.so, whatever)? Where on your system is the Xlib.h file? These are the types of questions that need answering when trying to compile the Tk extension to perl on your system.
The second of these build steps (make) is the compile, archive/library objects, and link step and must of course be translated into your platforms' C-compiler-and-linker's native format. As hinted there is an optional make tkperl step for statically linked compiler/linkers [of course this target may or may not be in your Makefile depending on whether you have a Makefile].
The third step (make test) really only runs the widget
demo script to make sure nothing has gone wrong. On Unix systems the
Makefile is set up with dependancies such that typing
make test will do a complete make if it had not already
been done. On a port to a system much different from Unix it would not be at
all unreasonable to ask people to simply run the widget demo using
perl in whatever fashion it is invoked on your system.
On Unix the make install step copies the code over to a special perl
installlation directory. This step may be unnecessary on your system.
In sum: the make step of compiling (cc) object collection (ar)
and linking (ld) is most critical [so tricky in fact that that is why the
make program was invented!], the first step is simply an automatic way
to get perl to set up the Makefile for you (and probably should not
be overlooked by you).
You can of course read a detailed description of how to build Unix Perl/Tk in the appropriate entry in the Perl/Tk FAQ.
Nick Ing-Simmons has outlined the steps necessary to port perl/Tk to other (non-unix) platforms:
In <30F594C8.5798@dsto.defence.gov.au>
On Fri, 12 Jan 1996 09:22:56 +1030
Matthew Phillips <mathew.phillips@dsto.defence.gov.au> writes:
>Hi,
>
>I'm very impressed with your Perl/Tk package and am hoping to be able to
>use it for the GUI implementation of our next project. However, we need
>to be able to run on Windows NT primarily, and UNIX (Solaris) at a later
>date. I know there is an NT Tcl/Tk port, but what are the odds of a
>Perl/Tk port? If there isn't one, how difficult would it be for a
>reasonably experienced UNIX hacker to convert the NT Tk package to be
>usable via Perl 5?
>
>Keep up the good work!
>
As far as work time goes I can justify (some) time spent on UNIX
perl/Tk. An NT (Win32) port would have to be a home (hobby) project,
and I don't have (or particularly want) an Win32 machine at home.
(My home machine is a dual CPU SPARCStation10,Solaris2.4.)
What 'we' need is a "reasonably experienced _NT_ hacker":
What I need is someone that understands Win32 (or OS/2 as may be),
to figure out issues like DLL/OLE (which is just an acronym to me).
I could learn this stuff of course - guess I will some day - but don't
have the time to learn it now. Anyone who knows they need the port
knows more than I do in this area.
The steps are :
1. Build Perl for your environment - I think you need to re-compile
from sources. This may be ntperl or via gcc-win32 or however.
2. Work with me/porters to incorporate a "trivial" C extension to this perl,
to see what is involved - we can do this 'static linked' if this
helps.
3. Build John Ousterhout's Tcl/Tk4.1a* for your environment, so that we
understand what it can do and bits that need to be there.
4. I apply my tk4.0 vs perl/Tk diffs
to 4.1a and run all the C files though my munging perl scripts.
I then have a UNIX 4.1a - my guess it might take a day or two.
5. Do same things as (4) to bits of 4.1a that UNIX does not use, based on
understanding developed in (3).
6. Then compile all those, iterate munging/compile as required.
7. Apply the "how do we add a C extension" lessons from (2) to objects
from (6) to get perl/Tk executable(s).
8. Sort out inevitable filename/UNIXisms issues in *.pm files.
I can do (4) almost anytime. But there is little point unless someone
is going to use it soon as otherwise it will have to all be done again
if a new Tk4.* comes out...
For help in understanding what is involved in Nick's step number 2 above consider working through the example given in the perlxstut man page (as well as perlxs(1) and the pod docs for MakeMaker.)
In step number 4 Nick is referring to the Unix diff program that tells you the difference between two files (usually text files). The output of diff are the "diff files" that Nick is referring to. The inverse of the diff program is Larry Wall's patch program (which is also distributed separately as a GNU utility - unfortunately not as a perl script!). Do you have a patch program on your system that would allow you to apply Nick's diff files? If you do not then you will need to do a lot of hand editing (it is possible to simply read diff files - they are plaintext).
Note that on the perl Makefile.PL step (under Unix) it is sometimes necessary to give explicit locations of the required X11 libraries and/or include headers. For example, if libraries and headers are in one location (that the xmkmf program cannot find) then:
perl Makefile.PL X11=/usr/local/X11R6or, if the headers are in one place and the sharable libraries are in another place then:
perl Makefile.PL X11INC=/usr/local/share/X11R6/include \ X11LIB=/usr/local/arch/X11R6/libWhere the Unix line continuation character "\" has been used to split the long input (that is the tcl line continuation character too :-). Hence, on VMS it should be possible to say:
perl Makefile.PL X11INC=SYS$SYSTEM: - X11LIB=SYS$LIBRARY:DECW$XlibShr.EXE/SHAREand have a DESCRIP.MMS file pop out! (Unfortunately perl has different ideas about what $SYSTEM and $LIBRARY mean on that system.)
Nick has also recently commented on the primary differences between the Tcl/Tk code and his Perl/Tk code.
Read the Camel...
Lesson 0: hiworld.c
In an effort to test your ability to port and use Xlib on your platform consider writing
and compiling a very simple C program that uses Xlib. For example
hiworld.c. On a typical UNIX computer
I can compile and link that program with a command like:
cc hiworld.c -lX11whereas if I used the GNU C compiler that would simply be:
gcc hiworld.c -lX11(and you may need other -l or -L arguments depending on the details of your system.)
It is amusing to note that the equivalent functionality of that roughly 73 line C program can, with Perl/Tk to the rescue, be written in about 10 lines:
#!/usr/bin/perl -w use Tk; my $m = MainWindow->new; my $c = $m -> Canvas(-height => 200, -width => 300,); $c -> pack; $c -> create('text', 40, 50, '-text' => "Hello World!"); $m -> bind('<Any-KeyPress>' => sub{exit}); $m -> bind('<Button-1>' => sub { $c -> create('text',$c->XEvent->x,$c->XEvent->y, -text => "Hi.") }); MainLoop;(Note the tcl/tk version is only 6 lines!, neither of which is really fair to the C version since it cannot even refresh the additional "Hi." strings on expose events the way the perl and wish scripts do automatically.)
Lesson 1: Makefile
Assuming you are able to figure out how to compile and link
hiworld.c, an additional step to
take would be to try coming up with a Makefile for it (although this
would not be necessary if you have MakeMaker and can follow the
steps in Lesson 2 below). The crude way to create a Makefile
is to simply use a text editor to write something like this:
hiworld : hiworld.c cc -o hiworld hiworld.c -lX11which would be invoked with "make hiworld" for example. It is considered much more fashionable to throw in a bunch of macros into one's Makefile's as in the following:
CC = cc X11 = -lX11 all : hiworld hiworld : hiworld.c $(CC) -o hiworld hiworld.c $(X11)which is still invoked via "make hiworld" even though it looks a little more complicated.
Lesson 2: h2xs, xsubpp, hiworld.xs, Makefile.PL
The point of this exercise is not to show how to "add X routines to perl" (even
though that is what it does). The point is to illustrate the use of
h2xs, xsubpp, ExtUtils::MakeMaker, et al. Please note
that each of these useful perl utilities may or may not have been ported to your
system. If not then see if you can lend a hand in doing the port.
Following the perlxstut(1) man page we go to an otherwise unused directory and type:
h2xs -A -n Howdyand note the creation of a new Howdy directory with four new files: Howdy.xs, Howdy.pm, Makefile.PL, and MANIFEST (with later versions of h2xs there will also be a test.pl and a Changes file).
To get our Xlib code into Howdy we will need to append (and slightly modify) the contents of hiworld.c to Howdy.xs (on Unix that would be something like cat hiworld.c >> Howdy.xs.) We edit Howdy.xs to add the required CODE: and OUTPUT: RETVAL statements, as well as to change function main(argv argc) to a funtion hiworld(argv argc) (clever name eh?). So that now the head of Howdy.xs appears as:
#include "EXTERN.h" #include "perl.h" #include "XSUB.h" #include <X11/Xlib.h> #include <X11/Xutil.h> MODULE = Howdy PACKAGE = Howdy int hiworld(argc, argv) int argc char argv CODE:(note the function type of int, although void would have been just as appropriate.) The tail of Howdy.xs now appears as:
XCloseDisplay(mydisplay); OUTPUT: RETVAL(note the absence of a call to exit(0);, and an absence of the braces {} for main.)
We turn our attention to the Howdy/Makefile.PL file and change the line that says:
'LIBS' => [''], # e.g., '-lm'to read something like what we needed to use to compile hiworld.c from the command line, like:
'LIBS' => ['-lX11'], # e.g., '-lm'We can now say
perl Makefile.PL make make install(note that after make and before make install you may be able to make test if you have updated test.pl. Also, statically linked Howdy perl binaries can be made by running:
make -f Makefile.aperl inst_perl MAP_TARGET=perlafter make and before make test.) After make install it is possible to run perl scripts that call the hiworld() subroutine in as little as three simple lines of perl:
#!/usr/bin/perl use Howdy; $return = &Howdy::hiworld($a, $b);That is all there is to it! For illustrative and testing purposes I have made a distribution copy of the Howdy "module" for perl. [Please also note that a much more extensive discussion of such an extension as a Tk widget building exercise is taking shape as this document.]
You may experience tremendous difficulty in getting any of the above steps to work (they work pretty smoothly on most Unices). Hopefully, by following these steps you will encounter the problem areas that need work on your platform's port of perl. Do not be discouraged - ask around for help.
Of course it should not ultimately be necessary for you to use these techniques (h2xs et al.) in a "standard compile" of Perl/Tk on your system because Nick Ing-Simmons has already packaged everything for you. Trying this test out as a means of uncovering what could possibly cause trouble on linking Xlib calls to your perl ought to help with the port of Perl/Tk to your system however.
Lesson 3: Tk's Makefile.PL
The Makefile.PL that is distributed with Tk is considerably more
complicated than the trivial one that we just made for Howdy in lesson 2.
Among other things the Makefile.PL with Tk calls external perl scripts that
try to call
the xmkmf utility on your system. Note that if your system does not
have xmkmf you may need to tell perl just where the Xlib stuff is
sitting on your system. This is why it is sometimes necessary to say something
like:
perl Makefile.PL X11=/usr/local/X11R6or, if the headers are in one place and the sharable libraries are in another place then:
perl Makefile.PL X11INC=/usr/local/share/X11R6/include \ X11LIB=/usr/local/arch/X11R6/lib(Another reason that specifying any of the X11 macros may be necessary is to force a choice of one version of X11 over the default that gets specified by xmkmf X11R6 over X11R5 for example.)
The statement within the main Tk Makefile.PL:
require "./myConfig";invokes the myConfig script for snooping out X on your system. Note also that in the Tk*/config directory there are a number of tiny C programs for testing platform dependent things like: signed vs unsigned char's and TIMEOFDAY_NO_TZ.
Tk's Makefile.PL also makes use of the Tk*/Tk/MM*.pm packages for help in making the multiple Makefiles necessary for the complete build.
You might find your system mentioned in the ptk hyper-mail archive at:
http://pubweb.bnl.gov/~ptk/ or http://www.rosat.mpe-garching.mpg.de/mailing-lists/ptk/ or ftp://ftp.ccd.bnl.gov/pub/ptk/archives/or the Perl 5 Porters (p5p) page at one of the following URLs:
http://www.rosat.mpe-garching.mpg.de/mailing-lists/Perl5-Porters/ http://www.hut.fi/~jhi/perl5-porters.html http://www.nicoh.com/cgi-bin/lwgate/PERL5-PORTERS/or the perl metaFAQ (pmFAQ) at
http://www.khoros.unm.edu/staff/neilb/perl/metaFAQ/entry-04.htmlIf you wish to discuss your Tk build problems with others run and save the output from the myConfig script in the Tk build directory (the output may already be in the myConfig.out file from your Tk-b# build directory), as well as the myconfig script in your perl build directory. It is often helpful to include the output of either (or both) of these scripts in your discussion.
Presented here are the beginnings of a list of problems* associated with building Tk-b# on various operating systems. Note that a working definition of "UNIX" would probably have to mention something like:
That form of computer operating system which has proven so wildly popular that one (or more) organization(s) has (have) attempted to either sue or demand payment from one (or more) other organization(s) over the use of the word "UNIX".I am not completely sure if all of the following meet this criterion... (You are welcome to visit a separate page on non UNIX perl platforms if you like.)
(* & successes are marked with an icon - meaning one or more versions of Perl/Tk has been reported to run on the named OS. Conversely, the absence of an icon cannot be construed to mean that Perl/Tk does not run there. The abscence of an icon may merely mean that I missed the announcement of the successful build [if such an announcement was made] :-)
For Tk-b8: modifying the perl.exp file may be necessary. There is a patch in Tk-b8/README.AIX. It may be necessary to make regen_headers after the patch.
.
Previous versions: Most people seem to prefer the dynamic linking afforded by a recent version of the gcc compiler on this system.
.
.
There is a FAQ-like question & answer document for MacPerl at:
http://err.ethz.ch/members/neeri/macintosh/perl-qa.html
(see also
pmFAQ
or
p5p)
The latest versions of the source code for Tcl/Tk have build directories for Macs.
For Xlib on this platform your choices appear to be limited to commercial packages:
In private communication with Richard Stallman the previous ban on GNU work for the MacPlatform has now been lifted (presumably because of competition it is no longer a closed, proprietary computer platform). However, regarding a port of the latest gcc to the Mac: "we have more urgent priorities".
For Perl/Tk see also Mach Ten.
.
See also Tenon's XTen Home Page (X for power Macs).
.
.
.
PVHP@LNS62.LNS.CORNELL.EDU writes:Ilya has ported Tk 4.1 to OS/2 and it too is available from:
> By the way Ilya - do you have Tk running on OS/2 ?
> Any hints or advice you could lend would be appreciated.I got the volume 9 of devcon today, maybe I will try to use DAPI to port the windows stuff. I need it badly, but not going to spend a lot of time on this.
Ilya
ftp://ftp.math.ohio-state.edu/pub/users/ilya/os2Here is what the author of the port had to say about it:
It takes ./generic part of the source, and compiles it pretending that it is UNIX using UNIXish CRT. It takes a ./win part and compiles it using Win32/OS/2 libraries (DAPIE).There are 2 or 3 places where I needed patches to soften the conflicts which obviously arise, 7 symbols intentionally missing in DAPIE, and 3 bugs in DAPIE which I should code around. That's all.
Be sure to see the XFree86/OS2 project page.
If you insist on spending money to do your port then some commercial Xlib alternatives are:
.
For Tk-b8: make is reputedly not up to the task on this system.
Tk-b8/README.OSF recommends gmake instead.
Stephane Bortzmeyer
<bortzmeyer@pasteur.fr>
reports a successful build with Perl 5.001m, xsubpp 1.922,
MakeMaker 4.23. He points out that it was necessary for him to
upgrade the xsubpp and MakeMaker that he received with his copy of
Perl5.001m.
.
.
.
.
.
John Stoffel reports a successful build of static Tk-b10 on Ultrix 4.5.
.
.
Angel Li has ported Tcl7.5a2 and Tk4.1a2 to VMS and maintains a web page at
http://www.rsmas.miami.edu/vms-tcl.html
.
.
Be sure to check out Cygnus' gnu win32 stuff.
The hip port was conducted under contract with Microsoft
corporation
See hip info on (perl5 only no Tk extension) at:
http://www.perl.hip.com/
There is a mailing list for hipsters at:
<Perl-Win32@mail.hip.com>.
There is also a mailing list for users at:
<Perl-Win32-users@mail.hip.com>.
There is a moderated mailing list for announcements at:
<Perl-Win32_announce@mail.hip.com>.
Questions concerning any of these lists can be addressed by sending e-mail to:
<perl-win32-owner@mail.hip.com>.
To unsubscribe from perl-win32-users send a message of
unsubscribe perl-win32-users to
<majordomo@mail.hip.com>.
If you are still having trouble with that list try sending e-mail to
<dick_hardt@hip.com>
Unfortunately, the hip NT Perl FAQ mentions:
The latest versions of the source code for Tcl/Tk have build directories for PC-style microcomputers.
Nick Ing-Simmons has recently (Jan 96) commented on the steps necessary to get perl/Tk running on these sorts of platforms. Check out: http://sun20.ccd.bnl.gov/~ptk/archive/ptk.1996.01/0062.html
Apparently on this platform a pre-packaged Xlib is something that people are
only willing to charge you money for.
There are a number of commercial X packages for this platform such as:
.
3b1 dynixptx irix_6_2 next_3_0 sunos_4_0 aix epix isc opus sunos_4_1 altos486 esix4 isc_2 os2 svr4 apollo fps linux powerux ti1500 aux freebsd machten sco titanos bsdos genix machten_2 sco_2_3_0 ultrix_4 convexos greenhills mips sco_2_3_1 unicos cxux hpux mpc sco_2_3_2 unisysdynix dec_osf i386 mpeix sco_2_3_3 utekv dgux irix_4 ncr_tower sco_2_3_4 uts dnix irix_5 netbsd solaris_2 dynix irix_6 next_3 stellar
Be sure to check out the Xlib man pages. See the PIGUI FAQ for more information. There is also the comp.windows.x FAQ. There is a Widget FAQ too. There is also Kenton Lee's excellent Xsite page. Zona Research Inc. provides a X news sub$cription service. Whereas the The X Advisor Home Page appears to be free (for the online version at least). Be sure to pay an occasional visit to the X Window System page at Yahoo for the latest hype[r]link.
Here are the some of the many fine people that distribute X for free (the way it's authors and copyright holders intended):
There are a number of commercial vendors of X code that tout "platform independence" more strongly than does the X consortium itself among them these organizations that typically offer Xlib for sale (usually to microcomputer users) [some have free demo versions available]:Intro. | License | Ingredients | Cookbook | Efficiency | Platforms | Misc.