I am trying to get a fair ranges of what i can really do with an executive with-out being to greedy on someone else machine.

One quick question about Memory.... Let say you got a 200kb Executive. On Disk it would be exactly 200KB in size ONLY....but when you fire-up that Executive it may grow depending on your buffers.

Lets said it grow to 300KB... when running.

But while running i check the size that Windows claims to give me... i got about 4,126,873 or over 4 Gigs i guest.... in size ANYWAY.... do i get any of this really...

My question is do it really matter if i had up to 1/2 MB - 1MB worth of Pure ASM code and buffers in my Executive, in use, while running. It seems that it is all in memory anyway and not running from the disk....is this true...

If this program is running on a 586 or better with 64kb of RAM.... Can it survive without any problems.... Is this to greedy.... can it even do a 386 as long as it got some ram...

I don't care about disk space just Run-time space with-out hogging the machine...

Could you please lay out a few facts for me about this

Thanks in advance
Posted on 2002-05-08 16:23:08 by cmax
cmax you remember that windows has
virtual memory and paging. It does not
have to load all of the program at once,
just a page at a time.

If you are worried about the size then
you can move code off to dlls. That is
what one of the simulation programs I
work with does.
Posted on 2002-05-10 03:24:31 by bdjames
this is a more philisophic question, some private statements here:

Lets think, you make an exe file with 10 K code and a 1 MB buffer inside the exe, so you have a 1,01 MB file. Other way would be allocating the buffer dynamically, so you get a 10 K exe.

(I hope this is the main message of your question)

Pro (small exe):
- no waste of HD space - o.k. not much need to optimize, but if each software would save up some bytes, windows would still fit on some floppies...
- faster startup of the exe
- smaller download / setup of the final software

Contra:- takes some time to allocate the buffer (if only one alloc, no matter)
- more programming needed
- needs one more API call, or two (freeing buffer)

So for a "normal" programmer there is not much argument for a smaller file, but as an assembly coder, it should be a must for you to produce smaller files :)
Posted on 2002-05-10 03:57:14 by beaster
After a while you tend to forget what it is all about. And what you guys said really brought me back...I really needed this one. I was going going nuts for a minute.

Thanks Guys, :alright:

fOdder gave me a hint about my problem in a previous post and i searched and recently founded this post *share section* .... It's the only one about linking it and best thing for my problem....I have not have the time to test things yet but i think i can make it work....It is very interesting and .thank God someone did it in ASM or someone else some day would have been just like me. :confused:
Posted on 2002-05-10 07:49:41 by cmax
You could also put the buffer in BSS (.data?), this is "static" allocation
without growing the executable (cmax, it isn't called "executive",
that word in computer context usually refers to an OS kernel :)).
Posted on 2002-05-10 10:16:49 by f0dder