khampton
asked on
ATL and MFC support
I'm new to ATL programming so kindly bare with my ignorance, please...
I've written an ATL COM .dll that populates a recordset and returns it to a VB Caller. Everything works great.
I followed a couple of examples and used the Wizard to build this .dll. When I compile it (with MFC support), the resulting .dll is about 45k long.
If I go to setting and specify No MFC support and complile it, I get a couple of warnings:
INK : warning LNK4089: all references to "SHELL32.dll" discarded by /OPT:REF
LINK : warning LNK4089: all references to "comdlg32.dll" discarded by /OPT:REF
The .dll still works as expected but the resulting .dll grows to approx. 128K long (I am expecting a smaller .dll not a larger one!)
Ok, so if I am trying to produce the lightest weight .dll, which way do I go - MFC support or not. (Or perhaps you have a different suggestion).
Thanks in advance for your assistance!
I've written an ATL COM .dll that populates a recordset and returns it to a VB Caller. Everything works great.
I followed a couple of examples and used the Wizard to build this .dll. When I compile it (with MFC support), the resulting .dll is about 45k long.
If I go to setting and specify No MFC support and complile it, I get a couple of warnings:
INK : warning LNK4089: all references to "SHELL32.dll" discarded by /OPT:REF
LINK : warning LNK4089: all references to "comdlg32.dll" discarded by /OPT:REF
The .dll still works as expected but the resulting .dll grows to approx. 128K long (I am expecting a smaller .dll not a larger one!)
Ok, so if I am trying to produce the lightest weight .dll, which way do I go - MFC support or not. (Or perhaps you have a different suggestion).
Thanks in advance for your assistance!
ASKER
That's what I thought. But my real question is why did the dll size grow from 45k to 128K. AND how do I get the lightest weight .dll? (ie: since including MFC support results in a smaller .dll, is it really lighter weight OR will I actually be having to download the MFC with it if I use it over the Web for instance?)
hi khampton,
Whats happening is this...
When your dll is built using MFC support, you are linking in to the resident MFC dll at runtime to access the code for some calls.
This requires the big ugly MFC dll to be loaded.
If you search in your windows or winnt directory for mfc*.dll you will find it lurking there. its about 1 meg.
When you build without MFC support you are telling the compiler that the MFC*.dll file will not be present when the dll is used, so the compiler includes the code previously linked into the MFC dll in your dll.
Thats why it's bigger.
The previous answerer was not quite correct. The warnings are informing you that the linker no longer requires the references as the code is now built into your dll.
What this all means is:
If youre going to ship without the MFC dll and you want to build TRULY lightweight components you have to make your gui stuff either use API calls, or use something like atlcontrols.h or the windows template library.
best of luck with your ATL programming,
Robert.
Whats happening is this...
When your dll is built using MFC support, you are linking in to the resident MFC dll at runtime to access the code for some calls.
This requires the big ugly MFC dll to be loaded.
If you search in your windows or winnt directory for mfc*.dll you will find it lurking there. its about 1 meg.
When you build without MFC support you are telling the compiler that the MFC*.dll file will not be present when the dll is used, so the compiler includes the code previously linked into the MFC dll in your dll.
Thats why it's bigger.
The previous answerer was not quite correct. The warnings are informing you that the linker no longer requires the references as the code is now built into your dll.
What this all means is:
If youre going to ship without the MFC dll and you want to build TRULY lightweight components you have to make your gui stuff either use API calls, or use something like atlcontrols.h or the windows template library.
best of luck with your ATL programming,
Robert.
ASKER
Ok, even after the RobertMitchell response, I'm still a little fuzzy --
Am I lighter weight by not including MFC support? My guess is that I am because I'm using only what I need and compiling it into my component RATHER that dynamically calling MFC runtime routines that may be the wrong version on the user's machine.
Also, since I built this ATL .dll from the wizard, I thought I WAS using the Windows Template Library. Right?
Am I lighter weight by not including MFC support? My guess is that I am because I'm using only what I need and compiling it into my component RATHER that dynamically calling MFC runtime routines that may be the wrong version on the user's machine.
Also, since I built this ATL .dll from the wizard, I thought I WAS using the Windows Template Library. Right?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
It's not an error, just the linker doing what you told it to do, that is remove all unused library code, and telling you that you specified unneeded library files.
In most cases, you'll just want to ignore this.