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,563 of 4,675    |
|    R.Wieser to All    |
|    Re: EXE program stack setup questions    |
|    08 Oct 18 09:06:50    |
      From: address@nospicedham.not.available              Rick,              > I don't understand.              You don't *have* to. You just have to accept that those are the facts, and       work from there.              If you want I can provide you with the values of all the registers you want,       but those will just support what I've been saying. If you want me to add       specific pseudo-ops to my code to see what the result is than I can       accomodate you too.              > I think that's an error in the loader,              If you mean by "loader" the program that actually loads the program than       thats XPsp3.              > or there's some startup code being injected by TASM to handle some kind of       > "fixup" at startup.              Shouldn't you just ASK ?              FYI: Tasm doesn't inject such code. Its an *assembler*. And yes, just to       make *very* sure I took another peek. The code is exactly as I wrote it.              But, I've added some .LST file output at the end, together with some       register values. Maybe that will allow you to understand.              > If I recall correctly, you can set it up that way manually       > (from memory, untested):              In other words, just point it about 64KB away from the start of the program,       regardles of if that memory is actually owned by the program ? Don't you       think that that would be a stupid thing to do ?              Besides the point that in the parent of the message you first responded to       I've put some code to show why such a simple solution would create a problem              And here we go *again* : because stuff has already been put on the stack       (like local storage), resulting in both BP and SP being altered/in use.              I described that in the first message (go read it!), in an attempt to       pre-empt exactly the song-and-dance you and I are now doing. :-(              Regards,       Rudy Wieser              -- Code example, stack defined, no stack-based storage              17 0000 Main proc       18 0000 2E: 8C 0E 00D0r mov [cs:OldCS],cs       19 0005 2E: 8C 16 00D2r mov [cs:OldSS],ss       20 000A 2E: 89 26 00D4r mov [cs:OldSP],sp       21 000F 2E: 89 2E 00DEr mov [cs:OldBP],bp              CS=0DD4 SS:SP=0DD4:0000 BP=091E              -- Code example, no stack defined, with stack-based storage       17 0000 Main proc       18 local @@Data[6]:BYTE       19       20 0000 C8 0006 00 ENTERW 00006h,0       21 0004 2E: 8C 0E 00D4r mov [cs:OldCS],cs       22 0009 2E: 8C 16 00D6r mov [cs:OldSS],ss       23 000E 2E: 89 26 00D8r mov [cs:OldSP],sp       24 0013 2E: 89 2E 00E2r mov [cs:OldBP],bp              CS=0DD4 SS:SP=0DD4:FFF8 BP=FFFE              In this code fragment you can see the local storage definition at line 18,       and the emitted code for it at line 20. The first actual instruction I've       written is now at line 21.              And please do compare the SP and BP contents of both fragments. Also       notice that, in the first code sample, SP is actually *zero* when no stack       has been defined (and accordingly adjusted in the second code sample)              --- 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