I'm trying to simulate the keypress events for Win+X on Windows 8 which should pop up a small menu, but I have been unable to get this to work by using SendInput. For any other combination of keys (e.g. Win+R, Win+E, Win+D) it works but not for Win+X. I've noticed that Synergy+ has the same problem, but the Windows on-screen keyboard doesn't. I have also looked at the parameters for SendInput that the on-screen keyboard uses but if I use exactly the same parameters in my application I still don't get the menu.
So my question, how do I get this to work? Or is there an alternative way to display this menu?
I've recently added support for this to our application. Glad we beat our competitor to it!
There are new UIPI restrictions in Windows 8. The most-used blocked shortcut is Alt+Tab, so you're going to want to do the workaround.
You have to mark your binaries with uiAccess="true" in the manifest. (For more detail on how to do this, google.) This manifest prevents binaries from being launched unless signed with a Microsoft-approved code signing certificate and installed in a "secure location" (system32 or Program Files/Program Files (x86)).
If you lanch your program from any helpers: The uiAccess binary can't be launched with CreateProcess from a medium integrity process (the manifest marks it as requiring "high" integrity). Instead, it's easiest to launch it using ShellExecute "open" to get the shell to elevate it. If using CreateProcessAsUser, you have to set TokenUIAccess to 1 using SetTokenInformation, or launching will fail.
Final provisos: note that uiAccess quite heavily restricts what a process can do. You can't receive UI input from normal (medium integrity) processes, so other applications can't interact with your windows. If you don't already follow good practices in separating your UI into a separate process, this would therefore be a good reason to do that. Alternatively, the tasks requiring uiAccess could be put into a small, self-contained helper binary and entirely separated from the non-UI process too. Your main app can run it as a high-integrity helper process that is sent instructions as required to perform those specific tasks (such as SendInput).
Finally, SendInput will work.
Related
I have a C++ windows service running on system privileges and I need to make some changes in some of my DLLs that are loaded to several windows processes (explorer.exe, etc.).
The only time to do so is when these processes are down. I'm trying to make to impact to the UX minimal, so I don't wan't to force quit those or to popup any annoying message boxes and ask the user to do so.
I have tried to start this task on the startup of my service, the issue is several of these processes start before I finished it.
I'm trying to understand if there is a way to delay the start of processes on Windows startup, until I finish my task. Is there any event or anything familiar that I can set that will block those?
The other option is to do the needed task on shutdown. I did not find a way to do so yet, and all the related questions seem a bit old (how to delay shutdown and run a process in window service
), and regard to older version of windows.
This solution needs to be compatible with Windows versions greater than 7.
You can do this by using MoveFileEx and setting MOVEFILE_DELAY_UNTIL_REBOOT which will replace the file at the next reboot.
This should be well before any other processes have started, but without more details on your usecase its hard to tell if this'll work for you. Either way, searching for this flag should give you lots of information about this kind of issue.
According to the documentation, this has been supported since XP.
I need to listen to few keys in my "background" application.
My application runs in background and is used to emulate keyboard input based on what user pressed on keyboard. It sounds strange but it actually is a very handy application. For example when I type "address" followed by double space bar it replaces it with my full address. I defined more "macros" like that. I wanted to share my application with friends.
But there is a problem with AV software telling them that this application is suspicious.
This is not a great problem, as my friends can mark that application as "trusted", but it takes time and very frustrating.
I tried hooking keyboard input. I used SetWindowsHookEx with keyboard hook. But there is a small problem. Nearly all the virus protection programs detect it as some kind of harmful program.
What is the proper / AV friendly way of making such program?
P.S.
I'm using C++ with WinApi.
If you indicate in your program manifest that it needs to run with elevated privileges, the AV programs shouldn't bother you any more. That is not the preferred way to write an app, but sometimes it is necessary for low-level stuff like you are trying to do.
Here is a link that gives you the details on how to implement requesting elevated privileges:
http://msdn.microsoft.com/en-us/library/bb756929.aspx
As a matter of fact you should consider three different things :
1. The behavior of an AV program is not always deterministic to you, because they change their rules as needed.
2. Different AV programs use different rules.
3. Back when I wrote a kiosk program which needed to block certain key combinations, I marked my app to run with elevated privileges, as #edtheprogrammerguy suggested and it worked fine with norton, kaspersky and bitdefender . Hope it helps
I've been asked by a client to solve the following pesky issue. They have a custom software that has a tendency of displaying message boxes "left and right" without any apparent reason. For instance, the software itself is an accounting program, and when they take a customer's payment, the message box may be displayed about 3 or 4 times in a row. Each message box plays Windows default sound. Unfortunately the way this software was programmed, the type of sounds it plays is completely wrong. For instance, it may display a warning message box and play the warning system sound when the message itself is just an information. All this is quite annoying for the staff who uses the software.
I tried to contact the vendor who distributes the software, but I hit a deadend with them. So now I am looking for ways to mitigate this issue.
My easiest solution was to suggest to mute the speakers, but unfortunately, they require sound to be present to be able to hear incoming emails, and most importantly, be able to play voice mail from them later. So my solution was to somehow mute message box sounds just for a single process.
From my experience, I know that there're two APIs that may be producing these sounds: MessageBeep and an older Beep.
I also found this article that explains how to use AppInit_DLLs to hook to system APIs. It works great, except that both of the APIs that I need to hook to come from User32.dll and not from kernel32.dll like the author suggests.
There's also this post in the questions section that kinda gives approximate steps to hooking to an API from User32.dll, but when I tried to implement them, there's not enough information (for my knowledge to do it.)
So my questions is, does anyone know how to hook to an API in the User32.dll module?
EDIT: PS. Forgot to mention. This software is installed on Windows 7 Professional, with UAC disabled -- because it is not compatible with UAC :)
As an alternative you can patch you application. Find calls to MessageBeep and overwrite them with nop.
This is the hard way of doing it: if your app is supposed to be running as Administrator on a pre-Vista Windows, you could get the address of the API via ::GetProcAddress(), give yourself privileges to write to its memory page, and overwrite the beginning of the API's code with a "jmp" assembly instruction jumping into the address of your override function. Make sure your overwrite function takes the same arguments and is declared as __cdecl.
Expanded answer follows.
The "standard" technique for API hooking involves the following steps:
1: Inject your DLL into the target process
This is usually accomplished by first allocating memory in the target process for a string containing the name/path of your DLL (e.g. "MyHook.dll"), and then creating a remote thread in the target process whose entry point is kernel32::LoadLibraryA() passing the name of your DLL as argument. This page has an implementation of this technique. You'll have to wrestle a bit with privileges, but it's guaranteed to work 100% on Windows XP and earlier OSes. I'm not sure about Vista and post-Vista, Address Space Layout Randomization might make this tricky.
2. Hook the API
Once your DLL is loaded into the target process, its DllMain() will be executed automatically, giving you a chance to run anything you want in the target process. From within your DllMain, use ::LoadLibraryA() to get the HMODULE of the library containing the API you want to hook (e.g. "user32.dll") and pass it to ::GetProcAddress() together with the name of the API you want to hook (e.g. "MessageBeep") to get the address of the API itself. Eventaully give yourself privileges to write to that address' page, and overwrite the beginning of the API with a jmp instruction jumping into your detour (i.e. into your "version" of the API to hook). Note that your detour needs to have the same signature and calling convention (usually _cdecl) as the API you want to hook, or else monsters will be awakened.
As described here, this technique is somewhat destructive: you can't call back into the original API from the detour, as the original API has been modified to jump into yours and you'll end up with a very tight and nice infinite loop. There are many different techniques that would allow you to preserve and/or call back into the original API, one of which is hooking the ...A() versions of the API and then calling into the ...W() versions (most if not all of the ...A() Windows API's convert ASCII strings into UNICODE strings and end up calling into their ...W() counterparts).
No need to spend time on a custom program to do this.
You can mute a particular application when it's running, and that setting will be remembered the next time you open the application. See https://superuser.com/questions/37281/how-to-disable-sound-of-certain-applications.
There's also the Windows Sound Sentry that will turn off most system sounds, although I'm not aware of any per-application settings for Sound Sentry.
You can use Deviare API hook and solve the hook in a couple of C# lines. Or you can use EasyHook that is a bit more difficult and less stable.
I've searched the web, and various forums, but I can't find one thing, how to continually monitor open programs and then close another program (not the one being monitored) if something happens to the program being monitored.
For example, say that there is an already open Notepad window, and then the user or some other program opens a Windows Explorer window. I want to know how to close the Notepad window without interacting with the Windows Explorer window (other than realizing that it is indeed open), as well as closing the Notepad window if the user closes the Windows Explorer window.
Thanks in advance! :D
On windows, you can use PSAPI (The Process Status API) to know when processes are started and terminate. The EnumProcesses function can give you this information.
A more reliable method to determine that a process terminated (since process ids can be reused) is to wait on its process handle (you will need the SYNCHRONIZE access right) which you can obtain using OpenProcess and the process' id obtained from EnumProcesses.
To terminate a process, there is always TerminateProcess. To call TerminateProcess, you will need a handle to the process with the PROCESS_TERMINATE access right. All of this assumes that you have the privileges needed to perform these actions on the process to be terminated.
One thing to be aware of is that processes and programs - or at least what the user regards as a program - are not necessarily the same thing.
If you use the PSAPI to get a list of all the processes running, you'll see a lot of background process that don't correspond to open windows at all. There's also cases where a single process can have multiple top-level windows open. So while you have simple cases like notepad where once notepad.exe process corresponds to one Notepad window, you also have cases like:
Word, where one word process handles all the word documents currently open (one process, many windows)
Explorer, where a single exploere.exe process handles all the open explorer windows, and also things like control panel windows and the task bar.
Chrome (and other browsers), where each tab gets its own process (many processes, one window!)
Using TerminateProcess is perhaps not the best way to close an app: it's not directly equivalent to clicking the close button. It forcibly terminates the entire process there and then, without giving it any chance to clean up. If you do this on Word, when it restarts, it will go into 'recovery mode', and act as though it hadn't shut down cleanly the last time. It's best left as a last resort if a process has stopped responding. Also, if you TerminateProcess on a process like Word or Explorer, you'll end up closing all windows owned by that process, not just one specific one.
Given all of this, if you want to essentially write some sort of program manager, you might be better off taking a window-centric approach rather than a process centric one. Instead of monitoring running processes, monitor top-level application windows.
There are several ways to listen for changes to windows; SetWinEventHook with EVENT_CREATE/DESTROY is one way to listen for HWNDs being created or destroyed (you'll need to do filtering here, since it will tell you about all HWNDs - and more! - but you only care about top-level ones, and only app ones at that). SetWindowsHookEx may have other options that could work here (WH_CBT). You can also use EnumWindows to list the windows currently present (again, you'll need to filter out owned dialogs and tooltips, currently invisible HWNDs, etc).
Given a HWND, you can get process information if needed by using GetWindowThreadProcessId.
To close a window, sending WM_SYSCOMMAND/SC_CLOSE is the best thing to try first: this is closer to clicking the close button, and it gives the app a chance to clean up. Note that some apps will display a "are you sure you wish to close?" dialog if you haven't saved recently - again, it's consistent with clicking the close button with the mouse.
The most well-known way of doing this on Windows is to use the Process Status API. You can use this API to enumerate processes However, this API is annoying in that it doesn't guarantee you get the full list or processes.
A better way to enumerate processes is using the Tool Help Library, which includes a way to take a complete snapshot of all processes in the system at any given time.
You need the Microsoft PSAPI (Processes API), for example to see the open processes you can use the openProcess function.
Are there winAPI function (without classes) to create a daughter window from console application. It necessary to print graphics of shapes on window, and input commands to console.
Thank you.
it's simpler to create console window for your GUI application. Have a look here
I'm not sure if you mean something specific by "daughter", but it's certainly possible for a console application to create a window (or as many as it likes). It's also possible for a windowed application to allocate a console.
Allocating a console from a windowed program is theoretically a bit work, but does have one advantage: you can write the majority of your windowing "stuff" using an application framework of your choice (Qt, wxWidgets, etc.)
If you work directly with the Windows API, it's a bit easier to create a console application and create windows as you see fit. About all you have to do in this case is write your code just as you normally would a windowed program, but instead of WinMain, name your entry function main. Based on that, the linker will automatically set the "console" flag in the executable, and Windows will give it a console when it starts up. The big advantage here is that C++ standard library gets initialized automatically, so things like cin all work without any extra effort on your part. If you start from a Windowed program and allocate a console, all that'll work by default will be the Windows API functions (ReadConsoleInput, WriteConsoleOutput, ReadFile, WriteFile, etc.) You can get the C and C++ functions to work, but you have to deal with some fairly poorly documented areas (that are all open to change with the next release of the compiler) to make it happen. I'd generally avoid this unless I was only going to use the Windows API functions to deal with the console anyway.
Here is a much easier way that may work well for you, provided you're using Visual Studio:
If you are, you can start a forms application by creating a forms project, add the necessary forms, and then change the application type (by right-clicking the project and selecting properties) and changing it to a console application. It will still spawn the form windows as you would expect, but will also start a Console window (which will still be populated by cout, etc...)!