-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrating to windows-sys #26
base: master
Are you sure you want to change the base?
Conversation
This replaces crossterm-rs#26 Using the windows crate instead of the windows-sys crate simplifies the code and avoids having to maintain code that handles errors, and various other simplifications provided by the higher level crate. From the windows crate documentation: > The windows-sys crate is a zero-overhead fallback for the most > demanding situations and primarily where the absolute best compile > time is essential. It only includes function declarations (externs), > structs, and constants. No convenience helpers, traits, or wrappers > are provided.
I rebased this and changed to use the windows crate instead of windows-sys in #29. This simplifies some of the result handling and conversions between types. I haven't tested it yet as I use a mac. It compiles, and runs the CI tests I added in #28. The APIs seem as correct as I can make them without actual testing on a Windows machine. |
@joshka Thank you for letting me know. I haven't used the higher-level windows crate in a long time, awesome to see it getting along. It would be interesting to see if it helps the main crossterm crate as well. Timon seems pretty apathetic to migrating from winapi unless a issue arises, so any benefit is awesome. |
Reading the other thread (and assuming positive intent), Timon's view seems more like a "don't fix what ain't broke" perspective combined with an acknowledgment that they don't have time to spend thoroughly testing this. Fundamentally changing a library like this that underpins one that has such a broad blast radius if it breaks is risky if done with limited time availability. |
Oh definitely, nothing negative or anything. It's just one of those things that will always be low priority, just like msvc to ucrt, with Win32 ABI backwards compatibility guarantees and all that. I was semi-expecting more ioctl changes in Win32 with the new APIs, but there doesn't seem to be better/faster ways yet, so any extra benefit helps motivate the migration that's all I was really saying. |
Attempt at moving to windows-sys for win32 api
Please do as you see fit, winapi still seems to be working fine for crossterm's use at the moment.