Probably this already was answered here, but i not found.
Then i want know how execute a c++ console application/service (installs itself as service) of way that i can see all output's (printf()) during your execution (similar to how happens in a normal console application when system("pause");is used in main())? until now i'm able to see you console window only while Avast DeepScreen is executing he :-).
Thanks in advance.
EDITION:
I already insert getchar(); in ServiceMain() and a while (true) ... Sleep() but without success.
A service does not have a console window. And even if it did, a service does not run in an interactive desktop, so you couldn't see such a window anyway.
You need to rethink your logging approach. Either
write your log messages to the Windows Event Log, and use the Windows Event Viewer to see the messages.
create a separate visual app that runs in the user's interactive desktop and communicates with the service process to receive log messages. Then you can display the messages however you want.
Well, take the execution of any program using a c++ program, you can simply do it using the command prompt.
Just type in :
system(“path to the program”);
And, the program will be executed. If it’s a console window program, it will pop-up.
You can see the outputs, well, follow these :
1 The System.Diagnostics.Trace class has a similar interface to the Console class so you could migrate your code quite easily to this.
2 It can then be configured to output to a file. You can use the System.Diagnostics.EventLog class to write to the Event Log which you can then monitor using Event Viewer.
3 You can use the third-party open-source log4net library which is very flexible.
Related
This question already has answers here:
Graceful exit when closing console window
(2 answers)
Closed 20 days ago.
I am making a console app, and I want my program,to do some cleaning up, after you close its console
I researched a lot but I haven't found any good answer to this
There are many ways for a process to be terminated—closing the console window is just one. In general, you cannot depend on being able to clean up on close. Alternatives are to clean-as-you-go and/or clean-up leftovers on the next launch.
If you're worried only about the closing the console situation. Here are a couple options on Windows. Unfortunately, neither of them is trivial to implement.
Rather than creating a console app, create a "Windows" app that doesn't have a GUI and instead creates its own console. When the user closes that console, the process will still be running. I cannot remember if there's a way to attach your "Windows" program to the console it was started from. If there were, I think Visual Studio would have used that rather than the devenv.com and devenv.exe trick.
Create a console app that launches a second (non-console) program. The second process is your main program, but it to direct its output to the console app (e.g., using a named pipe). Likewise, the console app would have to direct user input to the second process. If the user closes the console (or the console app), the second process can continue to run.
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 know this method of setting console size :
system("mode 128,128");
But when program starts, system at first is trying to create console with standard size and when execution reaches mode command - only then the console window gets my desired size. The question is how to make console according to my needs right from the start.
I'm speaking here of running the program with double click from explorer, so the console belongs to the program.
You might have more luck linking your program as a GUI application rather than command-line, calling AllocConsole() to create a console, and then SetConsoleWindowInfo() to resize it. The console would still get created before the resizing, but because you are using the API calls directly, the delay may be small enough to not be noticeable.
If you do this, you may need to do some setup to connect the C and C++ standard input/output/error to the console you created. For that, take a look at _fdopen() and ios_base::sync_with_stdio().
I need to make a windows GUI application can run in console, so I attach the console to the process when the application is invoked with a command line. However, after the application exit, the console prompt with the path doesn't show unless the ENTER key is pressed. Is there any way that the prompt with the path can directly show up without pressing the enter key? Thanks.
Short answer: This is not possible.
Long answer: Well, it is sort of possible if you are willing to relax your requirements a little bit. You basically have three options:
What you have done already. You can attach GUI application to a console but cmd.exe will not wait for your application to exit.
Create a GUI application and open console in the GUI application. The console will only last as long as you application.
Or you can restructure your application/source a bit and provide two executables, GUI one that starts GUI directly, another that is console executable.
In C#, I use SendKeys.SendWait("{ENTER}"); to do that. I think in C++, the keybd_event function does something similar.
Like Autodesk Maya with MayaBatch, you can build a small console application which basically run your GUI application with CreateProcess and wait with WaitForSingleObject.
You will have to use this "batch" version of your application in the console.
I want to make some debug console for my application. It should output some data and take input commands. How can I do this? The best way is updating console like: drawing information and prompt for input after the data.
I'm developing under Linux. For example, gdb could take input from console.
If you're familiar with socket programming (or actually, any other kind of IPC mechanism), you might want to enable some listener within your application, and develop an external application that will do all the "console" stuff for you, while communicating with the main application.
Let's suppose you have an application that has a single button and a single text label, and every time you press that button - the text label goes up by 1, from 1 to 2 to 3 etc.
You can build a socket listener into that application. When the socket listener accepts a new incoming connection, you'd start a connection thread that can:
Receive a "shutdown" command
Receive a "reset counter" command
Send an update regarding the current count on every click
etc.
Then you build another, external application, which connects to the main application, and sends messages to it, based on console input it gets from the user. It would also listen to incoming updates and show them to the user.
Using an external application for debug-controlling your main application is extremely helpful, with the following reasons being some of the advantages:
No matter how the debug application is buggy, it cannot hurt the release version of your main application.
All the code that deals with the console management, which is redundant to your main application, can be kept outside of the main app.
Making two projects out of it can make it easier to collaborate your work with someone else, as long as you are both aware of the protocol between the two sides.
Implementing what I suggested means you can debug your application remotely, in case you don't have access to the main application (for example, if it's on a customer site).