[danengel]

Hi,

My application needs to load libraries at runtime. It is an interpreter in which I'd like to allow commands like 'use libXXX' after which the functions in 'libXXX' can be used. I've read several manpages and PDFs but the only thing I've found is 'rld' which seems to solve my problem. The bad thing is that the necessary file 'rld.h' isn't around.

If you have any experience with this topic or know any place where I can find more information, this would be a great help for me.

-- Daniel

[Angus_D]

The standard UN*X way of doing this is via the dlopen() API, I think, but OS X doesn't have this so you need to deal with mach objects directly. Fortunately, Chrisoph Pfisterer has wrapped up the mach api into dlcompat, which you can find at http://fink.sourceforge.net

I hope I've understood your question correctly, though.

[danengel]

Thank you Angus_D for your help. Do you know why Apple doesn't support for the API you mentioned?

[aleph_null]

Shot in the dark: it sounds like the sort of thing for which you'd use some of the CFBundle APIs. They allow run-time, explicit loading of libraries and their symbols, though at maybe at a higher level than what you're looking for. (As in, I guess your libs would have to be packaged as bundles to access them with CFBundle.)

Eh, I probably mis-understood your question, or don't know enough to be useful...sorry.

[PerfectlyNormalBeast]

Oh my god. Please use CFBundle. I've loaded code dynmically on countless platforms and CFBundle is the ferrari of dynamic code architectures.

[danengel]

Hm, I read Apple's sample code about CFBundle and it seems like too much overhead. All I want is to include some of the libraries in /usr/lib, and if I had to build frameworks around them that would be far to complicated. Also I want to keep codesize and memory usage as small as possible. But why do you call it 'the Ferrari', what are its advantages?

[PerfectlyNormalBeast]

Well, I might have overreacted considering your context. The CFBundle API is, for very simple things, not much easier to use than unix dyld or Windows dlls. CFBundle attacks the problem that anyone familiar with large projects made up of multiple code modules is intimate with: versioning. One of the main reasons Windows sucks is that rouge apps continuously replace new dlls with old ones, and even properly written software doesn't know the difference.

Mac OS X attemps to solve this problem using bundles. First a bundle can contain two versions of the same code. Perhaps a 2.0 and a 1.5 in the same bundle. Apps that were written for 1.5 will still work, and apps that were written for 2.0 will work even better. The user sees only one file with a friendly icon.

Secondly, when you are looking for a certain bundle, CFBundle makes that search much simpler. Bundles can be nestled within bundles. OmniWeb for example contains many pieces of code within its bundle, each in bundle form. But OS X may or may not use them. OmniWeb can specify whether it must always use its internal bundles, or whether OS X should search for new ones. The effect of this is: When OmniWeb starts and asks for frameworks X, OS X first looks in the OmniWeb bundle for the proper frameworks. Then it looks in all the other apps on the machine. Then it looks in the frameworks directory in the user library, the root library and the system library. It keeps a cheat note about the location of frameworks so this isn't quite as slow as it sounds. (It's not exactly peppy though.) It picks the newest bundle that OmniWeb should be compatible with. This all happens transparently to the app developer. The other nice thing about nestled bundles is that it makes one file apps possible again, greatly simplifing installation.

Lastly, bundles can contain localized resources that work flawlessly with OS X's localization manager. With a single compiled .dyld, this is nearly impossible to do.

COM and CORBA attempt to solve the versioning problem in different ways. I won't go into the merits of each here, but they do so at the expense of complexity. IMO, CFBundle doesn't.

I highly recommend checking out Apple's PDF "Mac OS X: System Overview." It's got lots of neat info on the capabilities of dynamic code in OS X. It's not a programming reference though. You can find it on the Apple developer site.

[danengel]

Thank you, PerfectlyNormalBeast (why did you chose that name?), for your long explanation about dynamic libraries. Now I even know one more reason why Windoze sucks .
The CFBundle solution sounds very handy, I'll check the PDF you mentioned out and report how it (hopefully) worked.