mlandau@bbn.com (Matthew Landau) (06/09/90)
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.
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (06/10/90)
> 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
stripes@eng.umd.edu (Joshua Osborne) (06/11/90)
In article <14201@diamond.BBN.COM> mlandau@bbn.com (Matthew Landau) writes: [...] >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.) Or you could ask your friendly nameserver, not knowing the enviroment you work in I don't know if you keep your HINFO records up to date, but... nslookup > set querytype=HINFO > mojo Server: abyss.eng.umd.edu Address: 128.8.133.6 mojo.eng.umd.edu CPU=SUN-3/50 OS=UNIX > frob.eng.umd.edu Server: abyss.eng.umd.edu Address: 128.8.133.6 frob.eng.umd.edu CPU=SUN-4/60 OS=UNIX That looks like what you want to know, 'tho I'm not shure how uniformly people format that field both MIT & U of Maryland seem to do it the same... -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert
mlandau@bbn.com (Matthew Landau) (06/11/90)
stripes@eng.umd.edu (Joshua Osborne) writes: >In article <14201@diamond.BBN.COM> I wrote: [Some stuff about trying to identify exactly whose X server is on the other end of that XOpenDisplay...] >Or you could ask your friendly nameserver, not knowing the enviroment you >work in I don't know if you keep your HINFO records up to date, but... In retrospect, it appears my original message wasn't as clear as it should have been about one thing. The reason I'm worry about any of this in the first place, instead of just fixing my own server and forgetting about it, is that working on commercial software which is sold by my employer to lots of people running different versions of X in different environments. I am trying to make sure my *product* doesn't tweak the nastier bugs out there and crash someone's X server if I can avoid it. Commercial software almost by definition necessitates a least common denominator solution -- you can't simply tell X11 vendors or customers "Go fix your server", nor can you (sanely) get into the business of providing bug-fixed servers yourself, nor can you assume/depend on customers having up-to-date nameservers (or any nameservers at all), so you end up having to fall back on "something that works correctly most of the time, without the software using having to do anything". That's why it would have been nice to be able to *rely* on getting more information back from the server than is currently possible. [Yup, I've read der Mouse's argument that it's never enough, and you get into issues of patch level, revision date, etc. Well, what can I say? Some information seems better than no information...] -- Matt Landau Takes more than combat gear to make a man, mlandau@bbn.com Takes more than a license for a gun. Confront your enemies - avoid them when you can. A gentleman will walk but never run.
guy@auspex.auspex.com (Guy Harris) (06/12/90)
>Or you could ask your friendly nameserver, not knowing the enviroment you >work in I don't know if you keep your HINFO records up to date, but... Not all the people to whom BBN, the company for which Matthew works, sells their products necessarily run in environments where there *is* a DNS nameserver....