Date: Tue, 22 Apr 1997 13:58:15 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: rssh@cki.ipri.kiev.ua, msmith@atrad.adelaide.edu.au, freebsd-hackers@FreeBSD.org Subject: Re: Dynamic linking libraries [Q] Message-ID: <199704222058.NAA27156@phaeton.artisoft.com> In-Reply-To: <199704221742.DAA16750@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Apr 23, 97 03:12:29 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > i.e. you want describing of major differences between .dll and .so > > models, wich important for me ? > > So: > > > > 1. let we have program a.out , that use library libb.so > > when I start new a.out, each time new copy libb.so linking with > > a.out during execution of it. > > All static variables in libb.so are unique for each copy of a.out. > > (on this based, for example, strtoken) > > in .dll model, one example of code is shared between multiple > > versions of a.out > > Er, I'm not sure I follow the difference here. In each invocation of > an exectuable using a shared library, statics are common, yes. I > don't understand the second part though; with shared libraries, one > copy of the code is also used, regardless of how many processes are > using the library. > > If you are referring to interprocess communication using static > variables in a DLL, I think people here might be very ill. 8) I believe what he is referring to is that the MS executables put the library-specific data segment into the DLL rather than statically linking it with the program, as BSD does. For library private data, this is a mjor win, since it divorces the private data as an "interface" which must be the same from revision to revision. It also allows multiple "libraries" to provide the same interfaces, and allows them to be used interchangeably. In addition, fi you define an interface which supports agregation, you can use multiple objects as if they were a single object (for instance, say you wanted to implement PAM components which contained static local data and you wanted them to work with FreeBSD, but didn't want to specify which modules were available at the time you implemented your consumer code -- or if you wanted to implement an encapsulation layer for aton, addr, network, ntoa, makeaddr, lnaof, and netof functions that didn't care if they were iso, xns, ipx, netbios, or inet providers packing the functions -- etc.). The biggest example in FreeBSD's sordid static data history is the change in the handling of sys_errlist[], which might have been entirely opaque between libc.so revisions, assuing the program itself did not reference it (a bogus thing for a program to do anyway). If that were the case, a program which pulled the data in from the shared library instead of pulling it into the program image at link time would have continued to function. Instead, the entire FreeBSD world blew up. For a less drastic change, consider the increase of the size of an internal static buffer in a shared library and referenced only by the code in the shared library. In the FreeBSD method, the new library will reference the old (small) buffer when a new program attempts to use it. As a result, the program will fail to work, even though the defined interface for the library has not been changed. I believe FreeBSD had one of these (regarding tmpfile or tmpname) in its past, as well). Another feature of the Windows model is that there are routines for "process attach" and "thread attach" as part of the library definition, wherein the local data is instantiated (in shared heap and in thread local storage, respectrively). This is handled through the vtable method IDispatch, which is sent "events" by the "LoadLibrary" and "FreeLibrary" and "FreeLibraryAndExitThread" functions. The windows DLL's also have the ability to access the vtable as an OCX or ATL object; this defines the additional methods "IUnknown" and "IClassFactory" (encapsulating the library relationship via the "CoCreateInstance" and class "delete"). If the original poster is working on porting COM components to FreeBSD, then he will need to either modify the gcc vtable mechanism himself, or getsomeone else to do it, and he will *probably* need to move to COFF or ELF object modules, as opposed to a.out to make things work. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704222058.NAA27156>