可以打开窗口的 Win32 控制台应用程序

Question

My question is pretty simple. In Ubuntu, programs can often be deployed with or without a GUI, perhaps using a flag like --showGUI. I essentially want to recreate this functionality in windows, but it seems that windows applications start with win_main, while console applications start with main.

So what is the basic structure required to produce this behavior? Eg in in Visual Studio 2012, should I start with a Windows App and then hide the window and write to console? Or can I start with an empty Console Application and create a window with the windows API?

Thanks

(c/c++, btw)

Answer 1

A console application starts out attached to a console. It can then create windows as it sees fit--essentially no different from an application written specifically for the windows subsystem.

In theory you can do the opposite: create an application for the windows subsystem, and then attach a console to it. This adds a fair amount of extra work though. The startup code in the standard library normally does some work to attach stdin/cin, stdout/cout, stderr/cerr to the console. If you create a windows subsystem program, then attach a console, you basically have to reproduce that code to attach the console to the standard streams.

As such, it's usually easiest to start with a program written for the console subsystem and have it create windows than start with a program written for the windows subsystem and have it create/attach a console.

As far as main vs. WinMain goes: this controls which subsystem the program will be linked for by default. That is, if you have a function named main , it'll default to the console subsystem. If you have a function named WinMain , it'll default to the windows subsystem (offhand I don't remember which it'll do if you define both--I'd advise against doing that).

You can, however, force the subsystem choice with a linker flag if you want to, so you can use main as the entry point for a windows-subsystem program, or WinMain as the entry point for a console-subsystem program. I'd generally advise against doing either of those as well though.

Answer 2

Windows app's can have a GUI and console window at the same time. It's just that no one ever sets them up that way. You have to handle it your self.

Here is some example code that does this:

#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
#include <io.h>
#include <fcntl.h>
#include <iostream>

LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam);
bool ReconnectIO(bool OpenNewConsole);

int CALLBACK WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,
        LPSTR lpCmdLine,int nCmdShow)
{
    MSG msg;
    HWND hwnd;
    WNDCLASS wc;

    if(!ReconnectIO(false))
        printf("Started from command prompt\n");

    wc.style         = CS_HREDRAW | CS_VREDRAW;
    wc.cbClsExtra    = 0;
    wc.cbWndExtra    = 0;
    wc.lpszClassName = "Window";
    wc.hInstance     = hInstance;
    wc.hbrBackground = GetSysColorBrush(COLOR_3DFACE);
    wc.lpszMenuName  = NULL;
    wc.lpfnWndProc   = WndProc;
    wc.hCursor       = LoadCursor(NULL, IDC_ARROW);
    wc.hIcon         = LoadIcon(NULL, IDI_APPLICATION);

    RegisterClass(&wc);
    hwnd = CreateWindow(wc.lpszClassName, "Window",
                WS_OVERLAPPEDWINDOW | WS_VISIBLE,
                100, 100, 350, 250, NULL, NULL, hInstance, NULL);  

    ShowWindow(hwnd, nCmdShow);
    UpdateWindow(hwnd);

    printf("Entering GetMessage loop\n");
    while (GetMessage(&msg, NULL, 0, 0))
    {
        DispatchMessage(&msg);
    }

    return (int)msg.wParam;
}

LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
    switch(msg)
    {
        case WM_DESTROY:
            PostQuitMessage(0);
        return 0;
    }

    return DefWindowProc(hwnd, msg, wParam, lParam);
}

/*******************************************************************************
 * NAME:
 *    ReconnectIO
 *
 * SYNOPSIS:
 *    bool ReconnectIO(bool OpenNewConsole);
 *
 * PARAMETERS:
 *    OpenNewConsole [I] -- This controls if we open a console window or not.
 *                          True -- if the program was not started from an
 *                                  existing console open a new console window.
 *                          False -- Only connect stdio if the program was
 *                                   started from an existing console.
 *
 * FUNCTION:
 *    This function connects up the stardard IO (stdout, stdin, stderr) to
 *    the windows console.  It will open a new console window if needed
 *    (see 'OpenNewConsole').
 *
 * RETURNS:
 *    true -- A new console window was opened
 *    false -- Using an existing console window
 *
 * SEE ALSO:
 *    
 ******************************************************************************/
bool ReconnectIO(bool OpenNewConsole)
{
    int hConHandle;
    long lStdHandle;
    FILE *fp;
    bool MadeConsole;

    MadeConsole=false;
    if(!AttachConsole(ATTACH_PARENT_PROCESS))
    {
        if(!OpenNewConsole)
            return false;

        MadeConsole=true;
        if(!AllocConsole())
            return false;   // Could throw here
    }

    // STDOUT to the console
    lStdHandle = (long)GetStdHandle(STD_OUTPUT_HANDLE);
    hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
    fp = _fdopen( hConHandle, "w" );
    *stdout = *fp;
    setvbuf( stdout, NULL, _IONBF, 0 );

     // STDIN to the console
    lStdHandle = (long)GetStdHandle(STD_INPUT_HANDLE);
    hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
    fp = _fdopen( hConHandle, "r" );
    *stdin = *fp;
    setvbuf( stdin, NULL, _IONBF, 0 );

    // STDERR to the console
    lStdHandle = (long)GetStdHandle(STD_ERROR_HANDLE);
    hConHandle = _open_osfhandle(lStdHandle, _O_TEXT);
    fp = _fdopen( hConHandle, "w" );
    *stderr = *fp;
    setvbuf( stderr, NULL, _IONBF, 0 );

    // C++ streams to console
    std::ios_base::sync_with_stdio();

    return MadeConsole;
}

The top part of the program is just a normal Window's program with a WinMain() entry point. The magic comes from the ReconnectIO() function. It will reconnect the standard io's and open a console window if needed.

When you start the program from a command line, standard out will go to it, when you start from the desktop only the main window is opened.

It does have one draw back which is that when started from the command line it return right away instead of blocking until the program exits. The startup code is doing that and I haven't looked into how to stop it.

You can have a look at http://dslweb.nwnexus.com/~ast/dload/guicon.htm from some more info about what is going on.

Answer 3

This is really hard to do well in Windows.

1. If you create a program that uses the Windows subsystem, it's difficult to know which console to attach to. (What if it was started from the Run menu or a desktop shortcut and there isn't a console?)

2. If you create a program that uses the Console subsystem, you always get a console. (You can also create windows, but, if you launch from somewhere other than an existing console, a new console window is going to flash up whether you wanted it or not.)

Visual Studio has a hack to get around this. If you look closely, you'll see that there are two devenv executables in the same directory: devenv.exe is a Windows app and devenv.com is a console app.

All of the shortcuts point directly to the .exe. But if you type devenv in a console window, and the installation directory is in your path, it'll actually launch devenv.com, the console one. This is because .com is typically listed before .exe in the PATHEXT environment variable.

If you include a command line option (like /? ) that devenv.com can handle strictly in console mode, it will. Otherwise, it will just invoke devenv.exe for you and exit.