VS2010 - C++ EXE size reduction, how?

[Patrice Terrier]

The problem is that i am using <vector> <string> and a few others as well, requiring the Standard C++ Library that's really a big problem when you come from PB where everything is part of the EXE including the runtime.

[Mike Stefanik]

They're convenient for sure, but if size is a real issue for you, there's nothing that says that you have to use those standard templates in your code. If you want to take the time, you can implement your own dynamic string and array handling. And if size is really, really an issue then you just go with straight ANSI C and no C++ classes/templates whatsoever and your own trimmed-down C runtime library (e.g.: Tiny C Runtime Library). It all depends on how much work you want to throw into it.

[Patrice Terrier]

Mike--

What stress me much, is that even my new WinLIFT64.dll and GDImage64.dll seems to need this extra MSVCP100.dll, i was not prepared to that 

[Mike Stefanik]

As long as you're static linking to the runtime libraries, that shouldn't be the case. Have you checked your project settings? Project > Properties > Configuration Properties > C/C++ > Code Generation > Runtime Library

It should be set to Multi-threaded (/MT) for a release build and Multi-threaded Debug (/MTd) for a debug build for all your projects. If it's set to /MD or /MDd then you're using the shared CRT DLLs. You also need to make sure that any other libraries that you're statically linking to were not built using /MD (although if that's the case, you should be getting linker errors since you can't mix /MT and /MD compiled code together).

[Patrice Terrier]

Mike--

Both WinLIFT.dll and GDImage.dll are set to DLL multithread (/MD)

and my demo project HUDplus.exe using them, is set to Multithread (/MT)

[Mike Stefanik]

Every project should be set to /MT (or /MTd for debugging) and your redistribution issue is solved. There will be no external dependency on the C or C++ runtime libraries. You will note, however, that the size of your DLLs will increase as a result.

By the way, the reason that you can mix /MT while linking to your /MD compiled DLLs is because of just that, they're DLLs. Where you can't mix the two is when linking to multiple static libraries compiled in different modes; linking to an import library is a different sort of animal.

Edit: Just in case you were confused, the "DLL Multi-threaded" setting is not telling the compiler that you're creating a DLL. It's telling it that you want to dynamically link to the C/C++ runtimes (DLLs). Even for your own DLLs, you should be using /MT and not /MD to avoid having to redistribute the runtime DLLs.

[Kev Peel]

Try Dependency Walker to find out what the dependencies are.

You could also try creating another Win32 DLL project with a simple libmain() function in a single .C extension source file and check the output is not the same.

Also ensure you are looking at the correct output DLL - should be "release" configuration.

The runtime DLLs are definitely not required for every configuration!

[Brice Manuel]

Edit: Just in case you were confused, the "DLL Multi-threaded" setting is not telling the compiler that you're creating a DLL. It's telling it that you want to dynamically link to the C/C++ runtimes (DLLs). Even for your own DLLs, you should be using /MT and not /MD to avoid having to redistribute the runtime DLLs.

Thank you for this tip.

[Patrice Terrier]

Here is the final size result after applying the Multithread (/MT) switch.

            |   PB 9.05 | C++ 32-bit | C++ 64-bit |
GDImage.dll |    353 Kb |     334 Kb |     403 Kb |
            |           |            |            |
            |  PB 10.04 | C++ 32-bit | C++ 64-bit |
WinLIFT.dll |    217 Kb |     293 Kb |     341 Kb |

About PowerBASIC, using PB 10.04 instead of PB 9.05 to compile the same code, adds an extra 20 Kb to the resulting size.

The difference between the /MD and /MT switches adds an extra 90 Kb to my C++ code, not that much if i get free of the whole run-time.