windows: bump windows-sys to 0.52 #3639
Conversation
| @@ -187,7 +187,7 @@ impl FileDropHandler { | |||
| let get_data_fn = unsafe { (*(*data_obj).cast::<IDataObjectVtbl>()).GetData }; | |||
| let get_data_result = unsafe { get_data_fn(data_obj as *mut _, &drop_format, &mut medium) }; | |||
| if get_data_result >= 0 { | |||
| let hdrop = unsafe { medium.Anonymous.hGlobal }; | |||
| let hdrop = unsafe { medium.u.hGlobal as HDROP }; | |||
There was a problem hiding this comment.
Could someone verify that it's a correct change?
There was a problem hiding this comment.
Looking at the docs, I think windows-sys changed internal unions from being called Anonymous to being called u.
Additionally, HGLOBAL changed from isize to *mut c_void, I assume that's intentional too, at least that's what I'm getting from reading microsoft/windows-rs#1643 (comment).
There was a problem hiding this comment.
Annoying that we have to do the as u32 in a few places, but I think that's just how the Win32 API is, e.g. DwmSetWindowAttribute takes a DWORD so there isn't much that windows-rs can do here.
| @@ -187,7 +187,7 @@ impl FileDropHandler { | |||
| let get_data_fn = unsafe { (*(*data_obj).cast::<IDataObjectVtbl>()).GetData }; | |||
| let get_data_result = unsafe { get_data_fn(data_obj as *mut _, &drop_format, &mut medium) }; | |||
| if get_data_result >= 0 { | |||
| let hdrop = unsafe { medium.Anonymous.hGlobal }; | |||
| let hdrop = unsafe { medium.u.hGlobal as HDROP }; | |||
There was a problem hiding this comment.
Looking at the docs, I think windows-sys changed internal unions from being called Anonymous to being called u.
Additionally, HGLOBAL changed from isize to *mut c_void, I assume that's intentional too, at least that's what I'm getting from reading microsoft/windows-rs#1643 (comment).
Yeah, it's just I'm not sure if all of that is sound now. Like I understood that it's like that. |
kchibisov
force-pushed
the
kchibisov/windows-052
branch
from
fceb930 to
af11b7c
Compare
| @@ -105,7 +105,7 @@ pub unsafe fn hwnd_dpi(hwnd: HWND) -> u32 { | |||
| if unsafe { IsProcessDPIAware() } != false.into() { | |||
| // If the process is DPI aware, then scaling must be handled by the application using | |||
| // this DPI value. | |||
| unsafe { GetDeviceCaps(hdc, LOGPIXELSX) as u32 } | |||
| unsafe { GetDeviceCaps(hdc, LOGPIXELSX as i32) as u32 } | |||
There was a problem hiding this comment.
We should ask for upstream clarification about these. At least in the windows crate where these are newtyped, the underlying ABI is "kept in sync" (IIRC by casting in the wrapper implementation).
There was a problem hiding this comment.
Given that casting small u32 to positive i32 have the same binary repr, it's safe to do it here.
In general, a lot of casts seems to be that way because sometimes they accept enum but enum itself is i32 and not u32, and so on.
You can still ask though.
There was a problem hiding this comment.
Not saying that it's unsafe, just that it's inconvenient after these Windows crates already have all the type information they need; looks like it's all reserved for the high-level windows crate though.
changelogmodule if knowledge of this change could be valuable to users