This is kind of an odd question but does anyone know how to make a c++ program open multiple separate CMD prompts? they don't even have to be proper command prompts they can spit out text in a separate CMD like window that's fine. they don't need to talk to each other or do anything more than display text. the only reason I'm not doing this in Batch is because it needs to be a compiled EXE. I know I can run windows commands in c++ with "system(...)" however I'm not sure how to force these to be separate windows. if anyone knows a way to do that I would greatly appreciate it.
Thank you for your time
You can use CreateProcess to rum cmd,and communicate through pipe.
Your question is not clear to me, but let me try:
A single process can have no or exactly one console window. E.g. in Visual Studio, in the linker settings, you can set the subsystem to console, then the console window is opened automatically or you can use AllocConsole to get one. If you need more windows to display text, you have to create these windows by yourself (these windows aren't normal console windows). Another possibility is to start more backgroud processes, each having its own console window to display the text. To start these background processes, use CreateProcess and use for dwCreationFlags CREATE_NEW_CONSOLE.
If you have a batch file and want to display multiple console windows, use the start command to start your console program to create a new console and disply its output there, e.g.
start cmd.exe /k dir
Related
I'm trying to have a separate console window for my program that is already in a console. How would I be able to open this new console window then output to that specific console?
I've found ways to do it that work in windows using "cconsolelogger", but not for Linux.
I assume that by "new console", you mean a terminal emulator window.
A terminal is a program like any other, so you start it like any other program. The only standard way in C++ to open another program is std::system, which executes a shell command. Here is an example of opening a terminal emulator:
std::system("xterm");
Note that it is not safe to pass arbitrary user provided input into the command, because it is vulnerable to shell injection.
The POSIX standard - that is followed by Linux operating systems in general - provides other, lower level tools to run another executable. In particular the exec family of functions allows executing another program without starting a sub process and without involving the shell.
Maybe you can use popen.
You can choose the program to write command to it, for example:
gp = _popen("C:\Program Files (x86)\gnuplot\bin\pgnuplot.exe", "w");
fprintf(gp, "set term png\n");
My application is a GUI app that has helpful (though optional) information through the terminal (via cout).
In Windows I either have a console appear (by compiling as a console app, or allocating it dynamically) or I don't.
My intention is to make use of the console IF it is being run from the console, but ignore the console completely if it was not. (Essentially what happens in Linux and OS X).
I do not wish to redirect to a file (and in the case of using cin, this is not a viable solution anyway).
Is there a way to attach a GUI app in Windows to the console it is run from, if and only if it is run from a console?
and in the case of using cin, this is not a viable solution anyway
This is the killer detail in your question. It is simple on paper, just first call AttachConsole(ATTACH_PARENT_PROCESS) to try to attach to an existing console. That will fail when your program got started from a GUI program like Explorer or a desktop shortcut. So if it returns FALSE then call AllocConsole() to create your own console.
Using cin is a problem however. The command processor pays attention to your EXE and checks if it is console mode app or a GUI app. It will detect a GUI app in your case and then doesn't wait for the process to complete. It displays the prompt again and waits for input. You will then also wait for input but you'll lose, the command processor got there first. Your output is also intermingled with the command prompt, the easy problem to solve.
There's a simple workaround for that, your user should start your program with start /wait yourapp to tell the command processor to wait for the process to complete. Problem is: nobody ever uses that. And the user will not realize what happens when they type input, intending it to go into your program but it is actually interpreted by the command processor. Producing a mystifying error message or formatting the hard drive.
Only two good ways to solve this unsolvable problem. Either build your program as a console mode app and call FreeConsole() when you find out you want to display a GUI. Or always call AllocConsole(). These are not great alternatives. The first approach is the one used by the Java JVM on Windows. One of the oldest bugs filed against the JVM and driving Java programmers completely batty from the flashing console window.
The third alternative is the only decent one, and the one you don't want, create another EXE that will always use the console. Like Java does, javaw.exe vs java.exe.
A trick is possible, you can rename that file from "yourapp2.exe" to "yourapp.com". It will be picked first when the user types "yourapp" at the command line prompt, a desktop shortcut can still point to "yourapp.exe". Visual Studio uses this trick, devenv.com vs devenv.exe.
You can check CONSOLE_SCREEN_BUFFER_INFO (via GetConsoleScreenBufferInfo) on startup to determine if you've been run from within an existing console. If the buffer's position is 0,0, you were run from outside of the console. For details, see this Microsoft Knowledgebase Article which describes the process.
In order for this to work, you need to compile your application as a console application (using /SUBSYSTEM:CONSOLE), and then detach yourself from the console if the application started a new console (buffer at 0,0). This will cause the program to properly "attach" to the calling console when launched from a command line.
As others have pointed out you have to create a console app and a window app. So, you'd end up with console.exe and app.exe. To make it less obvious at the command-line, you can take advantage of the PATHEXT trick like devenv does. cmd.exe treats a file as a command if its extension is in the PATHEXT environment variable. COM is there by default so you could rename console.exe as app.com, allowing the command app to start the console app attached to the current console.
Note: Of course, a console app can show a GUI if desired.
The difference in the build between app.com and app.exe depends on your build system but it could just be the one attribute that sets the output type. With msbuild (for .vcxproj files), it's just a matter of another build configuration.
you can create an application in console that get a line using argc and prints it;
////
int main(int argc, char *argv[])
{
//here print argv....using cout or printf
}
save the file as console.exe in the folder of your app.
now in your app if you want to see any line in console you can call the command
system("console.exe this is the line i want to print and see in console");
I have a DLL for a program, and want to be able to run that program in a command line, and then pipe the output of my DLL to another program. How do I do this?
I can currently opening a new debug console to print to, but I want to be able to pipe the output so that I can run a shortcut like:
C:\Windows\System32\cmd.exe /K "C:\Program_Using_the_DLL.exe | C:\Program_to_Pipe_To.exe"
This is different from some similar questions (IE: this one) in that I need to be able to pipe the output, so I need it to come to the current console.
Perhaps I can use GetStdHandle() somehow, or is there someway of using AttachConsole(ATTACH_PARENT_PROCESS)? Any help would be appreciated! I'm new to this nitty-gritty part.
(DLL is written in C++)
Try using the function GetStdHandle(STD_OUTPUT_HANDLE) to get a HANDLE to the current output file.
Is there any way a C++ commandline program on Windows can produce a graphical GUI print dialog for printing to a printer, just like usual GUI programs? I've combed through this webpage and it seems there are only commands that print files in the background to a pre-determined printer.
Command-line applications in Windows still have full access to everything that GUI-mode applications do (the only difference is they start out with a console, whereas GUI-mode applications do not).
So you can still call all of the regular printing functions from GDI.
What I want to do is something like this:
ConsoleWindow1.Print("1");
ConsoleWindow2.Print("2");
When I run the program, two console windows pop up and one gets printed with 1 and the other gets printed with 2. Is there a simple way of doing this?
For console based application there can be only one console per process. You can start two processes and then do some sort of IPC to coordinate with each other
One way I see, to write a console that prints argument given to exe, and write another application that call both with different arguments, I didn't try but may be you can open two by WIN32 functions, see How to Open Console Window in a Win32 Application