I'm trying to reverse engineer (OllyDbg) an application (game) that disables (captures/intercepts/blocks) all global hot keys while its window (D3D) is active (except Ctrl-Alt-Del).
My question is in which ways could such application capture/disable global hot keys (including the winkey, CTRL+Esc, and global hotkeys set in other applications) while its window is active?
It seems to use DirectInput (if that matters). I see that it doesn't set any low level hooks (SetWindowsHookEx). In which other ways could such a thing it be done?
Observations made:
When the application is suspended (while its window is still in focus) the hot keys are still disabled while the window is in focus. Switching window to something else enables them. Switching back to the suspended applications window disables the hot keys again.
If doing the same thing but suspending the application after the window lost focus, and then switching back to the suspended window, hot keys are fully working.
Edit: The application appears to block global hotkeys set with RegisterHotKey, but does not disable any hotkeys made with help of a hook (SetWindowsHookEx).
The experiment above seems to indicate that it's some setting related to the window, that works even tho the app is suspended. Could it be some kind of DirectInput setting? (Altho the only DINPUT API function call I see is DINPUT8.DirectInput8Create.)
I'm doing this in hope of changing this behavior to make the hot keys from other applications work as usual while the games window is focused. Any ideas and tips appreciated.
Exactly as Hans Passant suggested in the comments, it was DirectInput causing this behavior, due to the DISCL_EXCLUSIVE flag set with IDirectInputDevice8::SetCooperativeLevel.
Related
Does Windows provide some sort of mechanism to detect when an app running in fullscreen mode (e.g. games, media players, etc.) exits fullscreen mode, either returning to windowed mode or exiting its process?
There is no such thing as "fullscreen mode" or "windowed mode" as far as the OS is concerned. A window simply has dimensions, which may happen to be the same as the screen dimensions or not. The application that owns the window controls that behavior, not the OS, so only the application knows when it is displaying the window in "full screen" or "windowed" mode.
That being said, the application may optionally call ChangeDisplaySettings/Ex() with the CDS_FULLSCREEN or CDS_RESET flag when changing modes. That will send WM_DISPLAYCHANGE notifications to all top-level windows, but it will not tell them that a fullscreen window is being displayed or not.
As for detecting process termination, WMI has an event for that. See Receiving Event Notifications Through WMI.
A simple approach to this, and what I decided to go with, is using RegisterWaitForSingleObject on the created process as explained here: https://stackoverflow.com/a/22418949/1019385
I found it more approachable than the WMI solution.
I'm part of the SFML Team and we're currently looking into a feature to "request" window focus. The goal is to get very similar behavior across Windows, OS X and Linux.
For Windows one gets the rather simple SetForegroundWindow function via the WinAPI, which has a few condition as to how the window actually gets focus. The most important part to notice here is, that it only gets focus if it's from the same foreground process.
On OS X it's possible to get the focus for the active app only and otherwise let the icon bounce, i.e. notification.
Here comes the problem now, we'd like to get the same behavior on Linux as well, meaning the window should get focus if the window belongs to the active/foreground process and otherwise it should generate a notification. What would be the closest thing to that with X11?
There are already a few suggestions on the issue tracker of SFML, but none of them are actually implementing this behavior.
"User Story"
I guess developers can think of different things when being confronted with different technical names, as such here's the issue from a user perspective.
There are mainly two situations in which requesting focus is needed:
Sometimes when starting an application that uses a console window in the background, it can happen that the console window gets the focus instead of the actual GUI window. When this happens it's rather annoying for the user having to click on the window first. Since the console window and the GUI window are from the same application there's no harm done in switching the focus to the GUI window.
When one is writing an application that supports multiple windows, there might be situations where the application should decide which window gets the focus and again since the window belong to the same application there's no harm done in switching the focus from one GUI window to the other GUI window.
Further more if a different application has the focus/is being used then it's not okay to steal the focus and as such we just want to get the user's attention. For Windows that might be a blinking taskbar or for OS X that might be a jumping icon.
The current implementation seems to work fine on OS X and Windows, butwe're unsure about the X11 implementation. Thus the question is: How would one go about switching the window focus if the currently focussed window has been created by the same application that makes the focus request and otherwise create some kind of notification. For the notification we're/I'm not even sure if there's some generic way of doing it with X11.
In X11, "focus" means "the keyboard focus", that is, the window that gets the keyboard input. The window that has the focus is not necessarily in the foreground. This depends on your window manager focus policy. Most can be configured to have "click-to-focus" or "point-to-focus" policy. If you are interested in the keyboard focus, use XSetInputFocus. If you want to bring your window to the foreground, use XRaiseWindow.
It is OK to call RaiseWindow and XSetInputFocus once, when the application starts. It is also OK to bring a window to the foreground/set focus as a response to a user interaction with that or some other window of the same application. But it's not OK to do so as a response to some background event (time passed, file downloaded etc).
The standard X11 method of drawing attention to a window is setting the urgency hint. This will normally flash or bounce the icon, depending on your window manager. Do not forget to unset the hint when the user finally interacts with the window.
I think all of this has been discussed in the thread you have linked. I'm not quite sure which concerns are still left unanswered. Nothing can implement the exact same behaviour as with the other windowing systems, simply because X11 is not those windowing systems, and it's totally OK. X11, Mac OS X and Windows all behave differently and the users know and expect that. It would annoy me to no end if some application on X11 decided to behave exactly like it does on Windows, instead of toeing the X11 party line.
I've been working on an input event system.
I mapped all the keys on my own keyboard, the scancodes and so on, including both windows keys.
When I press them, the program successfully receives the distinct keydown events for them without any trouble.
When I release the keys, however, the Start Menu pops up, obscuring the program in windows mode, or even minimizing it in fullscreen.
So my problem lies in suppressing that.
Arma 2, a Military Simulator/Game allows commands to be mapped on those keys without any trouble.
Where do I have to catch that event?
Can I do it for my own window as long as it has focus?
Am I going to be stuck with a disabled win-key as long as it is running?
Or something else?
Googling it was mainly fruitless due to Windows key also referring to the product key, and when I did find something, it usually flat out disabled the whole button.
I just want to suppress the popup.
Edit:
I tried
case WM_SYSCOMMAND:
switch(wParam)
{
case SC_TASKLIST:
return 0;
default:
break;
}
But that gave me very odd results.
If I spammed the winkeys and only the winkeys, it seemed to work, as soon as I moved the mouse while doing so, it didn't, the start menu would pop up again.
Edit:
I also tried hooks, but on win7 they get removed if the callback takes too much time, which can happen when large data is loaded, so they suggest a dedicated thread for it, but I think that's overkill for just one key that needs handled.
I just want to know where the Start Menu gets called. My own program? The system?
This is so friggin annoying, I am contemplating trying to reach the people from Bohemia Interactive and ask them how they did it.
Just this one key, sheesh Microsoft...even with "Super key/superkey" search terms, I usually only get flat out disabling methods, from registry changes to third party background programs.
Bah!
This artcile was relating to C# but may point you in the right direction;
From MSDN:
A global hook monitors messages for all threads in the same desktop as
the calling thread. A thread-specific hook monitors messages for only
an individual thread. A global hook procedure can be called in the
context of any application in the same desktop as the calling thread,
so the procedure must be in a separate DLL module. A thread-specific
hook procedure is called only in the context of the associated thread.
This was the most helpful link in order to answer the question in the above article
The Raw Input API should solve your problem.
http://msdn.microsoft.com/en-us/library/ms645543.aspx
Having setup C++ app originally using MS specific keyboard journaling hook (WH_JOURNALRECORD) we find that it does not work on Vista unless run as administrator with uiAccess enabled. MSDN Question - Journaling hooks on Vista?
We want to record a key sequence from the user in a friendly way that will be repeated at some later date. The user presses a record button, a dialog is displayed with a stop button and the recorded keys.
One advantage of using the journaling hook was that you only got keystrokes which did something. Holding down shift didn't report 100 shift keys, but did report usage when you hit a letter.
Another advantage was that you could set the focus to an area outside of the application, say another applications window, and record the action as the user interacted.
Asides from making the keyboard capture part of the existing app a separate executable which runs as administrator with uiAccess, I'm seeking other ideas on how to record keystrokes that work on windows for 2K, 2K3, 2K8, XP, Vista.
Edit: I know there is a security concern with just recording anything, obviously if you could do such a thing without the users notice you have your typical keystroke logger for hacking purposes. Soooooo.....
Is there a way to make journaling work, for this user, and their apps, running at the same level (or lower) and capture keystrokes? having it popup the vista security are you sure dialog would be allright, but the process cannot be marked with uiAccess (otherwise it won't interact properly with the rest of the system) and it will in 98% of cases be run by users without rights to elevate to administrator.
Even if you could, you'd probably would find Microsoft fixing that bug in the next patch. The change in Vista was intentional, and there's a clear way (uiAccess==true) to still do what you want.
We have worked around the main issues by using SetWindowsHook instead.
const HMODULE hDLL = ::GetModuleHandle(DLL_NAME);
::SetWindowsHookEx(WH_KEYBOARD_LL, myKeyboardProcCallback, hDLL, 0);
The callback now has to manage the keystroke information and translating it into usable sequences - ie don't record multiple ctrl presses when heeld down to press ctrl+key.
I am developing an application for PocketPC. When the application starts the custom function SetScreenOrientation(270) is called which rotates the screen. When the application closes the function SetScreenOrientation(0) is called which restores the screen orientation.
This way the screen orientation isn't restored if the user minimizes the application and this is not acceptable.
Does anyone know where (in which event handlers) should SetScreenOrientation(int angle) be called to set the screen orientation on application start, restore orientation on minimize, set the orientation on maximize and restore the orientation on close?
Actually I don't know which event handler handles the Minimize and Maximize event.
The correct message is WM_SIZE, but Daemin's answer points to the wrong WM_SIZE help topic. Check the wParam. Be careful as your window may be maximized but hidden.
Going from my Windows CE experience you should handle either the WM_SIZE or WM_WINDOWPOSCHANGED messages. If you're working on PocketPC I would suggest you take a look at the WM_WINDOWPOSCHANGED message first because I'm not sure the WM_SIZE has the right parameters that you need.
From the WM_WINDOWPOSCHANGED message's WINDOWPOS structure take a look at the flags member, specifically SWP_SHOWWINDOW and SWP_HIDEWINDOW.
The specific version of the messages that you need to look at vary with what operating system you're using. The Pocket PC OS is built on Windows CE 3.0 (and lower), while Windows Mobile is now built on Windows CE 5.0 (even Windows Mobile 6), but was also built on Windows CE 4. (Source)
So just look under the relevant section in MSDN for the OS that you're writing for.
I don't know what these are called in the C++ world, but in .NET Compact Framework your application form's Resize event would be called when you minimize/maximize a window, and then in the event code you would check the WindowState property of the form to see if its minimized or mazimized.
Altering the state of your PDA from within your application is risky (although there are lots of good reasons to do it), because if your app crashes it will leave the PDA in whatever state it was in. I've done a lot of kiosk-type (full-screen) apps in Windows Mobile, and one of the tricks to doing this effectively is to hide the WM title bar (the top row with the Windows start button) to keep it from flashing up for a split second every time you open a new form. If the app crashes, the windows bar remains invisible until you reset the device, which isn't good. At least with screen rotation the user can restore it manually.
It really depends on the platform, but I'd go with WM_WINDOWPOSCHANGED or the OnShow. It's not wm_size.. That one is not always thrown on all platforms. Casio's don't throw the size event when you'd expect them to. TDS and Symbol's do.
Even though the MSDN is a great sourse for info, remember not all OS's are created equal. In the PPC world the hardware provider gets to create their own OS and sometimes the miss things, or purposfully ignore things.
I've got a platform here (name withheld to protect... well me) that has left and right buttons.. When you press them, you'd expect to be able to catch VK_LEFT, VK_RIGHT.. You'd be wrong. You actually get ';' or ':'. How's that for a kick in the pants.