compiled to 1,5 kbytes

or http://board.flatassembler.net/topic.php?p=45385#45385 MessageBox example compiled to 680 bytes

I run program, press Alt+Ctrl+Del and see that it takes 3520 KBytes!
Why so much?

Maybe it's just the size of the page. Don't forget the 1 mb of stack space allocated for each thread (I think that's right). well, disasm it and start counting!! It's probably just paging, stack space, or something like that. I had a program once that didn't use 'include' , just did some other dll loading. I disasm'ed it, and it turned out to be hundreds upon hundreds of lines of the code from random windows functions and stuff. Maybe that happened in yours?? If you haven't done it before, use OllyDbg

use SysInternals process explorer for more detailed information

hmmm... Vid, check out the other post about this person trying to take over the Windows command prompt's output buffer with a pipe. Very interesting, I hope you can give him an explanation of how you can't do it. I suggested a "timing attack on the cmd process" for the moment when it relinquishes it's window. I totally made that up, but is it really possible to make a loop that will attack a program using AttachConsole for the exact moment it exits? That would be volatile lol...

KIRK: as vid recommended, get Process Explorer to get more detailed memory usage staticstics - what you should be most interested in is "Private Bytes" memory usage.

The memory size explorer shows will never really go below 2-3MB, since it includes the DLLs your process uses, and most of that memory is shared among all processes that's running on the system.

True, and those dll's may be very large, KERNEL32 I think is default for all apps, either that or NTDLL also. Combine that with stack space, align to page*? and other things it will only go down to around there. Still kind of funny though

You'll always end up including KERNEL32.DLL in your apps - XP forces it's inclusion, Win2k fails silently if you don't end up importing from it (ie., it's good enough to have a single import from, say, GDI32.DLL since GDI32 imports from KERNEL32), because of the way app loading happens (your proces doesn't start initial executing from peheader.entrypoint, but from kernel32.some_deep_function).

KERNEL32 in turn depends on NTDLL.

Ah, that's nothing - here is a real memory hog:

real available amount of memory to process - min (avail phys. memory; avail virt. mem) but with one remark - you will commit page by page size of total needed to be allocated memory - the cause is Virtual memory fragmentation.
I haven't seen ever that one (32 bit) program could take more than 1.6-1.7 GiB without some special manipulation - e.g. large_address_aware and boot.ini /3gb

and what you see?

Yep, you got stacks, PID's, TID's, DLL info tables, lots of other information things that Windows likes to use.

RBTray takes only 272 KB,
why such difference?

You wanted to include MessageBox so that means you get user32 and gdi32 mapped into you process. Background processes may not have used any GUI functions so accordingly have less mapped DLL's.

thanks:)

you need to look at PRIVATE BYTES, not WORKING SET. And do yourself a favor, open perfmon.msc and see the description of the process/memory counters.

Working set becomes small when you don't have any visible windows and sit in the background. If you worry too much about these things you can use SetProcessWorkingSetSize(hpro,-1,-1);, but it's a silly hack since windows will trim the working set as necessary.