home *** CD-ROM | disk | FTP | other *** search
Text File | 1996-12-24 | 48.0 KB | 1,302 lines |
-
-
-
-
-
-
-
-
-
- X Window System, Version 11
- Release 6.3
-
- Release Notes
-
-
-
-
-
-
-
-
- X Consortium, Inc.
-
- 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
- "Software"), to deal in the Software without restriction, including
- without limitation the rights to use, copy, modify, merge, publish, dis-
- tribute, sublicense, and/or sell copies of the Software, and to permit
- persons to whom the Software is furnished to do so, subject to the fol-
- lowing conditions:
-
- 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 Window System is a trademark of X Consortium, Inc.
-
-
-
- 1. What Is Release 6.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-
- compatible.
-
- 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 Consortium man page for addi-
- tional details about the X Consortium.
-
- See xc/INSTALL.PS (PostScript) or xc/INSTALL.TXT (plain text) for
- instructions on how to build and install this software.
-
-
- 1.1. Overview of the X Consortium Release
-
-
- The X Consortium software and documentation in Release 6.3 is in direc-
- tory xc/ and contains the following:
-
- X Consortium Standards
- The X Consortium produced standards: documents which define net-
- work protocols, programming interfaces, and other aspects of the X
- environment. See the XStandards manual page for a list of stan-
- dards.
-
- Implementations
- 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 reference implementations; the
- written specifications define the standards.
-
- Fonts
- A collection of bitmap and outline fonts are included in the dis-
- tribution, contributed by various individuals and companies.
-
- Utility Libraries
- A number of libraries, such as Xmu and the Athena Widget Set, are
- included. These are not standards, but are used in building X Con-
- sortium applications and may be useful in building other applica-
- tions.
-
- Programs
- We also provide a number of application programs. A few of these
- programs, such as xdm (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.2. Supported Systems
-
-
- 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 gcc.
-
-
- 1.2.1. Supported Display Devices
-
-
- This release includes the necessary device-dependent support to build a
- native X server for the following platforms:
-
- XFree86: See the XF_* man pages for supported video cards
-
- 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
- Ultrix[1] :Xdec
-
- 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.3. The XC Tree
-
-
- The general layout under xc/ is as follows:
-
-
- config/ config files, imake, makedepend, 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 rgb
- util/ patch, compress, other utilities
- bug-report bug reporting template
- registry X Registry
-
-
- This file is xc/RELNOTES.*, in various formats. The documentation
- source files RELNOTES.ms and INSTALL.ms are in the xc/doc/misc/ direc-
- tory.
-
-
- 1.4. X Registry
-
-
- 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 xc/registry 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.5. Extensions Supported
-
-
- 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 (print-
- ing), XTEST, and XTestExtension1.
-
- Not all of these extensions are standards; see the XStandards manual
- page. Some of these extensions are not supported on all platforms.
-
-
- 1.6. Implementation Parameters
-
-
- Some of the specifications define some behavior as implementation-
- dependent. 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 imake vari-
- ables XFileSearchPathDefault, XAppLoadDir, XFileSearchPathBase, and
- ProjectRoot in site.def. See xc/config/cf/README for instructions
- and xc/config/cf/X11.tmpl[2] 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 /usr/X11R6.3/lib/X11/XKeysymDB, assuming ProjectRoot is
- set to /usr/X11R6.3.
-
- XCMSDB default
- Defaults to /usr/X11R6.3/lib/X11/Xcms.txt, assuming ProjectRoot is
- set to /usr/X11R6.3.
-
- XLOCALEDIR default
- Defaults to the directory /usr/X11R6.3/lib/X11/locale, assuming
- ProjectRoot is set to /usr/X11R6.3. The XLOCALEDIR variable can
- contain multiple colon-separated pathnames.
-
- XErrorDB location
- The Xlib error database file is /usr/X11R6.3/lib/X11/XErrorDB,
- assuming ProjectRoot is set to /usr/X11R6.3.
-
- XtErrorDB location
- The Xt error database file is /usr/X11R6.3/lib/X11/XtErrorDB,
- assuming ProjectRoot is set to /usr/X11R6.3.
-
- Supported Locales
- X locales supported are in locale.dir; the mapping between various
- system locale names and X locale names is in locale.alias. Both
- files are shipped in the xc/nls/X11/locale/ directory and installed
- in the XLocaleDir directory (e.g. /usr/X11R6.3/lib/X11/locale/).
-
- 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
- xc/nls/X11/locale/Compose/iso8859-* for the supported compositions.
-
- There are input method servers available on the net.
-
-
-
- 2. What is Unchanged in Release 6.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 libICE; see below. The extension
- library, libXext, 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. What Is New in Release 6.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
- integration, 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.1. OS Support
-
-
- 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.2. New Standards
-
-
- 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. Low Bandwidth X Extension
-
-
- 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, lbxproxy, 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 xc/doc/specs/Xext/lbx.mif (FrameMaker
- interchange source) and xc/doc/hardcopy/Xext/lbx.PS.Z (compressed
- PostScript).
-
-
- 3.4. RX: X Remote eXecution
-
-
- 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 (xrx) and a Netscape Naviga-
- tor plug-in (libxrx) 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 xc/doc/specs/RX/RX.mif
- (FrameMaker interchange source) and xc/doc/hardcopy/RX/RX.PS.Z
- (compressed PostScript).
-
- The following section describes the procedure to set up your environment
- and try the examples provided in this distribution.
-
-
- 3.4.1. Preparing Your Web Server
-
-
- 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
- automated by adding the following definitions to your site.def or
- host.def 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 proxymngr
- man pages for further details. Typically the proxy
- manager host will be the same as your web server, for
- example:
-
- #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.4.2. The RX Helper Program
-
-
- The helper program, xrx, 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. xload) 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.4.3. The RX Netscape Navigator Plug-in
-
-
- The Navigator plug-in supports all the functions of xrx 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.
- Binaries 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 libxrx.so.6.3 or libxrx.sl.6.3 (or similar, depending on your
- platform) in <ProjectRoot>/lib (e.g. /usr/X11R6.3/lib) and copy it to
- either /usr/local/lib/netscape/plugins or $HOME/.netscape/plugins. Do
- not install the symlinks libxrx.so or libxrx.sl; 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 res-
- tart 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.4.4. Trying Embedding With an Old X Server
-
-
- The Netscape Navigator plug-in, libxrx, 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 Xnest server.
-
- A typical Xnest 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.4.5. Setting Up Your Own Applications To Run Over The Web
-
-
- 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
- appropriate for your application.
-
- You will not be able to run the dtcm demo unless you have dtcm (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
- dtcm.pl is, for that reason, slightly more complicated than other exam-
- ples.
-
-
- 3.5. Security Extension
-
-
- 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
- xc/doc/specs/Xext/security.tex (LaTeX source) and
- xc/doc/hardcopy/Xext/security.PS.Z (compressed PostScript).
-
-
- 3.5.1. Untrusted Application Behavior
-
-
- 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,
- separated 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.5.1.1. Behaviors That Are Implementation-Dependent
-
-
- 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.
-
- oclock is square because the SHAPE extension hasn't been marked secure
- yet. Similarly, Xaw applications that use oval buttons will have rec-
- tangular 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 xieperf and all
- the xkb utilities.
-
- emacs exits with a Window error when trying to use the QueryPointer
- request on the root window when you click in a buffer.
-
- FrameMaker, and xwd -root 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 Xserver 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 xcmsdb -remove, xprop -root -remove, and xstdcmap -delete.
-
- xprop exits with an Atom error when attempting to access protected pro-
- perties.
-
- 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
- intermediary.
-
- xterm 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 xcutsel 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.5.1.2. Behaviors That Are Not Likely To Change
-
-
- The following behaviors represent actions performed by the applications
- that are disallowed by design.
-
- editres will fail when pointed at a trusted client when it tries to read
- window properties on a window owned by that client.
-
- Xnest exits on startup with an Access error as it tries to use the
- ChangeKeyboardControl request.
-
- The new generate option to xauth fails because untrusted applications
- are not allowed to create additional authorizations.
-
- xhost cannot be used to modify the host access list.
-
- xmag 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. xmag could be modified to exit
- gracefully under these conditions.
-
- netscape exits on startup with a Drawable error when trying to use the
- GetImage request on the root window.
-
- xmodmap exits with an Access error when trying to use the ChangeKey-
- boardMapping request.
-
- xset with the b, c, led, or r options exits with an Access error when
- trying to use the ChangeKeyboardControl request. With the bc option, it
- can't find the MIT-SUNDRY-NONSTANDARD extension and exits gracefully.
-
- xsetroot exits with a Window error when trying to use the ChangeWin-
- dowAttributes request on the root window.
-
-
- 3.6. Application Group Extension
-
-
- 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
- xc/doc/specs/Xext/AppGroup.mif (FrameMaker interchange source) and
- xc/doc/hardcopy/Xext/AppGroup.PS.Z (compressed PostScript).
-
-
- 3.7. Print Extension
-
-
- 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
- xc/doc/specs/XPRINT/xp_proto.mif (FrameMaker interchange source) and
- xc/doc/hardcopy/XPRINT/xp_proto.PS.Z (compressed PostScript). The
- library API specification is in xc/doc/specs/XPRINT/xp_library.mif
- (FrameMaker interchange source) and
- xc/doc/hardcopy/XPRINT/xp_library.PS.Z (compressed PostScript).
-
-
- 3.7.1. Running an X Print Server
-
-
- 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.
-
- XPCONFIGDIREnvironment variable specifying alternative location of the
- print server configuration files.
-
- The print server, Xprt, 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 xc/config/cf/README.
- XprtServer defaults to the value of BuildServer (i.e. Xprt 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
- xc/programs/Xserver/XpConfig/. See also xc/doc/specs/Xserver/Xprt.mif
- (FrameMaker interchange source) and xc/doc/hardcopy/Xserver/Xprt.PS.Z
- (compressed PostScript) for further instructions on configuring Xprt.
-
-
- 3.7.2. Specifying The Print Server To A Client
-
-
- 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.8. Proxy Management Protocol
-
-
- 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
- appropriate, and keeping track of all of the available proxy services.
- The proxy manager strives to reuse existing proxy processes whenever
- possible.
-
- The Proxy Management Protocol is described in xc/doc/specs/PM/PM_spec.
-
-
- 3.9. Configuration
-
-
- As in R6.1, the top-level Makefile is no longer over-ridden by the first
- build. Instead a new file xmakefile is created. Thus is it not neces-
- sary to take any additional steps to reset the builds.
-
- The file xc/config/cf/README provides more guidance on how to write an
- Imakefile, including a list of variables that may be set in an
- Imakefile. 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 InstallXdmConfig, InstallXinitConfig,
- and InstallAppDefFiles 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 gzip rather than compress for font compression. It defaults to NO.
-
- The build creates a new directory xc/exports 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 contri-
- buted by the OSF CDE/Motif project and are included in R6.3.
-
-
- 3.10. Documentation
-
-
- Additional X server internals documentation is provided in the
- /xc/doc/specs/Xserver/ 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 /xc/doc/specs/RX/, /xc/doc/specs/XPRINT/, and
- /xc/doc/specs/Xext/.
-
-
- 3.11. Header Files
-
-
- xc/include/Xos_r.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.12. X Server
-
-
- 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
- /usr/X11R6.3/lib/X11/xserver/SecurityPolicy. Site-defined policy
- strings used by xfwp and rules for property access by untrusted clients
- are defined there. See the Xserver man page for full details.
-
-
- 3.12.1. New Device Support
-
-
- 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.12.2. Internal Changes
-
-
- 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 xc/doc/specs/Xserver/appgroup.ms and
- xc/doc/specs/Xserver/secint.tex for implementation details of the appli-
- cation group and security extensions, respectively.
-
-
- 3.13. ICE Library Addition
-
-
- 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.14. Xlib Vertical Writing and User-Defined Characters
-
-
- 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 /usr/X11R6.3/lib/X11/locale.
-
- The X[mb|wc]TextEscapement functions now return the text escapement in
- pixels for the vertical or horizontal direction depending on the
- XNOrientation XOCValue.
-
- The X[mb|wc]DrawString functions will now render a character string in
- the vertical or horizontal direction depending on the XNOrientation
- XOCValue.
-
- 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.15. Xt Geometry Management Debugger
-
-
- 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.16. New Programs
-
-
- There are new core programs lbxproxy, proxymngr, xfindproxy, xfwp, Xprt,
- and xrx.
-
-
- lbxproxy The lbxproxy 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. lbxproxy 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. lbxproxy can be used stand-
- alone or in conjunction with proxymngr and xfindproxy. See
- the lbxproxy man page for further details.
-
- proxymngr proxymngr is a process that runs continuously to control
- other proxy applications, such as lbxproxy and xfwp. It
- maintains a list of active proxy processes and responds to
- queries from xfindproxy. See the proxymngr man pages for
- further details.
-
- xfindproxy xfindproxy is used to locate a running proxy process for a
- given network service, such as lbxproxy or xfwp, or to
- request that a proxy be started if one is not already run-
- ning. xfindproxy communicates with proxymngr to perform the
- actual work.
-
- xfwp xfwp 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). xfwp appears to the clients
- using it as another X server; that is, clients connect
- through it using the conventional DISPLAY syntax. xfwp will
- not do anything useful without proxymngr and xfindproxy or
- xrx. See the xfwp man page for further details.
-
- Xprt Xprt is the print server, built as part of the Xserver build
- if the XprtServer config option is YES. The print server
- supports printing to PostScript and PCL devices, as well as
- raster output to an xwd format file (and thence to any
- printer that xpr 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 Xprt are in xc/doc/specs/Xserver/Xprt.mif (FrameMaker
- interchange source) and xc/doc/hardcopy/Xserver/Xprt.PS.Z
- (compressed PostScript).
-
- xrx, libxrx xrx is the Web browser helper application that interprets
- documents in the RX MIME type to remotely launch applica-
- tions via the Web. Its companion libxrx 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 xrx man page
- for further details.
-
-
- 3.16.1. Using The LBX Proxy
-
-
- The implementation of lbxproxy provided here will support an arbitrary
- number of clients connecting to the same X server. A separate lbxproxy
- process is required for each separate X server process. A typical com-
- mand line to invoke lbxproxy 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 proxymngr daemon is usually configured to invoke lbxproxy automati-
- cally when a user or a CGI script runs xfindproxy -name LBX.
-
- See the lbxproxy man page for further details.
-
-
- 3.17. Major Additions to Existing Programs
-
-
- The generate option of xauth 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
- independently revoked. Refer to the SECURITY extension for further
- details on authorizations.
-
- The xauth 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 xauth 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, xauth will use $XAUTHORITY (or ~/.Xauthority),
- which may not be what you want, especially if you are creating an
- untrusted auth. This is because xauth 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 xterm terminal emulator now supports the active icon mode that was
- in X version 10 Release 4. See the xterm man page for further details.
- There is support in the xterm source to build xterm without the active
- icon mode for those who may care for some reason to not provide it.
-
-
- 3.18. ANSIfication
-
-
- 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. Known Bugs
-
-
- There are no examples in this release showing how to use the print
- extension. CDE 2.1 has several such applications.
-
- lbxproxy fails to start on SCO Open Server.
-
- x11perf running through lbxproxy 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 -nogfx option to
- lbxproxy as a workaround on affected servers.
-
- If proxymngr 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 Xprt.
-
- There are no example fonts in the release with vertical text escapement
- (``vertical writing fonts'').
-
-
-
- 5. Filing Bug Reports
-
-
- If you find a reproducible bug in software in the xc/ directory, or find
- bugs in the xc documentation, please send a bug report to The Open Group
- using the form in the file xc/bug-report 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. Acknowledgements
-
-
- 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 Gil-
- dea (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
- compression 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.
-
-
-