Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!cs.mu.OZ.AU!cs.mu.oz.au!kre From: kre@cs.mu.oz.au (Robert Elz) Newsgroups: comp.windows.x Subject: Re: Making (Sun) Shared Libraries of Widgets Message-ID: Date: 3 Jun 91 16:45:02 GMT References: <9105271934.AA23188@expire.lcs.mit.edu> Sender: news@cs.mu.OZ.AU Organization: Comp Sci, University of Melbourne, Australia Lines: 33 samborn@sunrise.com (Kevin Samborn) writes: >Last, if you are just supposed to put a pointer in the .sa part, how >is that supposed to look? Just like this?: > extern WidgetClass myWidgetClassPointer; Definitely not that - only initialised data goes in the .sa file. I think I see Bob's point now ... anything in the .sa file is (effectively) part of the application, not part of the library for these purposes, so any data that anything in the .sa file refers to should (ideally) go in the .sa file too. Clearly that means that if a pointer to a Widget Class is there, the Widget Class should be too - which means its initialised value will be compiled into applications, and can't be changed later in the shared library. What's more, the class struct refers to procedures in the libraries, so they can't really be static, which they otherwise could. I'd like to actually try some variations sometime - but I think I might just wait till R5 now. I suspect that the eventual conclusion might be to put stuff in the sa file is you're largely an X user, rather than a developer - ie: if you're rarely (if ever) going to actually change any of the widgets - and if one is changed in a "bad" way you would be willing to relink everything that uses it (ie: losing much of the benefit of shared libraries). If you're a developer, you're probably better off lumping everything in the .so file, and suffering the preformance losses. kre