CODEWITHSUNDEEP
c++visual-studio-2010winapi
user3151902
user3151902

Reputation: 3176

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.

Example: calculator is still running, but the user can already enter new commands at the prompt

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?

Upvotes: 2

Views: 1154

Answers (2)

David Heffernan
David Heffernan

Reputation: 612983

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.

Upvotes: 2

jww
jww

Reputation: 102256

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.

Upvotes: 2

Related Questions