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,552 of 4,675   
   Alexei A. Frounze to R.Wieser   
   Re: EXE program stack setup questions   
   07 Oct 18 02:40:47   
   
   From: alexfrunews@nospicedham.gmail.com   
      
   On Sunday, October 7, 2018 at 1:11:16 AM UTC-7, R.Wieser wrote:   
   > Alexei,   
   >   
   > > This seems to work.   
   > > [snip]   
   >   
   > It does.  Its what I tried to describe with #1.   
   >   
   > The problem with it is that SP is not set up (its zero) and thus needs to be   
   > initialized by the program.   
      
   If you're referring to my code, SS:SP is properly   
   set up in it by DOS. I've checked the .EXE header   
   (the header says the stack space is reserved (minimum   
   of 100h paragraphs beyond the end of the image,   
   maximum of FFFFh paragraphs)) 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).   
      
   >  Which causes all kinds of trouble when using   
   > "uses {registers}" (pushing registers on the stack and auto-popping them   
   > before leaving the procedure) and possibly also when using "local {some data   
   > declaration}", as that automatically sets up BP and moves SP down.   
      
   You shouldn't have any issues with SP and BP.   
      
   ...   
   > By the way, I'm going to see if I can do something with patching the   
   > EXE-files header, especially in regard to the SS:SP field (offset   
   > 0x18..0x1B).   
      
   I don't quite see a need for patching the header. That is,   
   unless you want the .EXE to have DOS allocate less than all   
   of the available memory to it (that maximum number of   
   paragraphs allocated beyond the end of the .EXE image).   
   I think TLINK should have an option for it, but it probably   
   doesn't have any form of it.   
      
   > To give an idea of the build-in handies that Tasm offers take a look at the   
   > below:   
   >   
   > - - - - - - - - - - - - - - -   
   > SomeFunction proc   
   >   arg @@wArg1:WORD,@@wArg2:WORD   
   >   uses bx,si,di   
   >   local @@bBuffer[16]:BYTE   
   > ....   
   >   ret   
   > SomeFunction endp   
   > - - - - - - - - - - - - - - -   
   >   
   > "arg" allows pushed arguments to be referred to by their respective labels   
   >   
   > "uses" pushes the mentioned registers (and memory), which get auto-popped   
   > when leaving the procedure, just before a(ny) RET)   
   >   
   > "local" allows declared local storage to be referred to by their respective   
   > labels.   
   >   
   > the RET is automatically emitted as a RET {stack skip}, calculated from the   
   > declared "arg"s at the top   
   >   
   > The problem is that the above three *must* be used before any instructions.   
   > And thats includes setting up the segment registers and initializing the   
   > stackpointer.   
      
   Um... The below works fine for me:   
      
   myseg segment para stack 'stack' use16   
       assume cs:myseg, ds:myseg, es:myseg, ss:myseg   
   start:   
       mov     ax, cs   
       mov     ds, ax   
       mov     es, ax   
      
       push    ax   
       push    bx   
       call    SomeFunction   
       add     sp, 4   
      
       mov     ax, 4c00h   
       int     21h   
      
   SomeFunction proc C   
     arg @@wArg1:WORD,@@wArg2:WORD   
     uses bx,si,di   
     local @@bBuffer[16]:BYTE   
       lea     di, @@bBuffer   
       mov     cx, 16   
       xor     al, al   
       cld   
       rep     stosb   
       mov     ax, @@wArg1   
       add     ax, @@wArg2   
       ret   
   SomeFunction endp   
      
       align 16   
       db 4096 dup (?)   
   myseg ends   
      
   end start   
      
   You must set up DS and ES (DOS doesn't do this for you),   
   but you do it once and it does not interfere anyhow with   
   SomeFunction and the likes of it.   
      
   I'm not sure I understand the issue fully.   
   Do you want the entry point code (at label start) to   
   also be SomeFunction-like? If so, most (if not all)   
   executables produced by HLL compilers like C compilers   
   typically include some startup code to query the OS   
   capabilities and initialize this and that before   
   any regular HLL routine can execute, including   
   C's main().   
   Specifically, for C's main() you'd need to prepare its   
   argc and argv[] arguments on the stack and some code   
   needs to do that, to e.g. examine the .EXE's PSP   
   (if we're talking DOS). That code would set up DS and   
   ES too. As for SS:SP, it's been taken care of.   
      
   Any problem with my code above?   
      
   Alex   
      
   --- 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