I'm trying to go through all windows (using Windows API) and get a list of the windows, but when I try to pass through a vector as a LPARAM then I get an error:
non-primitive cast: *mut Vec<isize> as LPARAM an as expression can only be used to convert between primitive types or to coerce to a specific trait object
Code:
unsafe {
let windows: Vec<isize> = vec![];
let _ = WindowsAndMessaging::EnumWindows(Some(enum_window), &mut windows as *mut Vec<isize> as LPARAM).ok();
};
The error diagnostic contains two vital pieces of information:
The expression that failed to compile
*mut Vec<isize> as LPARAM
The language rule that's being violated
an as expression can only be used to convert between primitive types
Either one is spot-on. With any *mut _ a primitive type, it necessarily means that LPARAM isn't. And that is correct, too. Like most types that appear in the transformed API surface exposed by the windows crate, LPARAM follows the newtype idiom.
This prevents common errors where different types share the same underlying type (e.g. HWND and HDC), but also requires that clients construct values of the wrapper type. Casting won't work, as it would with the winapi or windows-sys crates (that use type aliases for primitive types instead).
The second argument to EnumWindows needs to be
LPARAM(&mut windows as *mut Vec<isize> as isize)
Related
I'm using the IDesktopWallpaper::SetWallpaper method from the windows crate. The second argument to this method is a PCWSTR(pointer) to the full path of an image that's meant to be set as the wallpaper. The problem is that the PCWSTR object is meant to be of type *const u16 not *const String. How can I get a PCWSTR object from a Path/String?
let path = "Path_to_image.jpg".to_string();
let ptr = &path as *const String;
let wallpaper = PCWSTR::from_raw(ptr);
// ^^^ expected raw pointer `*const u16`
// found raw pointer `*const String`
unsafe { desktop.SetWallpaper(None, wallpaper)};
When it comes to strings, Rust and Windows couldn't possibly disagree more. There's always going to be conversions involved when using Rust on Windows, and the best you can hope for is a crate that does this for you.
The windows crate doesn't just provide Rust mappings for Windows' API surface, it also contains a tiny library that addresses common issues when programming Windows with Rust, amongst which is string handling. A lot of thought went into string handling, and the result may seem somewhat anticlimactic: All string constants can be represented as HSTRING instances.
Consequently, HSTRING is the pivot point for string conversions in Rust for Windows. Its implementation has a sleuth of From trait implementations for Rust string types (all, I believe), with From implementations of all other Windows string types for HSTRING.
In this case, if path is of type Path you can simply construct an HSTRING from it, and pass it by reference. Everything else just happens due to implicit From trait invocations (namely From<&HSTRING> for PCWSTR):
unsafe { desktop.SetWallpaper(None, &HSTRING::from(path.as_os_str())) };
With rundll32 it is possible to call simple APIs into DLLs.
Two questions:
for this usage, should be the entry point use the __cdecl calling convention, or some other calling convention?
is it possible to pass only numeric args or also strings?
Don't use rundll32.exe. I can't word it any better than Raymond Chen did: What’s the guidance on when to use rundll32? Easy: Don’t use it.
If you read through the blog entry, and are still convinced, that this is the solution you need, here is the deal: The entry point must follow the __stdcall calling convention:
void CALLBACK
EntryPointW(HWND hwnd, HINSTANCE hinst, LPWSTR lpszCmdLine, int nCmdShow);
The trailing W is important, so that the lpszCmdLine argument is passed as Unicode (UTF-16LE). EntryPoint is a placeholder, it can be any legal symbol.
As an example, you can export a symbol called MyFunctionW, and pass an arbitrary command line using:
rundll32.exe MyDll.dll,MyFunction 132 C:\WINDOWS\INF\SHELL.INF
But really, you should evaluate other options (e.g. PowerShell). Convenience doesn't come for free.
The entry point must use the __stdcall calling convention:
void CALLBACK
EntryPoint(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow);
This is covered in the following documentation:
NFO: Windows Rundll and Rundll32 Interface
What does the :: syntax in Rust, as seen here, mean:
fn chunk(n: uint, idx: uint) -> uint {
let sh = uint::BITS - (SHIFT * (idx + 1));
(n >> sh) & MASK
}
In languages like Haskell it means a type hint, but here the compiler already has an annotation of that values type, so it seems it's likely type casting.
Please review Appendix B: Operators and Symbols of The Rust Programming Language.
In this case, the double colon (::) is the path separator. Paths are comprised of crates, modules, and items.
The full path for your example item, updated for 1.0 is:
std::usize::BITS
Here, std is the crate, usize is a module, and BITS is the specific item — in this case a constant.
If you scroll up in your file, you'll see use core::usize. use adds the path to the set of items to look in. That's how you can get away with just saying usize::BITS. The core crate is an implementation detail of the façade that is the std crate, so you can just substitute std for core in normal code.
:: can also be used as a way to specify generic types when they cannot otherwise be inferred; this is called the turbofish.
See also:
What is the syntax: `instance.method::<SomeThing>()`?
Oops. I wasn't reading very clearly. In this case, it's just the normal way of referring to anything under a module. uint::BITS is a constant, it seems.
Looking at the Windows SDK, I found this #define directive for MAKEINTRESOURCEW:
#define MAKEINTRESOURCEW(i) ((LPWSTR)((ULONG_PTR)((WORD)(i))))
Can someone explain to me what the heck that means? For example, what would be the value of MAKEINTRESOURCEW(0)? (1)? (-1)?
The result of this macro will be pointer to long string with value equal to given parameter. You can see it by reading precompiler output (see /P C++ compiler options). All casting is required to compile this macro result, when LP[w]WSTR pointer is required, both in Win32 and x64 configurations.
Some Windows API, like LoadIcon, expect string pointer as their parameter. Possibly, these functions test the pointer value, and if it is less than some maximum, they interpret it as resource index, and not as string (problems of ugly C-style interface). So, this macro allows to pass WORD as string, without changing its value, with appropriate casting.
For the most part, it leaves the value unchanged, but converts it from an int to a pointer so it's acceptable to functions that expect to see a pointer. The intermediate casts widen the input int to the same size as a pointer, while ensuring against it's being sign extended. In case you care, ULONG_PTR is not a "ULONG POINTER" like you might guess -- rather, it's an unsigned long the same size as a pointer. Back before 64-bit programming became a concern, the definition was something like:
#define MAKEINTRESOURCE(i) (LPTSTR) ((DWORD) ((WORD) (i)))
Nowadays, they use ULONG_PTR, which is a 32-bit unsigned long for a 32-bit target, and a 64-bit unsigned long for a 64-bit target.
That's a macro that casts an argument i to a word, then casts that result to a pointer to an unsigned long, then again to a long pointer to a wide-character string.
Like other users said - it just casts an integer into a "pointer to a string".
The reason for this is the following: At the ancient times of Windows 3.0 people tried to be minimalistic as much as possible.
It was assumed that resources in the executable can have either string identifier or integer. Hence when you try to access such a resource - you specify one of the above, and the function distinguish what you meant automatically (by checking if the provided "pointer" looks like a valid pointer).
Since the function could not receive a "variable argument type" - they decided to make it receive LPCTSTR (or similar), whereas the actual parameter passed may be integer.
Another example from Windows API: A pointer to the window procedure. Every window has a window procedure (accessed via GetWindowLong with GWL_WNDPROC flag.
However sometimes it's just an integer which specifies what "kind" of a window is that.
Then there's a CallWindowProc which knows to distinguish those cases.
What win32 calls can be used to detect key press events globally (not just for 1 window, I'd like to get a message EVERY time a key is pressed), from a windows service?
You want to use Win32 Hooks. In particular a keyboard hook.
You can read more about it here
The type of hook you want is WH_KEYBOARD and you can set it via the Win32 API SetWindowsHookEx.
Basically windows will call a function in a dll that you create everytime a key is pressed in any application system wide.
The hook will call your function which will have this interface:
LRESULT CALLBACK KeyboardProc(
int code,
WPARAM wParam,
LPARAM lParam
);
More information about this callback here.
With windows hooks you can not only track system wide events across all processes, but you can also filter them and stop them altogether.
Take a look at the hooks you can set with SetWindowHookEx:
http://msdn.microsoft.com/en-us/library/ms644990(VS.85).aspx
However, unless you are running an "interactive" service, you won't have access to the desktop (and you shouldn't be running an interactive service because it won't work right in newer versions of Windows). You will have to look into the session and desktop management APIs in order to access the desktop/console.
Check out the Raw Input API in MSDN:
http://msdn.microsoft.com/en-us/library/ms645536(VS.85).aspx
It allows you to get input from keyboards (among other things) without messing around with global hooks. Global hooks should only be used as a last resort as they may introduce unintended consequences.
The only drawback to using Raw Input is that it may not properly receive keystrokes which are generated by software.
Just use the native function GetKeyState, or GetAsyncKeyState, or GetKeyboardState from user32 DLL.
You can read about each function I mentioned above in the msdn site:
h ttp://msdn.microsoft.com/en-us/library/windows/desktop/ms646301(v=vs.85).aspx
for the GetKeyState, and
h ttp://msdn.microsoft.com/en-us/library/windows/desktop/ms646293(v=vs.85).aspx
for the GetAsyncKeyState, and
h ttp://msdn.microsoft.com/en-us/library/windows/desktop/ms646299(v=vs.85).aspx
for the GetKeyboardState.
If you program in C# then:
Your code must include the following line out of any class, struct or enum declaration:
using System.Runtime.InteropServices;
Then in the class that has the method where you want to detect the keys, define one of three functions above for your choice, or what works and what not.
[DllImport("user32.dll")]
static uint GetKeyState(byte virtualKeyCode);
//or
[DllImport("user32.dll")]
static uint GetAsyncKeyState(byte virtualKeyCode);
//or
[DllImport("user32.dll")]
static uint GetKeyboardState(byte[] virtualKeyCodes);
//NOTE: The length of the byte array parameter must be always 256 bytes!
If you dislike uint as return type, you can also change it to int.
If the native functions always return 1 as true or 0 as false, then you can change their return type to bool instead, but if you do so, then I think you should add another line of code above the native function definition, which is:
[MarshalAs(UnmanagedType.Bool)]
OR you can add the following line in the middle of the native function definition (below the line where the DllImport word is, and above the line, where the 'extern' word is):
[return: MarshalAs(UnmanagedType.Bool)]
Pinvoke site offers better definition for these functions, so you don't have to use integers to mention a particular key of your keyboard, but more understandable enum.
The following link leads to the definition of the GetKeyState in C#:
h ttp://www.pinvoke.net/default.aspx/user32.getkeystate
The following link leads to the definition of the GetAsyncKeyState in C#
h ttp://www.pinvoke.net/default.aspx/user32.getasynckeystate
The following link leads to the definition of the GetKeyboardState in C#
h ttp://www.pinvoke.net/default.aspx/user32.getkeyboardstate
To detect which key is held down (at any time, anywhere) then call GetKeyState or GetAsyncKeyState function, in the single parameter, mention the key you want to detect and then add: & 0x8000, or & 0x80 after the call.
If the mentioned key is held down, then the return value of the expression is not zero, but otherwise it is zero.
According to the returned integer of the expression, you can determine which key held down or not.
Note that if you put code inside if statement with that expression != 0 as enter condition, which is inside a loop, the code in that if statement will be executed more than once, actually many times, when you held down that key. If you want some code to be executed once When you press a key and then release it, then the following code is a trick that achieves this goal:
while (boolean exression that will return false when you want to quit this loop)
{
if (boolean expression that will return true when particular key is **held down**) //This boolean expression calls either GetKeyState or GetAsyncKeyState with the & 0x8000 or & 0x80 after the call, and then != 0 to check for **held down** key
while (true) //It's purpose is to wait for the same key that was held down to be released. After code execution, it will encounter the break keyword that will finish him, even though that his enter condition is true.
if (boolean expression that will return true when the **same** particular key is **NOT** held down! (NOT held down, means that at that time, that key was released). You can copy the same condition from the first if statement, and just change **!=**, which is next to 0, to **==**, or instead add brackets to the condition '(' and ')', and in left of '(' add '!').
{
//Put here the code that you want to execute once, when paticular key was pressed and then released.
break; //the while (true), which is the only way to get out of it
}
}
If you are implementing this in a .net application i'd recommend GlobalKeyboardHook, Otherwise i'd look at it's source and take what you need since it is implementing the DLLImport functions mentioned above.