Are they put onto the stack or into full/low/high registers ?

Thank you.
Posted on 2011-07-26 09:51:01 by Chuck Sausage
Homework question? Nope don't do those here. The return value is in the same place majority of the API calls use.
Posted on 2011-07-26 11:15:45 by Gunner
Thanks for the answer, that's not for homework. I just can't find them by looking at the previous stack addresses and so I'm asking.
Posted on 2011-07-26 12:17:22 by Chuck Sausage
That's because it returns the value in eax and not in the stack.
Posted on 2011-07-26 12:28:01 by JimmyClif
Aye, that's what I expected when I viewed the value stored into eax, but still it is that I can't manage to figure out what value is returned by eax, it obviously seems to be a pointer, but I don't know what to do with this value.

The API documentation @ http://msdn.microsoft.com/en-us/library/ms645465(v=vs.85).aspx doesn't help me much.

To be clear, I would just like to retrieve the uMsg parameter, eventually lParam but without using procedures, just the raw code.
That's how I thought that at each execution of the dialog box procedure, the parameters lParam, wParam, uMsg and finally the handle were pushed onto the stack. (True ?)
Posted on 2011-07-26 12:52:48 by Chuck Sausage

Aye, that's what I expected when I viewed the value stored into eax, but still it is that I can't manage to figure out what value is returned by eax, it obviously seems to be a pointer, but I don't know what to do with this value.

The API documentation @ http://msdn.microsoft.com/en-us/library/ms645465(v=vs.85).aspx doesn't help me much.

To be clear, I would just like to retrieve the uMsg parameter, eventually lParam but without using procedures, just the raw code.
That's how I thought that at each execution of the dialog box procedure, the parameters lParam, wParam, uMsg and finally the handle were pushed onto the stack. (True ?)


Return Value

INT_PTR

If the function succeeds, the return value is the value of the nResult parameter specified in the call to the EndDialog function used to terminate the dialog box.

If the function fails because the hWndParent parameter is invalid, the return value is zero. The function returns zero in this case for compatibility with previous versions of Windows. If the function fails for any other reason, the return value is 1. To get extended error information, call GetLastError.


Basically it says, if all goes well, the return value is whatever value the dialog specified when it closed itself with EndDialog().
What part don't you understand?

I think you want to look at the DialogProc instead though, if you're interested in messages and lparams.
That's where window messages come in during the lifetime of the dialog:
http://msdn.microsoft.com/en-us/library/ms645469(v=vs.85).aspx

DialogBoxParam just creates the dialog, and won't return until the dialog is closed.
Posted on 2011-07-26 15:52:11 by Scali
I'm stuck into the dialog procedure, I can do whatever I want in it but leave the program after clicking on a button.

Let's say my exit button ID is 1010.

While in the procedure, I would like to know if the exit button is pressed, so I can leave the program, which is what I can't manage to resolve. Also, as I said, I don't want to use the proc / endproc directives.

I hope it's not too confusing.
Posted on 2011-07-26 19:23:56 by Chuck Sausage

I'm stuck into the dialog procedure, I can do whatever I want in it but leave the program after clicking on a button.

Let's say my exit button ID is 1010.

While in the procedure, I would like to know if the exit button is pressed, so I can leave the program, which is what I can't manage to resolve. Also, as I said, I don't want to use the proc / endproc directives.

I hope it's not too confusing.


I take it you are a greenhorn to Assembly?  I HIGHLY recommend you use the proc/endproc macros.  If you just uses labels, you will have to take care of the stack yourself and will run into bugs.  Don't try to be "elite" until you learn more about Asm.  Some great tuts are here: http://win32assembly.online.fr/tutorials.html

To answer your question, well that tut will, but you handle the WM_COMMAND messages in your WinProc  I forgotton which param will have your button ID wParam or lParam, when you get that message from your button, you call EndDialog.  I highly recommend you look into downloading the PSDK from Microsoft.

Personally, I think this is easier to read:

CurrentlyOnline PROC
    LOCAL szHostName[256] :BYTE
   
    invoke gethostname, ADDR szHostName, 256
    .IF eax == SOCKET_ERROR
        xor eax, eax
        ret
    .ENDIF
    invoke gethostbyname, addr szHostName
    .IF ! eax
        xor eax, eax
        ret
    .ENDIF
    mov eax, dword ptr
    mov eax, dword ptr
    mov eax, dword ptr
    sub eax, 1 * 256 * 256 * 256 + 127
    ret
CurrentlyOnline ENDP


then this:

IsCurrentlyOnline:
    enter 256, 0
       
    push 256
    lea eax,
    push eax
    call gethostname
    test eax, eax
    js Nope
   
    lea eax,
    push eax
    call gethostbyname
    test eax, eax
    jz Nope
   
    mov eax, dword ptr
    mov eax, dword ptr
    mov eax, dword ptr
    sub eax, 1 * 256 * 256 * 256 + 127
    jmp Done
   
Nope:
    xor eax, eax
   
Done:
    leave
    ret


Especially when you get into the the WinProcs with MANY lines of code  :lol:

I code both ways, depending on how I feel
Posted on 2011-07-26 20:48:05 by Gunner
Good day.

A "greenhorn" ? Oh, I don't think so, however I'm just unexperienced with the win32 API and DialogBoxParamA is, for now, the only function which gets in my way. I tried all the possibilities which got in my mind just to resolve the problem, without success.

And talking about the procedures, I find them unclean, it kinda digusts me when I see a full line of arguments after a proc directive.
Same for the invoke instruction, I'm feeling good pushing the parameters myself, as I always keep a track of the stack when coding.
Posted on 2011-07-27 06:14:37 by Chuck Sausage
What don't you understand about the DialogBoxParam procedure?  It tells windows to send all messages to the DialogProc callback that you define. Remember, you HAVE to save edi, edi, ebx, ebp, esp in the proc.  It is where you handle ALL the WM messages and NM messages that you need to handle.  Scali gave you 2 MSDN links that tells how to use both.
Posted on 2011-07-27 10:26:36 by Gunner

Remember, you HAVE to save edi, edi, ebx, ebp, esp in the proc.


Aaaaahh, finally ! I think this is what I was looking for. At least, if I understand you, each parameter (wparam,lwparm,usmg etc...) are stored into these following registers : (ebx,edi,ebp and... and the stack pointer, or at the address pointed by that pointer ?!)


And here's what you're probably all waiting for from me :

I call DialogBoxParamA, indicate the box ID and a pointer to the label which will be constantly called to return messages.
Now I'm stuck into the said label, I can't retrieve the WM_CLOSE message, which prevents me from destroying the dialog.



push 0
push DialogProc ; <--- Push the pointer to the label
push 0
push 1000 ; <--- Push the ID corresponding to my dialog box.
push 0
call DialogBoxParamA ; <--- Execute the function, my EAX register is now filled with nResult, okay, goto DialogProc.
push 0
call ExitProcess

DialogProc: ; <--- This is where I'm stuck, I've got no idea on how to retrieve
            ; the message supposed to tell me if the user wants to  terminate the program.
    xor eax,eax ; <--- Also, why does the dialog box render badly if I don't reset EAX ?
    ret



For now, I put nothing in the label except the xor instruction just not to look dumb.
Posted on 2011-07-27 11:12:48 by Chuck Sausage
No the API's use STDCALL not FASTCALL.  Everything is pushed on the stack NOT regs.
the hWnd of your dlg is at ebp+8
the msg is ebp+12
wParam == ebp+16
lParam == ebp+20

You have to compare ebp+12 to WM_CLOSE, simple....  You REALLY should, no HAVE to read the tuts at the link I posted, plus http://www.asmcommunity.net/book/

and what you have won't work, you need to pass the hInstance of your app, and the address of the label.

Why does the dialog render badly?  Read the docs that scali pointed you to.. it tells you, there are 2 values you HAVE to return for different reasons, true and false.
Posted on 2011-07-27 11:29:26 by Gunner
You say you think procedures with a list of arguments are unclean, but they'd make accessing your message a lot easier.
You don't need to keep track of the relative addresses of the parameters on the stack manually.
I would suggest looking at this tutorial:
http://win32assembly.online.fr/tut10.html

Edit: No, forget that suggestion, I changed my mind.
I think you are trying to learn two things at the same time here:
1) Assembly programming
2) Win32API programming

You should tackle them one at a time. Currently you are running into problems because:
1) You don't know how to properly pass parameters between procedures.
2) You don't know what parameters you should be passing to these procedures.
That's like trying to solve a mathematical equation with too many unknowns... It can't be done.

So I would suggest either:
1) Start simple, don't dive into making dialogboxes etc right away. Start with the basics of assembly programming... manipulating registers, the stack, calling subroutines etc.
2) If you know any other programming language, build the program in that language first, using the Win32API. Once that works, try translating it into asm.
In fact, perhaps you should consider learning a bit of C first. The Win32API and its documentation are aimed at C-programmers, so it's easier if you 'speak their language'. C is a simple, uncomplicated language, and once you know C, the step to assembly is not that large.
Posted on 2011-07-27 11:34:05 by Scali

No the API's use STDCALL not FASTCALL.


For more information about the various Calling Conventions, Chuck, reference Agner Fog's Calling Conventions PDF.
Posted on 2011-07-27 11:45:23 by SpooK
Problem solved, I've found uMsg at offset 12 from the stack pointer and could finally exit my program.
Thanks Gunner, your last reply put me on the right way, I just don't get why these params are dwords, oh anyways.

Thanks for the help !

PS : Funny how only one word can resolve a problem while I'm suggested to learn tons of things I probably don't need.
PSS : Congratulations on the NASMx Project, this is my favorite IDE !
Posted on 2011-07-28 10:13:17 by Chuck Sausage

PS : Funny how only one word can resolve a problem while I'm suggested to learn tons of things I probably don't need.


I never suggest things you don't need. Perhaps you don't see why you need it yet... But think again: why didn't you know where to look for the message? Have you really learnt why esp+12 is the place for the message this time, and can you also solve the problem for any other API function?
Or did you just take the esp+12 suggestion from Gunner without a deeper understanding?

Let's have a pop quiz then...
http://msdn.microsoft.com/en-us/library/aa363858(v=vs.85).aspx
Where would lpSecurityAttributes be on the stack? And why?
Posted on 2011-07-28 11:00:37 by Scali
Shouldn't the question be where on the stack would dwCreationDisposition be?
Posted on 2011-07-28 11:48:22 by Gunner

Shouldn't the question be where on the stack would dwCreationDisposition be?


That would also be interesting... as would the address of any member value of the SECURITY_ATTRIBUTES structure...
Posted on 2011-07-28 12:38:01 by Scali