1.3.5 Why not use framework bundles?

Framework bundles are much more difficult to port and to use, and are very unnatural on a UNIX system; extremely unnatural on Windows. In a framework bundle, the shared dynamic library is inside a framework wrapper directory. Because of this, the dynamic linker can’t find it.

We have frameworks, so how do we work around that? Well, we build dynamic links from a directory inside the dynamic linker path into the framework, which work, but then you can’t move the framework anywhere else on the system, otherwise you break the link, and nothing will find the framework any longer!

On systems without dynamic links, like Windows, we can’t even do this! We have to copy the library from the framework into the dynamic linker path, but that is simply a shared library then! Absolutely no difference. You put the dynamic library in a system directory in the dynamic linker path, and associate with that library a resource directory.

OpenStep for Windows did that, and still called them frameworks. So we can do the same, and call our libraries frameworks.

In a shared library, the shared dynamic library is in a directory which is in the path to the dynamic linker. the dynamic linker can find it very easily. this is how all shared and static libraries work on UNIX systems, Windows systems and possibly most system at all.

Moreover, the OpenStep API requires us to provide some stuff for frameworks, like creating and registering automatically a framework object each time a framework is used (linked at runtime, or linked into the app), and attaching to it the list of classes inside the framework - which are not particularly trivial to implement — they depend on playing with the linker and the object file format — and might produce troubles when porting. And we never use these facilities.

For Apple Mac OS X sure it’s easier. They can modify the system linker, compiler, the system dynamical linker. They always know on which platform they are working (their own), etc. They can modify the system to support frameworks natively. Easy that way.

But GNUstep is meant to run on many different platforms, platforms which we don’t control (Windows, Sun Solaris, Darwin, GNU/Linux, UNIX system variants) and which have different linkers and do not support frameworks natively. On some systems it’s difficult to just load a bundle or compile a shared library!

So building the core libraries as ’libraries’ means that it’s much easier to port them, and it’s much more difficult to break them.

Sure, frameworks have a bundle of resources associated with it — but we can very easily associate a bundle of resource with a shared library, no reason why not. We are doing it.

So please note that GNUstep libraries are meant to be much similar to Mac OS X frameworks. They are composed of a shared library and associated with a bundle of resources. There is a difference in terminology, in where the resources are installed, and possibly a slight difference in the NSBundle API to get to the resource bundle (anyway, it’s a one line difference between Mac OS X and GNUstep, so it looks like very easy to #ifdef).

In other words, GNUstep libraries are meant to basically do the same as frameworks do on Mac OS X, but to be portable to very different platforms (such as Windows).