Replace winapi with windows crate and use webview2-com instead of webview2

[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:

This change goes along with tauri-apps/tao#206 to switch over to the windows crate. Since they both use webview2-com-sys for the generated bindings, they can share types for common types like HWND.

A big advantage of using the windows crate is that it's trivial to update the bindings when new versions of the WebView2 SDK drop. I noticed a new version had been released a few days ago, and I was able to pick that up and regenerate webview2-com and webview2-com-sys on crates.io within an hour and test it with my forks of TAO and WRY.

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 #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.

The TAO portion of this change is in tauri-apps/tao#206. Since there are some shared types between the two, both PRs would need to go in together. There's currently a [patch.crates-io] table in my version of WRY which redirects to my fork of TAO, if the TAO version goes in first and is published to crates.io with a version bump, then WRY can take this PR at any point after that and just bump the TAO version in [dependencies] while cleaning up the [patch.crates-io] table.

[wravery]

Holding off on marking this ready for review because I'd like to remove the [patch.crates-io] table once tauri-apps/tao#206 has been merged with a version coming from the next branch.

[wravery]

No new clippy warnings for this one on macOS, so it should be clean now.

[wusyong]

Just made it work on Tauri! Thanks for this amazing PR!
One thing I notice is that Tauri will need to use add_GotFocus and add_LostFocus method from controller but one of their parameter has type of Windows::Win32::System::WinRT::EventRegistrationToken. Is this going to work on Windows7?

[wravery]

Just made it work on Tauri! Thanks for this amazing PR!
One thing I notice is that Tauri will need to use add_GotFocus and add_LostFocus method from controller but one of their parameter has type of Windows::Win32::System::WinRT::EventRegistrationToken. Is this going to work on Windows7?

Yup, I ran into the same thing when I started trying to put it together with the rest of the Tauri runtime. I also got one of my apps working with that version of Tauri. 😄

Despite the namespace, EventRegistrationToken is really just a wrapper struct around a 64-bit (unsigned?) integer with no methods. In other words, it's basically a tuple struct in Rust. I think it's there in the win32metadata just because it's probably used more with WinRT interop/ABI interfaces.

I haven't tested the full stack against Win7 yet, but the WRY examples I did test, like multi_window, reuse a single instance of EventRegistrationToken to register the event/completion handlers. Since there's no need to remove the handlers before dropping the webview, it just puts them in a local variable initialized like so:

let mut token = EventRegistrationToken::default();

Each new event handler overwrites the value of the token from the previous one, and the last one gets dropped at the end of the initialization function in WRY. So I'm pretty sure that won't be a problem for this additional call site in Tauri itself.

[wusyong]

There are some error handling I think it could improve, but it's already LGTM.
All examples seems working fine!