search

microsoft / windows-rs

Rust for Windows
https://kennykerr.ca/rust-getting-started/
Apache License 2.0
10.36k stars 486 forks source link

COM can't be used on non-Windows platforms #3083

Closed sivadeilra closed 3 months ago

sivadeilra commented 3 months ago

Summary

I'm working on several cross-platform codebases, such as DWriteCore, which are based heavily on COM. Currently I'm using the old com-rs crate, which is no longer supported. I've converted everything in my codebase to use windows-rs, but currently compilation (linking, specifically) fails due to platform dependencies for Windows.

The first blocking issue I've hit is that the code generated for calling COM methods calls GetErrorInfo, which is only defined on Windows.

Crate manifest

No response

Crate code

No response

kennykerr commented 3 months ago

Note that non-Windows support has never been in scope. While I have no intention to block such support, this would definitely be considered a new feature, not a bug. Existing test coverage exists merely to support cross-compilation and to ease cross-platform development.

My general philosophy here continues to be that I am ok with enabling cross-platform support so long as it doesn't substantially impact the complexity and primacy of Windows support.

MarijnS95 commented 3 months ago

@sivadeilra this is awesome! It may one day help us migrate hassle-rs off of Microsoft's deprecated and unmaintained com-rs and onto windows-rs, while getting autogenerated/auto-maintained bindings for free!

Note that you'll face a lot of pushback, see for example https://github.com/microsoft/windows-rs/issues/1874 which @riverar already linked to you in #3082. Though a lot of folks will be very thankful if you do manage to sit this through to the end :crossed_fingers:

For the specific linker-error case, I did however manage to get at least https://github.com/microsoft/windows-rs/pull/1863 merged. This allows you to define symbols like GetErrorInfo in your own codebase, to provide a fallback when the symbol isn't defined by "the OS". For example: https://github.com/MarijnS95/windows-rs/commit/e595cda41cc8ca8163de6f15890da1f1e7150d2b#diff-1be65c4aa0a07017c9575e418540179c2b2f7638f022c867c0ba42d39e435e9bR63-R67 (But it's hacky and I hope you can come up with something better)

sivadeilra commented 3 months ago

To be clear, I do not want this to become something like WINE. I don't want additional functionality that tries to bridge the gap between Windows and other platforms. I just want the subset of windows-core and windows crates that can sensibly used on other platforms.

COM is the big one, for me. And that doesn't mean any runtime functions at all, it just means IUnknown, HRESULT, and the ability to use the #[implement] and #[interface] macros.

MarijnS95 commented 3 months ago

To be clear, hassle-rs's requirements (for using libdxcompiler.so) are identical to that.

youyuanwu commented 3 months ago

FYI: We use COM on linux for service-fabric-rs. mssf-pal crate supplies a subset of win32 api to make it work.

MarijnS95 commented 3 months ago

@youyuanwu cool, thanks for linking. That looks to be using the exact functionality proposed in #1863 :slightly_smiling_face:

kennykerr commented 3 months ago

I took a stab at pulling out the COM support in windows-core into its own crate but so much of the code generation depends on certain facilities living in windows-core that it's not very practical. My next experiment is to see how much of the bells and whistles that have crept into windows-core can be moved out. I'm thinking of variant support moving into the windows crate as an extension and string support moving into its own windows-strings crate.