Why does my program instantly gain 9K when I include masm32.inc & masm32.lib ? Even when I don't actually call any of the functions. I don't recall this happening with the others I've used (ole32,shell32,etc.) And while we are on this subject, I just noticed that if you include masm32.inc & masm32.lib you also HAVE to include ole32 and shell32 because of the "browse for folder" function. (I did not notice it earlier since I was already using SHBrowseForFolder API). And just one more :) usually if I have included a lib that I don't need, the linker optimizes it out. This did not happen with the masm32.lib Edited to include more ranting :) This message was edited by anon, on 3/30/2001 3:11:35 PM
I've noticed some similar things, but havn't got it to anything repeatable, definative yet. including an unreferenced lib shouldn't add anything, but it does seem in some cases 'things' get added anyway. masm32.lib isn't the only offender here, but I've yet to have the time to do any research into what does it, why it does it, or how to prevent IT.
anon, It sounds like an interesting phenomenon, I just don't get the problem at all. It is different to the IMPORT libraries in that it is a static library with code in it, not just the import addresses as most of the API function libraries have. When I write library modules, I write them in an APP first to get it going then convert it to a library module and rebuild it to test if it works correctly and see what the size is. There is never any difference in size and many of the programs that use MASM32 library functions are smaller than the 9k that you get added to your apps. Show us what the include code look like from your APP and what ML and LINK options you are using. It sounds like an unusual problem. Regards, email@example.com PS: Just to add to this, a minimum template written in Prostart with all of the options turned off but including both MASM32.LIB & INC builds at 4096 bytes in size. It uses one proc from the MASM32 lib so this is not the cause of the bloat that you are getting. Sounds like something is wrong with the way you are building the app. This message was edited by hutch--, on 3/30/2001 7:34:32 PM
OK, Now I feel really silly :) Here is how I normally compile my programs: C:\masm32\BIN\Ml.exe /coff MyProg.asm /link /SUBSYSTEM:WINDOWS MyProg.res But I found out what was causing the problem. I had the following in my "MyProg.inc" file: include \MASM32\INCLUDE\windows.inc include \MASM32\INCLUDE\masm32.inc <- Forgot to this one was here include \MASM32\INCLUDE\gdi32.inc include \MASM32\INCLUDE\user32.inc include \MASM32\INCLUDE\kernel32.inc include \MASM32\INCLUDE\Comctl32.inc include \MASM32\INCLUDE\comdlg32.inc include \MASM32\INCLUDE\ole32.inc include \MASM32\INCLUDE\shell32.inc include \MASM32\INCLUDE\masm32.inc <- Added this one when I needed the functions includelib \MASM32\LIB\gdi32.lib includelib \MASM32\LIB\user32.lib includelib \MASM32\LIB\kernel32.lib includelib \MASM32\LIB\Comctl32.lib includelib \MASM32\LIB\comdlg32.lib includelib \MASM32\LIB\ole32.lib includelib \MASM32\LIB\shell32.lib includelib \MASM32\LIB\masm32.lib If you do what I did above, and were not already using ole32 & shell32 then the linker would complain about unresolved externals required by bffolder.asm even though I was not using it. Very strange.
anon, Thanks for finding what the problem was, these things are very useful to know and it helps other people find similar problems. Regards, firstname.lastname@example.org