Does the windows crate still need no_std support?

[kennykerr]

Now that the windows-sys crate is available, is there still a need for the no_std support in the windows crate? I'm just worried about the usability since its not very discoverable that you need to declare the std/alloc features to use common features provided by the windows crate.

[samlh]

I just upgraded to 0.28.0 without enabling the std/alloc features, and I think I prefer not having any implicit allocations.

90% of the code is the same, with the exception of some HSTRING::from() calls. Including the HSTRING::from calls is good in my eyes, because it exposed a potential optimization in a few places in my code.

I like having the implicit conversions and type-safety of the windows bindings over what is in windows-sys, but only if they are "zero-cost".

[kennykerr]

Thanks for the feedback, I may keep the alloc feature but drop the std feature for the windows crate.

[lzybkr]

The pattern I've seen is that no_std users set:

default-features = false

This way, most users get the defaults and don't need to discover anything.

I mention this because I considered using windows instead of windows-sys to get a couple helpers, that is until I saw how much slower builds would be.

[kennykerr]

Since all APIs are off by default and need to be enabled with features, having defaults doesn't really help. Anyway, having windows imply std and windows-sys imply no_std seems to align well with the goals for these crates.

[stevefan1999-personal]

Please reopen this issue, I failed to compile the crate under no_std.

[stevefan1999-personal]

@kennykerr Some code can actually be written as imports to core, which exists in both std and no_std mode

[kennykerr]

See #1343 (comment)

[stevefan1999-personal]

@kennykerr but this would mean losing wrapper support for some types right?

[kennykerr]

Do you have an example? I'm not sure what you mean.

[stevefan1999-personal]

@kennykerr From the FAQ it said You would prefer to use APIs that feel idiomatic to Rust for using windows crate, and by using windows-sys you would lose that. I was just using some API like GetCommandLineA which would work just fine right now, but I expect things like to_string would be lost

[hrsman]

@kennykerr Is there anymore interest in having both windows and windows-sys support no_std? If not perhaps the FAQ should mention that you must use windows-sys to get no_std support. It doesn't look like there is a lot of code in windows that requires std. Have a way to disable std in windows would allow for a lot of benefits over windows-sys.

I had to run cargo nono to figure out that windows didn't support no_std.

windows: FAILURE
  - Did not find a #![no_std] attribute or a simple conditional attribute like #[cfg_attr(not(feature = "std"), no_std)] in the crate source. Crate most likely doesn't support no_std without changes.
  - Source code contains an explicit `use std::` statement.
   --> C:\Users\dev\.cargo\registry\src\github.com-1ecc6299db9ec823\windows-0.39.0\src\core\event.rs

  - Source code contains an explicit `use std::` statement.
   --> C:\Users\dev\.cargo\registry\src\github.com-1ecc6299db9ec823\windows-0.39.0\src\core\generic_factory.rs

[kennykerr]

I don't see a compelling need for no_std in the windows crate.

[Beachel]

I just wanted to move from (regarded as deprecated) winapi crate, but sadly there's no support for DirectX 9 and 11 apis in windows-sys crate.

I did some research and there few more developers that are facing similar issue:
#2187
#2514

Is there any compelling reason against supporting no_std in windows crate besides "semantics" (windows is std and -sys is no_std)?

[kennykerr]

The main difference is not no_std support but COM support.

https://kennykerr.ca/rust-getting-started/windows-or-windows-sys.html

[Beachel]

I'm well aware of that.

Because of this comment I suggested to bring back no_std support again to windows crate instead of bringing COM support to windows-sys crate.

[riverar]

Can you explain a bit more what you're trying to do? Why do you need no_std? Are you targeting Windows?

[Beachel]

I'm indeed targeting windows. For legal reasons I can't disclose much, but I'm part of the team that works on a plugin system.

Plugins need to be build as DLLs with a custom entry point (that's why no_std is needed, but that's not the only reason).

We explored other options but sadly no_std is needed in our work.

We are currently using winapi, the whole idea of moving to windows crate came while I tried to port my old project (and so the issue).

[riverar]

One approach to customizing the entry-point could be to do something as such:

// build.rs
fn main()
{
    println!("cargo:rustc-link-arg=/DEFAULTLIB:vcruntime.lib");
    println!("cargo:rustc-link-arg=/DEFAULTLIB:ucrt.lib");
    println!("cargo:rustc-link-arg=/ENTRY:ABC");
}

// main.rs
#![no_main]
#![windows_subsystem = "console"]

#[no_mangle]
pub extern "stdcall" fn ABC() {
    println!("hello!");
}

But sounds like you have other constraints waiting for me in the shadows 😅

[Beachel]

We need fine-grained control over the library being produced (something related to sections and general file structure).

I am not qualified enough to give enough details, but I have heard that this is the most important reason why we need no_std.

My personal impression is that no_std in windows crate is not desirable for a reason unknown to me.

If this is indeed the case, then the current winapi bindings were sufficient for our project and we will probably stay with that.