no_std support for windows-rs

[sagacity]

Suggestion

I am working in an environment in which I am quite executable size constrained, but I'd still like to use Direct3D11 in order to perform some rendering tasks. Since windows-sys has no support for this, I am currently using the winapi crate to fill in support for the relevant D3D COM classes I'm using. However, winapi has been unmaintained for three years after windows-rs ate its lunch :)

I've tried using windows-bindgen to generate bindings and patching them up manually, but I couldn't get the generated code to compile properly (after changing things like std::ptr::null_mut to core::ptr::null_mut and so on). Could this be a more or less valid path to take, though?

What is a good way forward, generally? I wouldn't mind using bindings that are generated by using a manual bindgen step, but ideally I'd just use the windows crate since that would also make all other non-COM code simpler and there wouldn't be a manual bindgen step.

(btw, I realize this issue has been brought up before, so feel free to close if this cannot be realized, but I'd like some guidance on how to avoid depending on an unmaintained crate)

[kennykerr]

Good news, the windows crate can now be compiled with no_std. #3047

Just make sure to specify default-features = false as this test illustrates:

https://github.com/microsoft/windows-rs/tree/master/crates/tests/misc/no_std

[sagacity]

I saw some support, indeed, but I wasn't clear on whether it was ready to be used since it is not part of an officially released crate yet (there is no windows version 0.59.0 / 0.60.0 yet).

Regardless, if I use the windows-rs 0.60 release zip from GitHub as a direct dependency, there are still references to std in the code. For instance, here's a reference to std::ptr::null:

windows-rs/crates/libs/windows/src/Windows/Win32/Graphics/Direct3D/Fxc/mod.rs

Line 10 in b2ffdc9

D3DCompile(psrcdata, srcdatasize, psourcename.param().abi(), core::mem::transmute(pdefines.unwrap_or(std::ptr::null())), pinclude.param().abi(), pentrypoint.param().abi(), ptarget.param().abi(), flags1, flags2, core::mem::transmute(ppcode), core::mem::transmute(pperrormsgs.unwrap_or(std::ptr::null_mut()))).ok()

The define_interface macro also generates code that references std types:

windows-rs/crates/libs/core/src/imp/mod.rs

Line 78 in b2ffdc9

pub struct $name(::std::ptr::NonNull<::std::ffi::c_void>);

If I mechanically convert references of std::ptr::* to core::ptr::* I can get quite far with compilation though so it seems like these were just missed in a previous PR, maybe? Or am I just completely looking in the wrong place (this is a distinct possibility, of course :D)

[kennykerr]

No, these look like they were overlooked by that PR. The challenge is exhaustively testing no_std since this cannot be covered by the GitHub workflows that otherwise test everything since we'd run out of memory in the GitHub VM runners. 😊

But we can use this issue to track this and make sure we fix up those few remaining references to std.

[sagacity]

Fair enough! I'd be happy to take a stab at it since most of it is mechanical conversion, but since testing is indeed difficult I'm not sure I'd end up accidentally breaking stuff.

[kennykerr]

Here you go: #3317