From: address@nospicedham.not.available   
      
   Rick,   
      
   > In that case, issue a:   
   >   
   >     MOV SP,OFFSET last_thing_in_asm_file + desired_stack_size   
      
   That is pretty-much what I have been doing for the past number of years ,   
   and works well enough (followed by a shrinking of the programs memoryblock).   
   Up until I realized I'm doing something the OS is giving me for free - as   
   long as I set the correct values (in file header).  And that is where I got   
   stuck.   
      
   > Do that in your main proc, and then JMP main2 to begin your real code.   
   > That way it will not start at 0, wrapping to 0xfffe, but it will start   
   > wherever you indicate, at the end of your true asm code + data + whatever   
   > size you desire for your stack.   
      
   Yep.  As mentioned, I've used that "trick" before. Among others so I could   
   call a procedure with, or without predefined (default) values.   
      
   > It's not for no reason.  DOS automatically allocates the full   
   > 64KB block to TINY memory model apps.   
      
   And by that leaving a ginormous gap (several times the size of the program   
   itself) between the bottom of the stack and the end of the program.   That   
   gap is what I ment is there for no reason.   
      
   Than again, when we forget to specify a stack what should the poor OS than   
   do instead ?   
      
   > 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.   
      
   Could you give a real-world example of when that that memory (of unknown   
   size!) would come in handy for a program ?   
      
   > I know .COM files received it all.  I'm pretty sure TINY model .EXE files   
   > did also   
      
   As mentioned, thats fully up to how the linker sets up those variables in   
   the file header (something which can have changed along the years).   I've   
   been told that limiting it could be set by an argument to (I think) the   
   linker.   My linker does not have such an argument/switch.   
      
   > 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 would only be an issue if you're allocating memory later.   
      
   Exactly.    I'm not realy prone to a "it just needs to work here"   
   methodology.  In this case that initializing will become part of my (new)   
   template for tiny model executables.   
      
   > 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).   
      
   > The AH=4Ah, INT 21h resize memory might tell you how bit it is if the EXE   
   > loader only allocated enough memory to   
   > hold the code + data, and you're out there in la la land with the stack.   
      
   I was thinking of creating a setup to check that, but eventually assumed the   
   OS would be smart enough to recognise it didn't have a full 64K available   
   (for a program that could easily slosh around in it), and because of it   
   adjusts the stackpointer to the top of what it actually does have - ir   
   simply refuses to run the proigram ofcourse.   
      
   If the stack than overwrites the BSS ?  Well that is what you get when you   
   forget to specify it. :-)   
      
   > If you're still stuck, I'll break it out and see if I can't   
   > figure out how to determine it reliably at startup.   
      
   I'm not anymore.  Determining the differences was the easy part.  Deciding   
   where I wanted to deal with it (inside the program, or with a smal external   
   program) was the hardest.   As I was not just considering the current   
   program only, but a (possible) slew of future ones as well.   
      
   After I did actually write a full initialisation preamble (to deal with all   
   the situations) I decided not to go that way though.  The end result is that   
   I'm using a small program to fix-up the involved fields in the generated   
   executables file header.  That needs absolutily zero preamble code in the   
   program itself.   
      
   Regards, and thank you for your help.   
   Rudy Wieser   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)