macphed@dvinci.usask.ca (Ian MacPhedran) (11/16/89)
Has anyone out there succeeded in porting the widgets distributed with the X11R3 tapes to VMS? (VMS version 5.1-1, unknown version of DECWindows.) I have seen previous postings which say that there should be no problem porting these over, but I have had no success. I was trying to port an application which used the Xaw (Athena) widgets (actually xdvi), but kept running into problems, the last of which was that I kept getting access violation errors when trying to create the first widget (a ViewPort). As the errors are occuring inside a routine in the VAX C runtime library, I couldn't really track them down. If you have SUCCEEDED in porting at least the Athena widgets (this implies that the Xmu library is also ported), could you please send me email, or post a follow-up to this message? Thanks in advance. Ian. (Ian MacPhedran, Engineering Computer Centre, University of Saskatchewan) (macphed@dvinci.USask.CA macphed@dvinci.UUCP macphedran@sask.BITNET)
taylort@decus.com.au (Trevor Taylor) (11/28/89)
In article <1989Nov16.065005.10644@dvinci.usask.ca>, macphed@dvinci.usask.ca (Ian MacPhedran) writes: > Has anyone out there succeeded in porting the widgets distributed with the > X11R3 tapes to VMS? (VMS version 5.1-1, unknown version of DECWindows.) > I have all the Athena widgets and Xmu routines working, but there are a couple of problems. The Form widget does not place its children correctly. (I think this is a problem with the DEC composite widget.) Xmu has a couple of funnies. However, the real test is that xedit works. As for getting them going, the main problem has to do with the way that global variables are declared in VAX-C. Using "extern" does not work. You need something like the following: 1. In the module which declares the variable: globaldef {"mywidgetclass"} noshare WidgetClass myWidgetClass; 2. In modules which reference it: globalref WidgetClass myWidgetClass; (Refer to the VAX-C manual for more information. If you don't get this right, you get access violations and/or errors about null widget class pointers.) Also, when compiling the widgets themselves, you need to avoid declaring these widget variables twice because both the private and public .H files reference them, one as an internal (1. above) and once as an external (2. above). You can get around this with a #define and a few #ifdef's. To make matters worse, some widget names, e.g. Label, conflict with the same widgets in the DECwindows toolkit. I have ported as much of the X11R3 tape as I could, and passed it back to DEC, and hence, I hope, to MIT. (The MIT clients are in the DECUS Library -- order number VS100, but this was before I started work on the Athena widgets.) All you Digits who may be listening, it is on node BUSHIE:: in the Customer Support Centre in Sydney. I think it is BUSHIE::IMAGE:[DEMO.ATHENA_X11...], but contact Rob O'Meley. If all goes well, you may see some #ifdef VMS code in X11R4. However, it may be too late. There is another problem though, and that is that my code uses a prefix of Xaw_ on all the widget names to distinguish them from the DEC ones. Last I heard, MIT did not intend to make these changes, although they have changed the prefix on all the routines from Xt to Xaw. Besides this, I modified R3, and have never seen R4 code, so it may not be easy to merge my changes into R4. Unfortunately, I have to leave that to DEC/MIT. From the DEC side, the problem I see is that the DEC Toolkit routines cannot be separated from the Intrinsics because they are both in the same shareable image. This may be necessary to get all the linkages right, but I think a little more work could have split them apart. Because the DEC Toolkit always "comes along for the ride", you may always have naming problems with other toolkits you try to use. Trevor Taylor