By “code packaging” I mean separating your code (on a high level) into manageable chunks (“components”) ready for (re)use. On Windows, this would generally be a DLL.

Windows was originally written in C (and to some extent now probably C++) so its packaging mechanisms are C based too. Unfortunately, this means that support for C++ had to be “bolted on” in some way, which resulted in a mess. Just think about it – should I export a class, or some of its methods? How should I export static members? How do I link with component of this particular library? Is this library static or is it import library (can’t guess by extension)? If I link dynamically, can I/should I link with another “component” of the same library statically? Where the hell are the boundaries?

I was reminded of all these questions while trying to build and link a 3rd party C++ library. One of the symbols just wasn’t exported properly. Even though I knew what was wrong, I was unable to fix the problem because the macros that control __declspec(dllimport) and/or __declspec(dllexport) were impossible to mentally unwrap.

Contrast this to Java/.NET packaging – from the very beginning, the packaging is well defined. The linking is always dynamic (at least for .NET, not sure for Java) which on a surface might seem too crude but in reality simplifies things – less choice is sometimes better (you can still do the ILMerge if you wish). The visibility of symbols is explicit both on the VM level and via keywords in each of the languages that compile into IL. “Linking” is always directly to the final DLL (there are no separate artifacts to use because all the metadata you need is directly in the final image).

While this is better from the standpoint of less hassle when designing libraries, there is one much bigger advantage here that is often overlooked – when packaging is complicated, we tend to avoid the issue altogether. Sometimes this leads into monolithic designs because separating/refactoring into “components” is difficult if for no other reason than packaging. When packaging is easy, this is a no-issue and leads into better designs for everyone: library designer and library consumer.

This has been one of the top few features of the .NET that I prefer over native/C++ development. Garbage collector is nice and some .NET/C# features like (asynchronous) delegates are cool, but packaging is the feature that saved me a lot of boring work while building my libraries, which left me more time to deal with real issues.