You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 = 4is 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.
The text was updated successfully, but these errors were encountered:
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:
Use Cpu-Specific to get access to full API
Use AnyCpu with limited Architecture set to get access to the api that is common to all supported architectures
Use AnyCpu with no limits on architectures to get the truly common API for everything that metadata supports
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.The text was updated successfully, but these errors were encountered: