ftp.pasteur.org/FAQ//ftp-pasteur-org-FAQ.zip/FAQ/graphics/pex-faq

Internet Message Format | 1996-12-02 | 52.4 KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!apollo.hp.com!lf.hp.com!news.dtc.hp.com!col.hp.com!fc.hp.com!kws
From: [e-mail] (Karl Schultz)
Newsgroups: comp.graphics.api.pexlib,comp.answers,news.answers
Subject: comp.graphics.api.pexlib - Welcome! (FAQ) (30nov95)
Followup-To: comp.graphics.api.pexlib
Date: 1 Dec 1996 12:00:03 GMT
Organization: Hewlett-Packard Fort Collins Site
Lines: 1278
Approved: [e-mail]
Distribution: world
Message-ID: <57rs03$[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: manfred.fc.hp.com
Summary: Frequently asked questions about PEX
Keywords: PEX, FAQ
Frequency: monthly
X-Rcs-Header: $Header: pex.faq,v 1.7 95/11/30 18:49:06 kws Exp $
Xref: senator-bedfellow.mit.edu comp.graphics.api.pexlib:611 comp.answers:22820 news.answers:88380

Archive-name: graphics/pex-faq
Last-Modified: 30 November 1995

This article discusses frequently asked questions (FAQs) about PEX.

Each question is grouped as an article in a digest.  Some news
readers (i.e rn) have commands for skipping to the next article
in a digest.  In rn, ^G (control-G) skips to the next article in a digest.

The information in this article is culled from several sources:
- the FAQ in comp.windows.x
- articles in the newsgroups comp.windows.x and comp.graphics
- articles from the retired newsgroup comp.windows.x.pex
- articles from the replacement newsgroup comp.graphics.api.pexlib

Where possible, the author, date and article id of the original
newsgroup article is included.  When I have edited/modified the
original article, I have enclosed my modifications in square brackets
[] with my initials (RT or KS) at the end.  Rich Thomson was the
previous owner of the FAQ.  Karl Schultz is the current owner.

Contents:
  1)  What's new?
  2)  What is PEX?
  3)  How can I tell if my X server supports PEX?
  4)  Why don't the R5 PEX demos work on my mono screen?
  5)  Where can I get an X-based PEX package?
  6)  What about immediate mode for PEX?
  7)  Why don't the R5 PEX contributed demos compile?
  8)  Why doesn't double-buffering work via phigs_ws_type_create?
  9)  What does "Kernel not configured with shared-memory IPC" mean?
 10)  Obtaining Graphics Standards (GKS, PHIGS, etc.)
 11)  PHIGS/PEX Books
 12)  Articles on PEX
 13)  PEX Application Programmer Interfaces (APIs)
 14)  PHIGS Toolkit -- a portable toolkit for PHIGS programmers
 15)  Why doesn't HLHSR mode (Z buffering) work with the PEX-SI?
 16)  printing from PEX
 17)  Porting from PEX-SI PHIGS to PEXlib
 18)  Using PHIGS with PEX servers w/o the Workstation Subset
 19)  OReilly's Program! (BadMatch error in first.c)

Acronyms:

ANSI        American National Standards Institute
API        Application Programmer Interface
CGM        Computer Graphics Metafile
GKS        Graphics Kernel System
HLHSR        Hidden line and hidden surface removal
ISO        International Organization for Standardization
PEX        PHIGS/PHIGS-PLUS Extensions to X (obsolete)
PHIGS        Progammer's Hierarchical Interactive Graphics System
PHIGS-PLUS    PHIGS Plus Lumiere Und Surfaces
R5        X Window System, Version 11 Release 5
R6        X Window System, Version 11 Release 6
SI        Sample Implementation, usually refering to the PEX-SI

------
Subject:  1)  What's new?
From: Karl Schultz
Date: Sat Jul 15 1995

Many articles updated or rewritten to reflect the many changes to PEX
since the last (Mar94) revision.

7 Aug 95:

 - adjusted headers to appease the *.answers approvers.
 - added FAQ for hardcopy.

29 Nov 95:

 - added articles 17 and 18.

30 Nov 95:

 - added article 19.

------
Subject:  2)  What is PEX?
From: [e-mail] (Jay Hersh)
Date: Mon Dec  7 14:10:47 MST 1992
Message-Id: <[e-mail]>

It is a an Extension to the Core X Protocol to provide 3D graphics
support within the X Windows environment.

[PEX originally stood for PHIGS Extensions to X because it was
once intended to be used for implementing PHIGS in the X Windows
environment due to the popularity of PHIGS at that time.  As time
passed, PHIGS support became less interesting, and the goal of
supporting PHIGS became secondary to providing support for 3D application
programs in general. Today's PEX contains features well beyond
those needed to support PHIGS. RT/KS]

Included in the X11R5 and X11R6 distributions is code for the
Sample Implementation of the extensions to the X Windows server which
implements the functionality defined by the PEX Protocol Extensions.

In order to access the PEX functional extensions to the X Server
one must use an application that generates PEX Protocol.  The
application can either generate the Protocol bytestream itself, or
use something called an Application Protocol Interface or API for
short.  One such API which is provided with the X11R5 distribution
is the PHIGS 3D graphics standard.  This is a port of the PHIGS C
language binding onto an internal layer which generates the PEX
Protocol allowing this particular PHIGS implementation to work
within the X windows environment. [This same PHIGS library may
be found in the R6 contrib area, since it was withdrawn from the
R6 distribution in favor of PEXlib. KS]

Other alternate APIs are available via anonymous ftp from ftp.x.org
in the contrib areas.

R5 Content

Patches for a variety of problems in R5 are now available via
anonymous ftp on ftp.x.org, and the xstuff mail archive.

Fixes are available via anonymous ftp to ftp.x.org,
in the directory /pub/R5/fixes/.  The files for the new
fixes are "fix-18", "fix-19", and "PEXlib.tar.Z".  PEXlib.tar.Z is
part of fix #19.

Note that PEXlib is available only via the patch (fix 19).

Instructions for applying the fixes are included in
the files.  Fixes usually propagate to other distribution sites as
well, so it may pay to check at a nearer site first.

[Hopefully, if you are using R5, you will be using a completely
patched R5.

R6 Content

R6 contains all the patches for R5, including PEXlib, but no
longer contains the PHIGS library.  The PHIGS library may be
found in the R6 contrib area and can be built in the R6 tree
with some difficulty. KS]

- Jay Hersh
  MIT X Consortium

------
Subject:  3)  How can I tell if my X server supports PEX?
From: [e-mail] (Jay Hersh)
Date: Mon, 20 Jan 92 12:06:01 -0500
Message-Id: <[e-mail]>

The xdpyinfo command displays all the extensions supported by a server.
If one of the extensions listed is X3D-PEX then your server supports PEX.

- Jay Hersh
  MIT X Consortium

------
Subject:  4)  Why don't the R5 PEX demos work on my mono screen?
From: [e-mail] (X User's Group)
Date: Sun, 15 Dec 91 20:51:04 GMT
Message-Id: <[e-mail]>
Newsgroups: comp.windows.x

The R5 sample server implementation only works on color screens, sorry.

------
Subject:  5)  Where can I get an X-based PEX package?
From: [e-mail] (X User's Group)
Date: Sun, 15 Dec 91 20:53:23 GMT
Message-Id: <[e-mail]>
Newsgroups: comp.windows.x

    The official release of PEX is with X11R5 and X11R6 from
the X Consortium.

    PEX is supplied with various distributions of XFree and Linux.

    Many vendors supply PEX with their workstations.

    There is now available from the University of Illinois an
implementation of the PEX 4.0 specification called UIPEX. It contains a "near-
complete" implementation of PHIGS and PHIGS PLUS. The file
pub/uipex/uipex.tar.Z is on a.cs.uiuc.edu (128.174.252.1); the porting platform
was an RT running 4.3.  Questions and comments can to go [e-mail].
[I do not know the status of this package. KS]

    In addition, the PEXt toolkit by Rich Thomson
([e-mail]) is available from the X Consortium contrib
areas as PEXt.tar.Z; it includes a PEX widget making it easier to
include PEX in Xt-based programs.

    [Jan Hardenburgh's PEXIM should also be available from the
X Consortium contrib areas. KS]

------
Subject:  6) What about immediate mode for PEX?
From: [e-mail] (Jan "Yon" Hardenbergh)
Date: 7 May 91 15:39:02 GMT
Message-Id: <[e-mail]>
References: <[e-mail]>
Newsgroups: comp.graphics

PEX has immediate mode intrinsically.  No need to add it.  What is
needed is the API.  There are currently three proposed interfaces to PEX
Immediate mode: PEXIM, PEXlib and PEXtk.  PEXIM is actually a PHIGS
subset with immediate mode extensions.  PEXlib is to the PEX protocol
what Xlib it to the X protocol.  PEXtk is trying to capture the best of
the proprietary graphics interfaces.

Of course, PEXIM has the advantage that graphics hackers familiar with
PHIGS can pick it right up, or that can read one of the (great :-) PHIGS
books coming out.

The ANSI PHIGS committee started to add immediate mode to PHIGS.  So,
eventually, the API for PEX immediate mode will probably fall back to
PHIGS, but that is just opinion.

From: [e-mail] (James Helman)
> But does this actually address the problem?  The main reason that
> PHIGS is well-suited for networked graphics is that once your large
> mass of geometry is downloaded, you can rapidly change attributes and
> transformations without blasting the whole object down the slow wire.
> But in immediate mode, one typically sends everything down the wire
> each draw cycle.  With graphics speeds hitting 1 million polys per
> second, you certainly can't blast enough data down an ethernet to feed
> the graphics hardware.

You have to look at what is happening to the majority of the data.  If
the geometry is stable but the attribute change, then you can store the
geometry in the server and use immediate mode to send the attributes.
This is referred to as "mixed mode" or mixing stored structures with
immediate mode.  This is a very powerful model of graphics.

> Hence unless network bandwidth outpaces graphics performance, an
> immediate mode PEX API won't be particularly useful over a network.
> One could replace the PEX layer with local graphics access to get
> performance, thus making the immediate mode PEX API a standard for
> non-PEX graphics, but this is a rather convoluted path to such an end.

It's never safe to assume that the relative speeds of components of the
system will stay the same.  You are comparing the high end of rendering
with the low end of networking.  Compare the current high end of
networking, like FDDI at 12 MBytes per second and it works out just
fine.  1 M polygons/sec takes 12 MB / second.  Of course both of those
numbers are PEAK numbers.  When you start to look at what applications
really do, the peak numbers become irrelevant.

> Maybe GL and XGL's days aren't so numbered.  Or am I missing
> something?  Perhaps, local shared memory PEX request queues?  The
> article didn't even mention bandwidth as a concern.

Yes, of course good implementations of PEX will have shared memory.

[And today there are "local" implementations that can bypass the
protocol completely and control the graphics device directly when
the application is running local to the display hardware. KS]

But let's talk about the bread and butter cases.  The majority of the
market has not hit the 30 K triangles per second mark.  Ethernet can
keep up with that quite easily, and shared memory does more than keep
up.

But, there is overhead in a network transparent protocol.  To get rid of
it would require the application to write thier data directly into the
shared memory, then there are no copies, still something to work for.
People used to say X would never work due to the overhead, or for that
matter that fancy UI's do not work due to the overhead.  Depends on what
you want and where your priorities are.

My guess is that the combination of compute servers and PEX terminals
and workstations will help PEX become the graphics of choice.  If you
are not recomputing your 1 million triangles they can be in the display
list.  If you are recomputing them, how long does that take? on what
machine?

Disclaimer: I've had something to do with PEX and PEXIM and I always
speak on my own behalf, unless specifically stated otherwise.

-Jan "YON" Hardenbergh       [e-mail]         (508)-371-9810x261
Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742

------
Subject:  7)  Why don't the R5 PEX contributed demos compile?
From: [e-mail]
Date: Thu, 30 Apr 92 15:39:27 -0400
Message-Id: <[e-mail]>

>   [Initially at the time of R5's release...] it was a bit of
>   work to upgrade PEX to the new ISO IS PHIGS C Binding.  The examples
>   had been put into contrib a while back and there was no time nor
>   manpower to worry about updating those when other things had to be
>   fixed and upgraded (like the man pages).

The demos have been upgraded.  The new versions for the ISO PHIGS C
binding are available from export.lcs.mit.edu  in the file
PEX.examples.tar.Z in the directory contrib/R5fixes.

- Jay Hersh

-----
Subject:  8)  Why doesn't double-buffering work via phigs_ws_type_create?
From: [e-mail] (Rich Thomson)
Date: Sat, 23 Nov 91 20:38:52 GMT
Message-ID: <[e-mail]>
References: <[e-mail]>
Newsgroups: comp.graphics,comp.windows.x

In article <[e-mail]>
    senften@taurus (Scott D. Senften) writes:
>
>I need your help...I just got X11R5 up and running on my Sparc and I'm wanting
>to do some PHIGS+ work.  I've got a rough prototype up and running but I can't
>seem to get the double buffering working.  I tried:
>
> wks = phigs_ws_type_create(phigs_ws_type_x_tool,
>                            PHIGS_X_BUF_MODE, PHIGS_BUF_DOUBLE,
>                            0);
>
>but that alone doesn't seem to do it.  Am I missing something?

What you're missing is that the PEX-SI provides no support for double
buffering.

A serious hole in the PEX-SI is its non-support for double buffering.
Even worse, the PEX-SI api assumes that the client desires an
XClearArea on the window before each frame is drawn.  What really
should have been done was to provide an end-of-render procedure hook,
with the default hook installed to do a clear area.

Individual vendors (because of market pressure) have provided their
own solutions to the double buffering problem (we do double buffering
an all PHIGS workstations; if you do immediate-mode you get single
buffering along with the PEX-SI's XClearArea call).

I believe the PEX interoperability group is currently working on a vendor
neutral solution that we can all agree on.

                        -- Rich

-----
Subject:  9)  What does "Kernel not configured with shared-memory IPC" mean?
From: [e-mail] (Mike Herbert)
Date: 25 Nov 91 18:54:35 GMT
Message-ID: <[e-mail]>
Newsgroups: comp.windows.x

Francis J. Hitchens writes:
> I have just built X11R5 on my VAXstatsion 3100, under ULTRIX 4.1, and
> tried to run the PEX
> tests.
>
> They all failed...
>
> PHIGS error -57 in OPEN PHIGS: Kernel not configured with shared-memory IPC
> facility needed for PEX SI communication

I ran into this problem last week.  Here's what I've determined so far.

Your PEX library has been built so that it is trying to use the shared-memory
IPC facility to communicate with the phigsmon program.  If your client
does not need phigsmon, then turn it off:

setenv PEX_SI_API_NO_PM 1

(Typically you should only need phigsmon for doing PHIGS input or client-
side structure storage.)

Another alternative is to rebuild the PEX library so that it uses sockets
to communicate with phigsmon.  You can do this by defining
"PEX_API_SOCKET_IPC".  (I haven't tried this, but the code indicates
that it should work.)

The other alternative, of course, it to configure your kernel to use IPC.
(I'm a novice as far as Ultrix is concerned, so I really don't understand
what's involved in doing that.)

Mike Herbert
Tektronix, Inc.
Network Displays Division
P.O. Box 1000, M/S 60-850
Wilsonville, OR 97070
[phone]

[e-mail]

-----
Subject:  10)  Obtaining Graphics Standards (GKS, PHIGS, etc.)
From: [e-mail] (Jan "Yon" Hardenbergh)
Date: 12 Feb 91 19:27:53 GMT
Message-ID: <[e-mail]>
Newsgroups: comp.graphics

GKS - Graphical Kernal System - geometric graphics system
CGM - Computer Graphics Metafile - archive of graphics commands - very
      useful for plotting.
PHIGS - the best graphics standard!  3D geometric graphics with lighting
      and shading and neat primitives to draw fancy pictures.
If you are looking for a broad overview of graphics standards you might
try this:

>   Guidelines for determining when to use GKS and when to use PHIGS
>   Bettels, J.; Bono, P.R.; McGinnis, E.; Rix, J.
>   Author Affil:  Digital Equipment Corp., Geneva, Switzerland
>   Source: Comput. Graph. Forum (Netherlands)  vol.7, no.4,    pp.: 347-54
>   Publication Year: Dec. 1988
>   (29 Refs)
>   Abstract:  GKS,  GKS-3D, and PHIGS are all approved ISO standards for the
> application  programmer  interface.  How  do system analysts or programmers
> decide which standard to use for their application? The authors discuss the
> range  of  application  requirements  likely to be encountered, explore the
> suitability  of  GKS and PHIGS for satisfying these requirements, and offer
> guidelines to aid in the decision process.

I know I've seen other overviews of graphics standards. Just none recently.

There are a couple of books on CGM and GKS, but I do not have the
references written down.

As, for PHIGS, you can get the standard itself from ANSI in New York.
212-642-4900, 11 West 42nd Street, NY, NY 10036.  [The following table
gives the ANSI standard numbers corresponding to the PHIGS standards:

    ANSI X3.144-1988    ISO 9592 parts 1, 2 and 3 for PHIGS
    ANSI X3.144.1        ISO 9593-1 for PHIGS FORTAN binding
    ANSI X3.144.3        ISO 9593-3 for PHIGS Ada binding
    ANSI X3.144.4        ISO 9593-4 for PHIGS C binding

--RT]  They will also have the GKS and CGM specs.

-Jan "YON" Hardenbergh       [e-mail]         (508)-371-9810x261
Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742

-----
Subject: 11) PHIGS/PEX books
From: [e-mail] (Jan Hardenbergh )
Date: Fri, 3 Sep 1993 00:31:21 GMT
Summary:  lots of PHIGS and PEX books out there.
Id:  <[e-mail]>

I'm perhaps not the best judge, since I have them all (or will soon) and
have a trial membership to the authors club, where we all chum around
together :-)

But if your job is actually to work with either PHIGS or PEX, SPEND the
$200+ or so to get many of the books here. It's a tiny investment in
your career, especially if you get reimbursed! If you are the type that
only wants one book on a subject, go to a bookstore and look carefully
at which one you want, after all, you can't judge a book by its email.

The books I'd buy again appear in order of appearance.

PHIGS Books
===========

Toby Howard et al. "A Practical Introduction to PHIGS and PHIGS PLUS"
Addison-Wesley 1991, ISBN 0-201-41641-7
  A "great" small book on PHIGS.  Covers almost everything, but briefly.
  Not good to program from, but if your question is what is PHIGS, this
  will be the best place to start for most people.

Tom Gaskins. "PHIGS Programming Manual", O'Reilly 1992,
    ISBN 0-937175-92-7 (casebound)  ISBN 0-937175-85-4 (soft)
  This is the most comprehensive and the best to program from for Sun
  and any PEX-SI based PHIGS product. Tom knows this stuff inside and out.

Joseph E Kasper and David Arns."Graphics Programming with PHIGS and PHIGS-PLUS"
HP Press/Addison Wesley, ISBN 0-201-56343-6
  A book more oriented to the standard than Gaskins' book, It has
  both FORTRAN and "C" and uses new binding. Especially good for HP.

John W. Blake. "PHIGS + PHIGS+, An Introduction to 3D Computer Graphics"
Acedemic Press/Harcourt Brace Jovanovich Ltd. ISBN 0.12.103515.8
(only from 24-28 Oval Road, London, NWI 7DX, UK //  Lbs 29.95 ??)
  I'm buying it, sight unseen...

"PHIGS Reference Manual", O'Reilly 1992, Edited by Rich Ellis & ...
 ISBN 0-937175-91-9
  Man Pages (improved version of the PEX-SI man pages)

Hopgood & Duce, "A Primer for PHIGS" John Wiley & Sons Ltd,
ISBN: 471 93042 3 (no PHIGS-PLUS)
  Some useful notions on structure editing.

W.A. Gaman, W.A. Giovinazzo, "PHIGS by Example", Springer-Verlag,
ISBN 0-387-97555-1

PEX Books
=========

Tom Gaskins' "PEXlib Programming Manual", O'Reilly 1992, ISBN 0-56592-028-7
  This is a great book.

Paula Womack, PEXlib: A Tutorial, Prentice Hall 1993 (printing, due October)
ISBN 013-015843-7.
  Sight unseen. Paula was document editor for PEX 5.1, I'd bet it's great.

Mark Graff, PEXlib: A Reference Manual, Prentice Hall, ISBN 013-176066-1,
  Sight unseen.

"PEXlib Reference Manual", O'Reilly 1992,  ISBN 1-56592-029-5
  Man pages for PEXlib SI,  with intro by Tom Gaskins.

...and one more...
Jan Hardenbergh, Building Applications with PEXlib, Prentice Hall, (December)
ISBN 013-012535-0.
  I've seen too much of this to be impartial! I like it.

My conscience is clean (still) about using the internet for commercial gain.
I've been sending out these lists of PHIGS books since before I had even
thought of writing one. But at this point I'll stop because I think it is
a gray area. I hope someone else will take it up. Joe?

Opinions expressed are my own, my employer uses HOOPS!
Jan "YON" Hardenbergh     - [e-mail] -      617-275-1800x3275
Computervision Corp.        MS 5-2, 14 Crosby Drive, Bedford, MA 01730
"Imagination is more important than knowledge" A. Einstein - Thank God!
-----

Subject: 12) Articles on PEX
From: [e-mail] (Ken Lee)
Date: 12 Aug 91 17:06:05 GMT
References: <[e-mail]>

Clifford, William, John McConnell, and Jeffrey Friedberg, "The Development
     of PEX, A Three-dimensional Graphics Extension to X11," in Proceedings
     of Eurographics'88, September, 1988.  An overview PEX, an extension to
     the X protocol to support PHIGS+.

Rost, Randi, Jeffrey Friedberg, and Peter Nishimoto, "PEX:  A Network-
     Transparent 3D Graphics System," IEEE Computer Graphics & Applica-
     tions, pp. 14-26, July, 1989.  A good overview of PEX, the
     PHIGS/PHIGS+ 3D extension to X. A complete PEX is currently being
     developed by Sun under contract to the MIT X Consortium and is
     scheduled to be publicly available in 1991.

Stroyan, Michael, "Three-Dimensional Graphics Using the X Window System,"
     Dr. Dobb's Journal, vol. 15, no. 2, pp. 28-36, February, 1990.  A high
     level description of various approaches to developing 3D graphics
     tools for X, including those of the PHIGS Extension to X (PEX) and
     HP's Starbase-on-X11 (sox11).

Sung, Hsien Ching Kelvin, Greg Rogers, and William Kubitz, "A Critical
     Evaluation of PEX," IEEE Computer Graphics & Applications, vol. 10,
     no. 6, pp. 65-75, November, 1990.  An evaluation of PEX, the X exten-
     sion to support PHIGS, from the point of view of a PHIGS implementor.

Thomas, Spencer W. and Martin Friedmann, "PEX - A 3-D Extension to X Win-
     dows," in Proceedings of the Winter, 1989 USENIX Conference, pp. 139-
     149.  Describes a demonstration implementation of PEX, the
     PHIGS/PHIGS+ 3D extension to X. A complete PEX is currently being
     developed by Sun under contract to the MIT X Consortium and is
     scheduled to be publically available in 1991.

-----
Subject: 13)  PEX Application Programmer Interfaces (APIs)
From: [e-mail] (Rich Thomson)
Date: Tue Mar  2 22:27:37 MST 1993

When discussing PEX, it is important not to confuse the protocol with
the API, or application programmer interface.  The API is the
conceptual model of 3D graphics that the application developer sees.
The protocol is generated by the API and is interpreted by the server
to perform graphics requests on behalf of the client program.

One API provided with the R5 PEX-SI is a PHIGS/PHIGS-PLUS API.  The
PHIGS/PHIGS-PLUS standards are specified in two parts.  First, a
functional description describes each operation conceptually, in a
language-independent manner.  Second, language bindings are used to
bind the particular PHIGS functions to the semantics of the language.
The PEX-SI comes with an application programmer interface that
conforms with the latest revision of the PHIGS/PHIGS-PLUS C language
binding.

Bob Schulte of SHOGraphics had this to say about their GL-like API
called PEXtk:

    Newsgroups: comp.windows.x.pex
    From: [e-mail] (Bob Schulte)
    Subject: Re: difference between PEX and GL
    Date: Fri, 5 Feb 1993 16:03:42 GMT

    PEXtk is complete and available now directly from export.mit.lcs.edu,
    and is located in /contrib. The files are pextk.PS.tar.Z, pextk.README,
    and pextk.tar.Z.  It is Free.

    Depending on how you write a GL program and what features you use
    it may or may not be difficult to port to PEXtk. It would certainly
    be easier than porting to PHIGS.

    For example PEXtk uses X as its windowing system, so the UI is X
    based. We have not attempted to duplicate any GL windowing functions.

    Bob
    --
    Bob Schulte,        E-Mail: [e-mail]    Voice: [phone]
    SHOgraphics.        Performance Through PEX


If your version of R5 is patched through patch #22, you have a second
MIT supplied API called "PEXlib".  PEXlib is to the PEX protocol what
Xlib is to the core X protocol.  PEXlib provides an interface that is
as close as possible to a one-to-one correspondence between functions
and protocol requests.  It is intended to be a systems programming
interface (i.e. people developing graphics toolkits and graphics
systems will implement their system on top of PEXlib).  It is proposed
that the PHIGS API be ported to PEXlib once PEXlib is finalized.  This
change would not affect programs written to the existing PHIGS API.
However, since PEXlib is intimately tied to the protocol, it is
expected that there will be changes between the current PEXlib (which
supports version 5.0 and 5.1 of the PEX protocol) and the PEXlib that
supports the next major version of the PEX protocol, version 6.0.
Naturally, every attempt will be made to make the changes to the API
minimal.  The nature of the changes from 5.1 to 6.0 are not such that
every primitive will be affected; rather the changes deal with the
sticky problems of subsets, multi-buffering, and other issues of
global rendering semantics.
[PEX 6.0 was dropped and a backwards compatible PEX 5.2 was created
instead. KS]

The future may contain other popular graphics APIs (SGI's GL, HP's
Starbase, Stardent's Dore') that also generate the PEX protocol.

                        -- Rich
-----
Subject: 14)  PHIGS Toolkit -- a portable toolkit for PHIGS programmers
From: Gareth Williams <[e-mail]>
Date: Mon, 8 Feb 93 08:56:20 GMT
Message-Id: <[e-mail]>

                     THE PHIGS TOOLKIT

     A PORTABLE TOOLKIT FOR PHIGS APPLICATION PROGRAMMERS

            *************************************
            **** NEW RELEASE VERSION 3.2 FOR ****
            ****       SunPHIGS 2.0          ****
            ****       HP PHIGS 2.2          ****
            **** ##    IBM graPHIGS 1.02  ## ****
            ****         PEX-SI              ****
            *************************************

We are pleased to announce the availability of version 3.2 of the PHIGS
Toolkit, a portable toolkit for PHIGS application Programmers. The PHIGS
Toolkit has been developed at the University of Manchester, UK, and is
funded by the Science and Engineering Research Council (SERC) and the
Advisory Group on Computer Graphics (AGOCG). The Toolkit is based on the
experience of the developers who have been active PHIGS programmers for
several years and were also involved in the ISO technical review of PHIGS
and PHIGS PLUS.

Following the release in September this year of version 3.1 of the PHIGS
Toolkit, version 3.2 is now available which supports SunPHIGS 2.0,
HP PHIGS 2.2, IBM graPHIGS 1.02 and MIT's PEX-SI.

MAIN FEATURES OF THE TOOLKIT
----------------------------

 o comprehensive transformations library
 o automatic drawing of structure network hierarchy diagrams
 o automatic drawing of structure content diagrams
 o interactive CSS debugger
 o interactive view editor
 o window system implemented using PHIGS structures
 o interactive PHIGS Interpreter
 o comprehensive colour model support library
 o menu system to extend PHIGS input

 o Runs with C and FORTRAN for SunPHIGS on SunOS
 o Runs with C for HP PHIGS on HP-UX
 o Runs with C for graPHIGS on AIX
 o Runs with C for PEX-SI on SunOS
 o Runs with C and FORTRAN for DEC PHIGS on VAX/VMS (PTK 2.0 only)

 o full source code provided
 o demonstration programs provided
 o comprehensive documentation

WHAT IS THE PHIGS TOOLKIT?
--------------------------

The purpose of the PHIGS Toolkit is to help application programmers to
program more effectively and securely using PHIGS. The functionality
provided by PHIGS is low-level, and the PHIGS Toolkit provides a number of
tools of various levels of complexity in order to make programming with
PHIGS quicker, and less painful.  To the programmer, it is as if the
functions provided by PHIGS have been supplemented with a set of additional
functions, and a typical application will use both `raw' PHIGS functions as
well as PHIGS Toolkit functions.  A convenient way to view the Toolkit is
as a layer of software which sits `on top of' PHIGS.

Tools in the PHIGS Toolkit are divided into two categories: PROGRAMMING
TOOLS, and HIGH-LEVEL TOOLS.  Programming tools are generally quite simple
single-purpose procedures, and are designed to help applications
programmers to construct PHIGS programs more quickly and reliably. The
high-level tools are more powerful, and provide programmers with means for
visualising and debugging structure networks.

PROGRAMMING TOOLS
-----------------

 o the Transformations Library -- functions for
   constructing and manipulating coordinate transformations.

 o the HashStrings Library -- functions which enable text
   strings to be used in situations where integers would normally
   be required.

 o the PHIGS Utilities Library -- utility functions,
   providing operations (such as `copy element') which are not directly
   provided by PHIGS, as well as common sequences of PHIGS function calls
   `bundled up' into single functions.

 o the PHIGS Traversal State List Library -- functions for
   controlling and inquiring a simulated structure network traversal.

 o the Colour Library -- functions for defining colour
   values using English words and phrases, and for interchangeably
   manipulating colours using various colour models.

 o the PHIGS Textual Interpreter (Phinter) -- a tool for reading textual
   PHIGS scripts. Phinter may be used interactively with a PHIGS string device
   or standard input.

HIGH-LEVEL TOOLS
----------------

 o the PHIGS Structure Content Drawer -- a tool to generate diagrams
   showing which elements structures contain.  The diagrams are themselves
   PHIGS structures, with a documented format.

 o the PHIGS Topology Library -- functions for
   automatically generating diagrams representing the topology of PHIGS
   structure networks. The diagrams are themselves PHIGS structures, with a
   documented format.

 o the PHIGS Menus Library -- functions for constructing
   and manipulating menus built using PHIGS structures.

 o the PHIGS Windows Library -- functions for displaying
   and viewing PHIGS structure networks in windows.

 o the PHIGS Debugger -- a tool (modelled after conventional
   programming language debuggers) for simulating the traversal of structure
   networks. The traversal may be stepped through incrementally and the state
   of the traversal inquired at any stage.

 o the PHIGS View Editor -- a utility for interactively editing and
   experimenting with viewing parameters for a scene.

PHIGS TOOLKIT INFORMATION   ** REGISTER NOW **
----------------------------------------------

We would like to encourage all people interested in the PHIGS Toolkit to
register as PHIGS Toolkit users. This will ensure that all PHIGS Toolkit
users will receive notice of new versions, course dates, bug reports and
any other useful information.  Please send the following information to
[e-mail].

   Name:
   Organisation:
   email:
   Telephone/FAX:
   PHIGS implementations used:

Even if the PHIGS Toolkit is not currently available for your particular
PHIGS implementation, please register. We are currently working on ports to
several other PHIGS implementations and it would be very useful to know
what the demand is for different versions.

HOW TO OBTAIN THE PHIGS TOOLKIT
-------------------------------

The PHIGS Toolkit is available from two sites in the UK:

PTK from Kent
-------------

The PHIGS Toolkit is available from HENSA (Higher Education National
Software Archive) at the University of Kent.

The HENSA Service at the University of Kent can be accessed in a number
of ways:

Interactive
-----------

There is a friendly interactive interface which has a useful find
utility for locating software.  Connect to unix.hensa.ac.uk and log
in as "archive" for an interactive interface to the HENSA archive.
Connections can be made using telnet (unix.hensa.ac.uk) and X.29
across JANET (uk.ac.hensa.unix, DTE 000049200900).

anonymous ftp
-------------

Using DARPA FTP connect to the machine unix.hensa.ac.uk and
login as "anonymous", giving your email address as the password.

guest NI-FTP]
Using Blue Book NI-FTP with the following:

address: uk.ac.hensa.unix
login: guest
path: <ARCHIVE>/filename

eg.     % fcp -b "<ARCHIVE>/uunet/ls-lR.Z"@uk.ac.hensa.unix ls-lR.Z
User name on uk.ac.hensa.unix? guest
Password on uk.ac.hensa.unix? [e-mail]

email server
------------

Send a message to "[e-mail]" containing the
string "help" for details on how to use it.

Any general queries regarding the HENSA service at The University of
Kent should be directed to [e-mail], queries specific to
the Netlib service should be sent to [e-mail] and
stuff concerning the source archive to [e-mail].

The relevant files for the PHIGS Toolkit on HENSA are:

PTK 3.2     /misc/unix/phigstk/PhigsToolkit3.2.tar.Z
                                      for SunPHIGS 2.0 on SunOS,
                                          HP PHIGS 2.2 on HP-UX,
                                          graPHIGS 1.02 on AIX,
                                          PEX-SI on SunOS.

PTK 2.0    /misc/unix/phigstk/PhigsToolkit.tar.Z
                                      for SunPHIGS 1.x on SunOS.
           /misc/vms/phigstk/ptk.hex for DEC PHIGS 2.3A on VAX/VMS.

PTK from Manchester
-------------------

  By anonymous ftp from uk.ac.mcc.hpb. (130.88.200.7)
  Username "anonymous", and your network address as password.
  The files are:

PTK 3.2     pub/cgu/ptk/ptk3.2.tar.Z for SunPHIGS 2.0 on SunOS,
                                  HP PHIGS 2.2 on HP-UX,
                                  graPHIGS 1.02 on AIX,
                                  PEX-SI on SunOS.

PTK 2.0     pub/cgu/ptk/ptk.tar.Z for SunPHIGS 1.x on SunOS.

            pub/cgu/ptk/ptk.shar* for DEC PHIGS 2.3A on VMS.

(
For VMS the Toolkit is stored as a collection of SHAR files.
There are 288 files in total, each 15K in size.
They are called ptk.shar_X where X is 1 ... 288.
To rebuild the Toolkit directory structure the
files must be concatenated together and run as a command file.

   $ copy ptk.shar_%, ptk.shar_%%, ptk.shar_%%% ptk.shar
   $ @ptk.shar
)

PTK by Magnetic Tape
--------------------

Send a 1/4 inch cartridge for SunOS, and a 1/2 inch open reel magnetic tape
for VMS to:

Tim Hopkins
Computing Laboratory
University of Kent
email: [e-mail]

or

Toby Howard
Department of Computer Science
University of Manchester
Oxford Road
Manchester M13 9PL
United Kingom
Tel: [phone]
Fax: [phone]
email: [e-mail]

PHIGS TOOLKIT TRAINING COURSE
-----------------------------

A training course for users of the PHIGS Toolkit was held at the
University of Manchester on September 23rd 1992. Course materials
including four programming exercises and three step-through
tutorials are provided in this release of the Toolkit.

FUTURE WORK
-----------

The first phase of the PHIGS Toolkit does not include support for PHIGS
PLUS. Work is now underway to expand the Toolkit to include extensive
support for PHIGS PLUS functions, and the expanded PHIGS Toolkit will be
released in April 1993.

A toolkit providing support for NURBS curves and surfaces has also
been developed at Manchester, and is designed to be complementary to
the PHIGS Toolkit. It is available from the same sites as PTK.

BETA TEST
---------

We are currently looking for beta testers for the PHIGS PLUS extensions
and the test will start in the new year and finish at the end of February
1993. A short report will be required from testers. Please get in touch
if you are interested in being a tester.

Toby Howard, Terry Hewitt, Gareth Williams, Steve Larkin, David Yip
University of Manchester
Oxford Road, Manchester, M13 9PL, United Kingdom


-----
Subject: 15)  Why doesn't HLHSR mode (Z buffering) work with the PEX-SI?
From: Rich Thomson <[e-mail]>
Date: Mon Mar 28 14:14:49 MST 1994

Sorry, the PEX-SI doesn't have any support for hidden line and hidden
surface removal (HLHSR), commonly implemented through Z buffering.
The PEX-SI team decided that since Z buffering is very device specific
they would leave it up to each vendor to implement Z buffering support
for the first release.

[The PEX-SI (server code) decomposes PEX primitives down to X-level
primitives and draws them via the DDX interface.  This allows the
PEX-SI code to work with virtually any X server implementation.
The downside is that certain non-X features like Z buffer operations
and color interpolation of spans is not available. KS]

It is planned to provide software Z buffer HLHSR support in the
PEX-SI, probably in the R6 release.

[There is a patch on contrib that does this. KS]

The PHIGS standard allows an implementation to provide only HLHSR mode
NONE and still be a conformant implementation of the standard.  This
is probably a leftover from the days of calligraphic and storage-scope
type displays which don't have Z buffers or other HLHSR removal methods
in hardware (except hardware-based sorting for hidden-line removal).

                        -- Rich


-----
Subject: 16) printing from PEX
From: [e-mail] (Karl Schultz)
Date: 4 Aug 1995 14:44:28 GMT

In article <3vl5ev$[e-mail]>, gero@PROBLEM_WITH_INEWS_DOMAIN_FILE (Gero Dargel) writes:
> Hi,
> can anybody tell me how to print (in better quality than
> screen-dump) from PEX-PHIGS (PEX-SI).
> I'm looking for a mechanism like the CGM-workstation in
> S?N-PHIGS.

In a word, no.

There may be a chance that some vendor has added this as a feature to
their product.

Additional info:

The PHIGS SI doesn't support any sort of hardcopy workstation type.
As noted above, some vendors may have PHIGS-related products that do
this.  The PHIGS SI does have some support of "workstation types" in
the area of whether or not PHIGS will create the window for you, or
will accept an existing window to draw into as is convenient with
toolkit applications.  This particular control is all implemented in
the PHIGS client-side library, so no real PEX protocol support is
required.

However, for additional workstation type requirements like hardcopy
support where you want the work done in the server someplace, PEX
would need some sort of extension or augmentation to allow the client
to specify what workstation type to use when creating a workstation.
In the PEX Workstation Subset, this might be some sort of list of
supported workstation types to select from, and in the Renderer Subset
of PEX, this concept might be introduced via "renderer classes" that
can be specified when creating a renderer.  This might, for example,
allow selection of a ray-tracer to draw a scene, instead of the
usual polygonal renderer.  In any case, the PEX protocol today probably
cannot support hardcopy workstation/renderer types and the SI certainly
does not implement anything like it.

Karl Schultz

-----
Subject: 17)  Porting from PEX-SI PHIGS to PEXlib
From: Karl Schultz <[e-mail]>

Here is an account (provided by David Friend) of the experience
of porting a PEX-SI PHIGS application to PEXlib.  As always,
your mileage may vary, but you can get some ideas of what is
involved from these notes.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I started by doing the following:

   - Stuff involved in making the decision.
   - Bought a copy of "PEXlib Programming Manual" by Tom Gaskins.
   - Printed out a copy of "PEXlib Specification and C Language
     Binding" by Jeff Stevenson.  (This is a postscript file that
     comes with X11R6.  It is for PEX version 5.1.  It was written
     November 5, 1992.  I did not buy the PEXlib reference manual
     because every store in town that normally stocked it was out.)

     At this point I went through the source code in my program and,
using my PHIGS and PEXlib manuals, replaced each structure type and
function call with the equivalent in PEXlib.  (I commented out the
three routines that handle picking, exposures, and the X-Windows to
world coordinates conversion.  I did not need these routines immed-
iately.)  After fixing errors and warnings generated by the compiler,
and one bug (to be mentioned shortly), I had a working program, barring
the missing sections.  In all, it took 30 hours to port the 550 Kbytes
of source code.  The picking and exposures took another 7.5 hours.
The XC to WC conversion routine took 7.5 hours; this is the one
point in the entire port that I had to write new code, rather than
do a straight forward conversion.

     The one serious bug I had was this.  Many of the routines require
that you pass a pointer to the display.  You must pass the one
returned by XOpenDisplay().  If you pass one returned by XtDisplay()
you will get an unexplained core dump.  Furthermore, some X and Xt
routines that worked fine before with the value returned by XtDisplay()
will now behave incorrectly.  Use the value from XOpenDisplay() instead.

(KWS: This is probably some sort of bug;  I've written many PEXlib
programs that obtain the Display variable from XtDisplay().)

     Completing the port, updating documentation, porting a second
program of similar size, creating installation disks, installing the
code in client sites, etc. will probably result in the port taking a
total of 150 hours.

(KWS: Port was done on Sun equipment - here are some notes:)

   - You may use shared library /usr/openwin/lib/libPEX5.so.2 that
     comes with Solaris.  However, you must provide your own include
     files.  They may be found in /usr/X11R6/include/X11/PEX5/PEX*.h,
     or in xc/lib/PEX5/PEX*.h in the uncompiled source distribution
     for X11R6.  Almost identical include files are provided with
     X11R5 after you have applied the 22 patches.

   - If you also use Motif, you may use the shared libraries and
     include files found under /usr/dt.  Do not use the ones that
     come with the Software Development Kit.  Programs that are
     compiled and linked with the SDK versions will not run unless
     the target computer also has the Motif shared libraries that
     come with the SDK.

   - Always use the Display pointer returned by XOpenDisplay() for
     all PEX, Xt and X routines.  Don't use the one returned by
     XtDisplay().  (Actually, I had two non-PEXlib routines that
     insisted on the one returned by XtDisplay(), and would not
     work with the one returned by XOpenDisplay().)

   - Your LD_LIBRARY_PATH environment variable must point to the
     correct shared library directories.  Unlike Solaris v1.1.x,
     the programs do not appear to know where to look for their
     shared libraries.  Use command "ldd" to see what shared
     libraries your program is looking for.

   - My program exercised PHIGS pretty thoroughly.  However, it did
     not use most of the new features available in PHIGS PLUS.  It
     did complicated viewport, etc. transformations.  It did picking,
     handled exposures, grabbed the images from the server after they
     were drawn, etc.  It used a fake RGB standard colormap, in which
     it wrote what every colours it wanted.  This kludge ported without
     special effort.  All of this translated easily into PEXlib,
     barring the X-Windows to World coordinates transformation.

   - Find below the notes I made while porting that relate directly
     to the PEX-SI to PHIGS conversion.  They are edited to remove
     some of the notes specific to my program.





                       PEX-SI to PEXlib Porting Notes


Done (in general):
   - In Imakefile replace "-lphigs" with "-lPEX5".
   - In Imakefile, for Solaris, add -I../R6_PEX5.
   - Replace "<phigs/phigs.h>" with "<X11/PEX5/PEXlib.h>".
   - Replace ppost_struct() and pupd_ws() with PEXRenderNetwork().
   - Replace pescape() request to wait for PHIGS update with XSync().
   - PEX cannot handle the value returned by XtDisplay().  It must use
     the one returned by XOpenDisplay().  Some X and Xt routines have
     the same problem.  Modify code accordingly.
   - Redid main.c:xc_to_wc().
   - Redid main.c:RedrawPHIGS().


Done (to initialize system and renderers, etc):
   - In main() replace initializing PHIGS with initialzing PEXlib.
   - In main() don't tell PHIGS to ignore DC limits.
   - Put "PEXRenderer renderer" in TargetType.  Initialize to None in main().
   - In create_workstation():
        - Remove test to see if workstation is open.
          Use "Target->renderer != None" in place of "workstation_open".
        - Remove closing of PHIGS workstation.
        - Replace section opening PHIGS workstation with the equivalent
          for opening a PEX renderer.
   - Add global values RendererDefaults and RendererDefaultMask.
   - Replace pclose_ws() with PEXFreeRenderer().
   - Deleted pclose_phigs().


Done (to update colour tables):
   - Replace "Pcolr_rep" with "PEXColorSpecifier".
   - Use the new member values in Target->ColourMap for read_file()
     and scale_image(); ColourMap in read_tiff_image(), write_tiff_image()
     and colour_to_bw(); rgb in create_workstation(); and colr in
     set_palette().
   - In create_workstation() call PEXSetTableEntries() in place of
     pset_colr_rep().
   - In main() create colour table and colour approximation table.
     Initialize the colour approximation table.
   - Move initializing colour table from create_workstation() to main().


Done (to update generating structures);
   - In main(), when calling PEXInitialize, make sure that the server
     supports structures.
   - Replace pempty_struct() with PEXDeleteElements().
   - Remove all calls to popen_struct() and pclose_struct().
   - In main() create the PEX structures.
   - In main(), at end, don't call punpost_all_structs(), do delete all
     PEX structures.
   - Replace pexec_struct() with PEXExecuteStructure().
   - Replace pset_line_colr_ind() with PEXSetLineColorIndex().
   - Replace "Ppoint3" with "PEXCoord".  (The members are the same.)
   - Got rid of "Ppoint_list3".
   - Replace ppolyline3() with PEXPolyline().
   - Replace pset_int_colr_ind() with PEXSetSurfaceColor().
   - Replace pfill_area_set3() with PEXFillArea().
   - Delete calls to pinq_edit_mode(), pset_edit_mode(), pset_edge_flag()
     and pset_linetype().  They were all setting values to the defaults.
   - Replace pset_int_style() with PEXSetInteriorStyle().
   - Replace pset_linewidth() with PEXSetLineWidth().
   - Replace pset_text_colr_ind() with PEXSetTextColor().
   - Replace pset_char_ht() with PEXSetCharHeight().
   - Replace ptext3() with PEXText().
   - Replace pset_text_align() with PEXSetTextAlignment().


Done (to update picking):
   - Replace padd_names_set() with PEXAddToNameSet().
   - Replace premove_names_set() with PEXRemoveFromNameSet().
   - In main() add and initialize a pick filter for the renderer defaults.
   - In main(), at end, free the pick filter name set resources.
   - Change "Ppick_path_elem" to "PEXPickElementRef".  Change members
     struct_id, pick_id and elem_pcs to sid, pick_id and offset.
   - Change "Ppick_path" to "PEXPickPath".  Change members depth and
     path_list to count and elements.
   - Replace pescape() request to do picking with PEXPickOne().
   - Replace pinq_elem_type_size() and pinq_elem_content() with
     PEXFetchElements() and PEXDecodeOCs().


Done (to update views):
   - Create a separate view table for each PEX renderer.
   - Replace pset_view_ind() with PEXSetViewIndex().
   - Replace pset_view_rep3() with PEXSetTableEntries().
   - Replace pset_ws_vp3() and pset_ws_win3() with PEXChangeRenderer()
     with mask = PEXRAViewport | PEXRANPCSubVolume.
   - Replacae peval_view_ori_matrix3() with PEXViewOrientationMatrix().
   - Replace Pview_rep3 with PEXViewEntry.  (The members have changed.)
   - Replace peval_view_map_matrix3() with PEXViewMappingMatrix().


Done (to update modelling transformations):
   - Replace "Pmatrix3" with "PEXMatrix".
   - Replace "Pvec3" with "PEXVector".  Change members from delta_x,
     delta_y and delta_z to x, y and z.
   - Replace ptranslate3() with PEXTranslate().
   - Replace pscale3() with PEXScale().
   - Replace protate_x() and protate_y() with PEXRotate().
   - Repalce pcompose_matrix3() with PEXMatrixMult().
   - Replace pset_local_tran3() with PEXSetLocalTransform().
   - Replace ptran_point3() with PEXTransformPoints().

-----
Subject: 18)  Using PHIGS with PEX servers w/o the Workstation Subset
From: Karl Schultz <[e-mail]>

Some PEX vendors (HP, and now Sun) do not support the PHIGS
Workstation Subset in their PEX servers.  Is it still possible
to use the PEX-SI PHIGS API with these servers?

The answer is YES, if you set the right environment variable.

The environment variable is PEX_SI_API_CLIENT_SS.

If you set it to a non-zero value, the PHIGS API will not use the
PHIGS workstation subset in the PEX server and send the data in
immediate mode to the server.

Note that this has obvious performance implications if you are
running your application over a network, but if running locally,
the difference may not be noticable.

-----
Subject: 19)  OReilly's Program! (BadMatch error in first.c)
From: [e-mail] (Karl Schultz)
Date: 1 Dec 1995 01:42:57 GMT
Organization: Hewlett-Packard Fort Collins Site
Lines: 59
Message-ID: <49lmj1$[e-mail]>
References: <49l2jv$[e-mail]>
NNTP-Posting-Host: manfred.fc.hp.com

In article <49l2jv$[e-mail]>, [e-mail] (Narayanan Ramabadran (R)) writes:
>
> Hi Everyone!
> I know i have been bugging some of you these past few days as to try and
> figure out why my "first.c" was not working on the sun solaris.
> I have figured out what the problem is.......

Maybe I'll add this to the FAQ.

> Here goes:
> the rest of the programs  use the functions given is "book_utils.c" where
> there is no bug... On the other hand, in the "first.c" the function call
> to XCreateWindow misses one of the parameters (in the calling function!).
> To be specific, the "CWBorderPixel" is missing... I added this and BINGO!
> it works fine..... i am feeling sick that i have been scratching my heaD
> over this for the last week or so!!!

If anyone wants to understand WHY, please read:

In the failing environment, Sun, in this case, the example program was
apparently trying to create a window that was of different (deeper) depth
than the parent.  This is fairly common on servers that support both
8 and say, 24 bit deep visuals.  The root window is usually 8 bit
and X clients can create 24-bit deep windows if they want.
When a client creates a window, the window usually inherits all its attributes
from the parent, unless they are overridden by parameters and supplied
window attrubutes.  In this case, the 24-bit window tried to inherit
the 8-bit parent's BorderPixel attribute.  A pixel for an 8-bit drawable
cannot be logically converted for use in a 24-bit drawable, so this
attribute MUST be supplied/overriden when creating a window of different
depth than its parent.

This is a very common error that traps a lot of people.

> But with the same error, it works from the IBM RS/6000...

Probably because the IBM machine didn't support visuals of more than
one depth.

> Karl: thanks for the mail you sent me.. i was trying to figure out what
> the border and background pixel values were (as per your advice) and that's
> when i noticed this!!!!!

I sent that to you because that is what I thought was causing the problem! :-)

> the book (pexlib prog. manual) also has the error... (i think its an error,
> but if it's not, please correct me)..

Yeah, technically it probably is an error.

The book_utils are probably more robust than the same type of code in
first.c.  The first.c program was trying to get folks started without
a lot of other distractions.  It is also possible that the bug was
discovered and fixed by somebody who didn't realize that first.c did not
include book_utils, so they assumed that fixing book_utils would fix the
entire set, which was *almost* a correct assumption.

Note that the problem is not strictly related to PEX.  You can get in the
same hole with an Xlib application.