Build in C++.net
I wrote a simple application that display a image using C++.net I didn''t use MFC and had define #WIN32_LEAN_AND_MEAN.
But my release build file size was about 1.44M, I see no reason to have such a big file size for my application. Does anyone know what Complier option I may have set wrongly to general such large file ?
following Lib was found in Linker command-line
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib ddraw.lib dxguid.lib D3d8.LIB D3dx8.lib
I don''t know what''s different about VC++.net as opposed to VC++6, but in VC++6 making sure you have it set to "Release" as opposed to "Debug" cuts down the file size fairly significantly...
Did you do that?
Did you do that?
Several things may be the result.
1) Make sure you're actually compiling to a pure executable and not the generic .NET type executable VS.NET can make (not exactly sure how I can explain this clearly).
2) Start an empty project, and not try not to use precompiled headers. (like stdfx.h, or something like this). Not sure why that would make a difference.
3) Include fewer libraries, and only use what you definately need.
4) Don't include the texture as a resource in the executable. That's my guess at why its happening.
I have a program which displays a texture and a fair bit more (runs off a script).
Program: 72kb
Script: 432 bytes (4kb used)
BMP's: 56kb
linked libs:
d3d8.lib winmm.lib dxguid.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
Compiler settings:
/nologo /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /Fp"Release/test.pch" /YX /Fo"Release/" /Fd"Release/" /FD /c
[edited by - Nytegard on August 16, 2002 1:05:24 AM]
1) Make sure you're actually compiling to a pure executable and not the generic .NET type executable VS.NET can make (not exactly sure how I can explain this clearly).
2) Start an empty project, and not try not to use precompiled headers. (like stdfx.h, or something like this). Not sure why that would make a difference.
3) Include fewer libraries, and only use what you definately need.
4) Don't include the texture as a resource in the executable. That's my guess at why its happening.
I have a program which displays a texture and a fair bit more (runs off a script).
Program: 72kb
Script: 432 bytes (4kb used)
BMP's: 56kb
linked libs:
d3d8.lib winmm.lib dxguid.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
Compiler settings:
/nologo /ML /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /Fp"Release/test.pch" /YX /Fo"Release/" /Fd"Release/" /FD /c
[edited by - Nytegard on August 16, 2002 1:05:24 AM]
quote:Original post by Nytegard
1) Make sure you''re actually compiling to a pure executable and not the generic .NET type executable VS.NET can make (not exactly sure how I can explain this clearly).
Actually, a comparable .NET exe would be far smaller than this.
Did you try turning off managed C++? Then if on release build open the properties for the soulotion and then go under C++/Optimizations and change to favor small code.
Actually, a managed C++ application is tiny compared to a similar non-managed one.
My guess would be that your image is a resource in the executable, right? That''s why it''s so big, the image is probably stored uncompressed...
Also, defining
My guess would be that your image is a resource in the executable, right? That''s why it''s so big, the image is probably stored uncompressed...
Also, defining
WIN32_LEAN_AND_MEAN
won''t do much in the way in decreasing your executable size (at least, not that much). The main reason for it is decreasing compile times. If I had my way, I''d have all of you shot!
codeka.com - Just click it.This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement