Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exclude MsHtml APIs #1925

Merged
merged 1 commit into from Jul 21, 2022
Merged

Exclude MsHtml APIs #1925

merged 1 commit into from Jul 21, 2022

Conversation

kennykerr
Copy link
Collaborator

These older APIs were only intended for JScript and VBScript clients, but MsHtml is by far the single largest module and as such takes a nice chunk out of the overall package size.

Copy link
Contributor

@rylev rylev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow! It would be nice if we clearly documented somewhere which APIs are being excluded since we're now not quite a 1 to 1 mapping to the metadata.

@kennykerr
Copy link
Collaborator Author

Yes, I really need to spend some time and write a more complete FAQ.

@kennykerr kennykerr merged commit 8c153be into master Jul 21, 2022
@kennykerr kennykerr deleted the sans-mshtml branch July 21, 2022 14:55
@kennykerr
Copy link
Collaborator Author

See #1933

@mwcampbell
Copy link

These older APIs were only intended for JScript and VBScript clients

I'm not sure about intention, but the vtable-based interfaces are certainly usable from C++, and presumably would be from Rust as well. I can think of two categories of software that make use of these interfaces: programs that embed the MSHTML engine (usually via the WebBrowser ActiveX control), and assistive technologies (e.g. screen readers) that have specific support for the MSHTML engine (which includes all actively maintained Windows screen readers except Narrator). I wrote one such screen reader (before my time at Microsoft, and it's not so actively maintained now), and if I were to port it to Rust, I would definitely need bindings for the MSHTML API. One may respond that the IE engine is dead anyway, and we may want to just forget about it, but it's still part of Windows, so removing MSHTML seems like going back on the promise of "any Windows API past, present, and future".

Would it be feasible to bring back the MSHTML API in a separate crate? How hard is it to do that for pieces of the Windows SDK, since it all comes from the same metadata and there will likely be cross-crate dependencies?

@kennykerr
Copy link
Collaborator Author

It can be reintroduced in a few different ways if the need arises. The windows-bindgen crate fulfills the promise of "any Windows API past, present, and future", is used to generate the windows crate, and any additional crates for supplemental APIs like this.

@mwcampbell
Copy link

OK, if it's feasible to have a separate mshtml crate via windows-bindgen, I will be happy to maintain such a crate if I have the need for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants