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

Make more structs AnyCPU-compatible by assuming Pack=4 for x86 #613

Closed
AArnott opened this issue Aug 18, 2021 · 2 comments
Closed

Make more structs AnyCPU-compatible by assuming Pack=4 for x86 #613

AArnott opened this issue Aug 18, 2021 · 2 comments
Assignees
Labels
usability Touch-up to improve the user experience for a language projection

Comments

@AArnott
Copy link
Member

AArnott commented Aug 18, 2021

We've had some pushback since CsWin32 started omitting APIs from C# AnyCPU projects that the metadata said were arch-specific. In some cases this is absolutely required and I stand behind the ability to do this. But wherever it's possible for the metadata the declare a struct fewer times so that one declaration is compatible with more architectures (and ideally, compatible with any architecture), we should strive for that as it dramatically improves the C# experience.

Per @AaronRobinsonMSFT's comment here: microsoft/CsWin32#336 (comment), in x86 Pack = 4 is the default. So although native headers may not set Pack=4 for x86 but set it for x64/arm64, the two are equivalent. It is not required for x86 but it is required for 64-bit architectures.

Therefore, I propose that when the metadata for a struct only varies by Pack=4 being absent on the x86 definition, we should assume it's present and consolidate the struct declarations and remove the CPU architecture attribute so that these structs can be generated in AnyCPU-targeting binaries.

In the case linked to above this would lead to MINIDUMP_EXCEPTION_INFORMATION being available in AnyCPU C# projects, and probably a great more structs too.

@marler8997
Copy link
Contributor

Inferring that Pack=4 on x86 when there is no explicit packing sounds reasonable to me.

That being said, it seems odd to me that if the metadata adds support for more architectures, it could mean that CsWin32 could suddenly lose more types for AnyCpu projects. It feels weird that coverage of CsWin32 depends on the metadata having "less coverage" of various architectures.

One way CsWin32 could mitigate this would be to allow AnyCpu projects to specify a set of architectures it will actually support. This way if the metadata adds support for architecture X, AnyCpu projects won't suddenly lose some of the API because architecture X has some weird one-off definitions. I think this extra option would allow CsWin32 to cover these 3 main use cases:

  1. Use Cpu-Specific to get access to full API
  2. Use AnyCpu with limited Architecture set to get access to the api that is common to all supported architectures
  3. Use AnyCpu with no limits on architectures to get the truly common API for everything that metadata supports

@AArnott
Copy link
Member Author

AArnott commented Aug 18, 2021

@marler8997 I like that idea. I'm tracking it with a new CsWin32 repo issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
usability Touch-up to improve the user experience for a language projection
Projects
None yet
Development

No branches or pull requests

3 participants