fisher@skylab.enet.dec.com (06/05/90)
(Forgive me if you get duplicates: I posted this via a gateway on Friday, and I have not seen it appear on my (or anyone else's) news server by Monday afternoon, so this time I'll try it direct to the news server) ----------------------------------------- In Article 23340 of comp.windows.x, Doug Klein of NCD made a number of comments about interoperability of DECwindows clients and server with other implementations. I will respond to these comments point by point, but I want to make a general statement as well: The DECwindows program, both on Ultrix and VMS, is committed to interoperability with other X11 implementations. If you discover a problem with such interoperability, you should let us know via an Software Problem Report (SPR). We take such reports seriously. While some of us try to monitor news groups such as comp.windows.x, the volume (and our work load) is such that we may well miss it if you just mention a problem there. We, as all manufacturers, reserve the right to add value over the commonly- available X implementations. Such things as special menu fonts for improved readibility and the system management extension (on VMS) for improved security fall into this category. However, if these added value features cause connections from standard Digital clients to non-Digital server implementations to fail (other than by simply not using the added value) then this is a bug which should be reported. I should add that Digital had both Ultrix and VMS attendees at Connectathon-90 sponsored by Sun last February. We did lots of testing with the other 40+ vendors that attended, and we didn't find any server interoperability bugs. We did find difficulties in the font fallback logic in our applications (which is why we created the font.alias file mentioned below). We also found the XPutImage ordering bugs in loginout & DECwrite mentioned below. We are working to correct these. Now for the point by point: >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. As stated above, we will fix problems that we know about, but we can't fix things that we don't know about. >Most of this information came from rather >painful trial and error - Sorry about that, but that tends to be the way with bugs. We never claim our code to be bug-free, even though we try. >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!) Ultrix and VMS do have different philosophies about resources. However, we are equally committed to supporting interoperability. Regarding the resource names, you need to accept that customers of different types of systems have different expectations. One expectation that most VMS customers have is that once we document a (non-privileged) interface, they can count on it. They expect that we won't make incompatible changes to such interfaces in the future. Because of the fact that we can't guarantee resources not to change at this point, we have not documented them. This does not mean that we want to pretend that they don't exist. It simply means that we refuse to make a promise (upward compatibility of resources) which we can't keep. We understand that this is a problem for some more technically oriented people. At this point, all I can do is ask you to please understand that we are walking a tightrope between the expectations of the X community and the VMS community. We do *not* make these kinds of decisions just to be rotten people. >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. As Doug mentioned, we posted this alias file in comp.windows.x a few months ago. It should also be available from the DEC customer support centers. I'm not sure what Doug means by "help most of the apps get started." That implies that most of the apps still don't run completely. I don't think that is true. I believe that our apps run quite nicely with the alias file on a server that has only the fonts distributed by MIT. Again, if there is a specific problem, we won't know about it unless you tell us. >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'. We agree that many of our applications are too fussy about fonts and don't fall back well enough. This is a bug which we know about and are working on. As to the resources, see above. >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. This is a bug that we did not know about until seeing this message. I believe it probably happened because the keyboard with which we do most of our development does not send different codes for right vs. left. Therefore we did not notice the problem. I can't tell you where the bug is; we need to investigate, and will. > >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! Compose is one of those added value features that I talked about above. If your server wants to support DEC multicharacter compose sequences, you need a key that maps to the XK_Multi_key keysym. There is nothing DEC specific about this on the server side of the wire; on the client side DEC's Xlib routine XLookupString has been extended to handle the compose processing. The comments about the details being *so* DEC specific are referring to the fallback strategy we use if a keyboard doesn't have an XK_Multi_key keysym. The truth is that on the current generation of DEC keyboards there is no key that maps to the XK_Multi_key keysym. To allow users to initiate compose sequences on these keyboards, DEC's Xlib also looks for the chorded sequence of XK_AltL with XK_space. Because this is really twisting these keysyms from their strict X11 protocol sense, Xlib only does this if the server is a DECwindows server as identified in the server vendor string passed to the client during XOpenDisplay. So while it is true that there is a DEC-specific fallback for compose sequences, the preferred mechanism uses standard vanilla X and works for any vendor's server than has an XK_Multi_key keysym. It should also be clear than we've gone to reasonable pains to prevent our private agreements between client and server from interfering with interoperability with standard implementations. >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; It has. The DECwrite folks intend to fix it. >I don't know about the 'print screen' bug. I did not know about this one until just now. Again, these are all bugs. We are fixing them as soon as possible. What more can we say? >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. The calendar application (and a couple others) did indeed not initialize the unused bits in the event selection field. Until R4, the MIT server did not check these bits, and neither did we. So far as we know, we have fixed all the applications that have this problem. The VMS versions (the only ones I am sure about) will appear in VMS V5.4. >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. Indeed we do have an extension called the Server Management Extension which the session manager uses to tell the server to do a few things which can't be said in the X protocol. The request we currently use forces the server to disconnect all clients after you log out. Without this capability, there is no way to insure that some remote client does not stay connected, keeping the server from resetting, and thus keeping the old host database active. The problem that the writer is referring to is probably the fact that if there *are* still connections to the server, the login application will refuse to run. Again, this is a security issue. We do not want a new person to be able to log in while a client enabled during the previous session still has a connection. However, in VMS V5.4, we have provided a way to override this check. It will be documented in the release notes. Incidently, part of the problem of forcing applications to exit will be solved with the ICCCM "Save Yourself" message. When DECwindows V1 was written, the ICCCM did not exist. We will be adding support for ICCCM in the future. Of course this still does not guarantee that an uncooperative client will not continue to stay connected. The SME extension will still be needed to solve this problem. >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. If you see this problem in the version of Paint you are using, it sounds like a bug. However, I just tried running Paint from VMS V5.4 and displaying on a server with backing store. It worked fine. >Xprompter loops >--------------- This was a purely Ultrix issue. Sorry, I can't answer this, but I will try to get someone from Ultrix to do so in another posting. >This may be more than you were originally asking, but hopefully some of this >will filter back to DEC-land and get fixed. It would be a lot more helpful if, rather than depending on "filtering", you explicitly reported bugs that you find. >It gets frustrating explaining to >customers that "no, our server isn't broken, sir, its your application >vendor's problem" :-(. It gets equally frustrating saying to customers, "yes it is our bug, and we will fix it. It would have been fixed in the version you have now if only someone had told us about it earlier." Thanks to all of you who are willing to listen to both sides of the story. Burns Fisher VMS DECwindows Engineering Burns Fisher VMS DECwindows and Display PostScript fisher@decwin.enet.dec.com
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (06/05/90)
We will be adding support for ICCCM in the future. Of
course this still does not guarantee that an uncooperative client will not
continue to stay connected. The SME extension will still be needed to
solve this problem.
Use of the X Consortium standard XDMCP would solve this problem, without
need for an extension.jg@zorch.crl.dec.com (Jim Gettys) (06/05/90)
I believe XDMCP did not exist when VMS went and defined its SME extension. Jake is now aware it is something we should deal with... - Jim
dpm@cs.cmu.edu (David Maynard) (06/06/90)
>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. The following (unofficial, unsupported, undesireable, etc...) patch to the X11R4 sample server has allowed me to display dxcalendar on the Sun (Sun-2 and Sun-3, SunOS 3.5). Since the patch adds another clause to the "bug-compatibility mode" of the sample server it could potentially allow programs to do bad or damaging things. I don't think that would be a problem in most cases, but as always, "let the buyer beware." My server is only up to fixlevel 9 so the diff may change with more recent fixes. As always, be sure to save the unpatched version so that later official patches don't break. I don't recommend diverging from the MIT sources, but if you insist... --- Begin patch --- *** mit/server/dix/events.c.save Tue Jun 5 14:04:02 1990 --- mit/server/dix/events.c Tue Jun 5 14:05:56 1990 *************** *** 2921,2927 **** client->errorValue = stuff->event.u.u.type; return BadValue; } ! if (stuff->eventMask & ~AllEventMasks) { client->errorValue = stuff->eventMask; return BadValue; --- 2921,2927 ---- client->errorValue = stuff->event.u.u.type; return BadValue; } ! if ((stuff->eventMask & ~AllEventMasks) && !permitOldBugs) { client->errorValue = stuff->eventMask; return BadValue; --- End patch --- --- David P. Maynard (dpm@cs.cmu.edu) Dept. of Electrical and Computer Engineering Carnegie Mellon University, Pittsburgh, PA 15213 --- Any opinions expressed are mine. I haven't asked the ECE department or CMU what they think. ---