A simple test app creates a window and places a static label on it. I built the thing in C and had the compiler generate assembly code. I converted the assembly code to fasm format and built the same app using fasm. When I run the app under WinXP, I get different results.

The C version gives me grey backgrounds for the static label. Grey is the default, and the rest of the window looks OK.

The fasm version gives me a white background for the static label. The rest of the main window has a grey background.

It's the exact same code, except the fasm version doesn't have all that unnecessary C header garbage that I never use. Well, I THOUGHT it was unnecessary. But it must be doing something that changes the background color of my static labels.

Initial search results get me conversations about how to handle messages in my message handler, but my C version isn't doing that. It must be something simpler than that. I can't be the only guy seeing this. Have you guys run into this and fixed it?

irrelevant answer. that's why deleted...

Never mind. I found it.

I can't use the exact same code that the c compiler gives me. You know that unnecessary garbage the c compiler puts in? Well one of them was a command line parameter to the main proc--the hInstance. If I don't use the C preludes, there are no parameters to my main proc. Once I used GetModuleHandle to give me the hInstance, and changed the references, it worked fine.

The thing on the stack it was using for the module handle was a return address into ntdll somewhere. As long as I used the same value of hInstance when I called RegisterClass and CreateWindowEx, it worked OK except for this weird background thing.

The C entrypoint (the language standard 'main' for console apps, WinMain for GUI apps) isn't the Portable Executable entrypoint - before your function calls, the C runtime startup code does a lot of (useful) stuff.

So yes, there's a bit more work needed for assembly