Note: This website is archived. For up-to-date information about D projects and development, please visit

Frequently Asked Questions

Q. What's the big deal, and why go through all the trouble?

A. In the D langauge, as well as for compiled languages in general, there is an open niche for process managed, gc friendly, runtime dynamic loading and linking. DDL fills that niche and brings along with it a whole host of useful properties that native solutions (.dll/.so files) simply cannot provide.

Q. Why not just use .dll/.so files instead?

A. While these two vernerable, and proven, means of binding code and data at runtime, they fall far short of what DDL can provide. DDL goes beyond what your operating system can already do for you:

  • It works with binaries that are produced via typical compilers available now, without the need for additional tools. Depending on how you code in D, these may even prove to be operating system independent.
  • DDL works where D works, on all its supported operating systems and platforms with the same behavior.
  • 100% of DDL's data is managed via D's runtime garbage collector, which is something that the standard loading scheme of windows or linux does not provide.
  • Works around problems with having multiple class-trees, garbage collectors and platform library code in your program during runtime (typical of .dll files and D).
  • Basic runtime reflection.
  • .dll files cannot import dependencies from the host .exe that loads it (without some rather nasty hacks anyway). DDL works completely around this by providing an alternate transport for runtime linking.
  • Has an arbitrary metadata facility for .ddl files, a custom set of utils, and is 100% BSD licensed.

If you don't need any of the above properties, then you probably should use .dll/.so files instead.

Q. Can .dll/.so files do things that DDL cannot? What about fan-in?

A. There are some things that the operating system's dynamic formats can do that DDL cannot.

Fan-in (static data in a library, shared between processes across the whole OS) is one such thing as DDL is not a kernel module. However, DDL can be leveraged to this effect with some effort, its just not provided as a part of the standard kit (read: this would be strictly DIY).

Also, as a rule, DDL does not hold the binary file's handle when it is in use. This is the exact opposite of the behavior that Windows exibits with .dll files, and is done largely to ease development as well as provide better crash recovery (ie. your .dll doesn't remain permanently locked).

In general, DDL is not engineered to prevent (nor care) if more than one copy of a given module is loaded more than once into one or more processes. While this is contrary to the behavior of .dll/.so files, it can be used to good effect as it opens up all sorts of new possibilities that were not available before.

Q. What are the performance tradeoffs of runtime linking versus static linking

A. In general, dynamic linking costs you additional time during the execution of your program, whereas static linking does not. In exchange you get a very nimble architecture that can bind code to your application just when you need it. In terms of your day-to-day software practices, this almost always benefits plugin oriented and highly configurable applications.

Purely statically linked programs, by definition, do not incorporate additional code at runtime, so they are fixed in their capability. They are also more stable than dynamically linked programs, as there is simply less to keep track of: can't fail due to missing files/libraries because there are none.

Q. Does DDL handle versioning?

A. DDL supports its own binary wrapper format (.ddl) that comes complete with a metadata facility. One can add a key/value pair to the file's metadata that flags its version, so that the correct version can be determined at runtime.

Q. My DDL-based program doesn't work - help!

A. Usually, the most frequent mistake is not creating an in situ module, and loading it into the linker prior to loading your other libraries. The second most frequent, is not updating your in situ module to use the current program after a compile.

If these two don't apply, then check out the forums for information and help. The community, and contributors, will likely be around to answer any questions you may have.