Today's entry in the "Say what?!" Derby came when I was told that we were no longer linking to a particular third party library file (.LIB). LIB files are a wonderful little invention that tell the linker where to look for all of the functions that are defined in a DLL (DynLink Library) so that the linker can fix up your code and make sure that the calls you make to the DLL actually work. This is good for those of you who think that having your code work is a good thing. The LIB file is generated by the process that made the DLL, so as long as you pick up matching versions, everything should work.
The problem is that you can't always be sure that all of the DLLs that you might want to call are present on the machine that you're working on, especially when you're providing "optional" support for a particular function and don't have the right to distribute the third party DLL that you need to call. This is the situation that I was in when I wrote this particular interface about a decade ago. I solved it by producing a version of one of our DLLs that stubbed out all of the calls to the third party DLL. If you had the third party DLL, you could put the working version on your computer; if not, you could just install the version that had the stubbed-out calls and you'd get a message saying that the interface wasn't available. Clunky, but it worked.
Since that time, Microsoft introduced a nice feature for delayed loading of DLLs. This means that you can wait until run-time to determine whether a particular DLL that you've linked to is present. If it is, you can load it. If not, you get an error return and can provide a nice message to your user telling them to get their DLLs in order if they want to use the functionality that the missing DLL would provide. This is much nicer than the hack that I put in and I figured that eventually we'd get around to using it.
Nope. Not so much.
When I went to look at the code this morning to find out how we were operating without linking with the provided LIB file, I discovered that one of our other programmers had extracted all of the interesting information from the LIB file, placed it in a header file, and was using that to locate the functions in the third party DLL which he was now loading using LoadLibrary (which is a perfectly fine function call). So there is now a header file full of decorated function names and ordinals which could happily change from release to release and which we now have to maintain, because we are doing this instead of using the perfectly good LIB file that was supplied with the third party DLL.
I am confused by the purpose of this display of brute force programming prowess and have asked the manager in charge to please find out what the heck problem this approach was supposed to solve that delay loading of DLLs doesn't.
Because I would really like to know.
I might learn something.
