Hi everybody,
I always liked TASM and its IDEAL mode, so after it 'died', the only assembler with similar syntax is FASM. Infortunately I have very strange problem with it. I want create window (without any controls/menus) but after I run my program I getting beautiful window (developed by Microsoft) which ask me if I could send report (Access violation after executing CreateWindowEx first time). Source looks correct (however in C++ it worked). What I can say is that when hMenu parameter is set to '0h' function cause access volation, when param is EAX(which contain '0h') function return NULL. Any suggestion?
;Program source is in attachement.

Problem with your program was rather uncommon. Try to replace 'RET' from line 57 with 'ret' (in lowercase). This will prevent from crashing.
But why it works now? Because 'ret' in proc macro is redefined (it becomes a macro too). Preprocessor is case-sensitive, so it replaces 'ret' properly, while it doesn't touch 'RET'. This, in your situation, leaves stack unballanced, therefore causing crash.
Alternaively, you can add line with "RET fix ret" in the beginning of your code, if you want to have every instruction written in uppercase.

without macroinstructions 'ret #_of_bytes_passed' will balance the stack, you can use cdecl style convention and do add esp, # after the call aswell

LZASM has the same syntax as TASM in ideal mode
and i am also (very slowly) working to an TASM like assembler

Not in this case - it's a window procedure.

If this:



How does this matter?

It matters because window procedure can't be cdecl.

he is refering to the stack, and ret # in relation to it. IMHO.
the inference that he is talking about the windowproc is wrong, and his
reference to cdecl stays within that reference since he uses *aswell*.

just semantics.

Guys, with window procedures there is an exception in OS programs were your program is even *lower* than the kernel, because what happens here is that USER32.DLL calls your procedure and when ret happens - it goes back to user32. You can't do 'add esp,const' to adjust it because you have no control over it.

There have been many problems before about unbalancing stack before leaving window proc or changin ebx which seems to be a 'safe' register. Eventually it will crash.

"You can't do 'add esp,const' to adjust it because you have no control over it. "

ok here is my comment in tarzan english:
(comment about stack and ret, no about winproc, must save jane)

I apologize for posting, I was only confused by the english syntax.

WOW!

I didn't think that the problem can be the 'ret' instruction in that line (I fought that I made a mistake in line between: 10 - 27). I began think it is something wrong with Fasm or me. Anyway it is good to know that fasm overwrite ret instruction in macros (with macro ). THANKS