Static Versus Dynamic-Link Libraries

Programmers coming from other compiled languages are in for one more surprise. Often people associate compiled code with static libraries and self-contained EXE files, but if you think about it, there’s no particular requirement that a compiled language support static linking. Visual Basic version 5 is the proof. It doesn’t support static linking, and that means you can’t create one big EXE file containing everything in your whole program. If you thought compiled Visual Basic was going to take you back to the old MS-DOS days when you could just compile a program and hand off the EXE to customers without a setup program or support DLLs, think again. Visual Basic supports only the DLL model, and you’ll still need a setup program for your compiled programs.

There’s a trade-off between using dynamic-link libraries and static libraries. If you use dynamic-link libraries, all your customers’ programs share the same copy of the code. If you use static libraries, all your customers’ programs duplicate the same code. For example, there’s only one copy of the Windows API wsprintf function in USER32.DLL, but try to imagine how many copies of the binary code for the C printf function you might have duplicated in all the statically linked C programs on your disk. If your customers have lots of programs developed with the same language, it definitely pays to use DLLs. But if a customer has only one small program developed with the language, the customer ends up with a lot of wasted code in support DLLs. In some cases, you really want a single executable file even if it’s big and potentially redundant.

I could go on with more advantages and disadvantages. The point is that with many languages, you choose the trade-offs for a particular program. With Visual Basic, you don’t choose; it chooses. There’s no such thing as a stand-alone EXE. If you want to share your own code between programs, you can write an ActiveX DLL. There’s no option to put that code in a static library and share it at link time. I suspect that this limitation will prove unpopular and that some future version of Visual Basic will give you more choices.