-
Notifications
You must be signed in to change notification settings - Fork 489
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
NTSTATUS error codes #983
Comments
Ooh, I love BCrypt. 😉 So there are a few different angles to this. The general principle is that if a type exists in both the WinRT and Win32 type systems then it must necessarily be lifted out and defined canonically in the Windows crate. However, As far as interoperability across crates, that should be solved with #432 however I would suggest that libraries should prefer to convert error codes like |
Oh wow, another phenomenal installment? That was a great read, well paced, well delivered, covering everything from the overall architecture, the rationale behind it, recurring patterns, down to common use cases. Plus a few "Cryptography for Dummies" lessons by the side. Thank you, Kenny! As a teacher you are extraordinarily effective (and this isn't just me either).
This wasn't obvious to me until you spelled it out. That makes sense, thanks!
Agreed.
Just to verify that I fully understand this: While a
Up until yesterday I was convinced that going from an Repurposing the For completeness, the generated |
Actually, the public interface of neither The latter currently produces an empty string for Regardless, I can still try to prepare a draft PR to illustrate, how |
Thanks Tim, I had a quick look at the PR. I like to work backward from the ideal design and then provide only as much library support as is absolutely necessary. The ideal in my mind is that we treat functions that return |
I'd love to do the same for |
At this time, both standard system error codes and HRESULTs are well covered by the Windows crate. This is not the case for NTSTATUS based error codes. Those are rarely used in the Windows API surface, though I just ran into a set of functions that do, namely in the Cryptography API: Next Generation (e.g.
BCryptOpenAlgorithmProvider
).Error handling with those APIs is manual, and with NTSTATUS being a generated type, interoperability across crate boundaries is stifled. Are there any plans to lift
NTSTATUS
out of the generated code into Windows' Error type?The text was updated successfully, but these errors were encountered: