Feature request: Provide bitness-independent mappings where available

[tim-weis]

Motivation

64-bit Windows introduced a number of new APIs to accommodate for increased pointer type widths. A prominent example being the [Get|Set]WindowLongPtr[A|W] family of functions. They supersede the [Get|Set]WindowLong[A|W] functions, but aren't available on 32-bit Windows.

As a consequence, code that needs to be compatible with 32-bit Windows as well as 64-bit Windows must conditionally pull in the required dependencies. C and C++ developers using the Windows SDK have this solved: They can unanimously use the *-Ptr-variants and rely on the preprocessor to transform their code as needed.

Rust developers using the windows or windows-sys crates, on the other hand, will not find themselves in as comfortable a situation. Getting code to compile across architectures with differing pointer widths usually involves a fair amount of conditional code (see the Direct2D sample for an example).

Ideally, clients should be able to just call GetWindowLongPtrA and have their code compile across architectures.

Drawbacks

I'm not aware of any adverse effects in providing this.

Rationale and alternatives

Rationale

The developer experience for clients of windows and windows-sys should be on par with that of C and C++ developers using the Windows SDK. This feature request addresses an issue where this is not the case.

Alternatives

The alternative is propagating the responsibility for writing bitness-adaptive code to clients or crate authors.

Additional context

Prior art

The winapi crate solves this by re-exporting the *-Ptr-variants as aliases for 32-bit platforms, e.g.

#[cfg(target_pointer_width = "32")]
pub use self::GetWindowLongA as GetWindowLongPtrA;

Unresolved questions

• Are there other API calls that fit this category?
• Should a solution be metadata-driven or would a hand-crafted implementation (akin to what winapi does) be manageable enough?

[kennykerr]

Thanks Tim. I don't think there will be any metadata to link them together, but I would like to simplify this if possible.

[kennykerr]

Sorry for the delay - let me know what you think of #1932.