X-Git-Url: https://git.sesse.net/?p=rdpsrv;a=blobdiff_plain;f=Xserver%2FRELNOTES.TXT;fp=Xserver%2FRELNOTES.TXT;h=8e47fef5ee4b24e15032da22dbd2469c5cf29321;hp=0000000000000000000000000000000000000000;hb=b6e6afccf37f4ad0515ef2a698f714fdf1bf23b3;hpb=e3340a110a3b01756b8e67531395a33b40a17d37 diff --git a/Xserver/RELNOTES.TXT b/Xserver/RELNOTES.TXT new file mode 100644 index 0000000..8e47fef --- /dev/null +++ b/Xserver/RELNOTES.TXT @@ -0,0 +1,1301 @@ + + + + + + + + + + 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 /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 /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 +/%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. + +