Using EnumProcesses I am able to get list of currently running processes. But how do I know which of them are applications? I am talking this w.r.t. task manager, see here.
I guess IsWindow() function is what I need.. right? If not, please guide further.
You are looking for the top-level visible windows. Find these with EnumWindows. This enumerates all top-level windows. The ones you are interested are the visible ones. Call IsWindowVisible to obtain that information.
Related
So I have spent that past week and a half working on code to simply setup the hook procedure for wh_shell for a program that will replace explorer.exe in the registry and will run as the main desktop program. There seems to be very little information and sources for using this outside of just the windows API which is a bit undescriptive and doesn't explain everything to a great detail. For some reason I just cant get it to work, no matter if I run it inside of explorer.exe, or if I replace the register and make it the default shell. I'm going to ask a couple of things in this post because I think that if you can answer one of these questions you likely have the answer to more.
So first I just have a question about hooks in general: When I run the SetWindowsHookEx(...) function -resource below- it says for var lpfn that a dll is not necessary if the hook is only used to monitor the current process. Now obviously when monitoring events such as window_created, those are events within a different processes which makes me think that the hookproc has to be within a DLL(which is how ive programmed so far). But this is questionable to me because when u are running SetWindowsHookEx(...) the process I wish to monitor do not yet exist until the user decides to start them. Do these processes notify the system when wh_shell events are being done so that I my hook doesnt need to get placed into every process upon creation, or is it more like when I run SetWindowsHookEx(...) with wh_shell that it will place a hook in all processes when the are created. The second resource states that the system just calls the hookproc when these things happen, so then do I even need a DLL, or what process does it need to be hooked to because I dont think it needs to be hooked into everything.
So second I have a question regarding setting my process as default shell - see resources - the resource states any process that registers itself as the default shell(which I assume is just modifying the registry to my process, if not and there is more please let me know) needs to call the SystemsParameterInfo(...) function. So first, does this func need to be called before running SetWindowsHookEx(...) or is there some expected spot it should be elsewhere in my code? Then in regards to the other variables it doesnt specify for, just curious what the recommended would be to set them as, like what are they set as for explorer.exe, and maybe a few other examples(including things NOT to do).
Finally for the sake of testing, using the console will be the most helpful to me here. The console will be used for input to run functions and commands for now(like open the register and swap back the shell to explorer.exe). If my hookproc is within a DLL, I need it to output some messages, I dont want to muddle the same console and I also dont even know if it will output to the same console, so what might be a recommended or potential solution for outputs(again this is temporary and for testing so it doesnt have to be perfect or even great)?
Also I would think windows 11 shouldn't be an issue, but I havent tested on windows 10 system...
I havent included any code as Im pretty sure most of this stuff can be answered without it and that its so few lines of code that its not like typical questions where its like examine my code and help me, maybe some example code you can show me would be really helpful.
Thankyou!
SetWindowsHookEx(...)
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa
defaultShell
https://learn.microsoft.com/en-us/windows/win32/winmsg/about-hooks#wh_shell
regards to WH_SHELL section
Testing Environment:
Windows 11 vm running in Hyper-V Manager
You haven't mentioned an important parameter in your description and that is the last argument of SetWindowsHookEx, the thread id.
When it is set to 0 then ..
'[in] Specifies the identifier of the thread with which the hook procedure is to be associated. If this parameter is zero, the hook procedure is associated with all existing threads running in the same desktop as the calling thread.'
That said, then like everything in Windows programming nothing is as what the documentation states, its as if the documentation is a wish-list Microsoft will like Windows to be when it grows up.
Actually even if you manage to get everything right you will see that the shell messages you will get will be VERY few compared to what the documentation states.
I am working on the same issue and when I get it going I will post the results here.
I want to monitor when a key is changed/added/deleted to the registry whenever application is being installed or removed. I have tested the sample code from the msdn(link) and it works fine.
But the problem is that it does not tell me which key has actually been modified/added/deleted. How can i retrieve this information using c++?
There are only 3 ways, none of which is both easy and adequate:
RegNotifyChangeKeyValue:
Doesn't give you the info you need, but is very easy to use.
EVENT_TRACE_FLAG_REGISTRY which is part of Event Tracing for Windows
which is what ProcMon uses. It works well, but it's quite difficult to use.
I'm not sure exactly how to use it myself, but if I figure it out I'll post it here.
CmRegisterCallback:
Requires kernel-mode driver, which is a pain in 64-bit.
But it's the most perfect solution otherwise.
Unfortunately Event Tracing for Windows (EWT) does not allow to see full key path in the event. You get only a partial key name and a strange handle with is actually a key control block. It's not so simple to get information from this block.
Yes the process monitor uses EWT, but it does not use Windows Kernel Trace as a provider.
I need to get the list of functions in global hook chain in Windows and get their corresponding application if it's possible. I don't know how to retrieve information from the global hook chain however.
As far as I know there is no windows API for doing this so I think I have to find them by parsing the hook chain link list. The problem is that I don't know the data structure of this link list and it's begin address.
Does anyone know how windows manages its global hook chain?
One approach I've seen is shown in this blog post. It was referenced by this code (beware of slow server). Crazy stuff of course, no idea how well this will port between different Windows versions.
Instead of trying to walk an internal Windows structure, you know that all Window hooks must have a loaded module associated with them that has been injected into the target process; if you're trying to ensure that your own application isn't being hooked, enumerate the loaded module list and look for modules that shouldn't be there.
I need a tool which will discover whether an arbitrary process is running in x86 or x64 mode on a machine. I need to do this programatically from C++, based on a process ID.
There has to be some way to do this (as you can clearly see it from the task manager). Does anyone know of a windows api that will tell you, given a process ID, whether the application is running under wow64?
Another approach would be to figure out, based on the process id, the executable name/path that is running and try to read the PE headers out of the file. Does anyone have a code snippet that would accomplish that?
There is a WinAPI function, IsWow64Process.
Basically what I am trying to do is write my own pseudo task bar in C++. The program needs to idle until another program is started up, at which point it needs to visually depict that the other program is running. For each other program that is running, the user should be able to click on the visual representation and have Windows switch focus to the selected program.
The big underlying question at this point: is this even a possibility? Or has Windows hidden most/all of its fiddly-bits to make this close to, if not completely, impossible?
[EDIT:] restructured the question
The obvious starting point would be SetWindowsHookEx(WH_SHELL,...); which will get you notifications when top-level windows are created or destroyed (along with some other related events, like a different window being activated, a window's title changing, etc.)
Think ahead to actually bringing the window to the front, as I once researched myself.
SetForegroundWindow() won't work unless issued from the foreground process - neither SwitchToThisWindow() nor the AttachThreadInput() kludge seemed to always work, but maybe I just wasn't doing it right. Anyway as far as I know there no way to make a window foreground as good as Windows does, please enlighten me if say you discover say an undocumented call which actually Works.
It seems possible to me at least in a basic way:
1. Set up a shell hook as described by Jerry
2. figure the executable file from the module handle to access it's icons using shell services
The Vista-like feature of keeping a 'live' miniature of the screen seems much more challenging.