home bbs files messages ]

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