Is there any thing I can do to make sure that the shell/command prompt does not show up when I run my C++ program, it is meant to be a background program? While it isn't a huge deal if it displays because it quickly closes, I would prefer it doesn't display at all. Program will run on windows xp/vista/7 OS
Configure your compiler or linker to mark your program as a GUI application.
Windows recognizes two main types of programs: GUI and console. If the EXE header is marked as a console program, then the OS creates a console window prior to executing it. Otherwise, it doesn't. This isn't something you can control at run time; you need to set it at link time. (You can call ShowWindow(GetConsoelWindow(), SW_HIDE) to try to control it at run time, but that doesn't prevent the window from flickering on and then off again. Plus, if your program is sharing the console with another program, like cmd.exe, then you'll have just hidden the user's command-prompt window!) Even if your program doesn't have any actual GUI, that's still the mode you need to avoid having a console window created for you.
If you're starting a new project in Visual Studio, select the "Win32 Console Application" option. If you already have a project, then in your project's configuration properties, find the "Subsystem" setting of the "Linker/System" section and set it to "Console." That makes the linker use the /subsystem:console option. If you're using Mingw, use the -Wl,--subsystem,windows option.
Sounds to me like you want to create a Windows service, not a command line utility. This is why services exist. Long running background tasks that require no user interaction. A simple example here.
Related
I was having an issue with a C++ program where when I ran the .exe the program would run and my window for the program would open, but the console would be open on the desktop in the background. I did a google search and found that compiling with the -mwindows command as an argument, removes the console. Which it did. But I'm unsure of what it actually does and I am curious.
It behaves exactly the same as the /subsystem:windows switch described on MSDN.
Basically, it sets the entry point to WinMain (or wWinMain) instead of main (or wmain), which results in no console window and some Win32 startup code running to create the arguments passed to WinMain. As Neil says, it does not prevent or enable anything you can't do without it.
A similar switch is -municode to switch between main/WinMain and wmain/wWinMain, which is not mirrorred by the Microsoft tools. These seem to automagically select the one you use).
It says that your application is one using the Win32 API that doesn't need a console window. You use this option when you are writing Windows GUI applications, DLLs and the like, although a console window can be useful when debugging these kinds of applications. Even with this option, you can explicitly create a console window, should your application need one dynamically and, contrariwise, you can call Win32 GUI APIs from a console application.
In Code::Blocks 20.03 (uses the MinGW-W64 gcc compiler project) the project target ( bin/Release ) compiles with -mwindows and the project target ( bin/debug ) compiles without -mwindows. The debug target not only has debugging information in the executable, but it runs with the console window exposed in the background. This is 'highly' useful for debugging, since your app can write to the console debugging messages while your gui app is processing... like an active debugging log.
Obviously the console is ugly for release targets. In Code::Blocks the switch -mwindows is set indirectly in the Project properties under the 'build targets' the bin/debug build target is specified as console app, while the bin/release target is specified as gui app.
Back in the day (maybe eight years ago) there was a catch-22; -mwindows was necessary to link the Win32 api (but no console). If you wanted a console AND the Win32 api it didn't work easily; fortunately this is not an issue today... you can mix and match. I generally build my release targets without the console; and I build the debug targets with the console, and I use the console for debugging copiously.
marcus
The dev environment in question consists of:
Windows 7
MinGW (g++)
CMake
Qt Creator
The problem is that Qt Creator, a lovely IDE as far as I can tell, does not display programs' command-line output. It seems to have its own proprietary debug pane, but it doesn't give me, for example, runtime errors. It just tells me that the program has failed and gives me the exit code. I'm using Creator only for its C++ capabilities, and not using Qt in any way, so the proprietary pane is useless to me.
So I ask this: Can something be done? Am I missing something really, stupidly obvious like a built-in command line? Or, if not, can I at least use some filthy and/or repulsive hack to get it to display the Windows command prompt upon running a program?
Last thing; I did do some research, and found a way to edit the Qt project file to display the prompt, but... I'm using CMake, not Qt projects. So that doesn't answer my question. If I can do something similar with CMakeLists.txt, that would be wonderful. But Google has failed me on that front, so I'm not holding out too much hope.
EDIT:
I'm specifically worried about runtime errors. cout and printf are rerouted to Qt Creator's window, so that's fine. I don't get runtime errors unless the debugger catches them, and the frequency of that is less than ideal.
Windows GUI programs don't have standard output.
In Windows there are two possible entry points in the standard runtime. The console one and the windows one. The console one will inherit console window from parent process or create a new one and connect the standard input/output/error streams to it, while the windows one will leave them unconnected unless they were explicitly redirected by the invoking process. A Qt application is (probably; you could have console Qt-Core application) a GUI application and Qt Creator (nor any other Windows IDE) does not redirect the output explicitly. Therefore the standard output is not open at all and the writes are being discarded.
However windows have separate logging facility for debugging purpose. This is what you see in the debug window. You can write to it using the native OutputDebugString API. I am sure you can also direct the Qt debug log there.
Note, that when it tells you the program has exited with status 0, it means the program ran, which in turn means it compiled successfully and thus there were no errors from g++. There may have been warnings, in which case you should see them in the appropriate other window. Compiler and program output are different things; the IDE does read the compiler output.
I am having an EXE of C++ program which takes one EXE as input searches for symbol in it and replace it with some value from user through command prompt.
I am using Eclipse IDE and MinGW compiler for development.I have also set linker flag to '-static'. but when I run EXE on some other machine I got with the problem of UAC popup window, which is asking for administrative privileges.
I also tried with the option of setting 'Run this program as an administrator',but it is also not working.
Please help me out..Thanks in advance.
Unless you have taken steps to add the requireAdministrator option to your requestedExecutionLevel application manifest setting, you would not expect to receive a UAC prompt. However, there are backwards compatibility options in Windows that will result in the UAC prompt being shown for certain applications.
These backwards compatibility UAC prompts only happen for executable files that do not include the requestedExecutionLevel application manifest setting. In that scenario the system uses heuristics to determine whether or not to show the UAC prompt. For instance, non-manifested applications named setup.exe or patch.exe will get the UAC prompt.
The way to avoid being subject to this backwards compatibility behaviour is to link an application manifest to your executable.
This question covers the topic in rather more detail: How does Windows decide whether to display the UAC prompt?
Apart from what #David Heffernan has written, you can also trigger UAC window when you launch your application from folders like Program Files etc., which require administrative privileges. The same applies if you try to manipulate files located in such folders. Wikipedia has nice section regarding events triggering the window: http://en.wikipedia.org/wiki/User_Account_Control#Tasks_that_trigger_a_UAC_prompt
I am using Eclipse with C++. When I run the program, I get the following message in my Console window:
**** Build of configuration Debug for project Disks Repulsion ****
**** Internal Builder is used for build ****
Nothing to build for Disks Repulsion
I makes changes to the program and run it again, and this time I get following message:
**** Build of configuration Debug for project Disks Repulsion ****
**** Internal Builder is used for build ****
g++ -oDisksRepulsion.exe DisksRepulsion.o -lopengl32 -lglu32 -lglut32
C:\MinGW\bin..\lib\gcc\mingw32\3.4.5........\mingw32\bin\ld.exe: cannot open output file DisksRepulsion.exe: Permission denied
collect2: ld returned 1 exit status
Build error occurred, build is stopped
Time consumed: 103 ms.
When I first ran the program, it started my program (I can see it running in my Window Task Manager), but there is no output being sent to the console.
After making changes to my program, the program is still running in the background, so I get the "Permission denied" error, when I try to run the program. I can make the error go away by ending the instances via task manager. However, when I run the program, I still don't see any output being sent to the console.
Yesterday, I was able to see the output in my console, but don't know why I cannot see it today. Also, when I saw my output, the cursor's focus did not change from the code to the console. I dislike having to do it manually.
I also don't like that when I make changes to my program, and run it again, that the program is not automatically terminated on its own.
I have used VC++ and I prefer the window Dos for output. So, I wanted to know if there is anyway in Eclipse to send the output to Windows Command Prompt, since I know that the instance of the .exe is really gone when I close the program. It automatically gets cursor's focus. I will also be able to get some output.
I installed MinGW with MaSYS or something, to compile the program.
It sounds like your application isn't terminating on its own and you didn't build in any sort of interface that would allow you to kill the program. This sounds like a bug in your code and not an Eclipse issue. If issuing a Ctrl+C in the console won't kill your program, then look into coding something that will let you kill your app with keystroke or input sequence.
If you want to run your app in a command console, then open a normal command console, browse to the folder containing your project, and run the compiled executable from the console instead of doing it through the Eclipse interface.
A simple solution, which I've been using for ages now, is opening a command prompt yourself and running the executable manually. An advantage of this method is that you can set your "DOS" window's size to anything you want. (Right now I'm using a 120x50 window with 8192 lines of scrollback buffer.) Another one is that you will never lose your console output; in fact, you'll be able to see outputs from past runs. (8192 lines is A LOT unless you're printf-debugging a tight loop.)
An alternative to terminating your program from the taskbar is using the red icons on the top right corner of the Eclipse "Console" window.
Is your program's entrypoint main() or WinMain()? There may also be a setting/link option for the "subsystem," console or Windows I think they're called in Visual Studio.
Anyway, if your program is starting up via WinMain, the expectation is that you'll have a Windows form of some sort through which the user can control the program. If you use main(), then your program should automatically trigger the opening of a console window.
Look up AllocConsole() on MSDN (or google it) if you are using WinMain() intentionally and want a console window to also open up. There's some trickery also available via google search that can hook stdout to this console, but at this time I don't remember what it is. (You basically redirect the stdout handle to your new console.)
Good luck.
When I ask CodeBlocks to run my built application it spawns a terminal window and runs the application within that window. How do I instead get it to run within the IDE's log window?
This is something that is not implemented in Code::Blocks as such.
Target executables are either run directly from the IDE (no console), or via the consolerunner program which calls whatever terminal is appropriate (e.g. cmd under Windows, xterm under Linux) and optionally prompts for a key once the process has exited. Which one it is (terminal or no terminal) depends on the "Type" field in the project's Properties window ("Build Targets" tab).
However, if you absolutely want, you can get the effect of running in the log window indirectly by executing your program as post-build step. In that case, your program's stdout and stderr will both be displayed in the build log tab.