How to get Process IDs of all running process (shown in windows task manager) by invoking window DLL function - powerbuilder

I want to get list of all the process IDs currently running on system even if they are in back ground using some windows dll. Is there any function of any dll which can return all PIDs.


window less Application

i got to do a task that is to find out process /exe/application running in the background.
ie:the process is running but do not have any UI/ Window visible although its an windows GUI application . i thot of reading EXEheader. The header contains a field called 'Subsystem'and application is to run under and the type of interface it requires.
but it returns Windows GUI and it is so. but i want teo detect if that application haves any window or not. also this application is not a service as if it is a service i can easily read the info.
i will be glad if any of you genious put some light on the pronblem stated.
Warm Greetings..
If I understand your question correctly, you want to know if a running application has any visible windows.
To do this, you can call EnumWindows to get all top-level windows. For each window, call GetWindowThreadProcessId to get the process ID and GetWindowLong(hwnd, GWL_STYLE) to get the window style. Test the style for WS_VISIBLE to see if the window is visible. Run through all the windows and see if your process owns a visible one. If you don't have the process ID, you can get them all with EnumProcesses.
The "subssytem" GUI doesn't tell you that the application has a window. In fact, the opposite is closer to the truth. A console application gets a console window. A GUI app is responsible for creating its own windows, if and when it needs them. A GUI process that hasn't called CreateWindow() won't have any windows.
Apparently, you do know the executable you're looking for. In that case, call EnumProcesses() to find all processes, and for each process call EnumProcessModules(). On Windows, "modules" are DLLs and EXEs. Each process will have exactly one EXE module. So, if the one EXE module of any process is the executable you're looking for, then your application is running.

Can an application run the code of another application?

I'm relatively new to C++ and WinAPI. So far I've managed to create an application, that is using the CreateProcess function and a STARTUPINFO structure to create a new desktop, launch inside that new desktop a new explorer.exe process and switch to it.
Next, because I wanted to be able to switch at any time between these two desktops, at a press of a key (LCTRL in my case), I've made another application that uses the SetWindowsHookEx function to create a global hook for the keyboard.
Because the hook is active only in the calling destkop, in the first app, using CreateProcess, before creating the explorer.exe process and switching to the new desktop, i've launched the executable of the second app twice: once in the current desktop and once in the new one.
Everything is working fine, I'm able to make the switch between desktops at any time, but now I've been asked to do something about the structure of the processes launched, somehow, to make the seconds app code run inside the first one, without creating a new process. Because this is my first post, I can't upload a snippet of the process tree, but the procexp application from live.systernals is showing the following structure:
-------------SecondApp.exe (original desktop)
-------------explorer.exe (new desktop)
-------------SecondApp.exe (new desktop)
So basically, my question is: can I make the code of the application that hooks the keyboard run in the same thread as the FirstApp? This implementation, an app that starts these three processes, and the second app that hooks the keyboard, was my idea (I was not requested to do it this way, I was only asked to create a new desktop and switch between them), so I am open to suggestions towards making a better implementation for this problem too.
It could be possible since there is little difference between a DLL and an EXE on Windows, so I think you could try to export the routines from SecondApp and then import them in FirstApp with LoadLibrary.
But IMHO the clean way to do that is to break SecondApp in two pieces : a DLL containing code that actually does the job and an EXE that would be a simple frontend calling routines from the DLL.
That way, it will be trivial (and portable across different versions of Windows and SDK) to call the routines of the DLL from FirstApp.

Possible to have Win32 application block until it exits?

When I open a command line in Windows (cmd) and start a program, for example calc, the prompt immediately returns and the program is started (the calculator window is displayed).
This is contrary to how I know it from the Linux world: when I start a (possibly with GUI) application, the prompt does not return until I exit the started program.
Using the w32 api, is it possible to program it so that my app displays a window, but the prompt is only returned after the user closes the window?
Possible to have Win32 application block until it exits?
Call CreateProcess to create the process. This will yield a handle to the process in the PROCESSINFORMATION struct that is returned. Pass that process handle to WaitForSingleObject to wait until the process is signaled.
Based on the comments it seems that what you really want is an executable that will behave like a console app when its parent process is a console app. And behave like a GUI app otherwise. It's not possible to do both from a single executable. The target subsystem is determined by metadata in the executable file.
The standard way to handle this is to have two executables, each targeting the different subsystems. One a console app, the other a GUI app. The common examples of this are java.exe and javaw.exe, python.exe and pythonw.exe.
Using the w32 api, is it possible to program it so that my app displays a window, but the prompt is only returned after the user closes the window?
I think there are a few questions here.
First, how do you create a process in Windows? To create a process Windows, you use CreateProcess.
Second, how does CreateProcess work? CreateProcess obviously creates a new process (like calc.exe), and it offers a lot of options to create the process. It also returns a BOOL to let you know if the call failed or succeeded.
In the case the call fails, you get a failure immediately. That's a "synchronous" failure, and you can continue moving along in your procedures.
In the case the call succeeds, your process is "detached" from the child. Its more like an "asynchronous" call to the function. You can synchronize with the child process, and you can learn that it has exited by waiting on the hProcess member of the PROCESS_INFORMATION structure.
Third, not everyone starts processes from the command line. It might be started by clicking it on the desktop. This is true in the Linux/X11 (et al) world too.
Fourth, from the Windows command line, I believe you can use CALL for other batch files. But I don't recall if it applies to programs, too.

How can I detect Applications Focus Changes?

I know how to get the title and exe name of the foreground window application that is running now, but I use a TTimer to verify when it changes.
Is there a way to detect events triggered by Alt+Tab, taskbar application selection or even the start of a new program?
I use Delphi 2006 and Windows 7 64 bits.
One option is to install a global hook. With a CBT hook, the system will call the hook procedure whenever a window is activated (among other things). A global hook callback is to be placed in a dll which gets loaded in the address space of processes, hence it can get mapped into only processes having the same 'bit'ness (using Delphi 2006, the callback will be called only by 32 bit processes). Moreover, it cannot be mapped into address space of a process that is created with a higher privilege (i.e. an application that is run as administrator if the process installing the hook is not). You also have to devise some kind of interprocess communication mechanism since your callback runs in other applications. You use SetWindowsHookEx to install a global hook.
One other option is using event hooks, that's SetWinEventHook. There are two kinds, in-context and out-of-context. The former one, like a global hook, is placed in a dll to be mapped into address spaces of other processes, so you'll suffer from same downsides. Out-of-context events are the most relaxed of all. They wouldn't be prompt as global hooks or in-context events when notifying but I believe that could still be better then a timer. One disadvantage of events to hooks in your context is that, you would have to code a bit more in the callback, f.i. you'll receive a window focus notification even for child windows and you would have to resolve which application it belongs to etc..

How do I use RestartManager to restart explorer.exe with Windows Installer custom action?

I have an installer that prompts users to restart their computer after an install. I would rather not have the user restart their computer in this case, and have explorer.exe just restart itself using the RestartManager API provided with Windows Vista and up.
I've created a separate executable that gets copied to the local computer during install and runs after that. The separate executable registers explorer.exe, shuts it down, and restarts it based on this code: When the executable is run separately from the installer, it works as designed. But when it runs as a custom action as part of an MSI package created with InstalShield, it shuts down explorer.exe but does not restart it.
I always get a 160 error code for RmRestart when it runs with the installer. The docs say it's an error code meaning there were invalid arguments provided. ( I'm fairly positive that my arguments are not invalid as they work when the executable runs separately from Windows Installer.
I'm stuck at this point and not sure what else to do to get this working. The only thing I'm uncertain of is if "0" can be a proper session handle returned from RmStartSession() with error code of 0 (Success). Assuming this was wrong, I set up my executable to also take in the RmSessionKey that's created by Windows Installer before InstallValidate. And I use that to call my executable as a deferred action. I get an error of 4c3 for RmShutdown in this case, which seems to be an invalid error code.
Cliffs: Have separate .exe that uses RestartManager API to shutdown, restart explorer.exe that works when not run with Windows Installer, but when combined, it breaks. Seeing error code of 160 for RmRestart(). Ran out of ideas to try to get this working. I can provide code snippets if people want...
Thanks for any suggestions/comments.
I ended up reaching a solution to this...
Rather than creating a separate executable that registers explorer.exe and shuts it down, create a MSI DLL Custom Action. All this DLL has to have is a single function that registers explorer.exe to be restarted and use the existing restart manager session provided by Windows Installer (by default). Then in your installer, add the MsiFilesInUse dialog and you'll be good to go.
Now when the installer runs, it starts the restart manager session, and calls your MSI DLL CA, and adds explorer.exe to the list. The list gets displayed and the user is given options to close or defer closing of the applications.
Using this method allows you to avoid having to distribute a pointless executable to the user, as well as simplifies the amount of code written greatly.