[Happy new year :-)] What compiler flags to set for AMD dual core ?

[pel]

setting the optimization: strip all symbols from binary changed my 718 KB .exe file into a 7 KB .exe file? how this?



when i run the 7 KB .exe file the win32 windows gets opened but the same time a console window in the background is opening, is this due to some settings in codeblocks?

[TDragon]

setting the optimization: strip all symbols from binary changed my 718 KB .exe file into a 7 KB .exe file? how this?

By default, many symbols are included which are not needed for normal operation. Whenever you don't need to debug your binary, have it stripped.

when i run the 7 KB .exe file the win32 windows gets opened but the same time a console window in the background is opening, is this due to some settings in codeblocks?

Yes; by default, the debug target from the Win32 GUI Project wizard is set to include a console window in case you want to use it for debugging. The release target by default does not have a console. To change this setting for a particular target, open your project's properties, select the Build targets tab, select the target you want to modify on the left, and for "Type" choose "Console application" (to include a console) or "GUI application" (to omit the console).

EDIT:
I realized I missed the question in the title. If you truly only want to run the program on Athlon64 series CPUs, choose AMD Athlon64. (Don't worry; this will still generate 32-bit code.) If you want the program to run on any modern CPU, choose Intel Pentium PRO (i686). (This is what I choose for release binaries.) If you want the program to run on any Windows machine, don't use any of the architecture options and it will generate code that will run on anything down to an i386.

Cheers,
JohnE / TDM

[pel]

setting the optimization: strip all symbols from binary changed my 718 KB .exe file into a 7 KB .exe file? how this?

By default, many symbols are included which are not needed for normal operation. Whenever you don't need to debug your binary, have it stripped.

the funny thing is that when i choose the build target: debug  , then the size of the .exe is 715 kb
but when i choose the build target: release, then the size of the .exe is 7 kb.

In both cases i have not used any compiler flags(Pentium 3 and up), strip symbols or optimize generated code settings. But when i use the left settings and rebuild the project the .exe file is still only 7 kb so no optimization has happened at all??? Is this due to that C compiler cant optimize a 7 kb file anymore? Then i checked the task manager in windows xp and saw that my bla.exe file is consuming 540 KB RAM  :shock: its a single window...  Why is my bla.exe that bloated?

minimized bla.exe window:  280 KB RAM
maximized bla.exe window: 535 kb RAM

minimized mirc.exe: 900 KB RAM
maximized mirc.exe: 1900 KB RAM

1.) How can ONE single visible windows consume a half MEGABYTE of RAM?

2.) Using GCC.exe or Mingw32-gcc.exe for compiling C apps is there any difference?

cheers,

Pel

[thomas]

setting the optimization: strip all symbols from binary changed my 718 KB .exe file into a 7 KB .exe file? how this?

This is not an optimisation. The executable has no debug symbols, so it is smaller.

the funny thing is that when i choose the build target: debug  , then the size of the .exe is 715 kb
but when i choose the build target: release, then the size of the .exe is 7 kb.

This target (by the default project wizard) enables stripping debug info.

But when i use the left settings and rebuild the project the .exe file is still only 7 kb so no optimization has happened at all???

There is little or no opportunity to optimise a program that opens a window. You may want to search the internet about what compiler optimisations are about.
Also, there is a minimum program size due to both runtime overhead and the PE format. If you really need a program file that is smaller than 7 kB (which is quite ridiculous) then you can waste your time and use the same tricks that those people making "4k demos" use. You will have to resort to assembler, though.

How can ONE single visible windows consume a half MEGABYTE of RAM?

The correct question would be: "why do I care about it?". But to answer your question: there is a minimum overhead that every running process consumes for such things as stack and heap. You can tweak these with some compiler settings or by modifying the PE header directly, but again, why would one want to do that...
Also the memory (application and system RAM, and video memory) necessary to manage a window may be considerable and well beyond your scope, depending on the actual program code, and on what you configure Windows or your display drivers to do.

Little of all this seems related to Code::Blocks to me.

[pel]

I just want to understand why a 7KB .exe file needs 560 KB appr. RAM, but anyway as you said its the wrong forum sorry i will ask that question in a pure C forum. thx!

[MortenMacFly]

I just want to understand why a 7KB .exe file needs 560 KB appr. RAM,

...because it allocates it?! You can "malloc" even more with a one-liner in console app much smaller than 7kB.
Don't forget that you automatically have dependencies to (system) DLL's that are being loaded etc. I guess it's best you take a book about how an operating system works and start reading... ;-)
With regards, Morten.

[thomas]

I just want to understand why a 7KB .exe file needs 560 KB appr. RAM

Like I said, there are many reasons, and it means nothing.

For example, the default minimum working set under Windows is 50 pages (204,800 bytes). This means that regardless of anything else, at least 200 kB are held in RAM by the operating system's policy, even if a program has zero size and does nothing at all.
Similarly, every program reserves a stack frame of some size, which is often 1 MB (but can be anything), whether you do something or not.

Most of these things are beyond your scope as program writer. You have little or no control over them, and for the most part, you need not care about them either.