Implement windows backend without windows-sys
#96
Conversation
Kijewski
force-pushed
the
pr-windows-manually
branch
5 times, most recently
from
9ecc98c to
41172b5
Compare
Kijewski
added
Unsafe-Proposed
Kijewski
force-pushed
the
pr-windows-manually
branch
2 times, most recently
from
082e3a0 to
9ea50b2
Compare
Kijewski
changed the title
windows backend without windows-sys
|
Tested successfully with {x86_64,i686}-pc-windows-{msvc,gnu}. It cross-compiles successfully for aarch64-pc-windows-msvc, but I have no device to test it on. |
Kijewski
force-pushed
the
pr-windows-manually
branch
from
9ea50b2 to
54c10b6
Compare
This PR removes the `windows-sys` and `winapi` dependency completely. Instead, the relevant API was extracted from `windows-sys`, which in turn is generated from Windows's header files. The only Windows specific depency now is `windows-targets`, which was a transitive dependency before. It contains the proper mappings between a function name, its mangled name, and its `.dll`. The rationale for this change is that the previously used `winapi` crate is unmaintained for the last three years, even though it contains some (minor) errors. The alternative to `winapi`, `windows-sys` is still fast moving. In its (at the time of writing this PR) newest release 0.45.0 it removed all WinRT functions, so it arguably does not any function we need to implement our library anymore.
Kijewski
force-pushed
the
pr-windows-manually
branch
from
54c10b6 to
79d0da7
Compare
| let mut pos = 0; | ||
| while pos < INPUT.len() { | ||
| // ensure that the input string is ASCII and does not contain any NUL characters | ||
| let _ascii_only = [0][if matches!(INPUT[pos], 1..=0x7f) { 0 } else { 1 }]; |
There was a problem hiding this comment.
The ASCII check isn't used for anything... but presumably it should be?
There was a problem hiding this comment.
Actually, no. I removed the UTF-8 → UCS2 conversion from the source, and the line is meant to throw an error at compile time if not all characters were in ASCII range. Panicking in const contexts is only stable since 1.57, so I used the older workaround to access an array out of bounds, which is caught by the compiler. I only gave the result a name, so it would occur in the error message quoting the offending line
|
I confirm this is working for me on |
Kijewski
force-pushed
the
pr-windows-manually
branch
from
5f47dbc to
6ad6fae
Compare
Kijewski
force-pushed
the
pr-windows-manually
branch
from
6ad6fae to
caf7869
Compare
|
Thank you for opening the thread over at windows-rs! I added another commit to make the error checking a little easier to read. I think the code is not too bad. It's just not rusty, and more like C++ written in Rust. :-/ |
|
I think this is superseded by #97. I will close this for now. (I'll be glad if we don't have to maintain this amount of |
This PR removes the
windows-sysandwinapidependency completely.Instead, the relevant API was extracted from
windows-sys, which inturn is generated from Windows's header files. The only Windows specific
depency now is
windows-targets, which was a transitive dependencybefore. It contains the proper mappings between a function name, its
mangled name, and its
.dll.The rationale for this change is that the previously used
winapicrateis unmaintained for the last three years, even though it contains some
(minor) errors.
The alternative to
winapi,windows-sysis still fast moving. In its(at the time of writing this PR) newest release 0.45.0 it removed all
WinRT functions, so it arguably does not provide any function we need to
implement our library anymore.