what are the problems, mainly, I must to care for that an program.exe run correctly with windowsXP?

I maid a .exe file with mASM32 with windows98SE, and a friend has problems to run it correctly on windowsXP Pro;

ex :there is an item menu which is not responding; normally this item open an DialogBox and my friend cann't see it, then on my computer there is no problem!!!!
Posted on 2002-05-30 10:12:29 by franlou
Hi franlou,

While it'd be impossible to list the differences between the two which cause bugs, even for Microsoft themselves, it usually is a problem of not clearing a structure before use or a typo in the API call somewhere.

If you can post some source I'm sure the community would help you track down this nasty bug, however without anything to look at all we can suggest is make sure your code is right, which I'm sure you agree is not very useful advice.

James
Posted on 2002-05-30 10:30:50 by JamesE
franlou,

add the code XOR EAX, EAX at the end of the message handling proc so that the return value is zero. That should fix the problem.

Regards,

hutch@movsd.com
Posted on 2002-05-30 10:49:57 by hutch--
to hutch
what do you call "end of the message handling proc "?

I am french and I don't understand the subtlety of english language
my procedure is the Wnd Procedure where ther is a line with

.elseif eax== WM_COMMAND

.if lParam==0

it is here that I handle the menu item;
.else
here I handle the notification mesage
.endif
Posted on 2002-05-30 13:41:28 by franlou
Make sure you are following the register saving conventions:

When calling APIs, EAX, ECX, and EDX can be trashed.

When creating callbacks like a window proc or a dialog proc, you must save and restore EBX, ESI, and EDI if you use them. If you use PROCs, EBP and ESP will be taken care of automatically.
Posted on 2002-05-30 14:37:29 by tenkey
Hello,

What Hutch meant by "end of the message handling proc" was that:

xor eax, eax
ret

would be the last two lines of your proc. For example using your puesdo code from above it would look something like this:


.elseif eax== WM_COMMAND

.if lParam==0

it is here that I handle the menu item;
.else
here I handle the notification mesage
.endif

xor eax, eax
ret


What is really happening here is that your processing the message through your if statements, which is what you've done, but once the execution is done there, it exits the if statements. Now to tell windows that you did actually process the message it sent (in the form of a WM_COMMAND message), you have to return zero which is what the xor eax, eax portion of the code does and by not xor'ing eax (zeroing it), you may get unexpected results because whatever is in eax when the 'ret' opcode executes will be sent to windows, which in turn Windows will decide to do something like not show a window or possibly even crash, who knows.

James
Posted on 2002-05-30 15:46:20 by JamesE
When I shifted from 98SE to XPCP I found about 50% of my compiled executables were wigging out on me.

I installed MASM on the XP box, and then I recompiled the executable source without ANY modifications under XP.

The executables now worked fine on XP , and now they worked on all the windows platforms.

I assume it's something to do with the exe header because my executables are the same bytelength, though I never looked into it, happy in the knowledge that my apps were working again.
Posted on 2002-05-31 00:03:08 by Homer
I found my error
I put twice hInstance in statement!!!:

invoke DialogBoxParam, hInstance, ADDR DlgAbout,hInstance,ADDR AboutProc,NULL

I put the hWndParent who

Identifies the window that owns the dialog box : 'hMainWnd' to third parameter and it's ok.
excuse me
Posted on 2002-05-31 12:50:22 by franlou
tenkey,

I had no sleep for the past 32 hours because.... ECX, and EDX will not trash depending...

I got a simple find window hook for all IE Broswers and others. It was perfect-toe...Then i added more PROC and it went NUTS ...

Than i put XOR everywhere ( in the right places AND WRONG to be sure ) and woud you know it....ECX, and EDX kelp the same API symbols ALL OVER THE PLACE regardless where i put XOR's... Now i screwed the whole da*m thing UP.

Is there something else OTHER THAN XOR

LIKE JZ>= trash that JUNK.... anyone know who..... This is no JOKE.Posted on 2002-05-31 15:49:33 by cmax
xor eax,eax simply makes eax=0

same as mov eax,0 but takes less opcodes and therefore less processing time

or eax,eax is not the same as xor and in fact or eax,eax = eax

remember when xor'ing like mad that sometimes a routine 'needs' to return a value and it would be very bad to set to zero.

i ye olde days before invokes and these lovely things you had to be very careful of pushing and popping the right things on and off the stack, sometimes you needed to leave something on the stack other times not.

Check the docs on the invokes you are using to make sure what needs to come back....

often a whole program will go completely nuts because of one tiny little mistake , like writing data over your own code :-)
Posted on 2002-06-05 10:19:42 by Terab
franlou,

I got caught years ago with this one and its why I remember it. Win95 did not exhibit the problem when you forgot to put ZERO in EAX before returning from the message handling procedure where NT4 would not display the dialog properly.

The specification in a dialog message handler is to return ZERO so before the RET as James mentioned, use XOR EAX, EAX to zero EAX.

In MASM, the beginning is,


WndProc0 proc hWin :DWORD,
uMsg :DWORD,
wParam :DWORD,
lParam :DWORD

The end is,


xor eax, eax ; this must be here in NT4 and later
ret

WndProc0 endp

Regards,

hutch@movsd.com
Posted on 2002-06-05 11:06:33 by hutch--