Build and manage large-scale C++ on Windows

As a result, once we identify the libraries we want to be DLLs and static we can identify the point in the dependency graph when the static library is first used by a DLL. We can add the "exports" of the static library to the DLL's exports list by using the /EXPORT option when linking the DLL. Any other users of that static library can now use it via this DLL to avoid duplicate definitions in the configuration.

What to do when it goes wrong

In a large project there will be of course many areas of responsibility producing many different deliverables. Often, such deliverables are provided in both static and dynamic configurations so those that want to link statically can and those who want the dynamic version are equally facilitated. Of course there's always the day when you need to link with one essential component, which is only available as a DLL and worse, it uses some other component in mode dynamic. Of course, this other component is the very same other component that everything else in your build uses in mode static and it's not necessarily easy to change that.

A consequence of the name decoration caused by exporting a symbol in Windows is that the binary name of a symbol coming from a DLL will be different that the name of the same symbol in a static library. OK, no big deal, one component uses the DLL version and the rest of the build configuration uses the static version. This should work, provided there is no data of static duration in the picture for the reasons we've already seen.

So what if there is some static data, what can be done to initialize it? Well if the data is initialized by a C function this isn't that hard. We can add code to our application to call LoadLibrary with the name of the DLL containing the static data. As the DLL is already loaded into the process we'll get a handle to this already loaded DLL. We then call GetProcAddress using this handle and the name of our function, casting the resulting function pointer appropriately and all is good again.

It's not always so easy though, as sometimes people will use constructors to initialize static data. It is possible to call a constructor in a DLL transitive dependency. It involves allocating memory with malloc, writing assembler to prepare the stack frame manually and calling the constructor as if it was a C function. This is unlikely to win awards for portable code though.

Navigate the differences

There are complexities specific to Windows DLLs especially when used with static libraries that contain data. As a consequence managing a large-scale project on Windows brings some additional considerations which should be thought about if supporting Windows in addition to Unix platforms is an issue. Even if the eventual product isn't cross platform, this issues can cause headaches if development and testing is supported on Windows, because some developers prefer tools on that platform.

In general, though, even with the additional complexity there's always a way to navigate the differences in the dynamic-linking model and I've yet to see a case of "we cant get that to run on Windows" that wasn't solvable.®