tbray@watsol.waterloo.edu (Tim Bray) (02/28/91)
Suppose I have a widget set called Xn. Suppose I need some general-purpose
initialization done. This is generally done by having a file called Vendor.c,
and in it declaring a global variable called
applicationShellWidgetClass
which is a complicated Xt structure containing, among other things, pointers
to several initialization routines.
Then, in XtAppInitialize, the following call gets my Xn code involved in the
initialization logic, and it all works hunky-dory...
root = XtAppCreateShell(NULL, application_class,
applicationShellWidgetClass,dpy, merged_args, num);
The the programmer builds her application, and eventually something like the
following happens:
cc -o app app.o -lXn -lXt -lX11
But wait! Suppose the widget set doesn't need any particular initialization,
and hasn't bothered to define the applicationShellWidgetClass global? No
problem, because libXt has its own Vendor.c, which has its own
applicationShellWidgetClass, which has pointers to some routines that do
something or other, and that'll get linked in if one hasn't already been
provided.
GENERAL CLAIM: this kind of dependence of on the semantics of the unix linker
is unclean, unportable, and downright icky.
SAMPLE PROBLEM: IBM's AIX on the RS/6000 supports shared libraries. Shared
libraries are a Good Thing; in fact with software as bloated as Xlib, Xt and
Xn, it verges on criminal negligence not to use them if they're there.
However, the shared-lib builder on AIX handily pre-resolves all the unresolved
pointers. So if you execute the cc command line above, and Xt has been built
shared, the applicationShellWidgetClass is already pointing at the Xt version,
and the first time you try to XtCreate an Xn widget, you go up ingloriously in
smoke. Am currently looking at various solutions involving different hacks
and kludges. And in the interim, running N applications that each carries its
own copy of Xt, Xn, and X11 around.
PROPOSED SOLUTION: We need two new function calls. Require an entry point in
each widget set with a nice standard name; in this case
void * XnGetApplicationShell();
(void *) because I think those are Xt data structures that application code
doesn't want to know about. If the widget set doesn't need to initialize, the
entry point just returns NULL. No args necessary, I think.
Then you have another call, a carbon copy of XtAppInitialize() with 1 more
argument, as follows:
Widget
XtAppInitializeW(app_context_return, application_class, options, num_options,
argc_in_out, argv_in_out, fallback_resources,
args_in, num_args_in, application_shell)
XtAppContext * app_context_return;
String application_class;
XrmOptionDescRec *options;
Cardinal num_options, *argc_in_out, num_args_in;
String *argv_in_out, * fallback_resources;
ArgList args_in;
void *application_shell;
Then, down its guts, it says:
if (application_shell)
root = XtAppCreateShell(NULL, application_class,
application_shell, dpy, merged_args, num);
else
root = XtAppCreateShell(NULL, application_class,
applicationShellWidgetClass, dpy, merged_args,
num);
If it isn't obvious, you use the return from XnGetApplicationShell() as the
last argument to XtAppInitializeW().
Of course, you'd want to have an analogous form of XtInitialize() and maybe
some of those other init calls.
Or am I missing some terribly obvious point?
Cheers, Tim Bray, University of Waterloodavid@jpl-devvax.JPL.NASA.GOV (David E. Smyth) (03/01/91)
tbray@watsol.waterloo.edu (Tim Bray) writes: > >GENERAL CLAIM: this kind of dependence of on the semantics of the unix linker >is unclean, unportable, and downright icky. > >SAMPLE PROBLEM: IBM's AIX on the RS/6000 supports shared libraries. I would say that AIX is not UNIX. Saying that you can't count on left to right evaluation of references by the linker is sort of like saying you can't count on the sequence of statements in C. Its not unportable and icky. It is the way its done. If AIX's shared library scheme works like this, you should submit a bug report to IBM, not to people who write UNIX software. ------------------------------------------------------------------------- David Smyth david@jpl-devvax.jpl.nasa.gov Senior Software Engineer, seismo!cit-vax!jpl-devvax!david X and Object Guru. (818)393-0983 Jet Propulsion Lab, M/S 230-103, 4800 Oak Grove Drive, Pasadena, CA 91109 --------------------------- Quote of the Day: --------------------------- "A Guru is not one who simply knows all the answers. Rather, a Guru is like one who walks among the mountains, and by wandering around abit, can see the horizon through long narrow canyons." -------------------------------------------------------------------------
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (03/06/91)
> ... However, the shared-lib builder on AIX handily pre-resolves all > the unresolved pointers. ... Then it's not a library at all! It is one monolithic package. It is not a group of optionally disassociable modules. Entirely too many operating system vendors are doing this "handy" pre-resolution in their supposed shared libraries. They should all be given a good spanking by the ISV community. ----------------------------------------------------------------------- All relevant disclaimers apply. And in this case the one that reads "I am NOT speaking for my company." Should be emphasized as being particularly applicable. ----------------------------------------------------------------------- Benjamin Ellsworth | ben@cv.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP 1000 N.E. Circle | (USA) (503) 750-4980 | FAX Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE -----------------------------------------------------------------------
ben@hpcvlx.cv.hp.com (Benjamin Ellsworth) (03/06/91)
>>SAMPLE PROBLEM: IBM's AIX on the RS/6000 supports shared libraries. > > I would say that AIX is not UNIX. ... So would I. Unfortunately *several* OS vendors disagree. ----------------------------------------------------------------------- All relevant disclaimers apply. And in this case the one that reads "I am NOT speaking for my company." Should be emphasized as being particularly applicable. ----------------------------------------------------------------------- Benjamin Ellsworth | ben@cv.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP 1000 N.E. Circle | (USA) (503) 750-4980 | FAX Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE -----------------------------------------------------------------------
tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) (03/06/91)
> Entirely too many operating system vendors are doing this "handy" > pre-resolution in their supposed shared libraries. They should all be > given a good spanking by the ISV community. The real crime isn't the "monolithic package" technology, it's that they misnamed the technology as "shared libraries"; I agree its very misleading. If one can live with the restrictions of monolithic packages however, there are some performance gains (X needs help there too). Its great for building operating systems, X Servers/drivers and such around. Of course, a true shared library implementation can still generate monolithic packages as desired by linking the little .o's Re: the flaw, another trick I've heard of is that some shared library/module implementations support a main() routine for the library (handy for C++ static constructors). When the library/module is loaded, the main() routine if there is one gets executed. I think the libXm/Xt/X problem can be hidden from the developer in this way. BTW - the lack of a true shared library technology on a vendors OS is not grounds for calling them non-UNIX. Expand on that, EVERY vendor I know of has some non-standard, never fully defined in UNIX, features. UNIX might be great, but its not the be-all do-all OS for all of man kind. Keeping an open mind can help UNIX progress even farther. ----------------------------------------------------------------------- Thomas Gilg | tomg@cv.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hpcvlx!tomg | UUCP 1000 N.E. Circle Blvd. | (USA) (503) 750-2756 | VOICE Corvallis, OR 97330 | (USA) (503) 750-3788 | FAX -----------------------------------------------------------------------
nazgul@alphalpha.com (Kee Hinckley) (03/08/91)
In article <100920307@hpcvlx.cv.hp.com> tomg@hpcvlx.cv.hp.com (Thomas J. Gilg) writes: >BTW - the lack of a true shared library technology on a vendors OS is not >grounds for calling them non-UNIX. Expand on that, EVERY vendor I know No, in fact I'd be more inclined to say that the *presence* of true shared libraries is grounds for calling them non-Unix. :-, -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
taylort@decus.com.au (Trevor Taylor) (03/10/91)
In article <1991Feb28.005057.24723@watdragon.waterloo.edu>, tbray@watsol.waterloo.edu (Tim Bray) writes: > Suppose I have a widget set called Xn. Suppose I need some general-purpose > initialization done. This is generally done by having a file called Vendor.c, > ... > ... > SAMPLE PROBLEM: IBM's AIX on the RS/6000 supports shared libraries. Shared > libraries are a Good Thing; in fact with software as bloated as Xlib, Xt and > Xn, it verges on criminal negligence not to use them if they're there. Let's ignore the arguments about AIX being non-UNIX. I have the same problem on VMS, which is most definitely non-UNIX, and the problem is with the Athena widgets -- yes, the very widget set which MIT distributes!!! > Or am I missing some terribly obvious point? No, you are not. I think it is a "bad" assumption on the part of the Intrinsics that Vendor.c can be replaced at will. We do need some form of pre-initialisation BEFORE XtInitialize(). In particular, the Athena widgets need to register some type converters. I posted a question on this to the net recently and got no response. In desperation, I mailed Chris Petersen, because his name appears in some of the Athena widgets. To quote part of his response: "Sounds like you are hosed ..." Maybe we could have a pre-initialization function in R5??? /*--------------------------------------------------------------------*/ /* Trevor Taylor E-Mail: TaylorT@decus.com.au */ /* P.O. Box 155 T.Taylor@praxa.com.au */ /* Aspley 4034 Phone: +(61) 7 369-8100 */ /* Australia Fax: +(61) 7 369-0722 */ /*--------------------------------------------------------------------*/