I'm at my wits end trying to figure this out. I'm hoping someone out there can help me identify my faults. All I wanted to do was to take an example from the MASM32 world and convert it to GoASM using RadASM 3.x. So far, all I've managed to do is pull my hair out.
My latest build has developed even more quirks and bugs that I can't seem to figure out.
(http://img52.imageshack.us/img52/3334/needhelpscr1.png) (http://img52.imageshack.us/i/needhelpscr1.png/)
Would someone please take a look at my project and tell me what I'm doing wrong?
I very much appreciate any help I can get.
Thanks,
-Shooter
Let's clean it up step by step until it's working properly and we need to begin the DlgProc
DlgProc FRAME hWin,uMsg,wParam,lParam
LOCAL ts:TC_ITEM
**** ENTER CONTIONAL HERE TO DETERMINE IF MESSAGE IS "WM_INITDIALOG" ***
.WM_INITDIALOG
cmp D[uMsg],WM_INITDIALOG
jne >>.WM_NOTIFY
What is happening here, is that every message is being passed to WM_NOTIFY except WM_INITIDIALOG. This is why the app hangs as it doen't respond properly to WM_DESTROY or WM_QUIT
Quote from: Tight_Coder_Ex on December 17, 2010, 06:27:04 PM
What is happening here, is that every message is being passed to WM_NOTIFY except WM_INITIDIALOG. This is why the app hangs as it doesn't respond properly to WM_DESTROY or WM_QUIT
I'm not sure I follow what you're saying. Isn't that what needs to happen? Do I need to add conditionals for the WM_DESTROY and WM_QUIT messages?
Sorry about that, not being used to GoAsm, I didn't immediately see the logic. In any event;
1. App gets hung on WM_PAINT, for the main window, but window is not visible. Suspect resource template incorrect
2. Your missing code to handle WM_COMMAND, but because the main window doesn't display, mute anyway
3. There are quite a few inconsistencies, between the original and what you've done, espcially in the resource files.
Go through everything and make sure your doing it the same as the original and I'm sure you'll find the problem.
Question about the resource editor in RadASM 3.x:
Does the number in the xStyle have greater or lesser importance than the settings of each of the other variables?
If I set the xStyle number to 50000000 for the 1st tab (40000000 for the 2nd and 3rd tabs), and
then set the Border to 'Flat', the xStyle reverts to D0000000 for the 1st tab (C0000000 for the 2nd and 3rd tabs). This does not happen in RadASM 2.x.
Quote from: Tight_Coder_Ex on December 17, 2010, 09:06:36 PM
3. There are quite a few inconsistencies, between the original and what you've done, especially in the resource files.
That's just the thing. I've gone over and over and over the code and haven't found anything that sticks out.
I've compiled the original and linked it without modification and it worked as expected, so there has to be something you've missed.
I'm not familiar with the tools you're using, so can't be of much help there
It took me a while to figure out why I kept getting this error when attempting to compile the original MASM32 demo project in RadASM 3.0.0.7g:
LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
It turns out that in RadASM the default set of paths for masm was .\masm\ instead of .\masm32\. Once I changed that everything compiled correctly AND just like you, the program does as advertised.
But I still haven't found why my conversion to GoASM has failed so miserably.
Sadly, based upon my experiences I think I'm just about to give up on GoASM. MASM32 seems to be more widely accepted, documented, and supported.
i thought *Witt's End* was an anteroom in a cave :P
Quote from: dedndave on December 18, 2010, 04:02:26 PM
i thought *Witt's End* was an anteroom in a cave :P
Always the funny one, you are.
The problem is obvious, default messages are not handled in any of the 4 procedures.
Tab2Proc FRAME hWin,uMsg,wParam,lParam
cmp D[uMsg],WM_INITDIALOG
jne >.WM_DEF ; on last message
; do stuff
jmp >.EndTab2Proc
.WM_DEF
xor eax, eax
ret
.EndTab2Proc
mov eax,TRUE
ret
endf
Quote from: ramguru on December 18, 2010, 04:42:16 PM
The problem is obvious, default messages are not handled in any of the 4 procedures.
Tab2Proc FRAME hWin,uMsg,wParam,lParam
cmp D[uMsg],WM_INITDIALOG
jne >.WM_DEF ; on last message
; do stuff
jmp >.EndTab2Proc
.WM_DEF
xor eax, eax
ret
.EndTab2Proc
mov eax,TRUE
ret
endf
Is this a GoASM thing? Because the original MASM code does not have that 'trap', and it compiles and runs just fine without it.
Tab2Proc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
.if uMsg==WM_INITDIALOG
.else
mov eax,FALSE
ret
.endif
mov eax,TRUE
ret
Tab2Proc endp
sure it does!!! else.... mov eax, false tells the dialog handler that you didn't process all other messages
Quote from: Gunner on December 18, 2010, 05:40:56 PM
sure it does!!! else.... mov eax, false tells the dialog handler that you didn't process all other messages
Not processing all the other messages and not needing to process all the other messages appear to be two different things, to me at least. The original example does not process the WM_DEF message, other than to say 'False', so I'm wondering why I would need to process it in my converted GoASM project any differently. What's the difference between the two different assemblers? Furthermore, what would I need to do when WM_DEF is encountered to make this work?
everything that starts with dot is a label (the name doesn't matter) .WM_DEF f.e. is like .ELSE .. but the point is:
for all messages that you handle you return 1
and for all that you don't you return 0
Hi Shooter, i,m not an expert or anything, but here is a working example, it may not be pretty, but it works on my Win7 64 bits box, no overhead on the processor. :bg
i have changed the TCITEM structure, because had some issue with the old one, the newer version seems to work just fine.
http://msdn.microsoft.com/en-us/library/bb760554%28VS.85%29.aspx (http://msdn.microsoft.com/en-us/library/bb760554%28VS.85%29.aspx)
ps you should preserve at least edi, i have changed it from eax to edi in the example code.
DlgProc frame hWnd,uMsg,wParam,lParam
uses ebx,edi,esi
or
push ebp
mov ebp,esp
push ebx,edi,esi
or
So, does this code:
Tab1Proc FRAME hWin,uMsg,wParam,lParam
cmp D[uMsg],WM_INITDIALOG
jne >.EndTab1Proc
mov eax,TRUE
ret
.EndTab1Proc
mov eax, FALSE
ret
endf
do the same thing as the original MASM32 code:
Tab1Proc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
.if uMsg==WM_INITDIALOG
.else
mov eax,FALSE
ret
.endif
mov eax,TRUE
ret
Tab1Proc endp
Not too sure on GoASM syntax...
should be something like:
cmp uiMsg, WM_INITDIALOG
; its the initdialog message, handle it
je _INITDIALOG
; all other messages, fall through
PassThrough:
xor eax, eax
ret
_INITDIALOG:
; Do something
mov eax, TRUE
ret
I am curious as to why the original code:
Tab1Proc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
.if uMsg==WM_INITDIALOG
.else
mov eax,FALSE
ret
.endif
mov eax,TRUE
ret
Tab2Proc endp
wouldn't have been written like this:
Tab1Proc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
.if uMsg==WM_INITDIALOG
mov eax,TRUE
ret
.else
mov eax,FALSE
ret
.endif
Tab1Proc endp
I mean, the first example seems confusing if the second example works.
Secondly, in GoASM is there a difference between FRAME and PROC??
Tab1Proc FRAME hWin,uMsg,wParam,lParam
cmp D[uMsg],WM_INITDIALOG
jne >.EndTab1Proc
mov eax,TRUE
ret
.EndTab1Proc
mov eax,FALSE
ret
endf
You could write it both ways.... I guess... but after you process the initdialog, it falls through the .if/endif and executes what is after the .endif
Quote from: Gunner on December 19, 2010, 03:10:46 AM
You could write it both ways.... I guess... but after you process the initdialog, it falls through the .if/endif and executes what is after the .endif
Unless it hits a return statement, right?
Here's something that's interesting.
This (GoASM):
Tab1Proc FRAME hwnd,uMsg,wParam,lParam
cmp D[uMsg],WM_INITDIALOG
jne >.EndTab1Proc
mov eax,TRUE
ret
.EndTab1Proc
mov eax,FALSE
ret
endf
Translates to this in OllyDbg:
CPU Disasm
Address Hex dump Command Comments
00401030 |$ 55 PUSH EBP ; Tab1Proc FRAME hwnd,uMsg,wParam,lParam
00401031 |. 89E5 MOV EBP,ESP
00401033 |. 817D 0C 10010 CMP DWORD PTR SS:[EBP+0C],110
0040103A |. 75 09 JNE SHORT 00401045
0040103C |. B8 01000000 MOV EAX,1
00401041 |. 5D POP EBP
00401042 |. C2 1000 RETN 10
00401045 |> B8 00000000 MOV EAX,0
0040104A |. 5D POP EBP
0040104B \. C2 1000 RETN 10
Whereas, this (Masm32):
Tab1Proc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
.if uMsg==WM_INITDIALOG
.else
mov eax,FALSE
ret
.endif
mov eax,TRUE
ret
Tab2Proc endp
Translates into:
CPU Disasm
Address Hex dump Command Comments
00401030 |$ 55 PUSH EBP ;Tab1Proc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
00401031 |. 8BEC MOV EBP,ESP
00401033 |. 817D 0C 10010 CMP DWORD PTR SS:[EBP+0C],110
0040103A |. 75 02 JNE SHORT 0040103E
0040103C |. EB 09 JMP SHORT 00401047
0040103E |> B8 00000000 MOV EAX,0
00401043 |. C9 LEAVE
00401044 |. C2 1000 RETN 10
00401047 |> B8 01000000 MOV EAX,1
0040104C |. C9 LEAVE
0040104D \. C2 1000 RETN 10
Other than the "POP EBP" vs. "LEAVE" stack changers, they are practically the same code, assuming the RETN 10 does it's job correctly in the GoASM sample. That is, unless the coffee has worn out and my eyes are crossed. :eek
I've made a discovery and started a new thread. http://www.masm32.com/board/index.php?topic=15690.0