Using multiple winio instances in the same process will cause panic

[Chaoses-Ib]

As said in #24, I'm writing plugins using winio, so there may be multiple instances of winio in the same process. However, this will cause panic because they all register the same class name:

winio/winio-ui-win32/src/ui/window.rs

Lines 326 to 345 in ca97049

	fn register() {
	unsafe {
	set_preferred_app_mode(PreferredAppMode::AllowDark);
	}
	let cls = WNDCLASSEXW {
	cbSize: std::mem::size_of::<WNDCLASSEXW>() as _,
	style: 0,
	lpfnWndProc: Some(window_proc),
	cbClsExtra: 0,
	cbWndExtra: 0,
	hInstance: unsafe { GetModuleHandleW(null()) },
	hIcon: null_mut(),
	hCursor: unsafe { LoadCursorW(null_mut(), IDC_ARROW) },
	hbrBackground: unsafe { GetStockObject(WHITE_BRUSH) },
	lpszMenuName: null(),
	lpszClassName: WINDOW_CLASS_NAME,
	hIconSm: null_mut(),
	};
	syscall!(BOOL, unsafe { RegisterClassExW(&cls) }).unwrap();
	}

A panic occurred panic.payload="called `Result::unwrap()` on an `Err` value: Os { code: 1410, kind: Uncategorized, message: \"Class already exists.\" }" panic.location="C:\\Users\\Chaoses\\.cargo\\git\\checkouts\\winio-267028aeb854993e\\ca97049\\winio-ui-win32\\src\\ui\\window.rs:344:55"

How about using the new added app name or something else to avoid conflicts?

[Berrysoft]

This method is guarded by Once::call_once and it should be called only once. Why is it called multiple times? Is it because you compiled many different dlls, and all of them link winio statically?

If so, that's a classical problem for Win32 programs. Although I can choose to ignore this error, it's not that "clean" because anyone can register a window class before winio with the same name. I need a way to ensure that I'm using my own window class. Seems that you have abundant experiences on Win32, so do you have some advice?

[Berrysoft]

How about using the new added app name or something else to avoid conflicts?

I'm not sure how to do that in a pretty TBH. Maybe I should just ignore ERROR_CLASS_ALREADY_EXISTS.

[Berrysoft]

#37 has been merged. You can ignore that error by enabling win32-ignore-class-conflict feature.

[Chaoses-Ib]

I need a way to ensure that I'm using my own window class.

Oh, this reminds me. That's what the hInstance parameter in RegisterClassExW is for. The real problem is Winio using GetModuleHandleW(null()), which is the handle to the executable, not the DLL. One can get the handle to the current DLL by GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS (or from DllMain), for example:

GetModuleHandleExW(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT, (LPCWSTR)_ReturnAddress(), &module);

I can make a PR if needed.

And just ignoring the error is error-prone as the lpfnWndProc is from a different Winio instance.

[Berrysoft]

Oh, you're right. I was a bit impatient.

I can make a PR if needed.

Thank you very much! Go ahead please.