ASM Community

Registers are a precious resource and the windows OS makes use of most of them. However, sometimes it would be convenient to have another register (apart from ebp) that you can count on API functions preserving AND is not "hands off" from your app's perspective.

Heres an example scenario in Pseudo-asm:

//////////////////////////////////////////

enter WNDCLASS_size, 0

%define wc ebp-WNDCLASS_size

;wc expands to ebp - 40

lea edx,

GetMessage edx,...etc

/////////////////////////////////////////

Now since I can't count on edx being preserved on the other side of the GetMessage call,
I have to do further leas:

///////////////////////////////////////

lea edx,

TranslateMessage edx

lea edx,

DispatchMessageA, edx

///////////////////////////////////////

That is an example of the situation. Windows preserves ebp, but wc is defined relative to ebp
so I can't touch it. I know that Windows also preserves the segment registers but I don't think I can store anything in them without crashing my App. Many have predefined uses (eg FS for exceptions).

What I can do besides storing the effective address in memory or doing
successive leas? Is there at least one other register that I can store temporary data in and assume it won't be modifed until I explicitly change it?

Thanks in advance for your comments.

I am a little hazy on windows' use of the some of the general purpose registers.

BTW, I did check all the popular sources (Iczelion's tutorials etc.)

I didn't know if I was required to preserve ebx as well, before calling an API function.
That would be kind of silly but most of the time windows preserves registers for totally selfish reasons.

Bah...I was just confused, plain and simple...heh.
Thanks for that unambiguous response. (minus the '?') :)

ALL windows API calls preserve ebx, esi, and edi for you.

In the particular example you posted, I would consider using globals instead of locals. That way, you don't need to calculate the effective address and disturb a variable. For example, I always code my WNDCLASSEX and MSG structures as globals.


Of course, there are always cases where you want a register preserved over an API call, but careful programming can sometimes eliminate these situations. For those times where you can't there's ebx, esi, edi


--Chorus

Just making sure ;)

BTW, you could also do some creative pushing to avoid the extra lea, since your going to have to push it later anyways:

lea eax,msg

push eax

push eax

call TranslateMessage

call DispatchMessage

or pushing/popping the value temporarily is pretty cheap

lea eax,msg

push eax

invoke DispatchMessage,eax

pop eax

invoke GetMessage,eax,NULL,NULL,NULL

--Chorus

esi, edi, ebx, ebp, esp
ebp and esp are preserved in prolog of API:
push ebp
mov ebp, esp
sub esp, xx
. . .

and restored in epilog of API:
. . .
mov esp, ebp
pop ebp
ret xx

or
. . .
leave
ret xx

If API is going to alter esi, edi or ebx it is responsible for preserving the value of these registers.
eax, ecx, edx are used by API (if needed) without preservation.

esi, edi, ebx, ebp, esp

eax, ecx, edx without preservation.
And any other (except segment regs) with preservation.

It depends on particular API, on parameters passed to API and many other reasons. But anyway, you should not expect that eax, ecx, edx and flags will be the same after API return. If API returns result (most of API do it), it's returned in the eax register (for 32-bit values), or the edx:eax registers (for 64-bit values). eax is most often used inside the API.

And of course you should play with esp by the rule.
And you must not change segment registers.

I'm hearing all kinds of answers on this.
Personnally I would think that the "USES" clause would handle all of this
but what do I know.

Maybe a tut by EOIN would be in order.

There is only one answer to register preservation in 32 bit windows coding and that is to use the Windows convention that Four-F has described in detail. Write API code any other way and it will be unreliable and subject to crashes on different versions of Windows.

To avoid some of the folklore surrounding this area, any procedure you write that uses EBX ESI EDI !!!!!!! MUST !!!!!!!! preserve them but can modify EAX ECX EDX.

If your procedure calls an API function, you need to remember that that API function can modify EAX ECX EDX as well so if you cannot select EBX ESI EDI for things like counters etc ... preserve them first before calling the API function.

Don't be fooled into thinking there is a simpler or easier way, vary from this Windows convention and risk your code crashing on different windows versions.

There are exceptions in nested procedures that do NOT call API functions and in this instance, you must design your own to work if you do it this way.

Regards,

hutch@movsd.com

So I have to preserve all registars needed by my app after an API call AND I must restore esi, edi, ebx, ebp, esp
before an API call or exiting.

I think that it be more correct to not molest ebp and esp since the all mighty processor manages stackframes with them.

Opps, still in console App mode.