Migration from winapi to windows-rs crate #68
Conversation
| // https://docs.microsoft.com/en-us/windows/win32/api/wbemcli/nf-wbemcli-iwbemobjectsink-indicate | ||
| // For error codes, see https://docs.microsoft.com/en-us/windows/win32/learnwin32/error-handling-in-com | ||
| let objs = unsafe { | ||
| std::slice::from_raw_parts( |
There was a problem hiding this comment.
The reason the old code used ptr.add was that from_raw_parts has a bunch of safety reqs which I didn't want to risk violating.
If you think that the apObjArray is OK to use in this context, that's fine by me 🙂
There was a problem hiding this comment.
I have updated the safety comment, imho it's "safe" to do so, as those safety requirements are supposed to be guaranteed by the API for Indicate (and if they are not upheld, we would be UB anyway as any read from apObjArray + i would be OOB)
There was a problem hiding this comment.
I think the note that The array memory itself is read-only from MSDN is the one thing I wasn't sure about 👍
|
|
||
| check_hres(VariantClear(&mut vt_prop))?; | ||
| VariantClear(&mut vt_prop)?; |
There was a problem hiding this comment.
Do we need this now? Maybe VARIANT does this by itself?
No, there's no Drop impl
There was a problem hiding this comment.
Yes, windows-rs does not improve the ease of use for VARIANT ^^ It's quite a pain to deal with, because it can be of any type and filled in many different ways. there's no clone/drop or any helpers for it yet in this crate.
| // https://docs.microsoft.com/en-us/windows/win32/api/wbemcli/nf-wbemcli-iwbemobjectsink-indicate | ||
| // For error codes, see https://docs.microsoft.com/en-us/windows/win32/learnwin32/error-handling-in-com | ||
| let objs = unsafe { | ||
| std::slice::from_raw_parts( |
There was a problem hiding this comment.
I think the note that The array memory itself is read-only from MSDN is the one thing I wasn't sure about 👍
|
I merged #66 and released 0.11.5. |
This is no longer used, automatically done by windows-rs
This error no longer is possible when using windows-rs, a failed allocation will panic.
vthib
force-pushed
the
67-windows-rs-migration
branch
from
6fe6d9c
to
0477540
Compare
|
Thanks for the reactivity and positivity :) I solved the conflicts, it should be good to go. |
Replace
winapi,comandwidestringwith thewindows-rscrate:What does it changes internally (should not be visible from the public API):
windows-rscomes with a BSTR module helper, so thewmi-rsone is no longer needed.implementfeature gives access to easy COM implementation: a rust struct can implement a COM interface, and the interface comes in the form of a clean Rust trait.check_hreshelper is no longer needed.What does it changes externally (breaking changes):
widestringdependency is no longer needed, and its errors are no longer exposed in the WMIError object. Instead, theBSTRhelper fromwindows-rsis used, and this one generates the standardstd::string::FromUtf16Errorerror. This gives less information on the conversion issue.BSTRhelper fromwindows-rsalso panics on allocation failure, making theWMIError::ConvertAllocateErrorobsolete. We could probably change this with an internal conversion if needed, but "panic on allocation failure" is probably baked in other windows-rs helpers...Another point to take into account is that
windows-rsis still getting updated regularly, and so it may be needed to release newwmi-rsversions more regularly to keep up with those updates. Thewindows-syscrate is a bit lower level and less often updated, and is supposed to be designed for libs like this. However, we need the COM helpers and the implement macro, which only exists in the higher-levelwindowscrate.Fixes #67