








                      XX WWiinnddooww SSyysstteemm,, VVeerrssiioonn 1111
                              RReelleeaassee 66..33

                             RReelleeaassee NNootteess







                           _X _C_o_n_s_o_r_t_i_u_m_, _I_n_c_.






                           December 23, 1996







Copyright (C) 1996 X Consortium

Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Soft-
ware"), to deal in the Software without restriction, including without
limitation the rights to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell copies of the Software, and to permit persons to
whom the Software is furnished to do so, subject to the following condi-
tions:

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABIL-
ITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABIL-
ITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.

Except as contained in this notice, the name of the X Consortium shall
not be used in advertising or otherwise to promote the sale, use or
other dealings in this Software without prior written authorization from
the X Consortium.

_X _W_i_n_d_o_w _S_y_s_t_e_m is a trademark of X Consortium, Inc.



11..  WWhhaatt IIss RReelleeaassee 66..33


This is the last X Consortium implementation of the X Window System.  X
is a vendor-neutral, system-architecture neutral network-transparent
window system and user interface standard.  X runs on a wide range of
computing and graphics machines.  For an overview of X, see the _X manual
page.

R6.3 is an update to R6.1.  It is compatible with R6 and R6.1 at the
source and protocol levels in all respects, and binaries are upward-com-
patible.

What about Release 6.2?  Release 6.2 is a proper subset of Release 6.3
produced at the request of the OSF Common Desktop Environment program.
It was produced by the X Consortium and is being released by OSF simul-
taneously with CDE 2.1.  Release 6.2 contains only the print extension
and the Xlib implementation of vertical writing and user-defined charac-
ter support.

The X Consortium was an independent, not-for-profit membership corpora-
tion formed in 1993 as the successor to the MIT X Consortium and dis-
solved at the end of 1996.  Refer to the _C_o_n_s_o_r_t_i_u_m man page for addi-
tional details about the X Consortium.

See xxcc//IINNSSTTAALLLL..PPSS (PostScript) or xxcc//IINNSSTTAALLLL..TTXXTT (plain text) for
instructions on how to build and install this software.


11..11..  OOvveerrvviieeww ooff tthhee XX CCoonnssoorrttiiuumm RReelleeaassee


The X Consortium software and documentation in Release 6.3 is in direc-
tory xxcc// and contains the following:

XX CCoonnssoorrttiiuumm SSttaannddaarrddss
     The X Consortium produced standards:  documents which define net-
     work protocols, programming interfaces, and other aspects of the X
     environment.  See the _X_S_t_a_n_d_a_r_d_s manual page for a list of stan-
     dards.

IImmpplleemmeennttaattiioonnss
     For most of our standards, we provide high-quality implementations
     to demonstrate proof of concept and to give early adopters and ven-
     dors a base to use.  These are not _r_e_f_e_r_e_n_c_e implementations; the
     written specifications define the standards.

FFoonnttss
     A collection of bitmap and outline fonts are included in the dis-
     tribution, contributed by various individuals and companies.

UUttiilliittyy LLiibbrraarriieess
     A number of libraries, such as _X_m_u and the _A_t_h_e_n_a _W_i_d_g_e_t _S_e_t, are
     included.  These are not standards, but are used in building X Con-
     sortium applications and may be useful in building other applica-
     tions.

PPrrooggrraammss
     We also provide a number of application programs.  A few of these
     programs, such as _x_d_m (or its equivalent), should be considered
     essential in almost all environments.  The rest of the applications
     carry no special status; they are simply programs that have been
     developed and/or maintained by X Consortium staff.  In some cases,
     you will find better substitutes for these programs contributed by
     others.


11..22..  SSuuppppoorrtteedd SSyysstteemmss


We built and tested this release on the following systems:


     AIX 4.2
     Digital Unix 4.0A
     HP-UX 10.01
     IRIX 6.2
     Solaris 2.5
     UNIX System V/386 Release 4.2 (Novell UnixWare) Version 2.02

We also built this release on the following and did some minimal test-
ing:

     FreeBSD 2.1.6
     Linux 1.2.13 (Yggdrasil) and 2.0.0 (Slackware 3.1)
     SCO Open Server 5.0
     SunOS 4.1.4
     Windows NT 4.0


In all cases except SunOS we have used the vendor's compiler.  On SunOS
we build with _g_c_c.


11..22..11..  SSuuppppoorrtteedd DDiissppllaayy DDeevviicceess


This release includes the necessary device-dependent support to build a
native X server for the following platforms:


     AIX: Xibm with Skyway display adapter
     HP-UX: Xhp
     Digital Unix: Xdec on Alpha AXP with PMAG-B frame buffer
     SunOS/Solaris: Xsun -- see the Xsun man page for supported frame buffers
     Ultrix1 :Xdec
     XFree86: See the XF_* man pages for supported video cards

In addition to the above, the Xvfb and Xnest servers can be built on
most platforms.

Native servers are not built on IRIX or Microsoft Windows NT.


11..33..  TThhee XXCC TTrreeee


The general layout under xxcc// is as follows:


config/             config files, _i_m_a_k_e, _m_a_k_e_d_e_p_e_n_d, build utilities
doc/                all documentation other than per-program manual pages
fonts/              BDF, Speedo, Type1 fonts
include/            include files shared by multiple directories
lib/                all libraries
nls/                national language support files
programs/           all programs, including the X server and _r_g_b
util/               _p_a_t_c_h, _c_o_m_p_r_e_s_s, other utilities
bug-report          bug reporting template
registry            X Registry


This file is xxcc//RREELLNNOOTTEESS..**, in various formats.  The documentation
source files RREELLNNOOTTEESS..mmss and IINNSSTTAALLLL..mmss are in the xxcc//ddoocc//mmiisscc// direc-
tory.


11..44..  XX RReeggiissttrryy


The X Consortium maintained a registry of certain X-related items to aid
in avoiding conflicts and to aid in sharing of such items.

The registry is in the file xxcc//rreeggiissttrryy in the distribution.  The latest
version may also be available by sending a message to xstuff@x.org.  The
message can have a subject line and no body, or a single-line body and
no subject; in either case the line should look like this:

     send docs registry



11..55..  EExxtteennssiioonnss SSuuppppoorrtteedd


The core distribution includes the following extensions: BIG-REQUESTS,
DOUBLE-BUFFER, LBX, MIT-SHM, MIT-SUNDRY-NONSTANDARD, Multi-Buffering,
RECORD, SECURITY, SHAPE, SYNC, X3D-PEX, XC-APPGROUP, XC-MISC,
XFree86-VidModeExtension, XIE, XInputExtension, XKEYBOARD, XpExtension
(printing), XTEST, and XTestExtension1.

Not all of these extensions are standards; see the _X_S_t_a_n_d_a_r_d_s manual
page.  Some of these extensions are not supported on all platforms.


11..66..  IImmpplleemmeennttaattiioonn PPaarraammeetteerrss


Some of the specifications define some behavior as implementation-depen-
dent.  Implementations of X Consortium standards need to document how
those parameters are implemented; this section does so.

XFILESEARCHPATH default
     This default can be set at build time by setting the _i_m_a_k_e vari-
     ables XFileSearchPathDefault, XAppLoadDir, XFileSearchPathBase, and
     ProjectRoot in ssiittee..ddeeff.  See xxcc//ccoonnffiigg//ccff//RREEAADDMMEE for instructions
     and xxcc//ccoonnffiigg//ccff//XX1111..ttmmppll2 for details of how these configuration
     variables are used.

     By default ProjectRoot is /usr/X11R6.3 and XFILESEARCHPATH has
     these components:

          /usr/X11R6.3/lib/X11/%L/%T/%N%C%S
          /usr/X11R6.3/lib/X11/%l/%T/%N%C%S
          /usr/X11R6.3/lib/X11/%T/%N%C%S
          /usr/X11R6.3/lib/X11/%L/%T/%N%S
          /usr/X11R6.3/lib/X11/%l/%T/%N%S
          /usr/X11R6.3/lib/X11/%T/%N%S


XUSERFILESEARCHPATH default
     If the environment variable XAPPLRESDIR is defined, the default
     value of XUSERFILESEARCHPATH has the following components:

          $XAPPLRESDIR/%L/%N%C
          $XAPPLRESDIR/%l/%N%C
          $XAPPLRESDIR/%N%C
          $HOME/%N%C
          $XAPPLRESDIR/%L/%N
          $XAPPLRESDIR/%l/%N
          $XAPPLRESDIR/%N
          $HOME/%N

     Otherwise it has these components:

          $HOME/%L/%N%C
          $HOME/%l/%N%C
          $HOME/%N%C
          $HOME/%L/%N
          $HOME/%l/%N
          $HOME/%N


XKEYSYMDB default
     Defaults to //uussrr//XX1111RR66..33//lliibb//XX1111//XXKKeeyyssyymmDDBB, assuming PPrroojjeeccttRRoooott is
     set to //uussrr//XX1111RR66..33.

XCMSDB default
     Defaults to //uussrr//XX1111RR66..33//lliibb//XX1111//XXccmmss..ttxxtt, assuming PPrroojjeeccttRRoooott is
     set to //uussrr//XX1111RR66..33.

XLOCALEDIR default
     Defaults to the directory //uussrr//XX1111RR66..33//lliibb//XX1111//llooccaallee, assuming
     PPrroojjeeccttRRoooott is set to //uussrr//XX1111RR66..33.  The XLOCALEDIR variable can
     contain multiple colon-separated pathnames.

XErrorDB location
     The Xlib error database file is //uussrr//XX1111RR66..33//lliibb//XX1111//XXEErrrroorrDDBB,
     assuming PPrroojjeeccttRRoooott is set to //uussrr//XX1111RR66..33.

XtErrorDB location
     The Xt error database file is //uussrr//XX1111RR66..33//lliibb//XX1111//XXttEErrrroorrDDBB,
     assuming PPrroojjeeccttRRoooott is set to //uussrr//XX1111RR66..33.

Supported Locales
     X locales supported are in llooccaallee..ddiirr; the mapping between various
     system locale names and X locale names is in llooccaallee..aalliiaass.  Both
     files are shipped in the xxcc//nnllss//XX1111//llooccaallee// directory and installed
     in the XLocaleDir directory (e.g. //uussrr//XX1111RR66..33//lliibb//XX1111//llooccaallee//).

Input Methods supported
     The core distribution does not include any input method servers.
     However, Xlib supplies a default built-in input method that sup-
     ports compose processing in 8-bit locales.  Compose files are pro-
     vided for Latin-1 and Latin-2.  The built-in input method can sup-
     port other locales, given suitable compose files.  See
     xxcc//nnllss//XX1111//llooccaallee//CCoommppoossee//iissoo88885599--** for the supported compositions.

There are input method servers available on the net.



22..  WWhhaatt iiss UUnncchhaannggeedd iinn RReelleeaassee 66..33


As this is an update release, there is a great deal of stability in the
standards, libraries, and clients.  No existing standards other than the
ICE library specification have changed in a material way, though several
documents have been updated with editorial improvements.  There is one
new interface added to the ICE library _l_i_b_I_C_E; see below.  The extension
library, _l_i_b_X_e_x_t, is updated to include the LBX, security, and applica-
tion group extension interfaces.  All previous interfaces in these and
all other libraries are unchanged.



33..  WWhhaatt IIss NNeeww iinn RReelleeaassee 66..33


This section describes changes in the X Consortium distribution since
Release 6.1.

All libraries, protocols, and servers are compatible with Release 6 and
Release 6.1.  That is, R6 and R6.1 clients and applications will work
with R6.3 libraries and servers.  Most R6.3 clients will work with R6.1
and R6 libraries except those that use the new interfaces in libICE,
libXext, and libXp.

The major new functionality in R6.3 is support for World Wide Web inte-
gration, protection of data from ``untrusted'' client connections, a
bandwidth- and latency-optimized protocol for using X across the Inter-
net, a print protocol following the Xlib API, and support for vertical
text writing and user-defined characters in the Xlib implementation.


33..11..  OOSS SSuuppppoorrtt


The following platforms have a newer operating system version supported:


System         R6.1           R6.3

AIX            4.1.4          4.2
Digital Unix   3.2C           4.0A
HP-UX          10.01
IRIX           5.3            6.2
Solaris        2.4            2.5
UnixWare       2.02


We also built on the following platforms, however full support is not
guaranteed:


System         R6.1           R6.3

FreeBSD        2.1.0          2.1.6
Linux          1.2.13         2.0
SCO Open Server               5.0
SunOS          4.1.3          4.1.4
Windows NT     3.5            4.0



33..22..  NNeeww SSttaannddaarrddss


The following are new X Consortium standards in Release 6.3.  Each is
described in its own section below.

     Low Bandwidth X Extension
     RX: X Remote Execution MIME type
     Security Extension
     Application Group Extension
     Print Extension
     Proxy Management Protocol



33..33..  LLooww BBaannddwwiiddtthh XX EExxtteennssiioonn


The Low Bandwidth X extension (LBX) defines several compression and
local caching techniques to improve performance on wide area networks
and also on slower-speed connections.  These reduce the amount of proto-
col data transported over the network and reduce the number of client-
to-server roundtrips required for common application startup operations.

LBX was referred to as X.fast in some materials but we elected to not go
through the implementation and change all the names.  To avoid any con-
fusion with an external name different from the internal name in the
implementation, we elected to drop the ``X.fast'' moniker.

LBX is implemented in two pieces; an X server extension and a proxy
application.  The X server extension provides the new optimized proto-
col.  The proxy application, _l_b_x_p_r_o_x_y, translates a normal client X pro-
tocol stream into an LBX stream.  This permits any existing application
to gain the benefit of the optimized protocol with no changes.  The
proxy is especially useful when multiple applications are running on the
same local area network separated from the X server by a slower network.
In this case the full benefit of the local cache is shared by each
application using the same proxy process.

The specification for LBX is in xxcc//ddoocc//ssppeeccss//XXeexxtt//llbbxx..mmiiff (FrameMaker
interchange source) and xxcc//ddoocc//hhaarrddccooppyy//XXeexxtt//llbbxx..PPSS..ZZ (compressed
PostScript).


33..44..  RRXX:: XX RReemmoottee eeXXeeccuuttiioonn


The remote execution (RX) service specifies a MIME format for invoking
applications remotely, for example via a World Wide Web browser.  This
RX format specifies a syntax for listing network services required by
the application, for example an X display server.  The requesting Web
browser must identify specific instances of the services in the request
to invoke the application.

The distribution contains a helper program (_x_r_x) and a Netscape Naviga-
tor plug-in (_l_i_b_x_r_x) that demonstrate this protocol.  The plug-in
requires Navigator 3.0.

We have only been able to test the plug-in on HP-UX, IRIX, Digital Unix,
and Solaris2.  Netscape Navigator binaries for other platforms are
either not available at all or were not available in time to be included
in the testing for this release.

The specification for the RX mime type is in xxcc//ddoocc//ssppeeccss//RRXX//RRXX..mmiiff
(FrameMaker interchange source) and xxcc//ddoocc//hhaarrddccooppyy//RRXX//RRXX..PPSS..ZZ (com-
pressed PostScript).

The following section describes the procedure to set up your environment
and try the examples provided in this distribution.


33..44..11..  PPrreeppaarriinngg YYoouurr WWeebb SSeerrvveerr


In order to demonstrate the RX helper program and the RX Netscape plug-
in you need to have access to an HTTP server to install ``common gateway
interface'' (CGI) scripts.  While CGI programs can be written in any
compiled or interpreted language, the sample CGI programs in the distri-
bution are written in perl.

If you don't currently have a web server the NCSA server is a good one
to try.  Binaries for various systems are available at:
     http://hoohoo.ncsa.uiuc.edu/docs/setup/PreExec.html

If you don't have perl you can get the source code from:
     ftp://prep.ai.mit.edu/pub/gnu/perl-4.036.tar.gz

You need to install the HTML, RX, and CGI sample files into your
server's HTML and CGI directories.  The process can be partially auto-
mated by adding the following definitions to your ssiittee..ddeeff or hhoosstt..ddeeff
file:


WebServer      defines the hostname and port of your web server, for
               example
               #define WebServer www.myorg.org:8001

HtmlDir        defines the path at which HTML and RX documents are
               installed, for example
               #define HtmlDir /usr/local/etc/httpd/htdocs

CgiBinDir      defines the path at which CGI programs are installed, for
               example
               #define CgiBinDir /usr/local/etc/httpd/cgi-bin

ProxyManager   defines the transport scheme, hostname, and port for CGI
               programs to contact the Proxy Manager.  See the _p_r_o_x_y_m_n_g_r
               man pages for further details.  Typically the proxy man-
               ager host will be the same as your web server, for exam-
               ple:
               #define ProxyManager tcp/www.myorg.org:6500

Then make the Makefiles and build the directories with the following
command sequence:

     cd xc/programs/xrx/htdocs
     xmkmf ../../.. programs/xrx/htdocs
     make
     make install
     cd ../cgi-bin
     xmkmf ../../.. programs/xrx/cgi-bin
     make
     make install


These directories are not automatically built or installed by the top
level Makefile because they install outside the ProjectRoot.

You also need to configure your web server so that files with the exten-
sion name ``rx'' are of the MIME type ``application/x-rx''.  See your
HTTP server's configuration documentation for the right procedure to do
so.


33..44..22..  TThhee RRXX HHeellppeerr PPrrooggrraamm


The helper program, _x_r_x, may be used with any Web browser to interpret
the new RX document type.

The RX helper program is installed in <ProjectRoot>/bin (e.g.
/usr/X11R6.3/bin/).  You will need to configure your web browser to use
it for RX documents by adding a line to your $HOME/.mailcap:
     application/x-rx; /X11/bin/xrx %s

You may need to refer to your web browser's documentation for exact
instructions on configuring helper applications.

The helper program is activated by your browser as soon as you retrieve
any document of the MIME type application/x-rx. All you need to do is to
point your browser at the URL:
     http://your.web.server/xload.rx

The application (i.e. _x_l_o_a_d) should appear on your DISPLAY as a new top-
level client.  The client will be running on your web server host and
connected to your X server.  If your X server supports the SECURITY
extension the client will be running as an untrusted client.


33..44..33..  TThhee RRXX NNeettssccaappee NNaavviiggaattoorr PPlluugg--iinn


The Navigator plug-in supports all the functions of _x_r_x and in addition
uses the new XC-APPGROUP extension, if your X server provides it, to
cause the remotely launched application to be embedded within the
browser page from which it was launched.

The HTML page links to an RX document via the EMBED tag, a Netscape
extension to HTML.  The RX document provides the plug-in with the list
of services the application wants to use.  Based on this information,
the plug-in sets the various requested services, including creating
authorization keys, and passes the relevant data to the application
through an HTTP GET request of the associated CGI script.  The Web
server then executes the CGI script to start the application.

To be able to use the RX plug-in you need Netscape Navigator 3.0.  Bina-
ries for various systems can be found at:
     http://home.netscape.com/comprod/mirror/client_download.html

To complete the installation of the Netscape plug-in, find the file
named _l_i_b_x_r_x_._s_o_._6_._3 or _l_i_b_x_r_x_._s_l_._6_._3 (or similar, depending on your
platform) in <ProjectRoot>/lib (e.g. //uussrr//XX1111RR66..33//lliibb) and copy it to
either /usr/local/lib/netscape/plugins or $HOME/.netscape/plugins. Do
not install the symlinks _l_i_b_x_r_x_._s_o or _l_i_b_x_r_x_._s_l; they may confuse
Netscape.

You should remove or comment out the line you may have previously added
in your mailcap file to use the RX helper program, otherwise the plug-in
will not be enabled.  (The usual comment character for mailcap is
``#''.)

If you are already running Netscape Navigator, you need to exit and
restart it after copying the plug-in library so the new plug-in will be
found.  Once this is done you can check that Navigator has successfully
loaded the plug-in by checking the ``About Plug-ins'' page from the Help
menu. This should show something like:


                                        RX Plug-in

         File name: /usr/guest/netscape/plugins/libxrx.sl.6.3

         X Remote Activation Plug-in

         Mime Type Description          Suffixes  Enabled
         application/x-rx               X Remote Activation Plug-inxrxYes


The plug-in will be activated by Netscape Navigator as soon as you
retrieve any document of the MIME type application/x-rx.  Several sam-
ples are included in the distribution. The most basic one is xload. All
you need to do is point your browser at the page:
     http://your.web.server/xload.html

If something goes wrong check on the all the previous steps listed above
and try again.  Once xload is working you can try some of the other
examples in the distribution such as bitmap.html or dtcm.html.


33..44..44..  TTrryyiinngg EEmmbbeeddddiinngg WWiitthh aann OOlldd XX SSeerrvveerr


The Netscape Navigator plug-in, _l_i_b_x_r_x, will work with an X server that
does not contain the application group or security extensions.  The
application will be started as a separate top-level client.

If you wish to try out the embedding facilities without replacing your
desktop X server, you may use the _X_n_e_s_t server.

A typical _X_n_e_s_t session would look like the following:

     % Xnest :11
     % xterm -display :11


These two commands start a ``nested'' server and a terminal emulator
within that server.  Your favorite window manager and Netscape Navigator
can now be executed from the nested xterm window.  You may wish to first
disable access control in the nested server by running ``xhost +'' in
the nested xterm.


33..44..55..  SSeettttiinngg UUpp YYoouurr OOwwnn AApppplliiccaattiioonnss TToo RRuunn OOvveerr TThhee WWeebb


Based on the examples provided in the distribution it should be easy to
set up your web server to run your own applications.  Every application
requires 3 additional files to identify it to Web browsers:

     myapp.htmlAn HTML page to present the application embedded
     myapp.rx  The RX document describing the application
     myapp.pl  The CGI script to start the application

Note that the separate ``.rx'' file could be omitted by implementing the
CGI script such that if it is invoked without a QUERY_STRING it will
return the RX content.  We decided not to do so in the distributed exam-
ples for purpose of clarity.

The xload demo provides a good starting point. Simply make a copy of
each of the files xload.rx, xload.html, and xload.pl. Then look inside
them for every instance of ``xload'' and change it to whatever is appro-
priate for your application.

You will not be able to run the dtcm demo unless you have _d_t_c_m (a CDE
component) installed on your web server host.  This example shows how a
CGI script would look when an X Print server is requested. The script
_d_t_c_m_._p_l is, for that reason, slightly more complicated than other exam-
ples.


33..55..  SSeeccuurriittyy EExxtteennssiioonn


The SECURITY extension contains new protocol needed to provide enhanced
X server security.  This extension adds to the X protocol the concepts
of ``trusted'' and ``untrusted'' clients.  The trust status of a client
is determined by the authorization used at connection setup.  All
clients using host-based authorization are considered ``trusted''.
Clients using other authorization protocols may be either trusted or
untrusted depending on the data included in the connection authorization
phase.

The requests in the security extension permit a trusted client to create
multiple authorization entries for a single authorization protocol.
Each entry is tagged with the trust status to be associated with any
client presenting that authorization.

When a connection identifying an ``untrusted'' client is accepted, the
client is restricted from performing certain operations that would steal
or modify data that is held by the server for trusted clients.  An
untrusted client performing a disallowed operation will receive protocol
errors.  Such a client may be written to catch these errors and continue
operation.

When a client is untrusted, the server will also limit the extensions
that are available to the client.  Each X protocol extension is respon-
sible for defining what operations are permitted to untrusted clients;
by default, the entire extension is hidden.

The specification for the SECURITY extension is in
xxcc//ddoocc//ssppeeccss//XXeexxtt//sseeccuurriittyy..tteexx (LaTeX source) and xxcc//ddoocc//hhaarrdd--
ccooppyy//XXeexxtt//sseeccuurriittyy..PPSS..ZZ (compressed PostScript).


33..55..11..  UUnnttrruusstteedd AApppplliiccaattiioonn BBeehhaavviioorr


Most applications work normally when run as untrusted clients, but since
the security extension changes the semantics of certain parts of the X
protocol, it is no surprise that some clients behave differently when
untrusted.  We note the following significant behavior changes, sepa-
rated into two categories: changes that we expect could disappear or
mutate if the implementation were improved in a future release, and
changes we expect are permanent, legitimate defenses against data loss
or leakage.


33..55..11..11..  BBeehhaavviioorrss TThhaatt AArree IImmpplleemmeennttaattiioonn--DDeeppeennddeenntt


The following behaviors when running the respective applications as
untrusted are not mandated by the security design but are side effects
of limitations in the current implementation.

_o_c_l_o_c_k is square because the SHAPE extension hasn't been marked secure
yet.  Similarly, Xaw applications that use oval buttons will have rect-
angular buttons instead.

Any application that depends on an extension other than XC-MISC, LBX, or
BIG-REQUESTS will have different behavior, as no other extensions are
currently marked secure.  The core clients affected are _x_i_e_p_e_r_f and all
the xkb utilities.

_e_m_a_c_s exits with a Window error when trying to use the QueryPointer
request on the root window when you click in a buffer.

_F_r_a_m_e_M_a_k_e_r, and _x_w_d _-_r_o_o_t both exit with a Window error when trying to
use the GetWindowAttributes request on a window manager frame window.

All the remaining changes are involved in some way with window proper-
ties.  Some of these behaviors can be modified with changes to the Secu-
rityPolicy file; see the _X_s_e_r_v_e_r man page.

Several clients exit with a Window error when trying to use the
DeleteProperty request on various properties on the root window.  These
include _x_c_m_s_d_b _-_r_e_m_o_v_e, _x_p_r_o_p _-_r_o_o_t _-_r_e_m_o_v_e, and _x_s_t_d_c_m_a_p _-_d_e_l_e_t_e.

_x_p_r_o_p exits with an Atom error when attempting to access protected prop-
erties.

The following two changes require, in addition, a ``trusted selection
intermediary'' to provide selection transfer from untrusted to trusted
clients (and vice-versa).  R6.3 does not include such a trusted interme-
diary.

_x_t_e_r_m exits with an Atom error when it tries to store the property value
during a selection transfer (paste) to a trusted selection requester.

The ``copy 0 to PRIMARY'' button of _x_c_u_t_s_e_l does not work.

Selection transfer from untrusted clients to trusted clients fails when
the untrusted client attempts to use SendEvent to generate the Selec-
tionNotify event for the requester.  Most requesters will treat this as
a transfer timeout and continue.  Xt-based applications will create an
additional Atom each time such a transfer is attempted.


33..55..11..22..  BBeehhaavviioorrss TThhaatt AArree NNoott LLiikkeellyy TToo CChhaannggee


The following behaviors represent actions performed by the applications
that are disallowed by design.

_e_d_i_t_r_e_s will fail when pointed at a trusted client when it tries to read
window properties on a window owned by that client.

_X_n_e_s_t exits on startup with an Access error as it tries to use the
ChangeKeyboardControl request.

The new _g_e_n_e_r_a_t_e option to _x_a_u_t_h fails because untrusted applications
are not allowed to create additional authorizations.

_x_h_o_s_t cannot be used to modify the host access list.

_x_m_a_g gets an unending stream of Drawable errors as it tries to use the
PolyRectangle request on the root window.  If you click to select a
location to magnify, xmag gets a Drawable error as it tries to use the
GetImage request on the root window.  _x_m_a_g could be modified to exit
gracefully under these conditions.

_n_e_t_s_c_a_p_e exits on startup with a Drawable error when trying to use the
GetImage request on the root window.

_x_m_o_d_m_a_p exits with an Access error when trying to use the ChangeKey-
boardMapping request.

_x_s_e_t with the _b, _c, _l_e_d, or _r options exits with an Access error when
trying to use the ChangeKeyboardControl request.  With the _b_c option, it
can't find the MIT-SUNDRY-NONSTANDARD extension and exits gracefully.

_x_s_e_t_r_o_o_t exits with a Window error when trying to use the ChangeWin-
dowAttributes request on the root window.


33..66..  AApppplliiccaattiioonn GGrroouupp EExxtteennssiioonn


The application group extension (XC-APPGROUP) provides new protocol to
implement Application Groups (``AppGroups'').  The AppGroup facility
allows other clients to share the SubstructureRedirect mechanism with
the window manager.  This allows another client called the ``application
group leader'', such as a web browser, to intercept a MapRequest made by
a third application and reparent its window into the web browser before
the window manager takes control.  The AppGroup leader may also limit
the screens and visuals available to the applications in the group.

Users who have an XC-APPGROUP enhanced X server and an RX plug-in for
their Netscape Navigator web browser can run programs remotely over the
web and have the output appear as part of the presentation in their web
browser.

The only way for an application to become a member of an AppGroup is by
using an authorization generated using the new security extension.
Whenever an application connects to the server, the authorization that
it used to connect is tested to see if it belongs to an AppGroup. This
means that the Authorization data must be transmitted to the remote host
where the application will be run. In the case of RX, HTTP is used to
send the Authorization.  Sites who have concerns about sending unen-
crypted authorization data such as MIT-MAGIC-COOKIE-1 via HTTP should
configure their web servers and web browsers to use SHTTP or SSL.

The specification for the XC-APPGROUP extension is in
xxcc//ddoocc//ssppeeccss//XXeexxtt//AAppppGGrroouupp..mmiiff (FrameMaker interchange source) and
xxcc//ddoocc//hhaarrddccooppyy//XXeexxtt//AAppppGGrroouupp..PPSS..ZZ (compressed PostScript).


33..77..  PPrriinntt EExxtteennssiioonn


The print extension supports output to hardcopy devices using the core X
drawing requests.  The print extension adds requests for job and page
control and defines how specific printer attributes are communicated
between the server and printing clients.  Printer attribute specifica-
tions are modeled after the ISO 10175 specification.

An X client that wants to produce hardcopy output will typically open a
second connection to an X print server, produce a print job, and then
close the print server connection.  The print server may be the same
process as the display server (the term ``video server'' is sometimes
used) although the implementation provided in R6.3 does not completely
support video and print servers in the same binary.

The specification for the print extension is in
xxcc//ddoocc//ssppeeccss//XXPPRRIINNTT//xxpp__pprroottoo..mmiiff (FrameMaker interchange source) and
xxcc//ddoocc//hhaarrddccooppyy//XXPPRRIINNTT//xxpp__pprroottoo..PPSS..ZZ (compressed PostScript).  The
library API specification is in xxcc//ddoocc//ssppeeccss//XXPPRRIINNTT//xxpp__lliibbrraarryy..mmiiff
(FrameMaker interchange source) and xxcc//ddoocc//hhaarrdd--
ccooppyy//XXPPRRIINNTT//xxpp__lliibbrraarryy..PPSS..ZZ (compressed PostScript).


33..77..11..  RRuunnnniinngg aann XX PPrriinntt SSeerrvveerr


The print server is simply an X server with the print extension and spe-
cial DDX implementations.  The X Print Server is started like any other
X server.

Here is a sample command line for use with a typical configuration:

     % Xprt :1 -ac


The options used in the example are:

:1        On a host that is running a video display server you will need
          to specify a different display from the default.

-ac       Disable access control, since no simple mechanism for sharing
          keys is provided.

The X print server supports the following additional options:

-XpFile   Points to the directory containing the print server configura-
          tion files.

XPCONFIGDIR
          Environment variable specifying alternative location of the
          print server configuration files.

The print server, _X_p_r_t, is built only if the config option XprtServer is
YES.  Four printer DDXen are provided, each with a separate config
option to control whether or not it will be included: XpRasterDDX,
XpColorPclDDX, XpMonoPclDDX, XpPostScriptDDX; see xxcc//ccoonnffiigg//ccff//RREEAADDMMEE.
XprtServer defaults to the value of BuildServer (i.e. _X_p_r_t will be built
by default on all platforms that build a full X server).  XpRasterDDX
and XpMonoPclDDX default to NO.  XpColorPclDDX and XpPostScriptDDX
default to YES.

The print server is configured through a directory of configuration
files that define printer model types and instances of printer models.
An example configuration tree is provided in xxcc//pprrooggrraammss//XXsseerrvveerr//XXppCCoonn--
ffiigg//.  See also xxcc//ddoocc//ssppeeccss//XXsseerrvveerr//XXpprrtt..mmiiff (FrameMaker interchange
source) and xxcc//ddoocc//hhaarrddccooppyy//XXsseerrvveerr//XXpprrtt..PPSS..ZZ (compressed PostScript)
for further instructions on configuring _X_p_r_t.


33..77..22..  SSppeecciiffyyiinngg TThhee PPrriinntt SSeerrvveerr TToo AA CClliieenntt


By convention, clients locate the print server using the environment
variable XPRINTER.  The syntax of XPRINTER is an augmented DISPLAY; i.e.
     printerName@host:display

where ``printerName'' is one of the printer instances listed in the
print server configuration files.  The use of XPRINTER and its syntax is
an application convention only; there is nothing in the supplied
libraries that uses (or parses) this environment variable.


33..88..  PPrrooxxyy MMaannaaggeemmeenntt PPrroottooccooll


The Proxy Management Protocol is an ICE based protocol that provides a
way for application servers to easily locate proxy services such as the
LBX proxy and the X firewall proxy.

Typically, a service called a ``proxy manager'' is responsible for
resolving requests for proxy services, starting new proxies when appro-
priate, and keeping track of all of the available proxy services.  The
proxy manager strives to reuse existing proxy processes whenever possi-
ble.

The Proxy Management Protocol is described in xxcc//ddoocc//ssppeeccss//PPMM//PPMM__ssppeecc.


33..99..  CCoonnffiigguurraattiioonn


As in R6.1, the top-level Makefile is no longer over-ridden by the first
build.  Instead a new file _x_m_a_k_e_f_i_l_e is created.  Thus is it not neces-
sary to take any additional steps to reset the builds.

The file xxcc//ccoonnffiigg//ccff//RREEAADDMMEE provides more guidance on how to write an
Imakefile, including a list of variables that may be set in an Imake-
file.  This file is strongly recommended reading for Imakefile authors.

The LaTeX text processor is supported as of R6.1.  If you have LaTeX on
your system, turn on HasLatex to have the MakeLatexDoc rule use it.

Also since R6.1, with System V Release 4 (SVR4) compilers we now use the
-Xa (ANSI C with native extensions) compiler flag rather than -Xc (limit
environment to that specified in the standard).  This provides access to
the full richness of the platform.  Unfortunately, it also defines the
preprocessor symbol __STDC__ to 0, instead of 1 as specified by the
standard.  Therefore we use "#ifdef __STDC__" in our sources rather than
"#if __STDC__".  On HP-UX systems we use the -Ae compiler option instead
of -Aa, also to access the full environment offered by the platform.

As in R6.1, the imake variables IInnssttaallllXXddmmCCoonnffiigg, IInnssttaallllXXiinniittCCoonnffiigg,
and IInnssttaallllAAppppDDeeffFFiilleess suppress overwriting existing files; if the files
didn't previously exist, the files are always installed.  This interpre-
tation makes bootstrapping a new system easier than in R6 and earlier
releases.

A new configuration build option, GzipFontCompression, has been added to
use _g_z_i_p rather than _c_o_m_p_r_e_s_s for font compression.  It defaults to NO.

The build creates a new directory xxcc//eexxppoorrttss into which the header
files, libraries, and certain build utility binaries are symlinked.
This greatly simplifies Imakefile construction and supports multiple
development projects (such as X, Motif, and CDE) on a single system.

Imake rules and template files for building Motif and CDE were con-
tributed by the OSF CDE/Motif project and are included in R6.3.


33..1100..  DDooccuummeennttaattiioonn


Additional X server internals documentation is provided in the
//xxcc//ddoocc//ssppeeccss//XXsseerrvveerr// directory for the XC-APPGROUP and SECURITY exten-
sions.  An analysis and rationale for the SECURITY extension will also
be found in that directory.  Specifications for the other new standards
are in //xxcc//ddoocc//ssppeeccss//RRXX//, //xxcc//ddoocc//ssppeeccss//XXPPRRIINNTT//, and
//xxcc//ddoocc//ssppeeccss//XXeexxtt//.


33..1111..  HHeeaaddeerr FFiilleess


xxcc//iinncclluuddee//XXooss__rr..hh is a new header file to promote portable source code
using thread-safe implementations of getpwnam, getpwuid, gethostbyname,
gethostbyaddr, and getservbyname.  It is not required by any X Consor-
tium standard.


33..1122..  XX SSeerrvveerr


The security, LBX, printing, and AppGroup extensions are all new.  In
R6.3 only MIT-MAGIC-COOKIE-1 is supported in the security extension.
Parts of the security policy are configured at run-time from the file
//uussrr//XX1111RR66..33//lliibb//XX1111//xxsseerrvveerr//SSeeccuurriittyyPPoolliiccyy.  Site-defined policy
strings used by _x_f_w_p and rules for property access by untrusted clients
are defined there.  See the _X_s_e_r_v_e_r man page for full details.


33..1122..11..  NNeeww DDeevviiccee SSuuppppoorrtt


Support has been added for the Sun TCX frame buffer as a dumb 8-bit
frame buffer on Solaris 2.5.

New XFree86 servers based on XFree86 3.2 are included.


33..1122..22..  IInntteerrnnaall CChhaannggeess


The security extension provides new internal resource ID lookup inter-
faces that incorporate the access control lookup.  In order to be
declared secure and therefore be made available to untrusted clients,
other extensions should, at a minimum, be changed to use these inter-
faces.  Depending on what the extension does, more may need to be done
in its implementation before it can appropriately be labeled ``secure''.

Refer to the documents xxcc//ddoocc//ssppeeccss//XXsseerrvveerr//aappppggrroouupp..mmss and
xxcc//ddoocc//ssppeeccss//XXsseerrvveerr//sseecciinntt..tteexx for implementation details of the appli-
cation group and security extensions, respectively.


33..1133..  IICCEE LLiibbrraarryy AAddddiittiioonn


To support proxy managers and firewall proxies using ICE on well-known
TCP ports, an additional interface has been added to the ICE library.
This new interface, IceListenForWellKnownConnections, has equivalent
calling parameters to IceListenForConnections plus an ICE network id
parameter.


33..1144..  XXlliibb VVeerrttiiccaall WWrriittiinngg aanndd UUsseerr--DDeeffiinneedd CChhaarraacctteerrss


The Xlib output method implementation has been enhanced to support the
XOM value drawing direction XOMOrientation_TTB_RTL.  Vertical writing
information and other locale specific information is read from the file
<XLocaleDir>/%L/XLC_LOCALE where the XLocaleDir configuration option
defaults to //uussrr//XX1111RR66..33//lliibb//XX1111//llooccaallee.

The X[mb|wc]TextEscapement functions now return the text escapement in
pixels for the vertical or horizontal direction depending on the XNOri-
entation XOCValue.

The X[mb|wc]DrawString functions will now render a character string in
the vertical or horizontal direction depending on the XNOrientation XOC-
Value.

The Xlib NLS database implementation has been enhanced to support
extended segments used for interchanging non-standard code sets.  Sup-
port has been added for control sequences and encoding names used in
extended segments and conversion of glyph indexes when interchanging
data in extended segments.


33..1155..  XXtt GGeeoommeettrryy MMaannaaggeemmeenntt DDeebbuuggggeerr


Daniel Dardailler's ``GeoTattler'' code has been merged into the Xt
Intrinsics library implementation.  This is not a standard.  If libXt is
compiled with the XT_GEO_TATTLER symbol defined (currently there is no
build configuration support to do this) then a ``geoTattler'' resource
may be specified for any widget in an application.  If the geoTattler
resource for a widget instance is True then libXt will generate debug-
ging information to stdout when the widget makes geometry change
requests.

For example, if the resources specify:

     myapp*draw.XmScale.geoTattler: ON
     *XmScrollBar.geoTattler:ON
     *XmRowColumn.exit_button.geoTattler:ON

then geometry management debugging information will be generated for all
the XmScale children of the widget named draw, all the XmScrollBars, and
the widget named exit_button in any XmRowColumn.

33..1166..  NNeeww PPrrooggrraammss


There are new core programs _l_b_x_p_r_o_x_y, _p_r_o_x_y_m_n_g_r, _x_f_i_n_d_p_r_o_x_y, _x_f_w_p, _X_p_r_t,
and _x_r_x.


lbxproxy    The _l_b_x_p_r_o_x_y program is used to ``translate'' X protocol to
            LBX protocol.  It should be executed on the same host as the
            client application or on a host connected to the client host
            by a fast network.  _l_b_x_p_r_o_x_y appears to the clients using it
            as another X server; that is, the clients connect through it
            using the conventional DISPLAY syntax, specifying the proxy
            host in place of the server.  _l_b_x_p_r_o_x_y can be used stand-
            alone or in conjunction with _p_r_o_x_y_m_n_g_r and _x_f_i_n_d_p_r_o_x_y.  See
            the _l_b_x_p_r_o_x_y man page for further details.

proxymngr   _p_r_o_x_y_m_n_g_r is a process that runs continuously to control
            other proxy applications, such as _l_b_x_p_r_o_x_y and _x_f_w_p.  It
            maintains a list of active proxy processes and responds to
            queries from _x_f_i_n_d_p_r_o_x_y.  See the _p_r_o_x_y_m_n_g_r man pages for
            further details.

xfindproxy  _x_f_i_n_d_p_r_o_x_y is used to locate a running proxy process for a
            given network service, such as _l_b_x_p_r_o_x_y or _x_f_w_p, or to
            request that a proxy be started if one is not already run-
            ning.  _x_f_i_n_d_p_r_o_x_y communicates with _p_r_o_x_y_m_n_g_r to perform the
            actual work.

xfwp        _x_f_w_p is the X firewall application proxy.  It is designed to
            run on a network firewall host and relay X protocol between
            applications (typically outside the firewall) and the X
            server (inside the firewall).  _x_f_w_p appears to the clients
            using it as another X server; that is, clients connect
            through it using the conventional DISPLAY syntax.  _x_f_w_p will
            not do anything useful without _p_r_o_x_y_m_n_g_r and _x_f_i_n_d_p_r_o_x_y or
            _x_r_x.  See the _x_f_w_p man page for further details.

Xprt        _X_p_r_t is the print server, built as part of the Xserver build
            if the XXpprrttSSeerrvveerr config option is YES.  The print server
            supports printing to PostScript and PCL devices, as well as
            raster output to an _x_w_d format file (and thence to any
            printer that _x_p_r supports).  The print extension was
            designed to be integrated with the ``video'' server in a
            single process but the R6.3 implementation does not support
            a combined video and print server.  Details of configuration
            for _X_p_r_t are in xxcc//ddoocc//ssppeeccss//XXsseerrvveerr//XXpprrtt..mmiiff (FrameMaker
            interchange source) and xxcc//ddoocc//hhaarrddccooppyy//XXsseerrvveerr//XXpprrtt..PPSS..ZZ
            (compressed PostScript).

xrx, libxrx _x_r_x is the Web browser helper application that interprets
            documents in the RX MIME type to remotely launch applica-
            tions via the Web.  Its companion _l_i_b_x_r_x is a plug-in for
            Netscape Navigator 3.0 that supports in addition the capa-
            bility to visually embed the remote applications in the
            associated browser Web page window.  See the _x_r_x man page
            for further details.


33..1166..11..  UUssiinngg TThhee LLBBXX PPrrooxxyy


The implementation of _l_b_x_p_r_o_x_y provided here will support an arbitrary
number of clients connecting to the same X server.  A separate _l_b_x_p_r_o_x_y
process is required for each separate X server process.  A typical com-
mand line to invoke _l_b_x_p_r_o_x_y is

     lbxproxy :22 -display myhost:0


This command runs a proxy with the X server ``myhost:0'' as the target.
Clients must connect to the proxy using ``proxyhost:22'' as the DISPLAY.
The .Xauthority file for these clients must contain an entry for server
``proxyhost:22'' with the same MIT-MAGIC-COOKIE as ``myhost:0'', or the
X server must be configured to permit connections from any host on the
network.

Here is an example showing how to setup the appropriate .Xauthority
entries:

     % lbxproxy :22 -display myws:0
     % xauth list
     myws:0  MIT-MAGIC-COOKIE-1  7fd231ccdce2
     myws/unix:0  MIT-MAGIC-COOKIE-1  7fd231ccdce2
     % xauth -f $HOME/proxyauth add proxyhost:22 .  7fd231ccdce2
     xauth:  creating new authority file /usr/myself/proxyauth
     % xauth -f $HOME/proxyauth  add proxyhost/unix:22 .  7fd231ccdce2
     % setenv XAUTHORITY $HOME/proxyauth


In this example, the authorization token for display 0 is copied into a
new file ``proxyauth'' and associated with the LBX proxy server display
number (22).  The new authority file may then be copied to another host
and used as the value of the XAUTHORITY environment variable.

The _p_r_o_x_y_m_n_g_r daemon is usually configured to invoke _l_b_x_p_r_o_x_y automati-
cally when a user or a CGI script runs _x_f_i_n_d_p_r_o_x_y _-_n_a_m_e _L_B_X.

See the _l_b_x_p_r_o_x_y man page for further details.


33..1177..  MMaajjoorr AAddddiittiioonnss ttoo EExxiissttiinngg PPrrooggrraammss


The _g_e_n_e_r_a_t_e option of _x_a_u_t_h is used to obtain additional authorization
tokens for client connections.  These authorization tokens may specify
that the client using them is to be restricted in the operations that
may be performed in the X server.  The authorization tokens may be inde-
pendently revoked.  Refer to the SECURITY extension for further details
on authorizations.

The _x_a_u_t_h man page gives full details on the new generate command.  Here
is an example use:

     xauth -f untrusted-auth-file g :0 . timeout 0
     setenv XAUTHORITY untrusted-auth-file

This will cause _x_a_u_t_h to contact server ``:0'' to get a long-lasting
untrusted cookie which it then stores in untrusted-auth-file.  By set-
ting XAUTHORITY to point to untrusted-auth-file, subsequent applications
run from this shell to server :0 will be untrusted.  The ``g'' is short
for ``generate'', and the ``.'' is short for ``MIT-MAGIC-COOKIE-1''.  If
you omit the -f argument, _x_a_u_t_h will use $XAUTHORITY (or ~/.Xauthority),
which may not be what you want, especially if you are creating an
untrusted auth.  This is because _x_a_u_t_h will replace the trusted auth in
~/.Xauthority (put there by xdm) with the untrusted one, preventing you
from making any further trusted connections to the server.

The _x_t_e_r_m terminal emulator now supports the active icon mode that was
in X version 10 Release 4.  See the _x_t_e_r_m man page for further details.
There is support in the _x_t_e_r_m source to build xterm without the active
icon mode for those who may care for some reason to not provide it.


33..1188..  AANNSSIIffiiccaattiioonn


As noted previously under "Configuration Files", for pragmatic reasons
we changed the way we use __STDC__ to test for standard C compilers.
R6.1 was officially the last release that supported traditional K&R C.
R6.3 assumes a standard C compiler and environment.  We have not inten-
tionally removed any K&R C support from old code; most of the release
will continue to build on older platforms.



44..  KKnnoowwnn BBuuggss


There are no examples in this release showing how to use the print
extension.  CDE 2.1 has several such applications.

_l_b_x_p_r_o_x_y fails to start on SCO Open Server.

_x_1_1_p_e_r_f running through _l_b_x_p_r_o_x_y will tickle a drawing bug in cfb-based
X servers that causes some lines and curves to be drawn to the wrong
coordinates and outside the window boundaries.  Use the _-_n_o_g_f_x option to
_l_b_x_p_r_o_x_y as a workaround on affected servers.

If _p_r_o_x_y_m_n_g_r exits abnormally all managed proxies die.

Documentation is missing on how to use the vertical writing and user-
defined character support.

Documentation is sparse on how to configure _X_p_r_t.

There are no example fonts in the release with vertical text escapement
(``vertical writing fonts'').



55..  FFiilliinngg BBuugg RReeppoorrttss


If you find a reproducible bug in software in the xxcc// directory, or find
bugs in the xxcc documentation, please send a bug report to The Open Group
using the form in the file xxcc//bbuugg--rreeppoorrtt and this destination address:

     xbugs@x.org


Please try to provide all of the information requested on the form if it
is applicable; the little extra time you spend on the report will make
it much easier for someone to reproduce, find, and fix the bug.

Bugs in the contributed software that is available on the net are not
handled on any official basis.  Consult the documentation for the indi-
vidual software to see where (if anywhere) to report the bug.  Many
authors of contributed software subscribe to the mailing list "contrib-
bugs" hosted at x.org, so this might be a useful place to report bugs.
(To subscribe to contrib-bugs yourself, send email to contrib-bugs-
request@x.org.)



66..  AAcckknnoowwlleeddggeemmeennttss


Release 6.3 of X Version 11 was brought to you by the X staff at the X
Consortium, Inc.: Donna Converse (emeritus), Jim Fournier, Stephen
Gildea (emeritus), Kaleb Keithley, Matt Landau (emeritus), Arnaud Le
Hors, Ralph Mor (emeritus), Bob Scheifler, Ralph Swick, Ray Tice, Mark
Welch (emeritus), and Dave Wiggins (emeritus).  Kevin Samborn and George
Tsang (emeritus) of the CDE staff at X Consortium, Inc. worked hard on
the print extension, including the PostScript driver; David Kaelbling of
the CDE staff converged the X, Motif, and CDE imake/config support and
helped with Xos_r.h; and Daniel Dardailler (emeritus) of the CDE staff
contributed the libXt geometry tracing code.  Also, contractors Reed
Augliere, Roger Helmendach (Liberty Systems), and Ann Pichey each worked
on critical components.

Several companies and individuals have cooperated and worked extremely
hard to make this release a reality, and our thanks go out to them.  You
will find many of them listed in the acknowledgements in the individual
specifications.

Ken Raeburn of XFree86 and Cygnus Support contributed the gzip font com-
pression support.

The Common Desktop Environment sponsors Digital Equipment Corp, Fujitsu,
Hewlett-Packard, Hitachi, IBM, Novell, and SunSoft jointly contributed
the print extension and the Xlib vertical writing and user-defined char-
acter support.  Axel Deininger, Harry Phinney, Tom Gilg, Charles Prince,
and Jim Miller all from Hewlett-Packard did the print extension and PCL
and raster drivers.  Fujitsu did the Xlib vertical writing and user-
defined character support.


