I have been trying to create a cmd.exe from a c++-program and then being able to execute commands from the program inside the cmd.exe, so I can view the results of the operation in the cmd.exe. CreateProcessA() is the function I used:
_STARTUPINFOA CMD_StartupInfo = {};
CMD_StartupInfo.cb = sizeof(_STARTUPINFOA);
_PROCESS_INFORMATION CMD_ProcessInfo = {};
CreateProcessA("C:\\Windows\\System32\\cmd.exe",
0,
NULL,
NULL,
FALSE,
CREATE_NEW_CONSOLE,
NULL,
NULL,
&CMD_StartupInfo,
&CMD_ProcessInfo);
The cmd.exe opened and it looked to be working. Then I thought I'd use PostMessage() to pass WM_KEYDOWN messages to the cmd.exe to execute a command. For this function I needed a window handle and it turns out that the process of getting a window handle from a process/thread ID which is obtained from the CreateProcessA() is f***ing complicated. You have to loop through all active windows with EnumWindows() that requires a callback function which needs to check whether or not the process ID of the current window is the same as the process ID of the process I created.
I did that and it turned out that none of the windows the function iterated over were my window.
So I presume that means that the thread of this process which I created has no windows but I can see a beautiful-looking cmd.exe right there. What is going on? Is this not considered a window? If not, how do I pass messages to the cmd.exe and if yes, how do I get the window handle?
Any help is appreciated (also ideas to do the entire cmd-thing differently).
Related
I have written a simple win32 program say abc.exe.
I have added a button in it, clicking on which an external exe say xyz.exe should start.
But the original program i.e. abc.exe should be inaccessible while xyz.exe is running. (Same as in the case of message box where the parent window remains inactive unless message box is closed)
How can Ido it ?
It would be great if you could post an example code.
You can use WaitForSingleObject (IIRC) to wait for the new process to terminate. You can make your window not visible (e.g. via ShowWindow) before waiting. Check successful launch first.
When the button is pressed, create the 'xyz.exe' process using CreateProcess function and save the new process' handle (hProcess in the PROCESS_INFORMATION struct you passed in CreateProcess).
Then you can disable the 'abc.exe' window by calling EnableWindow with bEnable set to FALSE.
In the window procedure of 'abc.exe', where the WM_PAINT message is handled add a check to see if the 'xyz.exe' process is still running. You can do this by using GetExitCodeProcess function with the handle you saved earlier and checking if the return value is STILL_ACTIVE. If the 'xyz.exe' process is no longer active, you can then enable the 'abc.exe' window using EnableWindow again.
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.
Hello fellow programmers, I have a problem with some console applications in a C++ program, and my objective is as follows.
Create first CMD window.
Execute a command. (system("print some error text");)
Create second CMD window.
Change system(...) focus to second CMD window.
Execute a command.
Change system(...) focus to first CMD window.
Execute a command.
The end goal of all this is to create a function that will be executed by a CMD application that will spawn another CMD window, execute a command on it, and then return focus to the original CMD window to continue executing other code. I do not need to keep track of the window, or be able to return to it. Just create new window, switch focus to it, execute a command, return focus to original window.
The first CMD window is created when the application is started.
Executing a command to this window with system(...); works fine.
I create a second CMD window with
HWND new_hWnd = NULL;
ShellExecute(new_hWnd, "open", "cmd.exe", NULL, NULL, SW_SHOW);
This is where I have problems, I have not been able to redirect system(...) to a different CMD window, and this is the part I need help with because if I can figure this out, then steps 5, 6 and 7 will be easy to complete.
I've tried researching this online and have come across some different examples using "pipes" but have not been able to recreate them, or understand them. Also, I noticed there is a
GetConsoleWindow();
function that returns a handle to the current CMD window, which to me kinda signals that there should be a way to switch between CMD windows by using handles, but since I have not switched focus to the other CMD window I can not call that function to get it's handle.
So, how do I make system(...) target different CMD windows with handles? If that is not possible, how can I implement this "pipe" system.
If the solution is the latter, please try to be as detailed and simple as possible with it because every example of it I have found online is really large and hard to read/understand.
If there is no easy way to implement "pipes" then please post or point me to the best(something that will help me understand how pipes work) example you can find and I will keep working with it till I figure it out. Thank you in advance!
You can create a new console for the new process by specifying the dwCreationFlags value CREATE_NEW_CONSOLE when calling CreateProcess.
See the documentation:
Process Creation Flags: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684863(v=vs.85).aspx
CreateProcess function: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
In MFC, I am using this code
ShellExecute(NULL, _T("open"), _T(EXTERNAL_APP), params,
_T(EXTERNAL_PATH), SW_HIDE);
to start an external program which runs in the background.
However when my app is terminated , this program is still running, as can be verified by inspecting the Windows Task Manager pane.
So my question is, how can I make the external program stop when my app stops ?
Try ShellExecuteEx instead, which can return a HANDLE hProcess of the newly-started process.
When/if you have a HANDLE hProcess then I expect you can pass it as a parameter it to the TerminateProcess function: which you would call (to terminate the child process) before your application stops.
I have tried doing things like...
const char *MessageBoxText = "";
DWORD WINAPI CreateMessageBox(LPVOID lpParam){
MessageBox(NULL, MessageBoxText, "", MB_OK|MB_APPLMODAL);
return TRUE;
}
MessageBoxText = "Blah, Blah, Blah...";
CreateThread(NULL, 0, &CreateMessageBox, NULL, 0, NULL);
However, this does not seem to work correctly for the task I am trying to perform.
What is the best way to create a thread for a message box, without having it glitch up?
Consider passing message text as thread parameter instead of global variable, to make code thread-safe.
DWORD WINAPI CreateMessageBox(LPVOID lpParam) {
MessageBoxA(NULL, (char*)lpParam, "", MB_OK);
return 0;
}
CreateThread(NULL, 0, &CreateMessageBox, "Blah, Blah, Blah...", 0, NULL);
Also, you don't need to specify MB_APPLMODAL as it's default flag (it equals to 0).
If you are targeting modern Windows OS, it's better to have UNICODE defined, because MessageBoxA will convert you strings to UTF-16 and call MessageBoxW
What is the best way to create a thread for a message box, without having it glitch up?
In general, you don't.
Under Windows, all the windows (small 'w', meaning individual GUI elements here) in an application "run" in a single thread. This is generally the "main" thread -- but in particular, it is the thread in which the message pump is running. See my linked post for more details on the message pump.
If what you are truly trying to achieve is a dialog box or some other kind of window that can run concurrently to other windows running, so that it can remain up while other windows are still responsive to user input, then you want a modeless window or dialog box. This is a window that doesn't block other windows from processing updates or accepting user input. See here for a description of how to implement this using MFC, but note that you don't need to use MFC in order to implement a modeless dialog box.
Old question, new answer...
If the thread being invoked is being called into existence by a process that immediately exits (say you're running an executable that uses a VC++ DLL which pops a message box) then the thread will never have a chance to execute.
I had created a VC++ executable for testing that ran a loadlibrary on my DLL and the DLL created various threads with debugging message boxes. Since my testing executable only called the DLL and then exited, it didn't work.
I was informed by a coworker that I needed to add a sleep to the end of the testing executable that is using the DLL file in order for it to work.
Sure enough, it fixed it. This makes sense too, especially in the context of a DLL. Most applications loop until instructed to exit; my test application did not.
Be mindful of how your application is behaving!