path: root/xc/RELNOTES.TXT

                      XX WWiinnddooww SSyysstteemm,, VVeerrssiioonn 1111

                              RReelleeaassee 66..44

                             RReelleeaassee NNootteess








                     The Open Group X Project Team

                            30 January, 1998










Copyright (C) 1998   The Open Group

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 the following permission notice shall be
included in all copies 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 NON- INFRINGEMENT. IN NO EVENT
SHALL THE OPEN GROUP 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 OF OTHER DEALINGS
IN THE SOFTWARE.

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

_X _W_i_n_d_o_w _S_y_s_t_e_m is a trademark of The Open Group.



_1_.  _W_h_a_t _I_s _X_1_1


X11, or X, is a vendor-neutral, system-architecture neutral network-
transparent window system and user interface standard.  In other words
it's windows for UNIX. But X is not just for UNIX -- X runs on a wide
range of computing and graphics machines including Macintosh, OS/2,
Microsoft's MS-Windows family of operating systems, and almost all of
the so-called Network Computers. X can use your network -- you may run
CPU-intensive programs on high powered workstations and display the user
interface (the windows) on inexpensive desktop machines.


_2_.  _W_h_a_t _i_s _R_e_l_e_a_s_e _6_._4


Release 6.4 (R6.4) is The Open Group X Project Team's update to the X
Consortium's Release 6.3 (R6.3) of X11 and all prior releases.  It is
compatible with with all releases going back to R1 at both the source
and protocol levels.

The X Consortium was an independent, not-for-profit membership corpora-
tion formed in 1993 as the successor to the MIT X Consortium.  It was
dissolved at the end of 1996 and all assets such as trademarks and copy-
rights were transferred to The Open Group.

The Open Group's X Project Team was formed to continue maintenance and
development of X. Membership in The Open Group X Project Team does not
require membership in The Open Group. To join the X Project Team contact
the sales office near you -- you can find a list of sales offices at
http://www.opengroup.org/contacts/sales.htm, or download the membership
kit from http://www.opengroup.org/tech/desktop/x/projteam.htm.

Instructions for building and installing R6.4 can be found in the file
INSTALL.PS (PostScript) or INSTALL.TXT (plain text), available sepa-
rately and also contained in the release.


_3_.  _O_v_e_r_v_i_e_w _o_f _t_h_e _X _P_r_o_j_e_c_t _T_e_a_m _R_e_l_e_a_s_e


Like all the releases that preceded it, R6.4 is a source code release.
In order to use the release it is necessary to first unpack the distri-
bution, compile it, and then install it. The source contains the follow-
ing items:

XX CCoonnssoorrttiiuumm SSttaannddaarrddss aanndd XX PPrroojjeecctt TTeeaamm SSppeecciiffiiccaattiioonnss
     The X Consortium produced standards -- documents which define net-
     work protocols, programming interfaces, and other aspects of the X
     environment. These standards continue to exists in the X Project
     Team release. The X Project Team produces specifications.  Like X
     Consortium Standards, these are documents which define network pro-
     tocols, programming interfaces, and other aspects of the X environ-
     ment. Under the aegis of The Open Group, X Consortium standards, X
     Project Team specifications, and other specifications are the basis
     for portions of The Open Group's various CAE Specifications. Some
     of the new features in this release are not _s_t_a_n_d_a_r_d, that is,
     there is no accompanying specification.

IImmpplleemmeennttaattiioonnss
     For most of X Consortium standards and X Project Team specifica-
     tions, a high-quality implementations is provided to demonstrate
     proof of concept, to give vendors a base to use, and early adopters
     a chance to begin developing using the new features. These are not
     _r_e_f_e_r_e_n_c_e implementations -- the written specifications are the
     authoritative definition.

FFoonnttss
     A collection of bitmap and outline fonts are included in the dis-
     tribution, contributed by various individuals and companies.

UUttiilliittyy LLiibbrraarriieess
     A number of libraries, such as Xmu and the Athena Widget Set, are
     included. These are not standards, but are used in building the
     applications contained in the release and may be useful in building
     other applications.

PPrrooggrraammss
     We also provide a number of application programs. A few of these
     programs, such as _x_d_m (or its equivalent), should be considered
     essential in almost all environments. The rest of the applications
     carry no special status; they are simply programs that have been
     developed and/or maintained by X Consortium and X Project Team
     staff.  In some cases, you will find better substitutes for these
     programs contributed by others.


_4_.  _S_u_p_p_o_r_t_e_d _O_p_e_r_a_t_i_n_g _S_y_s_t_e_m_s


This release was built and tested on the following reference platforms:


        Digital Unix 4.0A
        Fujitsu UXP V20L10
        HPUX 10.20
        Solaris 2.5


This release was also built on the following systems:


        AIX 4.2
        IRIX 6.2
        FreeBSD 2.2.2
        S.u.S.E. Linux 5.0.0 (kernel 2.0.30, libc 5.4.33)
        SunOS 4.1.4
        Windows NT 3.51 (NCD WinCenter)


In all cases except SunOS we have used the vendor's compiler. On SunOS
we build with the GNU C compiler (_g_c_c).


_5_.  _S_u_p_p_o_r_t_e_d _G_r_a_p_h_i_c_s _D_e_v_i_c_e_s


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


        HP-UX: Xhp
        Digital Unix: Xdec on DECstation 3000/400 (Alpha) with PMAG-B
        SunOS/Solaris: Xsun -- see the Xsun man page for supported cards
        XFree86: See the XF_* man pages for supported cards

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

Native X servers are not built on AIX, Fujitsu UXP, IRIX, or Microsoft
Windows NT.


_6_.  _T_h_e _S_o_u_r_c_e _T_r_e_e


The source is distributed in UNIX tar files. The source unpacks from the
tar files into a source tree, and the name of the base directory of  the
source  tree  is xxcc. The name xxcc as the base of the source tree has been
retained from the X Consortium releases.

The general layout under xxcc// is as follows:


config/             imake config files, _i_m_a_k_e, _m_a_k_e_d_e_p_e_n_d, etc.
doc/                all documentation other than per-program manual pages
fonts/              BDF, Speedo, Type1 fonts
include/            common include files
lib/                libraries
nls/                national language support files
programs/           all programs, including the X server and _r_g_b,
util/               _p_a_t_c_h, _c_o_m_p_r_e_s_s, other utilities
bug-report          bug reporting template
registry            X Registry



_7_.  _X _R_e_g_i_s_t_r_y


The X Project Team maintains a registry of certain X-related items to
aid in avoiding conflicts and to aid in sharing of such items. The reg-
istry is in the file xxcc//rreeggiissttrryy.


_8_.  _E_x_t_e_n_s_i_o_n_s _S_u_p_p_o_r_t_e_d


Release 6.4  includes source for the following extensions: BIG-REQUESTS,
DOUBLE-BUFFER, DPMS, Extended-Visual-Information, LBX, MIT-SHM, MIT-
SUNDRY-NONSTANDARD, Multi-Buffering, RECORD, SECURITY, SHAPE, SYNC, TOG-
CUP, X3D-PEX, XC-APPGROUP, XC-MISC, XFree86-VidModeExtension, XIE (X
Image Extension), XINERAMA.  XInputExtension, XKEYBOARD, XpExtension
(printing), XTEST, and XTestExtension1,

Not all of these extensions are standard; see the Standards manual page.
Some of these extensions may not be supported on every platform.


_9_.  _I_m_p_l_e_m_e_n_t_a_t_i_o_n _D_e_p_e_n_d_e_n_t _P_a_r_a_m_e_t_e_r_s


Some of the specifications define some behavior as implementation-depen-
dent. Implementations of the X Consortium standards and X Project Team
specifications must document how those parameters are implemented.

The default values in this release of the implementation dependent
parameters are:


XFILESEARCHPATH default:
     This default can be set at build time by setting the _i_m_a_k_e vari-
     ables XFileSearchPathDefault, XAppLoadDir, XFileSearchPathBase, and
     ProjectRoot in xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff. See xxcc//ccoonnffiigg//ccff//RREEAADDMMEE for
     instructions and xxcc//ccoonnffiigg//ccff//XX1111..ttmmppll for details of how these
     configuration variables are used.

     By default the imake variable ProjectRoot is //uussrr//XX1111RR66..44 and
     XFILESEARCHPATH has these components:

             _$_P_r_o_j_e_c_t_R_o_o_t/lib/X11/%L/%T/%N%C%S
             _$_P_r_o_j_e_c_t_R_o_o_t/lib/X11/%l/%T/%N%C%S
             _$_P_r_o_j_e_c_t_R_o_o_t/lib/X11/%T/%N%C%S
             _$_P_r_o_j_e_c_t_R_o_o_t/lib/X11/%L/%T/%N%S
             _$_P_r_o_j_e_c_t_R_o_o_t/lib/X11/%l/%T/%N%S
             _$_P_r_o_j_e_c_t_R_o_o_t/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 _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//XXKKeeyyssyymmDDBB.


XCMSDB default:
     Defaults to _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//XXccmmss..ttxxtt.


XLOCALEDIR default:
     Defaults to the directory _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//llooccaallee.  The XLO-
     CALEDIR variable can contain multiple colon-separated pathnames.


XErrorDB location
     The Xlib error database file is _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//XXEErrrroorrDDBB.


XtErrorDB location
     The Xt error database file is _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//XXttEErrrroorrDDBB.


Supported Locales
     Locales supported by this implementation are in xxcc//nnllss//llooccaallee..ddiirr.
     The mapping between various system locale names and X locale names
     is in xxcc//nnllss//llooccaallee..aalliiaass. Both files are installed in the default
     XLOCALEDIR directory, i.e. _$_P_r_o_j_e_c_t_R_o_o_t//lliibb//XX1111//llooccaallee//).


Supported Input Methods
     This distribution does not include source for any input method
     servers; however Xlib supplies a default built-in input method that
     supports compose processing in 8-bit locales. Compose files are
     provided for Latin-1 and Latin-2. The built-in input method can
     support other locales, given suitable compose files. See
     xxcc//nnllss//CCoommppoossee//iissoo88885599--** for the supported compositions.

The Input Method Server Development Kit (IMdkit) is at
ftp://ftp.x.org/pub/unsupported/lib/IMdkit/.


_1_0_.  _W_h_a_t _I_s _N_e_w _i_n _R_e_l_e_a_s_e _6_._4


This section describes changes in the X Project Team distribution since
Release 6.3.

The major new functionality in R6.4 is: Display Power Management Signal-
ing (DPMS) to set "green" computer monitors into power saving mode;
Extended Visual Information to allow applications to discover more about
the graphics capabilities of the server than the core protocol allows;
Colormap Utilization Policy (TOG-CUP) allows applications to discover
desktop special colors, e.g.  MS-Windows reserved (pre-allocated) colors
on PC-Xservers, and store read-only (sharable) colors in specific loca-
tions in a colormap; and Xinerama, a wide screen server that combines
two or more screens into a single virtual screen.

The X Toolkit Intrinsics library (libXt) now has IBM's Easy Resource
Configuration support included.

Xlib (libX11) has two new APIs: XkbSetPerClientControls and XkbGetPer-
ClientControls. These two functions were unintentionally omitted from
the library in previous releases.

The XFree86 servers are now based on XFree86 3.3.1.


_1_1_.  _W_h_a_t _i_s _U_n_c_h_a_n_g_e_d _i_n _R_e_l_e_a_s_e _6_._4


As this is an update release, there is a great deal of stability in the
standards, libraries, and clients. No existing standards have changed in
a material way; although some documents have been updated with minor
corrections. The extension library, _l_i_b_X_e_x_t, is updated to include the
DPMS, Extended-Visual-Information, TOG-CUP, and XINERAMA extension
interfaces. All previous interfaces in these and all other libraries are
unchanged.


_1_2_.  _N_e_w _O_S _S_u_p_p_o_r_t


The  following  table  shows  the versions of the operating systems that
were used to develop this and prior releases:


System         R6        R6.1      R6.[23]   R6.4

AIX            3.2.5     4.1.4     4.2       4.2
A/UX           3.0.1     -         -         -
BSD/386        1.0       -         -         -
Digital Unix (OSF/1)     1.0/1.3   3.2C      4.0A4.0A
FreeBSD        -         2.1.0     2.1.6     2.2.2
Fujitsu UXP    -         -         -         V20L10
HP-UX          9.1       10.01     10.01     10.20
IRIX           5.2       5.3       6.2       6.2
Linux (kernel)
  Slackware 2.3          -         1.2.11    --
  Slackware 3.1          -         -         2.0-
  S.u.S.E. 5.0 -         -         -         2.0.30
Mach           2.5       -         -         -
NEWS-OS        6.0       -         -         -
Solaris        2.3       2.4       2.5       2.5
SunOS          4.1.3     4.1.3     4.1.4     4.1.4
Ultrix-32      4.3       4.4       -         -
UNICOS         8.0       -         -         -
Unixware SVR4.2          1.0       2.02      2.02-
Windows NT     3.1       3.5       4.0       3.51



_1_3_.  _N_e_w _S_p_e_c_i_f_i_c_a_t_i_o_n_s


The following are the new X Project Team specifications in Release 6.4.
Each is described in its own section below.

        Display Power Management Signalling (DPMS)
        Extended Visual Information (EVI)
        Colormap Utilization Policy (TOG-CUP)



_1_3_._1_.  _D_i_s_p_l_a_y _P_o_w_e_r _M_a_n_a_g_e_m_e_n_t _S_i_g_n_a_l_i_n_g


This extension provides X Protocol control over the VESA Display Power
Management Signaling (DPMS) characteristics of video boards under con-
trol of the X Window System.

Traditionally, the X Window System has provided for both blanking and
non-blanking screen savers.  Timeouts associated with these built-in
screen saver mechanisms are limited to idle (dwell) time, and a change
timeout that specifies the change interval for non-blanking screen
savers.

The United States' Environmental Protection Agency (EPA) Energy Star
program requires that monitors power down after some idle time by
default. While it is possible to simply overload the existing screen
saver timeouts, this solution leaves the non-privileged user little to
no control over the DPMS characteristics of his or her system.  For
example, disabling DPMS would require some unintended side effect in the
core screen saver, such as disabling the changing of a non-blanking
screen saver.


_1_3_._2_.  _E_x_t_e_n_d_e_d _V_i_s_u_a_l _I_n_f_o_r_m_a_t_i_o_n


The Extended Visual Information (EVI) extension allows a client to
determine information about core X visuals beyond what the core protocol
provides.

As the X Window System has evolved, it has become clear that the infor-
mation returned by the core X protocol regarding Visuals is often insuf-
ficient for a client to determine which is the most appropriate visual
for its needs. This extension allows clients to query the X server for
additional visual information, specifically as regards colormaps and
framebuffer levels.

This extension is meant to address the needs of pure X clients only.  It
is specifically and purposefully not designed to address the needs of X
extensions. Extensions that have an impact on visual information should
provide their own mechanisms for delivering that information. For exam-
ple, the Double Buffering Extension (DBE) provides its own mechanism for
determining which visuals support double-buffering.


_1_3_._3_.  _C_o_l_o_r_m_a_p _U_t_i_l_i_z_a_t_i_o_n _P_o_l_i_c_y


This extension has three purposes: a) to provide mechanism for a special
application (a colormap manager) to discover any special colormap
requirements, e.g. the colormap entries that are nominally reserved for
desktop colors in the MS-Windows environment and initialize the default
colormap so that it can be more easily shared; and b) to encourage col-
ormap sharing and reduce colormap flashing on low-end 8-bit frame
buffers by providing a policy for sharing; and c) when colormaps aren't
shared, define a behavior in the X server color allocation scheme to
reduce colormap flashing.

To encourage colormap sharing and accommodate special colormap require-
ments two new protocols are defined: the first provides a way to query
the server for a list of reserved colormap entries, and the second is a
way to initialize read-only (sharable) colormap entries at specific
locations in a colormap.

To minimize colormap flashing when the root window's default visual is
one of GrayScale, PseudoColor, or DirectColor, and a private colormap
for the default visual is being used, a minor (but compatible) change to
the server implementation of the AllocColor and AllocNamedColor requests
is required. Where the core protocol says nothing about the pixel values
returned, when this extension is in effect, the AllocColor and Alloc-
NamedColor requests will first look for a matching color in the default
colormap, and, if a match is found and the same cell in the private col-
ormap has not already been allocated, the color will be allocated in the
private colormap at the same location as in the default colormap
(instead of in the first available location.)


_1_4_.  _E_a_s_y _R_e_s_o_u_r_c_e _C_o_n_f_i_g_u_r_a_t_i_o_n


Setting and changing resources in X applications can be difficult for
both the application programmer and the end user.  RReessoouurrccee CCoonnffiigguurraa--
ttiioonn MMaannaaggeemmeenntt ((RRCCMM)) addresses this problem by changing the XX IInnttrriinn--
ssiiccss to immediately modify a resource for a specified widget and each
child widget in the hierarchy.  In this context, immediate means: no
sourcing of a resource file is required; the application does not need
to be restarted for the new resource values to take effect; and the
change occurs immediately.

The main difference between RRCCMM and the EEddiittrreess protocol is that the RRCCMM
customizing hooks reside in the IInnttrriinnssiiccss and thus are linked with
other toolkits such as Motif and the Athena widgets. However, the
EEddiittRReess protocol requires the application to link with the EEddiittRReess rou-
tines in the Xmu library and Xmu is not used by all applications that
use Motif.

Easy Resource Configuration is not a standard part of the X Toolkit
Intrinsics (libXt). It is neither an X Consortium standard nor an X Pro-
ject Team specification.


_1_5_.  _X_i_n_e_r_a_m_a


The Xinerama extension provides a way for a multi-headed system to func-
tion as one large screen. Windows can span multiple screens and can move
from one screen to another.

Currently, the Xinerama Extension works in a homogeneous graphics envi-
ronment. A graphics environment is considered homogeneous if, for exam-
ple, all of the graphics cards have 8 planes with 6 visuals.  Mixing a
24-plane graphics card with a 8-plane card creates a heterogeneous envi-
ronment.

Unlike other multiple screen implementations, Xinerama provides a solu-
tion at the device-independent level. The advantage of this approach is
that it reduces the amount of work involved in supporting and maintain-
ing the extension. The number of graphics devices on the market contin-
ues to grow; embedding the extension functionality into the device
dependent code for each device would be a maintenance nightmare. Since
the Xinerama implementation does not require any low-level graphics mod-
ifications, existing device-dependent code does not have to be recom-
piled. In the loadable server world, the Xinerama Extension will work
with existing device-dependent shared libraries.

The Xinerama extension is not a standard. It is neither an X Consortium
standard nor an X Project Team specification.


_1_6_.  _A_N_S_I_f_i_c_a_t_i_o_n


R6.1 was officially the last release that supported traditional K&R C.
Like R6.3, R6.4 assumes a Standard C compiler and environment. We have
not intentionally removed any K&R C support from old code, and most of
the release will continue to build on platforms without an ANSI C com-
piler.


_1_7_.  _V_S_W_5


We have tested this release with VSW5 version 5.0.0. This release passes
all tests in VSW5 with the following exceptions:

+o    tests for which a permanent waiver has been granted.

+o    tests for which a temporary waiver have been granted.

+o    tests where a defect in the test has been identified and reported.

VSW licensees may obtain a list of waivers granted from
http://www.rdg.opengroup.org/interpretations/database/.


_1_8_.  _Y_e_a_r _2_0_0_0 _(_Y_2_K_) _C_o_m_p_l_i_a_n_c_e


For a statement of compliance see http://www.camb.open-
group.org/tech/desktop/faq/y2k.htm


_1_9_.  _M_e_m_o_r_y _T_e_s_t_i_n_g


Beginning circa X11R5 the MIT X Consortium staff, and later the X Con-
sortium, Inc. staff, and now the X Project Team staff have routinely
tested this implementation for a variety of memory-type errors such as
leaks, array bounds writes, uninitialized memory reads, and a variety of
other errors; using a combination of commercial and "home grown" memory
testing tools. All the real problems were fixed long ago; however we
aren't so naive as to believe that there no remaining bugs. If you find
a memory problem in this implementation please file a bug-report. If you
find a memory problem in your vendor's implementation, tell your vendor.
The popular commercial memory checking tools emit lots of false or spu-
rious warnings, most of which can be safely ignored.


_2_0_.  _S_e_c_u_r_i_t_y _C_o_n_s_i_d_e_r_a_t_i_o_n_s


On UNIX and UNIX-like operating systems there are serious security
implications associated with running suid-root programs.

By default the xterm terminal emulation program is installed suid-root
in order to be able to update utmp or utmpx entries. All the known (as
of this writing) exploitable security holes in the X libraries have been
eliminated -- making it theoretically safe for xterm to be suid-root.
For additional security you may install xterm without suid-root; however
if you do, xterm will not be able to make utmp or utmpx entries.

On many Intel-based machines the X server must have root privileges in
order to access the graphics card and open other devices. The easiest
way to grant the requisite privileges is to use xdm to run your X
server. Some people, who prefer not to use xdm, often work around the
need for the X server to run with root privileges by making their X
server a suid-root program. While all the known (as of this writing)
exploitable security holes in the server have been eliminated, the X
Project Team still recommends that you nnoott make your X server suid-root.
There are _s_a_f_e suid-root wrapper programs available (but not in this
release) that you can use to start your server if you don't want to use
xdm.


_2_1_.  _F_i_l_i_n_g _B_u_g _R_e_p_o_r_t_s


If you find a reproducible bug in software built from the source in this
distribution or find bugs in its documentation, please complete a bug-
report using the form in the file xxcc//bbuugg--rreeppoorrtt and send it to The Open
Group X Project Team at

        mailto:xbugs@opengroup.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.


_2_2_.  _A_c_k_n_o_w_l_e_d_g_e_m_e_n_t_s


Release 6.4 of X11 was brought to you by the X Project Team staff at The
Open Group: Arthur Barstow, Kaleb Keithley, Sekhar Makkapati, M.S.
Ramesh, Jingping Ge, Ken Flowers, and Dave Knorr.

Several companies and individuals have cooperated and worked hard to
make this release a reality, and our thanks go out to them:

Madeline Asmus of Digital for Xinerama.

Peter Daifuku of Silicon Graphics for Extended-Visual-Information.

Scott Revelt of Sun Microsystems for preliminary work on TOG-CUP.

Rob Lembree, formerly of Digital, for DPMS.

Jeff Walls of Hewlett Packard.

Wojtek Jarosz of Attachmate.

Bob Schulman of Seaweed.

Brian Bobryk of Digital.

Tom Brown of NetManage.

Garry Paxinos of Metro Link.

Victor Gold of Peritek.

Jackie Drane of IBM.