From: address@nospicedham.not.available   
      
   Alexei,   
      
   > the header says the stack space is reserved (minimum   
   > of 100h paragraphs beyond the end of the image,   
   > maximum of FFFFh paragraphs))   
      
   In my case it looks to be 1000h paragraphs (64KB) beyond it - assuming that   
   the SP of zero simply rolls over to the top.   And as the OS just grabs as   
   much memory for the program as it can (subject to the max_extra_paragraphs   
   at offset 0x0C,0x0D ofcourse) that does not strike me as odd.   
      
   > and run it in a debugger to confirm that CS:IP and SS:SP have   
   > the expected values (CS = SS, execution begins with  IP of 0   
   > and SP of 1010h).   
      
   In my case, where I did not specify a stack, the numbers are exactly as   
   expected: Both the SS and SP fields are zero.    Which is confirmed when I   
   display them in my program (I saved them as the first thing in my code).   
      
   > You shouldn't have any issues with SP and BP.   
      
   But, as posted, I have.   As such I do not understand your above assertion.   
      
   > I don't quite see a need for patching the header. That is,   
   > unless you want the .EXE to have DOS allocate less than   
   > allof the available memory to it.   
      
   So I could tinker around with that SS:SP ?   
      
   But yes, I will also set the "max_extra_paragraphs" to   
   "min_extra_paragraphs".   To be honest, I have absolutily *no* idea why you   
   would want to allocate (much, but unknown) more than what the program   
   actually needs.   It only serves to cause problems when you would want to   
   allcoate some memory later on (no memory available anymore, its all in use   
   by the program)   
      
   Damn, I just noticed : "especially in regard to the SS:SP field (offset   
   0x18..0x1B)."  I mentioned the wrong offsets (should have been 0x0E...0x11).   
   :-(   
      
   > I think TLINK should have an option for it, but it   
   > probably doesn't have any form of it.   
      
   Thats the reason. :-)   A screen full of switches (two columns) , but the   
   above does not seem to be one of them.   
      
   > Um... The below works fine for me:   
      
   It does work fine for me too (the OS does set SS to match CS).   But only if   
   I ignore where the stack-based stuff is dumped.   
      
   > You must set up DS and ES (DOS doesn't do this for you),   
      
   Actually, it does.   Its just that they point to the PSP, and not the start   
   of the actual code.   
      
   > I'm not sure I understand the issue fully.   
      
   I want a TINY model, with *all* segments overlapping (SS=ES=DS=CS), for easy   
   access to stack-based data structures.   
      
   Simply said: when I do not specify a stack SP equals zero and I need to   
   change it myself.  When I do declare a stack SS will not match CS, and I   
   also need to change both it and SP as well   
      
   The problem is that I can only do that *after* the local stack-based stuff   
   is initialized.  Which means that SS and BP have values I should not (just)   
   touch.   
      
   > Do you want the entry point code (at label start)   
   > to also be SomeFunction-like?   
      
   An example:   
      
   - - - - - - - - - - - -   
   Main proc   
     uses bx,si,di   
     local @@bBuffer[10h]:BYTE   
      
     mov ax,cs   
     mov ds,ax   
     mov es,ax   
      
   [1]   
      
     lea si,[@@bBuffer]   
      
   - - - - - - - - - - - -   
      
   If SS != CS than SI is *not* pointing to "@@bBuffer".   
      
   If, at point [1], I would want to initialize SS:SP I'm going to have a   
   problem, as the either the "user" or "local" causes an "enter" instruction   
   (or similar) to be emitted, setting BP (toSP) and than lowering SP.   
      
   > Any problem with my code above?   
      
   >  local @@bBuffer[16]:BYTE   
   >    lea     di, @@bBuffer   
   ...   
   >    rep     stosb   
      
   DI points into ES, not SS.  If SS != ES than you're dumping your data at   
   unexpected places.   
      
   Do you have an HexOutWord routine hanging around somewhere ?  Just try this   
   :   
      
   - - - - - - - - - - - - - - -   
     local @@bBuffer[16]:BYTE   
      
     lea     di, [@@bBuffer]   
     mov    ax,1234h   
     stosw   
      
     lea     di, [@@bBuffer]   
     call HexOutWord, dword ptr [di]   ;uses [ES:DI]   
     call HexOutWord, dword ptr [@@bBuffer]   ;uses [BP+offset]   
   - - - - - - - - - - - - - - -   
      
   Assuming you actually specified a stack (and thus(?) SS != CS) The first one   
   will show 1234h, while the latter won't.   
      
   Regards,   
   Rudy Wieser   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)