Compiling a Win32 Gui App (Without a Console) Using Mingw and Eclipse

Compiling a Win32 GUI app (without a console) using MinGW and Eclipse

For gcc on Windows, two things should be considered to build a non-console Windows app:

1. Compiler option -mwindows
2. Have WinMain()

It is possible, however, to manually specify -Wl,-subsystem,windows to the linker and include gdi32 and comdlg32 into the build. This is exactly what -mwindows automates.

Reference.

MinGW, build GUI application with console

I have no evidence for this answer, only a bit of experiments that were successful. If I have a hello app, like this:

#include <stdio.h>
#include <windows.h>

int main(void)
{
    puts("hi");
    MessageBox(NULL, "test", "test", NULL);
    GetStockObject(0);
    return 0;
}

I cannot compile it with -mconsole, because linker complains about GetStockObject. But when I add the necessary library with -lgdi32 switch on my command line, the app compiles and executes cleanly. Maybe this is the way to keep both console and gdi. This is the command line:

gcc -mconsole test_gdi.c -lgdi32

How do I build a Windows GUI Application in Eclipse using C++ (a non console application)

Unlike Visual Studio, Eclipse CDT does not have a built-in wizard or options for automatically configuring compiler settings and libraries for building Windows GUI applications. You will need to know what you are doing. Do you intend to build the GUI using Win32/MinGW, or perhaps using some other GUI library, like Qt or wxWidgets? There are many options.

If you are new to C++ and/or GUI development on windows, then there are easier options to get started with.

Hide the console window on an exe

If you're on Windows, and use MinGW GCC (or Clang with GCC's libraries), pass -mwindows flag to the linker.

How to get ride of console box of a GUI program compile by MinGW + Code::Block

Put it in a project, and in the project settings there's an option to not have a console window.

If you can't be bothered to have it in a project, a call to ShowWindow (GetConsoleWindow(), SW_HIDE); will make it flash on the screen and then disappear. Note that you must #define _WIN32_WINNT as 0x0500 or greater before including windows.h to have access to GetConsoleWindow(). I'll come back in a bit with a specific location to disable it.

//hide console window at start
#define _WIN32_WINNT 0x0501 //this is for XP
#include <windows.h>

int main()
{
    ShowWindow (GetConsoleWindow(), SW_HIDE);
    //rest of program here
}

EDIT:
Found it, here's how to not have a console window:

1. Click Project on the CodeBlocks menu.
2. Click Properties.
3. Click the second tab, Build Targets.
4. On the right, where it says Type: Console application, change it to GUI application.
5. Rebuild the project.

Make a C++ Program Run without a Window Using gcc/g++?

int main()
{
  FreeConsole();
  PlaySound(...);
  ...
}

This kind of program can only be killed from the task manager. You might want to consider setting some sort of IPC so that you can instruct an existing instance to turn off the sound and quit.

How to not open a console when starting program written in D

You need to add

"lflags": ["-Subsystem:Windows"]

to your dub.json file to tell ldc to create a Window UI binary. The command line option to use is ldc2 -L=-Subsystem:Windows.

Basic SDL2 app compiles with MinGW-w64 but doesn't run

Aside from startup issue with missing dynamic library, you seem to be mislead (arguably by SDL actually being misleading in that aspect) that your b main in gdb sets breakpoint in your main function. That's not the case as SDL redefines main to SDL_main, so if you have #include "SDL2.h" or something similar and SDL have main wrapper implemented for your operating system - your function gets renamed. Internally main (or wmain, or WinMain, or whatever target system uses as user-defined code entry point) is implemented in SDL2main library that you link with, and it calls SDL_main (your code).

TL;DR use b SDL_main in gdb instead.

Second point is why you don't see output text. That's once again windows specific, basically because you've build "GUI" app, which is different from "console" app, and don't really have its stdout associated with console output. Output is still there but you can't see it - but it can be redirected to other program or file, e.g. your_program.exe | more or your_program.exe > stdout.txt. There are ways to reconnect stdout to console (some freopen with CON magic, as I recall), or you can just build console program instead with -Wl,-subsystem,console.

As a side note, -w compiler flag (that could be loosely read as "don't ever warn me about any potential problems with my code as I'm 100% sure it is absolutely perfect and all your warnings are unjustified complaints about my perfect code" (sorry)) is a really really bad idea, with some very rare exceptions. Compilers, especially gcc and clang, are very good at giving warnings in places where it really matter, allowing you to spot mistakes early. You want more warnings (e.g. -Wall -Wextra, probably more), not no warnings at all. And while we're at it, OBJS in makefile logically should mean object files, not sources (of course you technically can call your variables anything you like, it is just misleading).

---

Related Topics