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

Expose the DualApiPartition attribute #52

Open
Boddlnagg opened this issue Dec 30, 2017 · 1 comment
Open

Expose the DualApiPartition attribute #52

Boddlnagg opened this issue Dec 30, 2017 · 1 comment

Comments

@Boddlnagg
Copy link
Collaborator

Boddlnagg commented Dec 30, 2017

See https://msdn.microsoft.com/de-de/library/windows/desktop/mt695951(v=vs.85).aspx.
Probably the APIs that don't have the DualApiPartition attribute should be disabled by default, and enabled only via a feature flag. Currently they won't be of much use anyway, because I know of no way to create a real UWP app with Rust.

Notet that the attribute seems to be only applied to classes, so it's not clear what to to with the corresponding interfaces. Those that are marked ExclusiveTo should probably be handled in the same way.

@Boddlnagg
Copy link
Collaborator Author

Boddlnagg commented Dec 30, 2017

I looked into this a little more and found that e.g. the XML DOM classes in Windows.Data.Xml.Dom don't have the DualApiPartition attribute, but they can be used from desktop apps just fine ... I'm not sure what this means.

The absence of the DualApiPartition attribute for a lot of APIs also doesn't really make sense in light of this statement (from https://msdn.microsoft.com/de-de/library/windows/desktop/mt695951(v=vs.85).aspx):

With some notable exceptions, the general rule is that a Universal Windows Platform (UWP) API can be called from a classic desktop app. The two main areas of APIs that are an exception to this general rule are XAML UI APIs, and APIs that require the calling app to have a package identity.

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

No branches or pull requests

1 participant