Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!usenet.ins.cwru.edu!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!SHAMASH.MCRCIM.MCGILL.EDU!mouse
From: mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Determining EXACTLY whose server you're talking to
Message-ID: <9006100416.AA17201@shamash.McRCIM.McGill.EDU>
Date: 10 Jun 90 04:16:27 GMT
Sender: root@athena.mit.edu (Wizard A. Root)
Organization: The Internet
Lines: 51

> In the course of trying to program around a particularly nasty bug in
> a particular X server ([...]), 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.

Right.

> 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.

> 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...)

And then what if it turns out to be OS-specific?  Or CPU ECO level
specific?  Or dependent on the compiler used to build the server?  I
can see it now, ServerVendor =

"MIT X Consortium (Sun-3/60 hostid 1234567 with 68881 type-3 keyboard
bwtwo 1600x1280 display running 4.1.3 server patchlevel 14 compiled
with gcc 1.44.8 -O -fstrength-reduce -fcombine-regs on a Sun-3/140
running 4.0.3)"

No thanks.  I would prefer to fix the server bug, send the fix in to
MIT, and forget it.  If you're stuck with a binary-only server, port
the MIT server (only half kidding) or demand that the vendor fix it.

In fact, that's what I did.  I came across two bugs in the MIT server,
both of them crippling for something I wanted to do (one if them severe
enough that I simply couldn't use R4 at all until I fixed it).  So what
did I do?  Did I kludge around them in the clients?  No, I fixed them,
sent the fix in, and forgot them.  I make no effort to avoid tickling
them in code I write, and if someone else has trouble, I'll be glad to
ftp the relevant fix and send it to them.  If I were to try to kludge
around all known bugs in anyone's servers, the result would be a web of
conditionals *I* certainly wouldn't want to have to maintain.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu