7. For UNIX gurus and fanatics only

If you have a history using Electric Fence in UNIX, you'll remember that the only thing required was linking with libefence.a. Why can't we do something like this under Win32 for HeapCheck, too?

1. Win32 ain't UNIX. I guess you knew that, but there's this little fact about libraries that makes them almost useless: if a library uses any function of the C run-time library (like memchr, strcpy, etc) it has to link with one of the six versions of the run-time library (RTL):
   • Release, static, no multithreading
   • Release, static, multithreading
   • Release, dynamic, multithreading
   • Debug, static, no multithreading
   • Debug, static, multithreading
   • Debug, dynamic, multithreading
   Now suppose that your library is linked with one of these RTLs. When you use your library inside one of your own projects, your project MUST be linked with the same RTL! Amazing. I don't know about you, but I prefer to just add two source files in the project and be done with it, instead of building six HeapCheck libraries. I could replace calls to the C run-time library with my own versions of things, but that would lead to the next problem:
2. If HeapCheck was a library with implementations of standard functions (malloc, realloc, etc) then the projects using it would have to choose between using HeapCheck and using the C runtime library. Unless I am doing something wrong, the linker can't tolerate two libraries providing implementations of the same function. How is he to choose? The UNIX ld implements a first-serve attitude: Whichever library provides it first in the link line, is chosen.