Hello World program 5 MB!

[Yes]

I have just finished installing and configuring Qt statically, and then followed this tutorial to create a simple "Hello World!" program in Visual Studio 2008. It works perfectly fine, it's just that – it takes up 5 MB of space, for a tiny program! I have made more advanced programs than that in Visual Basic that takes up not much more than 50 kB of space. 5 MB is for the release version, while the debug version takes up 14 MB. How is it possible that this simple program can grow so large, ans is there anything I can do to shrink it? It also takes quite long time to build the project, at least the first time you're building it or if you're making a rebuild.

I have also another question – I wanted to configure Qt statically because I think it's much more neat with a program that doesn't need an external library to run that a program that does need an external library and can't run as a standalone application. But yet the shared Qt configuration seems to be the standard and what is usually recommended, how does that come? Is it considered to be better in some way?

For the rest, I configured Qt from the Visual Studio Command Prompt and the lines I used was these two:

configure -static
nmake sub-src

configure -static
nmake sub-src

To copy to clipboard, switch view to plain text mode 

[Talei]

No You are mistaken, Qt apps. are not big at all.

For example how much space uses windows notepad.exe? Application is like 64KB but with all dll's it's over 10MB.
Only difference is that all notepad dll's come with standard Windows installation. So one can say blame M$ for not including qt dll's in windows .
Simple remedy to this problem is copying libs into %windir%/system|system32, or better adding into PATH variable Qt lib location, so You don't need to copy dll's to apps location.
But seriously it's normal and You just see that because those dll's are not present by default in Windows.

Qt by default is build as shared because they are licensed as LGPL. With static You go with commercial or GPL license and share your src.
Shared is better because program (ironically in Your post context) is smaller . Qt is not present in Windows but is by default present in KDE Linux base environment (KDE is build using Qt). So If you want to ports Win app. to KDE/Linux You will need all Windows dll's and situation will be in reverse (and is worse then that, because probably all Win dll are proprietary, so porting is not so easy - that's why we use Qt to port apps. easily across various OS).

Also statically linking won't solve size problem (at least not without changing default Qt build specs)

To shrink app You could compress it (upx).

[MaKo]

I have made more advanced programs than that in Visual Basic that takes up not much more than 50 kB of space.

Visual Basic programs need VB DLLs. Bundle them together and the program is many megabytes.

How is it possible that this simple program can grow so large, ans is there anything I can do to shrink it?

Because you linked it statically with libraries. Libraries have their internal dependencies, which means, that using some of their functions add many more to the linked package. You can only strip out debugging information and pack the exe with UPX (as suggested in previous post) to shrink the size.

But yet the shared Qt configuration seems to be the standard and what is usually recommended, how does that come? Is it considered to be better in some way?

Shared libraries are technically better. They are shared between all the programs using them, which leads considerable RAM savings the more applications use them. Also, this leads to better cache performance, and of course reduces swapping. Linux machines usually come with quite a large bunch of shared libraries by default, and you can usually install additional libraries from package managers. Windows machines usually don't have many shared libraries (other than Microsoft's own, unless user installs development environments and such) and users do not have centralized location to get them. Thus, many Windows binary distributions come as statically linked packages or as ZIP archives containing the libraries.