Skip to content

Guard windows::ffi::OsStringExt usage behind #[cfg(windows)] for WSL and Linux support #1860

Closed
@MarijnS95

Description

@MarijnS95

Motivation

We'd like to run - run, not cross-compile - DirectXShaderCompiler directly on Linux. At the same time, @riverar found a case to run dxcore inside WSL, which is also a Linux target.

The windows crate doesn't compile for / run on non-Windows targets currently, as std::os::windows::ffi::OsStrExt isn't available on target_os != "windows".

A proposed fix guards all trait implementations containing std::os::windows::ffi::OsStrExt behind a #[cfg(windows)] flag. If needed, followup PRs can introduce Linux-specific implementations for these conversion traits (but read on for a 32-bit wchar caveat).

Drawbacks

Extra complexity for a "purely Windows-oriented" crate. We can solve that by build-testing for Linux - in addition to cross-compiling from it.

Rationale and alternatives

Impact: Not supporting windows-rs on Linux and WSL while at the same time deprecating com-rs leaves users with no alternative for cross-platform COM bindings into libraries like DirectXShaderCompiler.

Additional context

Prior art: #1842 (comment)

Caveat

Furthermore, non-Windows targets use 32-bit widechars instead of 16-bit:

https://en.cppreference.com/w/cpp/language/types#Character%20types:~:text=wchar_t,a%20distinct%20type.

32 bits on systems that support Unicode. A notable exception is Windows, where wchar_t is 16 bits and holds UTF-16 code units

This should be addressed in a separate issue, and seems to be trivially implementable using Rust's char type. This is also how https://docs.rs/widestring implements it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions