anderson@ncrorl.Orlando.NCR.COM (Anderson) (05/25/90)
I have recently heard of a compatability problem between DECWindows clients and X servers based on the MIT Sample Server. Does anybody have some more specific information about this problem? Does anybody have a list of known problems and their causes? From what I have heard, the clients generate incorrect X protocol. Is this true? Any information would be greatly appreciated. Stuart Anderson anderson@Orlando.NCR.COM
jg@zorch.crl.dec.com (Jim Gettys) (05/29/90)
MIT X11R4 does more complete protocol checking than previous releases. There is a "bug compatibility" extension which helps with older clients that may have bugs in them (for example, an R3 xterm acutally needs this!); unfortunately, there are a few such checks which the bug compatibility does not catch. As a result, some older clients (not just Digital software) may not run correctly against an R4 server, even with bug compatibility enabled. An example of this is dxcalendar, which uses an illegal event mask in SendEvent. (fixed in next release; and unfortunately, dxcalendar is the nicest of our "out of the box" applications, in my opinion... so people notice... Sigh...). Beyond that, you may have font trouble; some fonts we use are licensed and cannot be given away. We posted an alias file several months ago so you don't have to figure out suitable font aliases on your own. Beyond these nits, things should just work (and at the moment, I am running an R4 server on my multi-screen DS5000, so I speak from first hand knowledge). I happily run DECwrite on my R4 server (I'm working on finishing a draft of the mythical X11 paper right now...), for example. If things don't work, its a bug, and should be reported. - Jim Gettys Digital Equipment Corporation Cambridge Research Laboratory Cambridge, Massachusetts.
klein%ncd@UUNET.UU.NET (05/30/90)
> I have recently heard of a compatability problem between DECWindows >clients and X servers based on the MIT Sample Server. Does anybody have some >more specific information about this problem? Does anybody have a list >of known problems and their causes? > From what I have heard, the clients generate incorrect X protocol. Is >this true? We have run into lots of incompatibilities between DECwindows and the MIT sample servers, both in R3 and R4. Some of these have been fixed by DEC, some are being fixed by DEC, some we've worked around in our own implementation, and others, well, caveat emptor. Most of this information came from rather painful trial and error - our impression from DEC has a very mixed internal story on compatibility. Seems to depend on which coast you talk to, with the east coast preferring to keep everyone in the dark, (resources! what do you mean you want the names of our resources!), and the west coast fighting the burden of the 'illegimate child' status (Ultrix). Problems we have observed: Missing fonts ------------- This is the number one big problem. Yes, there are about a dozen or so fonts that are not distributed with R4 that the DEC apps insist on using. Most of these are the menu fonts and the terminal fonts, but guess what gets used first - menus and terminal emulators. Get a hold of the font alias file that DEC posted a while back. It will help get most of the apps started. This would be less annoying if the DEC apps were more robust when faced with anything but the expected fonts, or if at least they would let you modify them with X resources. This is where at least the Ultrix folks are helpful - the resources are reasonably available and settable. The VMS policy seems to be 'this is dangerous, you don't want to know'. Keyboard -------- After you run the DEC session manager, try using your right shift key. Weird, huh? Seems that DEC keyboards and servers don't have 'right' anything, and what is odd is that the apps will put *very* odd things in those slots in your keysym table if your server has the spaces available! Completely bizarre. The only workaround we found was to give the user the option to 'break' our keyboard for use with DECwindows. Broken Compose key ------------------ The Compose key sequence in DECterm will not work against most servers. Poking around proved that it is looking for a certain field in the return message from OpenDisplay to be set a certain way. The details are *so* DEC specific it isn't even funny. One thing for sure, it ain't even close to being compatible with *anybody's* server! Bugs with PutImage ------------------ This is pretty common in the DEC apps, but at least appears to be getting better. Early releases of DECwindows ignored the servers bit ordering for image data, resulting in some truly psychedelic images! The most noticable one was the login banner from either the VMS login proc or the Ultrix xprompter. This was fixed with the most recent releases of DECwindows for both OS's, but the bug is still apparent when trying to use DECwrite and any fonts larger than 24 points, or when trying to use the 'print screen' button from the DEC session manager. Both of these apps exhibit the scrambled image bugs. I have heard that the DECwrite bug has at least been reported internally; I don't know about the 'print screen' bug. Bad protocol ------------ 'dxcalendar' is the specific app (as Jim Gettys mentions) that we have seen break the protocol. We have also seen it die trying to create zero width windows (I think that was the case), but we are not able to easily duplicate this, so it may not be a real problem. Undocumented extensions ----------------------- Somebody in VMS land decided that VMS 5.3 needed some 'xdm-like' smarts. If you are running a 'real' DEC server, the login proc will look for a special extension at connection. If you support it, 'quitting' your session will clean up running clients for you, much like xdm. Unfortunately, if you don't support the extension, you will not be able to finish your session, and hence will not be able to easily start another one. I will leave it to you and your sniffer to figure out what the extension is. Backing store ------------- Inputting in text mode in DECpaint will appear broken if you support backing store. You will see the text as you type into the text window, but when you go back into draw mode the text will 'disappear'. The text is actually there, but the application is errantly waiting for an exposure event that isn't coming. Xprompter loops --------------- This may be misleading, but on an Ultrix system, if you set up the 'standard' DEC login proc 'xprompter' to work with a remote display, you can kiss your cpu goodbye. I never took the time to explore it further, (and haven't tried it with the latest Ultrix release), but during one 12 hour period the init process gathered 11 hours of cpu time! This one's easy to work around - use xdm. This may be more than you were originally asking, but hopefully some of this will filter back to DEC-land and get fixed. It gets frustrating explaining to customers that "no, our server isn't broken, sir, its your application vendor's problem" :-(. Doug klein@ncd.com