Replace winapi with windows crate bindings shared with WRY

[wravery]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Documentation
• Build-related changes
• Other, please describe:

By itself, this change should not have much impact on TAO. I've replaced all of the winapi crate references with the windows crate. The generated bindings are in the webview2-com-sys crate, which is important to be able to share types with WRY later in a separate PR. That's already working in my fork of WRY,

Mostly that's a matter of 1:1 replacements, where the types and functions in winapi matched what the windows crate generated, although there are a few less obvious changes. For one thing, the winapi crate seems to declare enums for most of the #define macros in the Windows headers, and the windows crate declares them as const values. That means you can't refer to them in a pattern (i.e. match arms), because that just shadows the const with a local variable using the same name. So that's why I had to replace so many patterns with something like _ if msg == WM_FOO =>, using a pattern guard expression.

There were a few macros like GET_X_LPARAM/GET_Y_LAPARAM and PRIMARYLANGID that did bit manipulation which winapi reimplemented as public functions, and the windows crate doesn't. I ended up reimplementing those inline where I found them, but I might go back and replace some of those with const fns. On the bright side, while researching those macros I also found a few places where TAO was not quite passing the correct values. For instance, drag_window passed a pointer to a POINTS struct instead of encoding the x/y coordinates as i16 values in a u32. I think I saw the same bug in at least one other place.

One thing the windows crate does much better is argument coercions, so for example you can pass false and it will automatically convert that to a BOOL(0) with a conversion trait. It also implements the Default trait for many of the structs, so you don't need to use std::mem::zeroed in an unsafe block to initialize them.

The windows crate also wins hands down when dealing with COM, especially if you need to implement them. For instance, TAO benefits from this in the FileDropHandler and when dealing with ITaskbarList2. I was able to remove a lot of code in FileDropHandler dealing with ref-counts and v-tables and replace it with #[windows::implement(Windows::Win32::System::Com::IDropTarget)].

Does this PR introduce a breaking change? (check one)

• Yes. Issue #___
• No

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

This is related to tauri-apps/wry#133, which was later removed because it only worked for Windows 10 and it required redistributing DLLs along with the app. Both of those have been addressed since then, plus the windows crate now supports the #[implement] macro. I think it's worth another try.

[wravery]

Marking this ready for review. Now that it's targeting the next branch I don't think there's any reason to hold it back.

[lemarier]

Personally, it looks AMAZING.
I'll not tell you how the Windows API work :P

We'll run different tests/scenarios on different platforms, and we'll wait for the complete review from @amrbashir (he's away for few days) as it's our Windows specialist ;)

Meanwhile, there is a little fmt error, would be great if you can fix it.

This is the kind of gift we didn't expect and we do appreciate it a lot.
It'll change a lot of things.

Thanks again from the whole Tauri community.

[wravery]

We'll run different tests/scenarios on different platforms, and we'll wait for the complete review from @amrbashir (he's away for few days) as it's our Windows specialist ;)

Sounds great, LMK if I can help. 👍🏼

Meanwhile, there is a little fmt error, would be great if you can fix it.

It looks like the errors came from clippy running on macOS. I have a Mac (and Linux machine), so I can take a look, but I wonder if it would make sense to run the clippy checks on Windows and Linux as well. When I ran clippy on Windows I found a couple of other pre-existing errors that I fixed on Windows and the workflow doesn't seem to have caught those.

[lemarier]

but I wonder if it would make sense to run the clippy checks on Windows and Linux as well

Yes totally! I was sure it was checking all platforms already. We can add it in another PR, you don't have to deal with the CI fun. You've already done enough hehehe ;)

Thanks for the clippy fix!!

[amrbashir]

Thanks for the awesome PR and I apologize for the nit-picks.

There is 2 concerns I have:

1. DWORD, UINT and similar types are replaced with rust types, I think I prefer to stick with win32 types if possible, so it is consistent with original c++ win32 api.
2. There is a lot of Anonymous fields on structs in this PR which tbh kinda scary and I don't understand why they exist and how much maintenance it will require.

A totally useless request is can we rename webview2-com-sys, seems like win32-com-sys might be a better name, as my OCD is triggered 😅 (A window management crate depending on a webview crate) .

[wravery]

Couple of remaining issues that I haven't really addressed, hopefully neither of them is a blocker. 😄

1. DWORD, UINT and similar types are replaced with rust types, I think I prefer to stick with win32 types if possible, so it is consistent with original c++ win32 api.

The windows-rs crate takes a somewhat different approach by preferring Rust types as much as possible with automatic conversions. It keeps the same function/struct names to make it easier to find documentation even though they don't use snake-case, but where there's an equivalent simple type it will use them. It doesn't include any structs for DWORD or UINT, so we'd need to include our own. I think that would just make it a little harder to consume from the Rust side though, and it wouldn't apply to any other platforms.

A totally useless request is can we rename webview2-com-sys, seems like win32-com-sys might be a better name, as my OCD is triggered 😅 (A window management crate depending on a webview crate) .

Maybe... but then I think we should probably create a TAO-specific bindings crate for it, under the tauri-apps org. The thing that worries me about that is the types wouldn't be the same as the bindings consumed by WRY, but if all of the types from webview2-com-sys are removed from the TAO public interface (e.g. putting back *mut libc::c_void), I guess that should be OK. In the worst case, it might define 2 different implementations of any associated functions that are referenced in each crate and bloat the binary a little bit.

[amrbashir]

No these are not exactly blockers, it was just a mere preference.

I will try to do a final review of this PR soon and make sure it is all fine before merge.

[amrbashir]

Thanks again for the awesome work, the PR looks fantastic.

[wusyong]

Thanks both of your works! Let's move to wry and make this happen!