Closed jardhu closed 1 month ago
Hey, Thanks for the report. Seems it was broken in https://github.com/emoon/rust_minifb/commit/4b4af731ccd3738492aa4f785733f9af207e0623 cc @StefanoIncardone
The old code was using unsafe { libloaderapi::GetModuleHandleA(ptr::null()) } as *mut raw::c_void;
When requesting a
RawWindowHandle
for a win32Window
(such as passing aWindow
to functions written with theraw_window_handle
API), the instantiation of theRawWindowHandle
performs some incorrect logic which results in either a panic after dereferencing a byte-misaligned pointer, or a segmentation fault.There were three bugs which I've encountered and fixed with a workaround:
HasWindowHandle
implementation for win32 assumes that the underlying window handle is a pointer to aHWND
and dereferences it, when the handle is itself theHWND
and simply needs to be casted to anisize
. Hence, retrieving theHWND
should look something like:HINSTANCE
handle is a pointer to anHINSTANCE
and dereferences it. TheHINSTANCE
handle fromGetWindowLongPtr
needs to be casted to anisize
.GetWindowLongPtrW(hwnd, GWLP_HINSTANCE)
returns a null pointer for a validHWND
. I'm not exactly sure why this happens, but I instead opted to retrieve theHMODULE
and pass that as theHINSTANCE
:I can confirm that the resulting
RawWindowHandle
constructed from theHWND
andHMODULE
works for the purposes of, in my particular use case, constructing a valid Vulkan surface with the window and display handles.