+++ /dev/null
-
-
-
-
-
-
-
-
-
- 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.
-
-
projects / rdpsrv / blobdiff