-
-
Notifications
You must be signed in to change notification settings - Fork 392
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
SetWindowLong vs SetWindowLongPtr #285
Comments
For winapi 0.3 functions will be defined in file corresponding to the header they are from since I will be getting rid of the -sys crate nonsense. Thus you'd also be able to reexport functions under different names (as well as defining shim functions that call functions) since everything would be in the same crate. |
I meeting plans about 0.3 from time to time, but is any roadmap and dates about it? Just to be aware of it. |
There have never been any dates or roadmaps for winapi. It'll happen once I catch up on all the PRs, get the license situation squared away (I want to make all the copyrights consistent and switch to dual licensing MIT/apache), and then finally start overhauling stuff. It'll occur in bursts whenever I feel sufficiently motivated. |
I have added re-exports for these functions so you can now use |
For x86
SetWindowLongPtr
is just a macro substitution forSetWindowLong
, and user32-sys declaresSetWindowLongPtr
only for x64, because x86 user32.dll has noPtr
version.But what about
SetWindowLongPtr
usage? We can implement it inuser32-sys
, but winapi-rs prefers no executable code as mentioned in #218. Or we can write the portable stub for x86/x64 in every rusty crate, which tries to use the user32.Any better solutions for this?
The text was updated successfully, but these errors were encountered: