Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.asm.x86    |    Ahh, the lost art of x86 assembly    |    4,675 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,581 of 4,675    |
|    Rick C. Hodgin to R.Wieser    |
|    Re: EXE program stack setup questions    |
|    13 Oct 18 11:25:18    |
      From: rick.c.hodgin@gmail.com              On 10/13/2018 10:08 AM, R.Wieser wrote:       > Rick C. Hodgin wrote:       >> I would double-check that with an AH=4Ah, BX=0FFFFh, INT 21h function call       >       > Why ? What good will that info do me ? If my program gets exactly       > the, in the files header specified, minimum ammount of memory than its able       > to run. Anything more is, as far as I'm concerned, wasted space. Hence my       > templated "set stack, shrink program-memory usage" initialisation sequence.              I've never observed any value in having all memory allocated to your app       at startup. You don't know how much is there, so it seems like a bad idea.       I have always immediately resized the allocated block, and then allocated       blocks as needed so I know how much I have left, etc.              > Could you give a real-world example of when that that memory (of unknown       > size!) would come in handy for a program ?              I can only assume in cases where you just need to use memory beyond the       end of your program for some cheap dangerous living-on-the-edge kind of       purpose. :-)              >> Out of curiosity, why is this too big?       >       > Look at it this way: Why do you not drive a 6-wheel truck to get a pound of       > cheese from your local super ? Why do you than opt to take a small car or       > even a bike ? The same principle goes here. I *could* take that truck,       > but a bike will probably be even quicker. :-)              It's totally different. DOS was (generally speaking) a single-threaded       OS, so if you run your app, have all of your locally allocated space in       there at compile-time so it's available at startup, what difference       would it make that the rest of memory is already allocated?              I see (and saw back then) no value in it, but that's the way the memory       cookie crumbles. :-)              >> Then all you need to do is find out how big your .EXE code + data is in       >> memory, which you can probably do by using two OFFSET values, one at the       >> start of everything, one at the end, and then subtracting.       >       > Yes, I've been looking into that too. Not only for .EXE , but also for .COM       > style programs. Its harder than you think. If-and-when you are using       > named segments the linker can reorder them, causing those adresses to move       > in .. well, unexpected ways (not really, but I think you know what I mean).              I never had any trouble. I didn't do it down to the byte, but would       just generally work to the nearest KB or so, always erring on the side       of caution and safety. And, I tested my program with the settings I       had so if it failed, I would redo it.              > Regards, and thank you for your help.       > Rudy Wieser              It was an interesting thought down memory lane.              --       Rick C. Hodgin              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca