I have translated a few of my WinLIFT/GDImage projects from PowerBASIC to VS2010 C++.
The resulting C++ EXE is more than 3.2 the size of the same PB EXE.
I have been playing with the C++ project optimisation settings, however i couldn't get something that could be significant to reduce the size.
Note : I am using the X86 platform with no MFC, and only native Win32 SDK calls.
Suggestion?
...
Patrice,
Have you done any benchmarking comparing the speed of execution between VS2010 C++ and PowerBasic (9.0 or later) ?
I posted a simple example on CodeProject ( http://www.codeproject.com/Lounge.aspx?msg=3728478#xx3728478xx (http://www.codeproject.com/Lounge.aspx?msg=3728478#xx3728478xx) )(the Lounge forum discussions) and I got replies from one person who used C# and it appeared significantly faster than PowerBasic.
I could not tell whether C# was doing some "tricks" to appear faster (ie. shortcuts). PowerBasic does not use any of the old "tricks" to appear fast simply for benchmarking.
I would be interested to see how well PowerBasic does with actual code execution speed.
You can make a comparison with the GDImage sprite Carousel demo project, that is available in C#, PowerBASIC, and WinDev (XP, VISTA/SEVEN).
And you can compare C++ and PB with the HUDplus project (VISTA/SEVEN aero).
All these projects can be downloaded from this forum.
I have the feeling than the C# carousel is faster than PB, but this is very subjective, and anyway the core GDImage graphic engine is the same, and it is written in... PB.
...
Patrice,
I would hazard a guess that the extra size is due to C++ string libraries. If this is the case then I think Frederick may have the answer - emulating Basic-style string functions.
With regard to speed, I would expect PB string management to be slower (flexibility tradeoff) than C++ but very little difference in Integers, Floats, and Function calls. There is not much scope for optimisation with these once you hit machine code bedrock.
Charles
Why should it be needed to make so much circumstances.
You take both systems as they ship. Write your code and compare size and speed.
In real life people choose the system they like most.
From how it looks, from SYNTAX.
From my standpoint the PB program is just more readable because its BASIC.
I can find and fix error much faster. I can use the comfortable string engine.
And i know its rock-stable. I can count on it when i need it!
My customers won't have surprising bugs in their software!
No need to sent updates all 4 weeks (unless with new features!)
If you look at the adverisement for VS there is no word about speed or size.
They talk about bussiness, Teamwork, Usability etc.
Thats what counts in the mass market.
Would you choose another compiler because it has a "nose more speed" in a loop-benchmark?
If it has roughly the same size (ok PB is even smaller!), and it roughly the same speed (its a bit faster this time!), then this is Ok.
In both systems you can go the one or other more complicated way to make smaller or faster things.
Thats available anywhere it depends on the programmer.
What counts is YOUR final choice.
Do you believe that other fathers have also beautiful daughters?
Do you want the slim one or the fat one ;D ? (Its your choice)
Is it ok, if she goes dancing sometimes and you have to cook?
Or you want one you can trust in any case?
It's your choice.
I decided for PowerBasic.
Please,
I didn't start this thread to compare the merits of each compiler.
I am asking for suggestions on how to further reduce the size of a VS EXE, as i am still a C++ novice, and i want to learn from those who are using themselves VISUAL STUDIO 2010 Professional.
...
Quote from: Patrice Terrier on February 08, 2011, 08:51:02 AM
Please,
I didn't start this thread to compare the merits of each compiler.
I am asking for suggestions on how to further reduce the size of a VS EXE, as i am still a C++ novice, and i want to learn from those who are using themselves VISUAL STUDIO 2010 Professional.
...
Hi Patrice
offhand there's not much I can tell you since you haven't provided enough information about the optimizations you are using. Some useful pointers to reducing size:
- don't use the heap manager (malloc, new, free and so on) but call Win32 memory functions (you mention you only use win32 calls so you should be good)
- don't use cout, printf, etc but again use Win32 equivalent (you mention you only use win32 calls so you should be good)
- don't use exception handling (well you should but we're talking about reducing size ;) - turn off exception handling
Make sure you're building a Release as opposed to a Debug build (I'm sure you known this - just mentioning for the sake of completeness).
Some useful switches:
/Og (general optimize) /Os (optimize size) /Oy (don't use frame pointers) - you can set these switches in the project settings or by using a pragma in your source code (for instance #pragma optimize("gsy", on) ). Additionally you can use merge optimization to merge the .rdata, .text and .reloc sections (need to look up the pragma for those).
There's more you can such as using small /ALIGN and FILEALIGN directives, etc.
Hope that's enough to get you started,
Cheers, Florent
The web seems to be rather thin on the subject but this article might also help.
(2008)
http://www.catch22.net/tuts/minexe
Charles
Here's a version of your Hudplus.exe demo VC++ executable optimized for size (attached). I had a look at Charles Pegge's link and the optimizations posted there look good - although I'm not sure about his ALIGN and FILEALIGN directives which may result in the loader not recognizing the file as a valid executable (YMMV) (not even sure if FILEALIGN is still supported). I wouldn't bother with the .reloc section on second thought because I don't think MSVC 10 will allow it :)
Florent
QuoteI didn't start this thread to compare the merits of each compiler.
I did not want to say that you did so, Patrice :D.
I just used the chance, to put focus of people on "what really influences the decision for a compiler".
Size and Speed were in the past most interesting.
It's still interesting for many if us, but majority of people just want "get quick from A to B".
And they want it to look "modern". (About this you are the right person to ask :-))
Florent--
The size of 26Kb is very good, however i couldn't get it to work by me.
Would it be possible for you to send me the whole project, to let me see what could be wrong with it.
Charles--
I'll check your link asap.
Thanks both of you.
...
Quote from: Patrice Terrier on February 08, 2011, 11:50:38 AM
Florent--
The size of 26Kb is very good, however i couldn't get it to work by me.
Would it be possible for you to send me the whole project, to let me see what could be wrong with it.
Charles--
I'll check your link asap.
Thanks both of you.
...
Hi Patrice
I can send you the project this evening - I don't have it on the machine I'm on at present. The EXE should just work provided all dependencies (dlls such as GDImage.dll, etc and resources - basically all DLLs, sks file and resource folders that are in your DEBUG folder are included in its path). I think that may be the problem you're having with the EXE not working - I take it it's just starting and then immediately closing?
Cheers, Florent
Here are a few things that helped me to reduce the size of the C++ HUDplus project EXE.
Using #pragma optimize("gsy", on) decrease the size from 92 Kb down to 87 Kb.
Replacing the C++ standard function sprintf with the SDK API wsprintf decrease the size from 87 Kb down to 76 Kb.
I shall try to replace more of C++ functions with their native Win32 counterparts and see how much i can further reduce the size.
...
Hi Patrice
here's the solution for reference, cheers, Florent
Florent
Does it work by you?
I mean, when you copy the Release 26 Kb EXE into the Debug folder (where there are the resources) do you see the skinned interface with the Naavi?
...
Quote from: Patrice Terrier on February 08, 2011, 10:23:54 PM
Florent
Does it work by you?
I mean, when you copy the Release 26 Kb EXE into the Debug folder (where there are the resources) do you see the skinned interface with the Naavi?
...
Hi Patrice
yes it works fine - I tested both yesterday on my Windows 7 PC - and I get the HUD, can load graphics, move and rotate the images... I downloaded the HUD demo project from your website and used the resources in that Debug folder - could it be that you are testing it with other versions of these resources/DLLs?
Cheers. Florent
Hi Patrice
one more thought - the project depends on external DLLs - do you have MSVCP100.dll and MSVCR100.dll (part of the redistributable C++ 2010 redistributable package) in your paths? What happens when you run the executable?
Cheers, Florent
Hi Patrice
here's a dependency profile log from running the hudplus EXE. Download depends.exe (http://www.dependencywalker.com) and compare the results on your system.
Cheers, Florent
Florent,
I run it on Seven 64-bit.
I shall check about MSVCP100.dll and MSVCR100.dll being into the path, but what i want, is to produce the smallest EXE with no external dependencies, except the standard Win32 OS DLLs.
...
Hi Patrice
I also run it on Win 7 64-bit :) It's failing because it can't find the redistributable C++ dependencies. Now here's where the tradeoff happens: either you keep the EXE size small and depend on external runtime or you statically link against those dependencies. Since the project already needs WinLift, GDImage, etc I 'm not sure what you mean with no external dependencies... There's no such thing as no dependency...
The problem is that MSVCRT.lib automatically references the MSVC*100.dlls in Visual Studio 2010 instead of linking against the system's default msvcrt.dll. The basic problem is you need to link against the Runtime library - either statically with the /MT flag (which naturally bumps the EXE size sizably upwards) or dynamically with the /MD flag. Using /MD however requires that the MSVC100 runtine redistributable be installed....
You can start by getting rid of all standard C++ library headers (such as ios, string, etc.) - a lot of work which in my opinion is not worth it - C++ programmers won't want to jump through hoops just to keep the size down. How about simply using static runtime linking (/MT) and then using a compressor to reduce the EXE size. Having your cake and eating it is a lot of work :)
Cheers, Florent
Florent,
Here is the dependency profile log from running your 26 Kb HUDplus.exe on my computer:
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
--------------------------------------------------------------------------------
Starting profile on 09/02/2011 at 08:43:56
Operating System: Microsoft Windows NT/2000/XP/2003/Vista based Home Premium (64-bit), version 6.01.7600
Program Executable: i:\solutions\hudplusc++\debug\HUDPLUS.EXE
Program Arguments:
Starting Directory: I:\Solutions\HUDplusC++\Debug\
Search Path: C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live;c:\Outils;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files (x86)\CyberLink\Power2Go;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Common Files\Acronis\SnapAPI\;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;D:\BCX\Bin;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files (x86)\IDM Computer Solutions\UltraEdit\;C:\Program Files (x86)\IDM Computer Solutions\UltraCompare\
Options Selected:
Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.
Log DllMain calls for process attach and process detach messages.
Hook the process to gather more detailed dependency information.
Log LoadLibrary function calls.
Log GetProcAddress function calls.
Log debug output messages.
Automatically open and profile child processes.
--------------------------------------------------------------------------------
Started "HUDPLUS.EXE" (process 0x118C) at address 0x002D0000. Successfully hooked module.
Loaded "NTDLL.DLL" at address 0x76F10000. Successfully hooked module.
Loaded "KERNEL32.DLL" at address 0x751B0000. Successfully hooked module.
Loaded "KERNELBASE.DLL" at address 0x760E0000. Successfully hooked module.
DllMain(0x760E0000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNELBASE.DLL" called.
DllMain(0x760E0000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNELBASE.DLL" returned 1 (0x1).
DllMain(0x751B0000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" called.
DllMain(0x751B0000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" returned 1 (0x1).
Injected "DEPENDS.DLL" at address 0x08370000.
DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" called.
DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" returned 1 (0x1).
Loaded "USER32.DLL" at address 0x76690000. Successfully hooked module.
Loaded "GDI32.DLL" at address 0x74B70000. Successfully hooked module.
Loaded "LPK.DLL" at address 0x76B00000. Successfully hooked module.
Loaded "USP10.DLL" at address 0x765F0000. Successfully hooked module.
Loaded "MSVCRT.DLL" at address 0x75340000. Successfully hooked module.
Loaded "ADVAPI32.DLL" at address 0x753F0000. Successfully hooked module.
Loaded "SECHOST.DLL" at address 0x74FF0000. Successfully hooked module.
Loaded "RPCRT4.DLL" at address 0x76130000. Successfully hooked module.
Loaded "SSPICLI.DLL" at address 0x74A80000. Successfully hooked module.
Loaded "CRYPTBASE.DLL" at address 0x74A70000. Successfully hooked module.
Loaded "SHELL32.DLL" at address 0x75490000. Successfully hooked module.
Loaded "SHLWAPI.DLL" at address 0x76790000. Successfully hooked module.
Loaded "MSVCP100.DLL" at address 0x743B0000. Successfully hooked module.
Loaded "MSVCR100.DLL" at address 0x6C2F0000. Successfully hooked module.
Entrypoint reached. All implicit modules have been loaded.
DllMain(0x75340000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "MSVCRT.DLL" called.
DllMain(0x75340000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "MSVCRT.DLL" returned 1 (0x1).
DllMain(0x765F0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "USP10.DLL" called.
LoadLibraryA("gdi32.dll") called from "USP10.DLL" at address 0x76606890.
LoadLibraryA("gdi32.dll") returned 0x74B70000.
GetProcAddress(0x74B70000 [GDI32.DLL], "GetCharABCWidthsI") called from "USP10.DLL" at address 0x766068C5 and returned 0x74B8AFF8.
DllMain(0x765F0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "USP10.DLL" returned 1 (0x1).
DllMain(0x76B00000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "LPK.DLL" called.
DllMain(0x76B00000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "LPK.DLL" returned 1 (0x1).
DllMain(0x74B70000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "GDI32.DLL" called.
DllMain(0x74B70000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "GDI32.DLL" returned 1 (0x1).
DllMain(0x74A70000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "CRYPTBASE.DLL" called.
DllMain(0x74A70000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "CRYPTBASE.DLL" returned 1 (0x1).
DllMain(0x74A80000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SSPICLI.DLL" called.
DllMain(0x74A80000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SSPICLI.DLL" returned 1 (0x1).
DllMain(0x76130000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "RPCRT4.DLL" called.
DllMain(0x76130000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "RPCRT4.DLL" returned 1981064961 (0x7614A701).
DllMain(0x74FF0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SECHOST.DLL" called.
DllMain(0x74FF0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SECHOST.DLL" returned 1 (0x1).
DllMain(0x753F0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "ADVAPI32.DLL" called.
DllMain(0x753F0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "ADVAPI32.DLL" returned 1 (0x1).
DllMain(0x76690000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "USER32.DLL" called.
LoadLibraryW("C:\Windows\system32\IMM32.DLL") called from "USER32.DLL" at address 0x766AC2B5.
Loaded "IMM32.DLL" at address 0x750D0000. Successfully hooked module.
Loaded "MSCTF.DLL" at address 0x74DD0000. Successfully hooked module.
DllMain(0x74DD0000, DLL_PROCESS_ATTACH, 0x00000000) in "MSCTF.DLL" called.
DllMain(0x74DD0000, DLL_PROCESS_ATTACH, 0x00000000) in "MSCTF.DLL" returned 1 (0x1).
DllMain(0x750D0000, DLL_PROCESS_ATTACH, 0x00000000) in "IMM32.DLL" called.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmWINNLSEnableIME") called from "USER32.DLL" at address 0x766AB776 and returned 0x750EF637.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmWINNLSGetEnableStatus") called from "USER32.DLL" at address 0x766AB78B and returned 0x750EF65E.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSendIMEMessageExW") called from "USER32.DLL" at address 0x766AB7A0 and returned 0x750EF8EC.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSendIMEMessageExA") called from "USER32.DLL" at address 0x766AB7B5 and returned 0x750EF907.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmIMPGetIMEW") called from "USER32.DLL" at address 0x766AB7CA and returned 0x750EFB65.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmIMPGetIMEA") called from "USER32.DLL" at address 0x766AB7DF and returned 0x750EFB99.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmIMPQueryIMEW") called from "USER32.DLL" at address 0x766AB7F4 and returned 0x750EF9CA.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmIMPQueryIMEA") called from "USER32.DLL" at address 0x766AB809 and returned 0x750EFAD6.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmIMPSetIMEW") called from "USER32.DLL" at address 0x766AB81E and returned 0x750EF746.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmIMPSetIMEA") called from "USER32.DLL" at address 0x766AB833 and returned 0x750EF86E.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmAssociateContext") called from "USER32.DLL" at address 0x766AB848 and returned 0x750E3691.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmEscapeA") called from "USER32.DLL" at address 0x766AB85D and returned 0x750E9327.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmEscapeW") called from "USER32.DLL" at address 0x766AB872 and returned 0x750E95A9.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetCompositionStringA") called from "USER32.DLL" at address 0x766AB887 and returned 0x750E7A37.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetCompositionStringW") called from "USER32.DLL" at address 0x766AB89C and returned 0x750E420D.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetCompositionWindow") called from "USER32.DLL" at address 0x766AB8B1 and returned 0x750E2DF9.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetContext") called from "USER32.DLL" at address 0x766AB8C6 and returned 0x750E2004.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetDefaultIMEWnd") called from "USER32.DLL" at address 0x766AB8DB and returned 0x750E1F1D.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmIsIME") called from "USER32.DLL" at address 0x766AB8F0 and returned 0x750E2FC8.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmReleaseContext") called from "USER32.DLL" at address 0x766AB905 and returned 0x750E2122.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmRegisterClient") called from "USER32.DLL" at address 0x766AB91A and returned 0x750E135E.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetCompositionFontW") called from "USER32.DLL" at address 0x766AB92F and returned 0x750E68C8.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetCompositionFontA") called from "USER32.DLL" at address 0x766AB944 and returned 0x750E682C.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSetCompositionFontW") called from "USER32.DLL" at address 0x766AB959 and returned 0x750E3966.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSetCompositionFontA") called from "USER32.DLL" at address 0x766AB96E and returned 0x750E6964.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSetCompositionWindow") called from "USER32.DLL" at address 0x766AB983 and returned 0x750E38D8.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmNotifyIME") called from "USER32.DLL" at address 0x766AB998 and returned 0x750E3BB9.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmLockIMC") called from "USER32.DLL" at address 0x766AB9AD and returned 0x750E1DDD.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmUnlockIMC") called from "USER32.DLL" at address 0x766AB9C2 and returned 0x750E1D89.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmLoadIME") called from "USER32.DLL" at address 0x766AB9D7 and returned 0x750E18F9.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSetOpenStatus") called from "USER32.DLL" at address 0x766AB9EC and returned 0x750E3FF4.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmFreeLayout") called from "USER32.DLL" at address 0x766ABA01 and returned 0x750E97EF.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmActivateLayout") called from "USER32.DLL" at address 0x766ABA16 and returned 0x750E8DF5.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetCandidateWindow") called from "USER32.DLL" at address 0x766ABA2B and returned 0x750E2E3C.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSetCandidateWindow") called from "USER32.DLL" at address 0x766ABA40 and returned 0x750E3E03.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmConfigureIMEW") called from "USER32.DLL" at address 0x766ABA55 and returned 0x750E913F.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetConversionStatus") called from "USER32.DLL" at address 0x766ABA6A and returned 0x750E2469.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSetConversionStatus") called from "USER32.DLL" at address 0x766ABA7F and returned 0x750E3EE7.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSetStatusWindowPos") called from "USER32.DLL" at address 0x766ABA94 and returned 0x750E6A7C.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetImeInfoEx") called from "USER32.DLL" at address 0x766ABAA9 and returned 0x750E14F0.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmLockImeDpi") called from "USER32.DLL" at address 0x766ABABE and returned 0x750E1FA5.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmUnlockImeDpi") called from "USER32.DLL" at address 0x766ABAD3 and returned 0x750E1F58.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetOpenStatus") called from "USER32.DLL" at address 0x766ABAE8 and returned 0x750E3DD0.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSetActiveContext") called from "USER32.DLL" at address 0x766ABAFD and returned 0x750E21D1.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmTranslateMessage") called from "USER32.DLL" at address 0x766ABB12 and returned 0x750EF27F.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmLoadLayout") called from "USER32.DLL" at address 0x766ABB27 and returned 0x750E9E79.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmProcessKey") called from "USER32.DLL" at address 0x766ABB3C and returned 0x750E3A6A.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmPutImeMenuItemsIntoMappedFile") called from "USER32.DLL" at address 0x766ABB51 and returned 0x750F4E96.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmGetProperty") called from "USER32.DLL" at address 0x766ABB66 and returned 0x750E3C1B.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSetCompositionStringA") called from "USER32.DLL" at address 0x766ABB7B and returned 0x750E83C2.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSetCompositionStringW") called from "USER32.DLL" at address 0x766ABB90 and returned 0x750E83E9.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmEnumInputContext") called from "USER32.DLL" at address 0x766ABBA5 and returned 0x750E320A.
GetProcAddress(0x750D0000 [IMM32.DLL], "ImmSystemHandler") called from "USER32.DLL" at address 0x766ABBBA and returned 0x750EB1CF.
GetProcAddress(0x750D0000 [IMM32.DLL], "CtfImmTIMActivate") called from "USER32.DLL" at address 0x766ABBCB and returned 0x750E1807.
GetProcAddress(0x750D0000 [IMM32.DLL], "CtfImmRestoreToolbarWnd") called from "USER32.DLL" at address 0x766ABBDC and returned 0x750F5114.
GetProcAddress(0x750D0000 [IMM32.DLL], "CtfImmHideToolbarWnd") called from "USER32.DLL" at address 0x766ABBED and returned 0x750F514B.
GetProcAddress(0x750D0000 [IMM32.DLL], "CtfImmDispatchDefImeMessage") called from "USER32.DLL" at address 0x766ABBFE and returned 0x750E1611.
GetProcAddress(0x750D0000 [IMM32.DLL], "CtfImmNotify") called from "USER32.DLL" at address 0x766ABC0F and returned 0x750E1346.
GetProcAddress(0x750D0000 [IMM32.DLL], "CtfImmSetDefaultRemoteKeyboardLayout") called from "USER32.DLL" at address 0x766ABC20 and returned 0x750F53CC.
GetProcAddress(0x750D0000 [IMM32.DLL], "CtfImmGetCompatibleKeyboardLayout") called from "USER32.DLL" at address 0x766ABC31 and returned 0x750F53DC.
DllMain(0x750D0000, DLL_PROCESS_ATTACH, 0x00000000) in "IMM32.DLL" returned 1 (0x1).
LoadLibraryW("C:\Windows\system32\IMM32.DLL") returned 0x750D0000.
GetProcAddress(0x76B00000 [LPK.DLL], "LpkTabbedTextOut") called from "GDI32.DLL" at address 0x74B86970 and returned 0x76B048A0.
GetProcAddress(0x76B00000 [LPK.DLL], "LpkPSMTextOut") called from "GDI32.DLL" at address 0x74B8697B and returned 0x76B01430.
GetProcAddress(0x76B00000 [LPK.DLL], "LpkDrawTextEx") called from "GDI32.DLL" at address 0x74B86986 and returned 0x76B013D0.
GetProcAddress(0x76B00000 [LPK.DLL], "LpkEditControl") called from "GDI32.DLL" at address 0x74B86991 and returned 0x76B07000.
DllMain(0x76690000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "USER32.DLL" returned 1 (0x1).
DllMain(0x76790000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SHLWAPI.DLL" called.
DllMain(0x76790000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SHLWAPI.DLL" returned 1 (0x1).
DllMain(0x75490000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SHELL32.DLL" called.
DllMain(0x75490000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SHELL32.DLL" returned 1 (0x1).
DllMain(0x6C2F0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "MSVCR100.DLL" called.
GetProcAddress(0x751B0000 [KERNEL32.DLL], "FlsAlloc") called from "MSVCR100.DLL" at address 0x6C30B3BF and returned 0x751C1F22.
GetProcAddress(0x751B0000 [KERNEL32.DLL], "FlsGetValue") called from "MSVCR100.DLL" at address 0x6C30B3CC and returned 0x751C123D.
GetProcAddress(0x751B0000 [KERNEL32.DLL], "FlsSetValue") called from "MSVCR100.DLL" at address 0x6C30B3D9 and returned 0x751C18E4.
GetProcAddress(0x751B0000 [KERNEL32.DLL], "FlsFree") called from "MSVCR100.DLL" at address 0x6C30B3E6 and returned 0x751C3954.
DllMain(0x6C2F0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "MSVCR100.DLL" returned 1 (0x1).
DllMain(0x743B0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "MSVCP100.DLL" called.
DllMain(0x743B0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "MSVCP100.DLL" returned 1 (0x1).
Second chance exception 0xC0000005 (Access Violation) occurred in "HUDPLUS.EXE" at address 0x002D4BF0.
Exited "HUDPLUS.EXE" (process 0x118C) with code -1073741819 (0xC0000005).
And the difference between your log file and mine starts here:
GetProcAddress(0x76B00000 [LPK.DLL], "LpkEditControl") called from "GDI32.DLL" at address 0x74B86991 and returned 0x76B07000.
DllMain(0x76690000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "USER32.DLL" returned 1 (0x1).
DllMain(0x76790000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SHLWAPI.DLL" called.
DllMain(0x76790000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SHLWAPI.DLL" returned 1 (0x1).
DllMain(0x75490000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SHELL32.DLL" called.
DllMain(0x75490000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "SHELL32.DLL" returned 1 (0x1).
DllMain(0x6C2F0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "MSVCR100.DLL" called.
GetProcAddress(0x751B0000 [KERNEL32.DLL], "FlsAlloc") called from "MSVCR100.DLL" at address 0x6C30B3BF and returned 0x751C1F22.
GetProcAddress(0x751B0000 [KERNEL32.DLL], "FlsGetValue") called from "MSVCR100.DLL" at address 0x6C30B3CC and returned 0x751C123D.
GetProcAddress(0x751B0000 [KERNEL32.DLL], "FlsSetValue") called from "MSVCR100.DLL" at address 0x6C30B3D9 and returned 0x751C18E4.
GetProcAddress(0x751B0000 [KERNEL32.DLL], "FlsFree") called from "MSVCR100.DLL" at address 0x6C30B3E6 and returned 0x751C3954.
DllMain(0x6C2F0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "MSVCR100.DLL" returned 1 (0x1).
DllMain(0x743B0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "MSVCP100.DLL" called.
DllMain(0x743B0000, DLL_PROCESS_ATTACH, 0x0023FAA0) in "MSVCP100.DLL" returned 1 (0x1).
Second chance exception 0xC0000005 (Access Violation) occurred in "HUDPLUS.EXE" at address 0x002D4BF0.
Exited "HUDPLUS.EXE" (process 0x118C) with code -1073741819 (0xC0000005).
...
Florent,
Quotea lot of work which in my opinion is not worth it
I wanted to check how much work i had to do to produce an EXE as small as PB with C++, and i think you hit the nail in my head, thank you.
...
Hi Patrice
I concurr :) A propos the exception: now we're getting into arcane territorry - take the /merge #pragmas out and recompile - does the exception still occur?
Cheers, Florent
Florent,
One more question about your 26 Kb HUDplus.exe, does it works with the ZWP.exe child process.
I mean can you see the background animation and hear the audio playing when you check "Use visual plugin",
and can you change the audio file(s) and the visual plugin(s) when selecting them from combobox?
...
Hi Patrice
yes - clicking on Visual Plugin starts the music and I can select visual plugins which change the background - just a thought about the exception:
go into the project properties/Code Generation and make sure Enable C++ exceptions "Yes (/EHsc)" is enabled - the exception you're seeing might be coming from one of the standard library calls (such as xlocale) which uses TRY_BEGIN macros - the second-chance exception should not be happening.
Cheers, Florent
Do you need the C++ Standard String Class Patrice? I don't know how much string processing your application does, but if it isn't anything heavy duty or fancy, you could do this...
#include <string.h>
instead of this...
#include <string>
or this...
<cstring>
...at least nin VC9 I can do that ( VS 2008 )
and that drastically affects what gets compiled. The difference on a static link like Florence mentioned would likely be around 40K. You would still have the C style string primitives such as strcpy(), strncpy(), strcat(), etc.
Quote from: Frederick J. Harris on February 12, 2011, 12:56:37 AM
Do you need the C++ Standard String Class Patrice? I don't know how much string processing your application does, but if it isn't anything heavy duty or fancy, you could do this...
#include <string.h>
instead of this...
#include <string>
or this...
<cstring>
...at least nin VC9 I can do that ( VS 2008 )
and that drastically affects what gets compiled. The difference on a static link like Florence mentioned would likely be around 40K. You would still have the C style string primitives such as strcpy(), strncpy(), strcat(), etc.
Hi Frederick
actually Patrice's <string.h> directive was replaced by <string> - out of habit after I saw he was using the std namespace in the main program - so mea culpa to me ;)
Cheers, Florent
I am using already <string.h> with VS2010 C/C++
However i can't get my code to be as small as Florent's, but his small 26 Kb EXE doesn't work by me.
The best i can do so far is a 76 Kb exe.
The only difference i can see between the PB and the C++ code, is is the use of the C++ string classes that makes the code larger.
...
Patrice did you try my suggestion of Enabling /EHsc (exception handling) and recompiling the project - there's no reason I can see why it should not work provided the runtime is somewhere in your path?
Florent
Florent,
I have removed the two extra pragma you added at the begining of WinLIFT.h:
//#pragma comment(linker, "/MERGE:.rdata=.data")
//#pragma comment(linker, "/MERGE:.text=.data")
(they were causing error by me)
as well as
//#pragma optimize("gsy", on)
and restored: #include <string.h> , everywhere.
And now the resulting EXE is only 25 Kb in size, and it works very well by me ;)
That is 3 Kb less than PB...
Thank you!
...
The merge pragmas can make for tricky output sometimes - strange about the optimize gsy pragma - could it be that some additional linker/compilation options were set that created a conflict. All's well that ends well :)
Cheers, Florent
Quote
That is 3 Kb less than PB...
That's something of a general truth there Patrice. C++ programs will always be larger than PowerBASIC programs if the includes are <string> or <cstring> because the whole C++ Standard Library's String Class will be compiled into your code. The C++ String Class is a rather complicated beast. At its most basic level it is represented as a Standard Template Library ( STL ) instantiation of the basic_string template where a char or wchar_t is passed in. Then there are a lot of member functions associated with both the resulting string class, and the underlying STL basic_string container. Its very fast but at times difficult to use.
I mostly use CodeBlocks GNU to code, and my basic Hello World with the String Class is about 45K. With just stdio.h and string.h its only about 6K. So you can see the difference. Whether to use it or not depends on how bad one needs it. I would think in the heavy duty graphics programming you do you wouldn't have more then incidental use for advanced capability string handling routines such as Replace, Parse, InStr, etc. So you can save a lot by doing what you did. The only other alternative is to do what I did and that's create my own string class. It saves me about 20 - 25 K or so on the one in the Std Lib.
Of course, the beauty of PowerBASIC is that all that logic is built into the compiler, so it doesn't have to be written into one's executable. With C++, all that logic ends up in the executable.
>Of course, the beauty of PowerBASIC is that all that logic is built into the compiler, so it doesn't have to be written into one's executable. With C++, all that logic ends up in the executable.
The current PB versions add functionallity in blocks and not per function.
A GetAttr() for example seems to add much more than only a simple wrapper to the Windows SDK.
Maybe the new upcoming version may reduce the size again, maybe the internals are also stuck in SLL kind of libraries (embedded or so) and maybe it now takes what is requested only.
Note that i little care if the app is 100KB or 10KB, as long it ain't megabytes of difference it's fine by me :)
At least i would be very pleased with the new behaviour.
PowerBASIC for Windows
PB/Win Version 9.01
Copyright (c) 1996-2009 PowerBasic Inc.
Venice, Florida USA
All Rights Reserved
412 bytes compiled code, 1576 bytes RTLibrary,
0 bytes string literals, and 1872 bytes dgroup.
Executable stack size: 1048576 bytes.
Disk image: 5120 bytes Memory image: 3448 bytes.
428 bytes compiled code, 3067 bytes RTLibrary,
8 bytes string literals, and 1880 bytes dgroup.
Executable stack size: 1048576 bytes.
Disk image: 7168 bytes Memory image: 4955 bytes.
Quote>Maybe the new upcoming version may reduce the size again
It is my experience that each new PB version didn't reduce the size of my own code, but instead each new release make it larger.
No surprise there, because every new features that are encapsulating the core API, are indeed adding more bytes to the code.
A good example of this, is to use the built-in PowerBASIC I/O facilities, if you rather use the core CreateFile API, you will see a significative file size reduction.
And this is the same when you use FORMAT instead of STR$ just to convert number to string. Non-speaking of the overhead of DDT over SDK.
This is the reason why a strict SDK coder, like myself, is very interrested to check wich language is able to produce the smallest code, trying to use only the Windows built-in API.
So far i would say that for my HUDplus project, the C++ 25 Kb and the PB 9.05 28 Kb are very similar, and they are both working at the same speed.
...
>This is the reason why a strict SDK coder, like myself, is very interrested to check wich language is able to produce the smallest code, trying to use only the Windows built-in API.
What reason?
For the 3K of difference Patrice its probably not worth anywhere near the effort, but I expect removing Win32Api.inc and just declaring/defining only what's needed could easily save that difference. Or maybe you already did that?
From what I read before you and Florent were doing Win64. I'm taking from that that the Win64 compiles don't affect resulting program sizes too much. I need to jump on this Win64 bandwagon I guess and get myself one. I just keep putting it off.
Edwin--
QuoteWhat reason?
I avoid to use extra encapsulation when there is no need for me to use them, because i have been programming long ago before these encapsulations have been made available. Using the core API, allows me to produce smaller and faster code, and this is the way i like it. ;D
Frederick--
Quotebut I expect removing Win32Api.inc and just declaring/defining only what's needed could easily save that difference. Or maybe you already did that?
Yes, i already did that ;)
QuoteFrom what I read before you and Florent were doing Win64. I'm taking from that that the Win64 compiles don't affect resulting program sizes too much.
From my own test, the EXE size difference is something around 1.35 larger.
...
While the size of the C++ exe is only 25K, i must say that is also require the installation of the C++ runtime.
Aka: vcredist_x86.exe
This means that PB's code, is definitly much smaller, because it doesn't require any runtime! :o
...
That issue with the redistributable really caught me by surprise Patrice! I purchased VS 2008 ( VC9 ) summer before last. I had been using VC6 from way back in Win 98 times. With that old version it defaulted to the non - runtime version. Microsoft changed the defaults somewhere along the way between vc6 and vc9, and it took a long time for me to catch it, much to my embarressment! Right from the start I couldn't believe how small the executables were from VC 9! I was amazed! Just couldn't believe it! It never occurred to me that my executables required the VC9 runtime! I was comparing apples to oranges.
The way I finally discovered it, is somehow or other I tried to run one of my VC9 produced exes on one of my Win 2000 machines. Since then I've been seeing what I expected; compiled with VC9, my executables are fairly large. For this reason (and others), I tend to use the GNU Mingw compiler suite with CodeBlocks. It produces somewhat smaller exes. I don't have hard figures on it, but off the top of my head I'd estimate 5% to 15% smaller. The only thing is, I've never been able to have much success with it doing low level COM work. For that I have to resort to VC6 or VC9. The problem involves DEF files as related to creating COM servers.
You know, I recall the discussion you started several months ago when you were wanting to know how to do explicit linking with PowerBASIC Dlls from C++. That topic interests me, and I could see at some point taking it up. It is a PIA to have to do the LoadLibrary() / GetProcAddress() thing and use pointers to call functions in PB Dlls.
I have again the problem of the C++ run-time
QuoteThe program can't start because MSVCP100.dll is missing from your computer. Try reinstalling the program to fix this problem
I couldn't remember the switch to use
to get rid of the Micrsoft's Visual C++ Redistributable PackageNote: I am already using the
Multithread /MT switch...
>:(
The runtimes are one of the major issues with VC++. Not everybody has the runtimes installed for the newer versions of VC++. It is not just EXEs. DLLs will require those runtimes, too. This was the main reason I dropped my DX9 2D engine that was written in VC++ 2008. It worked fine, but so many people did not have the necessary VC++ runtimes, that it was more hassle than it was worth. At some point, I should rewrite it in OpenGL.
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.
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 (http://www.codeproject.com/Articles/15156/Tiny-C-Runtime-Library)). It all depends on how much work you want to throw into it.
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 :(
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).
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)
::)
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.
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!
Quote from: Mike Stefanik on October 11, 2013, 12:25:34 AM
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.
Here is the final size result after applying the
Multithread (/MT) switch.
Quote | 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.