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