Inline assembly code check

Code:

void a(char *string, HWND rsHwnd)
{
	
	sMessage = (DWORD)GetProcAddress(LoadLibrary("User32.dll"), "SendMessageA");
	LPARAM lstring = LPARAM(string);
	__asm {
		mov eax, rsHwnd
		
		xor ebx, ebx
		cmp eax, ebx

		je $invalidHandle

		mov ebx, WM_SETTEXT
		
		push lstring
		push 0
		push ebx
		push eax
		call sMessage
$invalidHandle:
	};
}

I am kind of new to the whole assembly thing. I am just wondering if this code is ok. Someone told me I should save ebx.

You don't need to save EBX, it's done by the compiler for you. But I don't see why you need to use EBX in the first place - nor why you really need to use inline assembler (that will ensure that your code won't be portable to Windows x64 if you should wish to do that later on.

Some simplification in red:

Code:

void a(char *string, HWND rsHwnd)
{
	
	sMessage = (DWORD)GetProcAddress(LoadLibrary("User32.dll"), "SendMessageA");
	LPARAM lstring = LPARAM(string);
	__asm {
		mov eax, rsHwnd

		cmp eax, 0
		je $invalidHandle

		push lstring
		push 0
		push VM_SETTEXT
		push eax
		call sMessage
$invalidHandle:
	};
}

Alternative C-code:

Code:

typedef LRESULT (*tpSendMessage)(      
    HWND hWnd,
    UINT Msg,
    WPARAM wParam,
    LPARAM lParam
);
void a(char *string, HWND rsHwnd)
{
        static tpSendMessage pSendMessage = 0;
	if (rsHwnd) {
           if (!pSendMessage) {
     	      pSendMessage = GetProcAddress(LoadLibrary("User32.dll"), "SendMessageA");
              if (!pSendMessage) {  ... do some error handling ... }
           }
	   pSendMessage(rsHwnd, VM_SETTEXT, 0, LPARAM(string));
        }
}

Note, I made pSendMessage a static variable, so once it's been "found", you don't need to call GetProcAddress/LoadLibrary again.

--
Mats

test eax, eax
is the common form of the == 0 check (followed by a jz). The reason is that the instruction is smaller (1 byte vs 2, I think).

But I agree that the plain C is better.

Originally Posted by CornedBee

test eax, eax
is the common form of the == 0 check (followed by a jz). The reason is that the instruction is smaller (1 byte vs 2, I think).

But I agree that the plain C is better.

Good point on test (or and eax, eax - same length and same result).

But I don't see any point in using inline assembler for this at all - there's no performance benefit (calling loadlibrary will take 1000x more time than calling sendmessage anyways), and it can be done in C. Which makes it portable to other processor architectures, including x64 which doesn't allow inline assembler.

--
Mats

including x64 which doesn't allow inline assembler.

whoa, what? why not?

Originally Posted by robwhit

whoa, what? why not?

Because Microsoft didn't want it in the compiler... I don't know if it's changed, but it wasn't part of 64-bit visual C++ a couple of years ago.

--
Mats

x64 has no problem with inline assembler (how would it tell if there is any?) It's Visual C++ for x64 that refuses to compile it.

Originally Posted by CornedBee

x64 has no problem with inline assembler (how would it tell if there is any?) It's Visual C++ for x64 that refuses to compile it.

Yes, that's what I was trying to say. May not have been entirely clear tho'.

32-bit Inline assembler works just fine with the 32-bit compiler on 64-bit machine, but if you compile for 64-bit, the Visual C++ compiler will refuse any inline-code. Using GCC (and probably PGC) you can compile with Inline assembler. There's also a version of MASM that works for 64-bit, so if you really need some assembler-code, it can be done - just not as inline in Visual C++ [or the compiler behind the IDE].

--
Mats