Skip to content
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

cargo-release changes and migrate to windows-sys #97

Closed
wants to merge 1 commit into from
Closed

cargo-release changes and migrate to windows-sys #97

wants to merge 1 commit into from

Conversation

sn99
Copy link

@sn99 sn99 commented Jan 30, 2023

Changes include migrating to windows-sys and cargo release optimizations

@Narsil
Copy link
Owner

Narsil commented Jan 30, 2023

No.

(You didn't argument for this change, so I won't argument in my refusal)

@Narsil Narsil closed this Jan 30, 2023
@sn99
Copy link
Author

sn99 commented Jan 30, 2023

@Narsil My bad, the changes include:

  • Migrating from winapi to windows-sys: winapi is no longer maintained in favor of windows-rs which is provided by Microsoft itself. It should provide more robustness against future windows upgrade and better compile and runtime guarantees
  • cargo.toml release arguments especially lto=true help libs further down the line to have certain optimizations enabled

@Narsil Narsil reopened this Jan 30, 2023
@Narsil
Copy link
Owner

Narsil commented Jan 30, 2023

I'll reopen, since it does seem winapi is not well maintained.

@sn99
Copy link
Author

sn99 commented Jan 30, 2023

I am on a windows system and the last test seems to fail even on my machine, even before I made any changes:

PS C:\Users\sn99\Downloads\rdev-main\rdev-main> cargo test
    Finished test [unoptimized + debuginfo] target(s) in 0.06s
     Running unittests src\lib.rs (target\debug\deps\rdev-c607d680501d202a.exe)

running 2 tests
test tests::test_keyboard_state ... ok
test windows::keycodes::test::test_reversible ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests\listen_and_simulate.rs (target\debug\deps\listen_and_simulate-7e3563f7acb512d4.exe)

running 1 test
test test_listen_and_simulate ... FAILED

failures:

---- test_listen_and_simulate stdout ----
thread 'test_listen_and_simulate' panicked at 'assertion failed: `(left == right)`
  left: `MouseMove { x: 0.0, y: 1.0 }`,
 right: `MouseMove { x: 0.0, y: 0.0 }`', tests\listen_and_simulate.rs:39:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    test_listen_and_simulate

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.10s

error: test failed, to rerun pass `--test listen_and_simulate`

Copy link
Owner

@Narsil Narsil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok gave it a little more thorough review.

I'm being harsh. This is not towards you, mostly towards Microsoft.
Since I had to go through all the BS of their API, I'm very unfavorable of touching anything.

Despite the outdatedness of winapi I actually went through a ton of testing to make sure things work. I'm very reluctant to make any changes that change types.

And there's a least 2 instances here where type seem to be modified between winapi and windows-rs. This in addition with the lack of consistency with the original windows docs, give me very little confidence that those modifications are actually working.

Of course I'm likely to be wrong, since windows-rs seems to be getting quite a lot of usage, but my experience, is that this crate touches not so widely used API, or in an odd fashion (or many devs are getting insane).

All in all, I'd like to keep this PR open. It's a very nice PR, thanks for working on it.
But I'm not trusting enough that the changes are actually valid to merge it anytime soon.

This will happen only after extensive testing (especially the corner cases which I know caused a ton of issues). And that unfortunately won't happen anytime soon.
This is now a personal project, and it's already in a working state, so I'd rather not spend the time on something I don't think adds a ton of values (like fixing existing bugs, or add new features)

@@ -1,2 +1,4 @@
/target
Cargo.lock

/.idea
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[profile.release]
lto = true
codegen-units = 1
opt-level = 3
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still no. This is really not the job of the lib.
Or prove that it does matter, if you really think that's the case.

@@ -9,14 +9,14 @@ fn main() {
listen(move |event| {
schan
.send(event)
.unwrap_or_else(|e| println!("Could not send event {:?}", e));
.unwrap_or_else(|e| println!("Could not send event {e:?}"));
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove all these changes and put them in a separate PR please.

While being nice, they pollute the PR by adding a lot of meaningless changes.
Changing a dependency is not a simple thing, keeping the changes to a minimum increases the likelihood that the review will be done correctly.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see it's a new clippy lint. Let's still move it to another PR.

pub static mut HOOK: HHOOK = null_mut();
#[inline]
pub fn hiword(l: u32) -> u16 {
((l >> 16) & 0xffff) as u16
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

microsoft/windows-rs#2273

This feels broken to me. Classic Microsoft thing.
This single thing gives me doubt in moving dependency altogether.

((l >> 16) & 0xffff) as u16
}

pub static mut HOOK: HHOOK = 0;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this

@@ -117,8 +121,8 @@ pub unsafe fn set_key_hook(callback: RawCallback) -> Result<(), HookError> {
}

pub unsafe fn set_mouse_hook(callback: RawCallback) -> Result<(), HookError> {
let hook = SetWindowsHookExA(WH_MOUSE_LL, Some(callback), null_mut(), 0);
if hook.is_null() {
let hook = SetWindowsHookExA(WH_MOUSE_LL, Some(callback), 0, 0);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


static mut GLOBAL_CALLBACK: Option<Box<dyn FnMut(Event) -> Option<Event>>> = None;

unsafe extern "system" fn raw_callback(code: i32, param: usize, lpdata: isize) -> isize {
if code == HC_ACTION {
if code == HC_ACTION as i32 {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -53,7 +53,7 @@ where
set_key_hook(raw_callback)?;
set_mouse_hook(raw_callback)?;

GetMessageA(null_mut(), null_mut(), 0, 0);
GetMessageA(null_mut(), 0, 0, 0);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -47,16 +49,16 @@ impl Keyboard {
let mut state = [0_u8; 256];
let state_ptr = state.as_mut_ptr();

let _shift = GetKeyState(VK_SHIFT);
let _shift = GetKeyState(VK_SHIFT as i32);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*inner_union = MOUSEINPUT {
dx,
dy,
mouseData: data,
mouseData: data as i32,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No we can't cast here. something else has to be modified in types.

@sn99
Copy link
Author

sn99 commented Jan 30, 2023

I think the suggested changes are pretty good, I will look into them again tomorrow, windows-rs has 2 parts windows and windows-sys, the differences are mentioned here https://kennykerr.ca/rust-getting-started/windows-or-windows-sys.html, do you want me to choose windows rather than windows-sys?

@Narsil
Copy link
Owner

Narsil commented Jan 30, 2023

I think the suggested changes are pretty good, I will look into them again tomorrow, windows-rs has 2 parts windows and windows-sys, the differences are mentioned here https://kennykerr.ca/rust-getting-started/windows-or-windows-sys.html, do you want me to choose windows rather than windows-sys?

I think as a starter let's keep to windows-sys. It's closer to what is already there so it will be easier to spot the core differences.

@sn99 sn99 closed this by deleting the head repository Jan 31, 2023
@sn99
Copy link
Author

sn99 commented Jan 31, 2023

I will make separate pulls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants