Path: utzoo!attcan!uunet!aplcen!samsung!usc!apple!oliveb!orc!bbn.com!diamond.bbn.com!mlandau
From: mlandau@bbn.com (Matthew Landau)
Newsgroups: comp.windows.x
Subject: Determining EXACTLY whose server you're talking to
Message-ID: <14201@diamond.BBN.COM>
Date: 9 Jun 90 05:17:25 GMT
Sender: news@bbn.com
Distribution: comp
Lines: 54

In the course of trying to program around a particularly nasty bug 
in a particular X server (the MIT server running on the Sun-386i 
will core dump if asked to draw arcs with a particular combination 
of drawing attributes -- bug report to be submitted shortly), I've 
noticed that there doesn't seem to be any reliable way to tell 
*exactly* what server is on the other end of that XOpenDisplay you
just did.

Now I realize that in the ideal world for which X was designed, you
wouldn't CARE what server is on the other end of an application, but
in the real world, sometimes you just have to know.  Programming 
around bugs is a prime example -- ANY program that performs a certain
operation, running on ANY host, pointed at an MIT X11R4 server running
on a Sun-386i, will crash the server.  

Knowing this, we can program defensively by having our applications 
detect that they're running with such a server and either disable 
certain features, or implement them in a different (i.e., worse) way.
We can do this IF we can tell what server is on the other end, but
we need to know very specifically what server we're talking to -- the
OpenWindows server running on the 386i, for instance, does NOT show
the same bug, nor does the MIT server running on a Sun-4.  It's ONLY
the combination of MIT R4 and the 386i that proves deadly, and there
doesn't seem to be any offically blessed way to get that much 
information back.  (All MIT servers seem to have the ServerVendor set
to "MIT X Consortium", for instance -- you can't really tell one MIT
server from another.)

For the moment, I've resorted to a hack, basically looking at the
Display returned by XOpenDisplay and checking the ProtocolVersion,
ServerVendor, and VendorRelease to see if this is an MIT R4 server, 
then checking the BitmapBitOrder and ImageByteOrder to see if this 
might be a 386i (i.e., if they're both LSBFirst), and finally cheating
and looking at the min_keycode and max_keycode fields to see if they
match what I'd expect to find in a Sun server (as opposed to a server
for some other little endian machine like a VAX).

This seems to work, at least for the moment, but it strikes me as 
a truly awful hack to have to use.  Is there no better way?  

Perhaps in future versions of the server (even future patch levels?) 
the Consortium could suggest that vendors include the CPU architecture 
as part of the ServerVendor string?  Then we could have vendor names 
like "MIT X Consortium (Sun 386i)" versus "MIT X Consortium (IBM RT/PC)" 
versus "Digital Equipment Corporation (DECStation)", which would go a 
long way toward helping those of us who just HAVE to be able to program
around a particular server "feature" until someone gets around to 
fixing it (and all those users out there get around to upgrading their
servers...)

Any takers?
--
 Matt Landau		    The happiest cold and lonely guy 
 mlandau@bbn.com	          stuck in the Yukon without a dog.