I am planning to follow one of the suggestions made here to control window dimensions, hide/show and bring to front of a window owned by a different process from my process.
Window manipulation using window-handle from different process on MS Windows(XP)
How can I control the size and position of a new process Window from a WinForms app?
Will my process be reported as malware by any of the malware detection software you know?
Will my process need any higher privileges to control the other process window than the highest of the privileges with which my process and the other process are running?
I suggest you use UI Automation to manipulate another application's window.
This is probably the best way to ensure your manipulating application will not be seen as malware, as UI Automation is 100% part of the OS, not a HACK, supports security. It also application authors to add or remove automation capabilities to their application. See this somewhat related thread here on SO: https://stackoverflow.com/questions/5383600/win32-vs-ui-automation
Related
The documentation for CGWindowListCopyWindowInfo says
Generating the dictionaries for system windows is a relatively expensive operation. As always, you should profile your code and adjust your usage of this function appropriately for your needs.
My question is how can I "adjust" my use of this function? For a code automation process I frequently need to check what window is frontmost among those of document or modal level. That is, I call CGWindowListCopyWindowInfo, ignore the windows that belong to other processes or have levels that I don't care about, and identify the first window that remains.
If there were a way to ask for information about just the windows owned by my process, say, that would be nice, but I see no way to do that. Or if there were a way to be notified when my windows change. I could watch for Carbon Events when windows are hidden or shown, but of course that is a deprecated technology.
You can use [NSWindow windowNumbersWithOptions:0] to get the window numbers of just the current application's windows (on the active space) in z-order.
On Microsoft Windows (8), I would like to start a process, and prevent it from showing any windows at all. Alternatively, to force-close any windows that are shown. Is there a way to do this?
My application is this: I'm running an automated (nunit) test suite on my continuous integration (teamcity) server. The code under test is also used by an interactive application. Developers occasionally slip in a dialog with a user prompt, without realising what they are doing. This causes the CI process to stop, waiting for user input which never comes. I'd like to be able to dismiss any dialog that appears, or prevent them from being shown.
Even better would be to force an exception at this point, so that the test would also fail.
In my case, this is a C# application, and the dialogs shown are Windows Forms or WPF dialogs.
I did find a couple of similar questions. However each turned out to be solving a slightly different problem.
Stop a process from showing a window from C# (solves a different problem)
Preventing blocking dialogs/message boxes/hanging GUI from non-interactive processes on Windows? (promising solution but C++-specific)
Prevent child process from creating visible windows? (solves a different problem)
Have you considered asking your development team to have a "no dialog" mode of the app for testing purposes? Perhaps if you stopped referring to them as (!!*&%) they would be more inclined to partner with you. ;) Afterall, you do work at the same company on the same product :)
In any case, without a dev-specific solution, consider having a another app (process or thread) that continually sleeps for a few seconds, wakes up and looks for a modal dialog in your application. You can use APIs such as FindWindow to identify when a modal dialog has popped up. (Use Spy++ to get the class name for windows created by MessageBox and CreateDialog APIs).
Related to my question here, is it possible to create a window hook that will monitor if an application has been opened or not?
Most that I have found about hooks seem to focus on user input (keyboard press, mouse events), but I could not confirm if it is possible to know that the "double click" the user made is to open an application, or just to highlight a word.
Thank you.
Indeed, window hooks would not be sufficient. In fact for the task you are asking about you could use various strategies, such as:
enumerating the processes to find the one you're looking for (Tool Help API or PSAPI)
enumerating the top-level windows on the desktop (but you're limited to your desktop then)
check for a global or local event, mutex (or other kernel object) to deduce from that that some instance of the application is running
... or even from kernel PsSetCreateProcessNotifyRoutine
probably there are variations on the above plus some more.
In essence the question is whether you want to check for the process or for some other indicator that signifies whether the program you want to check for has been started.
I have been working on windows automation and monitoring.
What exactly happens when I lock the screen of a windows machine?
I am working with Windows 7 at the moment, are there big differences to the behavior if I switch to Vista or the server versions?
Is there still a desktop that can be accessed via api's?
I know that i can still send key strokes and mouse clicks to specific windows (via ControlSend and ControlClick), but there seems to be no "desktop" itself.
Could someone shed some light on this whole thing or point me at a readable source where I could get an overview over the topic?
Basically what happens is that Windows switches to the secure desktop, makes it the current one, so input is now associated with it.
The old desktop remains where it was: all the HWNDs on the desktop are still there, and any thread attached to that desktop can still access those HWNDs, get their location, and so on. You can still send messages to windows on this desktop, so long as the thread sending the message is also on that desktop.
However, since the desktop is now inactive, it cannot receive input. GetForegroundWindow will return NULL (IIRC), and you can't use SendInput any longer, since input now belongs to [a thread on] a different desktop; no controls on that inactive desktop can receive focus.
Note that sending keypress messages to a control that doesn't have focus can sometimes cause unexpected behavior, since the app or control generally never expects to receive keyboard input without getting the focus first. (This can be problematic for controls that set up some sort of input context in WM_SETFOCUS and clear it up in WM_KILLFOCUS, for example.)
In short, the UI is still there: you can do certain queries against it, but you can no longer automate it as you could on a regular desktop by sending input, and some other functions that relate to focus or input may fail.
I'm not super familiar with AutoHotKey, but the name and description of functionality suggests that it's heavily reliant on the underlying Win32 SendInput API. This won't work at all for keyboard input when a desktop is inactive.
For a reasonable overview of how desktops work and how they relate to winstations, the locked desktop, and so on, check out the Desktop article on MSDN.
One issue that I've run into in the past with desktops and automation is: how to I leave a long-running test that's using some form of user input automation (mouse, keyboard simulation), but still lock my PC so that someone can't just walk by and interfere with it. Once you lock the PC, the desktop is inactive, and so the automation stops working. A similar issue happens if the screensaver kicks in: the desktop switches, and the automation fails.
One solution is to use two PCs: let's call them Main and Test: from Main, open a remote terminal services client onto the Test machine, and then run the automated test on the test machine, but from a terminal services client window on the Main machine. Now the cool part: you can minimize that TSC window, or even lock the Main machine (or let the screensaver kick in), and that virtual session will continue working, thinking that it is still active - it's just that nobody is paying it any attention. This is one way to create a "connected" session with an active desktop, but one that no-one can interfere with, because it's protected behind the locked desktop of the Main machine.
I don't know the details, but I believe the lock screen constitutes a separate "desktop" and maybe also a separate "window station" (as I understand it a window station is merely a container for desktops). The MSDN section on window stations should hopefully be useful: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687098%28v=vs.85%29.aspx
In order to access a desktop, you will need to use the regular windows api's from a thread that is on that desktop. SetThreadDesktop would probably be the easiest way to do that in C, as long as the desktop isn't on a different window station.
Unfortunately, this is already difficult for a regular privileged application, and using AutoHotkey complicates it even more. Since you don't have control over threads or over process initialization, you will probably have to create a new process in the other desktop (you can do this using the CreateProcess API, which appears to have a wrapper available for AHK to which you can supply a desktop name: http://www.autohotkey.com/forum/topic1952.html). Your process will need special privileges to do this; I'm not sure that even running as Administrator is enough.
In Visual Studio's Attach to Process dialog, one of the columns in the Available Processes list is "Title", which lists the title of the topmost window owned by each process.
We spawn multiple instances of several server processes in order to compartmentalize the work. For these console processes, the Title field is blank, so currently we have to look up the process id in our management tool in order to find the correct process.
In order to streamline the debugging process, I would love to be able to use the Title field to directly determine which process I want.
SetConsoleTitle does not do the trick, nor SetWindowText with a NULL hWnd. To the best of my knowledge, a console application does not intrinsically own any window handles that we could pass to SetWindowText. We don't want to create any visible windows for these server processes.
Any suggestions for a reasonable way to trick Visual Studio into displaying some useful information here?
I think you might be out of luck. The console window does not belong to the console process, but instead belongs to a system process (conhost.exe on win7 and maybe vista, csrss.exe before that) so if Visual Studio is just looking for a processes top level windows it won't find the console window. Probing consoles out of proc is not supported as far as I know, so there is probably no sensible way for visual studio to see the title of the console windows you have.
One possible solution might be to create a top level window in your console process as a debugging aid. You might want to conditionally compile it, so it is only available when you're debugging though. Just create an additional thread which pumps messages, and create a top level window. If you set the right styles the window will be invisible. You might not want to ship with the window in the code because in long running server code, windows always increase your attack surface, even if only a little bit.
This is probably not very helpful, but it is worth mentioning that on windows the preferred way of portioning up work would be to use threads rather than multiple processes. A process is an expensive object, and threads are much cheaper in terms of system resources as well as being easier to debug.