RTL DLL's

[dbruceg]

In debug mode, linking with the single-thread dll debug library, I find it necessary to load 4 RTL DLLs for a total of about 7 meg. Two of those libraries are apparently multi-thread libraries, each about 3 meg. I find it difficult to believe that the processing of a dynamically-linked program requires that much overhead, so I suspect I'm doing something wrong. I also find it interesting that I can load the main program with a very few DLLs and it appears to run WITHOUT the RTL DLLs (or, at least, without the necessity of putting them on the path). What's going on here?

Bruce

[Steven_L_Intel1]

I tried a simple example and don't see the same results. I get LIBIFCORERTD.DLL (which loads LIBMMD.DLL) and MSVCR80D.DLL. I don't see any multithread DLLs. What are you seeing?

[dbruceg]

LIBIFCORERTD.DLL, LIBIFPORT.DLL, LIBMMD.DLL, andLIBMMDD.DLL. If these 4 aren't on the path, the loader whines until they are. I have never seen a request for MSVCR80D.DLL, but your testmight have calls I'm not using.

I think I misinterpreted something. I thought the last two were multi-thread libraries. From your comments, apparently they're not.

I presume the first two are IFCORE and IFPORT, included as DLLs rather than statically linked to knock down the sizes of the user DLLs. I further presume that the last two are the doodads that provide the dynamic link/load functions - maybe one containsdebug stuff. In any case, since you are not surprised at the appearance of the 3-meg LIBMMD.DLL, I guess that's the overhead price of dynamic link/load.

[Steven_L_Intel1]

LIBMMD/LIBMMDD is the math library in non-debug and debug form. I'm not entirely sure why you're getting both, but I'd suggest that you uncheck the box for the debug libraries as it doesn't really buy you anything unless you have C code in the application.

The thing with DLLs is that it's all or nothing in terms of loading. On the other hand, address space that is loaded but not referenced isn't that much of a burden.