pop before or after ExitProcess.. does it matter?

[uziq]

Should the pops occur before or after invoking ExitProcess?
Thanks in advance. :)

Code Select Expand

push esi
push edi
push ebx

; code

invoke ExitProcess, NULL

pop ebx
pop edi
pop esi

[u]

ExitProcess never returns. So, you can have it anyway.

[GregL]

The pops should occur before invoking ExitProcess.

[MaynardG_Krebs]

Doesn't ExitProcess halt the program? It would seem as if ExitProcess was invoked before the pops then the register values would not be restored.

[PBrennick]

It does not halt anything. It destroys the window and returns its resources back to the system. There is a lot more that goes on but that is what you see happen.

The point that Greg made is a good one. You must remember that there is no protection between the code and the OS unlike some languages that use runtime modules. In assembly, the cpu executes your code with no regard as to whether it is valid or not so it is very important that you work to develop certain habits.

1. Always restore any registers that you have preserved.
2. Always return any additional memory that you may reserve.
3. Always destroy any resources you may create in the asm source; icons, controls, windows, dialogs, etc. etc., etc.
4. Always take the advice you get from the forum seriously. It is okay to question but it is a lot better if you test the advice and
   THEN ask questions.

There should be more in the list probably but it is almost 2:00am and I am beat. Just wanted to help.
Paul

[hutch--]

I concur with both Greg and Paul on this issue, there are occasions where you can get away with leaving a procedure without balancing the stack or restoring system defined registers but it teaches you bad habits that can come back to haunt you. How often we have all seen someone who gets a program going on one OS only to have it crash on another due to incorrect register preservation and restoration. Do it the right way the first time and it never fails on you.

[lingo]

ExitProcess allows the DLL to execute cleanup code and free all the virtual
memory space of the process (including memory space for the "stack"), close all handles, etc.
Hence, ExitProcess doesn't care and no reason to check about "balancing the stack" and "restoring the registers"

Example:
push 7
call ExitProcess

So,in the begin of the ExitProcess API we have two values in the stack:
return value from the call and 7 as a parameter of the ExitProcess API.
Hence we have unbalanced stack?
Why?
Because "ExitProcess never returns"
Hence, "return value from the call" unbalance the stack...  :lol


About "restoring the registers":

When DispatchMessage API transfers control to the WndProc CALLBACK proc
and if we use EBX,ESI,EDI,EBP registers in it we should preserve them because
WndProc is a CALLBACK proc.
It is true for all Windows CALLBACK procs ONLY.

In the Main proc we can use EBX, ESI,EDI registers WITHOUT preservation
because it is NOT a CALLBACK proc. We call ExitProcess from Main too.. :lol

[TNick]

In the Main proc we can use EBX, ESI,EDI registers WITHOUT preservation
because it is NOT a CALLBACK proc. We call ExitProcess from Main too.. :lol

So, there's no need for this, either?

Code Select Expand

.CODE
App_Entry_Point:
push esi
push edi
push ebx

...


pop ebx
pop edi
pop esi
INVOKE ExitProcess, ExitCode
END AppEntryPoint

Nick

[PBrennick]

When we are trying to teach good coding habits there is always some ----- who comes along and, well you know.

Paul

[hutch--]

I have split this topic because the latter content was not suitable for the Campus. The topic is now in the Workshop under the title "Lingo on code design" so that those who are interested in the discussion can read it and contribute to it.

Th Campus has rules specific to how assistance is given and it does not allow extended discussion in this context as it annoys the people learning assembler programming.