Front Page

Introduction

Derelict is a collection of D bindings to C shared (dynamic) libraries which are useful for multimedia applications, with a heavy bias toward libraries commonly used in game development. Derelict currently includes bindings for the following libraries:

Over the past few years, D bindings for some of the above libraries have been created as part of other projects. One thing all of the existing bindings had in common was that they required users to statically link to import libraries. None of the bindings were designed to allow a user to manually load libraries via an operating system API (such as LoadLibrary/GetProcAddress on Windows, or libdl on Linux and Mac). Linking to a shared library's static import library is not a bad thing, but having the option to load a shared library manually allows the developer a great deal more flexibility - particularly when things go wrong.

Static Import Issues

One issue with static import libraries is that of the object format used. If the D linker on your platform does not support a particular object format for a library you wish to link with, then you need to go through the step of converting the library to the proper format, or, if the library's source is available, compile the library with a compiler that outputs the proper object format (currently, this is only an issue on Windows when using the DMD tools). This is only a minor annoyance that can usually be handled once and forgotten about until you upgrade to a new version of a library. But, there is a more serious issue with static import libraries in that they lack flexibility and robustness.

When an application is linked with a static import library, the shared library from which the import library derives will be loaded automatically at application startup. If the shared library is missing or corrupt, then the application will fail to load and the operating system will display an error message to the user. This could also occur if the only version of a shared library available on the user's system is older than the version of the static import library. The error message displayed may not be very user-friendly. Some users who do not understand the concepts behind the error message could become frustrated with you, the developer, and may even view you as unprofessional. When it comes to software, there is no such thing as one-size-fits-all. A large company like Adobe, or someone making free software, may not find such errors a concern. A solo game developer attempting to sell casual games online may find such errors costly. For that developer, having the option to avoid such errors is ideal.

Derelict's Solution

Derelict solves both potential problems by eliminating the requirement of a static import library. Instead, Derelict handles the loading of shared libraries manually after the application has already started. This gives a great amount of flexibility to the application developer. Object file formats are irrelevant, as the application will be linked to a D library rather than a C library. The case of missing or corrupt shared libraries can be handled gracefully in an application specific manner. For example, the application could display an error message that details how to solve the problem, or where to go for technical support. But the benefits don't stop there.

With Derelict, shared libraries can be loaded and unloaded at will. When you consider that each shared library, when loaded, consumes system resources, then you might find it beneficial to only load the library when it is needed and not before. Some applications could also benefit from a hot-swap system. For example, a game might have a generic audio interface with implementations for both OpenAL and SDL_mixer, and provide a means for players to switch between the two at runtime. Derelict makes implementing such a feature a snap.

Special Features

Derelict goes one step further and allows selective loading of shared library symbols. This gives you the freedom to do things like falling back to older versions of a shared library when a current version is not available. For example, if a particular Derelict package is setup to load version 2 of a shared library, but your application does not use any exported functions or variables that are specific to version 2, then you can use selective symbol loading to allow version 1 of the shared library to be loaded if version 2 fails to load.

While some of the functionality that Derelict provides is baked into the process of manually loading libraries, other features (such as selective symbol exceptions) are provided through the DerelictUtil package. As a side effect, all Derelict packages have an implicit dependency upon DerelictUtil. This means that when compiling any individual packages, DerelictUtil must be available on the import path, and when linking, DerelictUtil must be linked into the application. See the DerelictUtil documentation for more details.

The Future

Derelict has grown quite a bit since its humble beginnnings as OpenGL and SDL bindings created by one guy as a hobby project. Users have contributed a number of packages, bugfixes and improvements over the project's lifetime. The build system has been overhauled twice. The internal loading system has been rewritten twice. Other packages are waiting in the wings to be added somewhere down the road. Most importantly, the user community has continued to grow.

More users also means more demand for new Derelict packages. Rather than adding just any old binding to Derelict, there must be some guidelines in place to keep things under control. The following (loose) criteria are used to determine the fitness of bindings to any given library for inclusion in the Derelict trunk:

If "yes" can be answered to all of the above questions for any given library, its chances for inclusion into Derelict are high. While the given criteria are not etched in stone and anything is possible, you can be certain that no library licensed under the GPL will ever make it into Derelict. Keeping Derelict free of viral licenses like the GPL allows users to make their own decision about whether or not to open their source, rather than being forced to do so.

If a particular library you want to use is not currently in Derelict, you can feel free to make a Derelictified binding for the library and request on the Derelict forums that it be included. Even if your work is not officially added to the trunk, you are still free to use it yourself or even distribute it as a separate package from your own website. Read Aldacron's Guide to Derelictification for instructions on how to create your own Derelict packages.

Dependencies

On Windows, Derelict has no external dependencies for compilation other than the Win32 API libraries which are linked in automatically. However, on Unix-like platforms (such as Linux and Mac) there is a dependency upon libdl. Therefore, any time you compile Derelict application on such a platform you must link with libdl. Failure to do so will result in linker errors.

Internally, every Derelict package depends upon DerelictUtil. Some packages have other internal dependencies as well (for example, DerelictGLU depends upon DerelictGL). Dependent packages must be on the import path when you compile the Derelict libraries (an optional step) and when compiling Derelict applications. Additionally, dependencies must be linked or compiled with Derelict applications. More details can be found in the documentation below.

The Docs

The documents linked in the first section below give a general overview of Derelict, explaining functionality common to all Derelict packages. The documents linked in the second section give details on building and using specific packages.

General Documentation

Package Documentation