I have a windows application which invokes CreateProcess and then it exits. The process being invoked displays console and GUI windows at startup. I would like to hide the console window of the child process right when it starts.
More info:
Process is NOT started with DETACHED_PROCESS flag.
If injecting code with FreeConsole() to the remote process is the only way (I'm looking for a better one), is it not going to cause trouble with over-sensitive anti-viruses?
You can use the CREATE_NO_WINDOW flag to start a console application without a console window. It's not the same as it being hidden, but it sounds like it's what you want.
Related
I have a WinAPI/Win32 application. If I try to use cin/cout/cerr when it is run from a command prompt, it doesn't work. I tried switching the project type from Windows Application to Console Application, but the problem is that a console window appears when I run it normally by double-clicking the executable.
So my question is: Is there any way I can use cin/cout/cerr with the parent (calling) console window in a Win32 application? (I only want this behaviour if parameter /c or /? were passed, so if it is called with no arguments then no matter what it should launch the GUI).
A GUI app does not have a console window attached to it by default.
When a GUI app is run from a console process, the GUI app can use AttachConsole() to attach itself to the console.
Or, if the GUI app is not run from a console process, but still wants to use a console window, it can create its own console window using AllocConsole().
Once the GUI app is attached to a console, it can use GetStdHandle() to get handles to the console's STDIN/STDOUT, and then redirect cin/cout to use them (how is dependent on your particular STL implementation).
Or, you can ignore cin/cout and just use ReadConsole() and WriteConsole() directly instead.
I have a program that launches a child process.
When the child process crashes I would like there not to be a debug message box. I would like to do this without writing anything in the child process.
I am running this on windows 7.
In the createProcess function, in the flags parameter I only put CREATE_NEW_CONSOLE.
During my attempts, I put SetErrorMode(SEM_FAILCRITICALERRORS|SEM_NOGPFAULTERRORBOX) in the child process and made it crash, there was no dialog box. Now I put the same function call in the parent program before I called create process, and made the child program crash, now the message box appeared.
What should I do differently?
have you set CREATE_DEFAULT_ERROR_MODE in process creation flags?
I'd like to create a tool that can either act as command line (display some console output based on input parameters), or display a window, based on input parameters.
I'm using MSV2012 with C++, and it seems you have to 'choose' between console and window app.
I know the net is filled with samples which use AllocConsole() and redirect std::out, but it doesn't make it feel like a command line application : calling the exe from the windows console will open a new window with the console output...
Is there a way to have it use the current console window instead of allocating a new one?
If not possible, I'll make 2 applications instead, but that's a pity..
Someone else may have a more authoritative answer, but I don't believe it's supported.
The usual workaround is to create a Windows app, but have a command-line wrapper that launches it from the CLI (and provides a channel for communicating with the original console).
It's not technically supported but I found a good solution by getting a snapshot for the current process, finding the parent process, attaching to it's console if it's a console app or creating one with AllocConsole, redirecting the output, getting the thread of the parent process if it's cmd.exe and suspending it, resuming it just before I exit my app
Using the Win32 API in Visual C++, I want to create a program under the Windows subsystem that allocates a console with AllocConsole and writes to it with WriteConsole. However, if the user closes the console, the process should keep running in the background. As it stands, I can't get that to happen. When X is pressed on the console title bar, the process exits.
Is there any particular way of doing this?
Thanks in advance!
The key is to respond to the Console Control Event that is raised when the user attempts to close the console. You can then call FreeConsole to detach your program from the console, and let the console be destroyed. That should keep your program running.
Additional info:
If the process is terminated when the HandlerRoutine exits, then my suggestion didn't work as expected. If that's the case, then you might have a problem. You can try hooking the SC_CLOSE system message, and do the FreeConsole there before passing the message on. That might work, although I don't know what it'll do if the user presses Ctrl+C or Ctrl+Break.
The problem is that the control handler exits the process. It might be that calling FreeConsole in the HandlerRoutine is too late.
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..
Sarfu
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.