To be or not to be (a console app)

Although I'm not a great Linux fan, I often find myself building Windows apps that were originally written for Linux. The code is usually sprinkled with printf() statements and the like which can occasionally be useful at run time.

One of the nicer features of Linux is that apps aren't tied to being either a console app or a GUI app. If you double-click an app's icon it launches as a GUI app. However, if you open a terminal and launch the app from that, you'll see the GUI app but also see its console output.

AFAIK this isn't easy to achieve on Windows. Whether or not an app has a console is a build time decision, not a run time decision. So if you specify System:Console you'll always get a console, no matter how you launch the app. OTOH if you specify System:Windows you'll never see any console output, not even if you launch from a terminal.

The Linux approach is superior IMHO. Anyone know of any tricks for emulating it in a Windows app?

This seems like what you want:

Code:

---

#include <windows.h>
#include <iostream>
#include <cstdio>

bool IsAConsole( HANDLE Handle )
{
    DWORD Mode;
    return GetConsoleMode( Handle, &Mode ) != 0;
}

FILE* MapStdToConsole()
{ 
    FILE* File = NULL;

    HANDLE StdOut = GetStdHandle( STD_OUTPUT_HANDLE );

    if( StdOut && AttachConsole( ATTACH_PARENT_PROCESS ) )
    {
        if( IsAConsole( StdOut ) )
            File = freopen( "CONOUT$", "w", stdout );
    }

    return File;
}

class cConsoleInitializer
{
    FILE* File;
public:
    cConsoleInitializer()
    {
        File = MapStdToConsole();
    }

    ~cConsoleInitializer()
    {
        if( File )
        {
            INPUT_RECORD InputRecord;

            InputRecord.EventType = KEY_EVENT;
            InputRecord.Event.KeyEvent.bKeyDown = TRUE;
            InputRecord.Event.KeyEvent.dwControlKeyState = 0;
            InputRecord.Event.KeyEvent.uChar.UnicodeChar = VK_RETURN;
            InputRecord.Event.KeyEvent.wRepeatCount = 1;
            InputRecord.Event.KeyEvent.wVirtualKeyCode = VK_RETURN;
            InputRecord.Event.KeyEvent.wVirtualScanCode =  MapVirtualKey( VK_RETURN, 0 );

            DWORD Written = 0;
            WriteConsoleInput( GetStdHandle( STD_INPUT_HANDLE ), &InputRecord, 1, &Written );

            fclose( File );

            FreeConsole();
        }
    }
};

---

Just construct a cConsoleInitializer.

Completing what Joeman already answered:

If you really need that kind of ostrich-camel, no problem:

• In a console application (built using /SUBSYSTEM:CONSOLE), you can add any GUI stuff your muscles want.
  To hide/show the console window, you can get a hadle with GetConsoleWindow, then call ShowWindow.
• In a non-console application you can create and attach a console with AllocConsole.

No sweat, like a walking in the park.
// I'm wondering how easy the *nix guys can do the same. ;)

Thanks guys. AllocConsole() and AttachConsole() are two functions I'd never heard of but they do seem quite promising. I'll try Joeman's suggestion first.

Ovidiucucu - yours is a good idea but I've seen that done before and it tends to look clumsy at runtime. If you double-click to open the app, a console window appears very briefly then shuts down which doesn't tend to look nice. It's quite common in apps built with MinGW I've found. Your 2nd suggestion about AllocConsole() looks a bit more promising.

In any case, the key to success here lies in the GUI app being able to detect "how" it was launched (i.e. was it launched by double-clicking its icon / was it launched by some other process / or was it launched from a command line). Any ideas about how to test for that at run time?

I found some ideas at stackoverflow that seems to do the trick http://stackoverflow.com/questions/5...-explorer-or-n

Quote:

---

Originally Posted by John E

... I've seen that done before and it tends to look clumsy at runtime. If you double-click to open the app, a console window appears very briefly then shuts down which doesn't tend to look nice.

---

One solutin is to make a little "launcher" application which creates the console in "hidden" mode.

Quote:

---

Originally Posted by John E

In any case, the key to success here lies in the GUI app being able to detect "how" it was launched (i.e. was it launched by double-clicking its icon / was it launched by some other process / or was it launched from a command line). Any ideas about how to test for that at run time?

---

You can enumerate the processes (using WMI or Tool Help Library) and find the parent process (the process which launched the current one).
But this is not very reliable. Just imagine the parent process is no longer running.
Anyhow, why do you need that? I can't get any practical reason.

Quote:

---

Originally Posted by ovidiucucu

Anyhow, why do you need that? I can't get any practical reason.

---

In Linux it's genereally used so that Release builds which don't work properly can give some feedback to the user. It can be especially helpful if the app fails while launching. In Windows we'd usually display a suitable dialog box maybe - or write to a log file but most Linux programs simply write something to stderr or stdout. When you launch the app normally (by double-clicking its icon) you don't see the output. But if the app encounters some kind of problem while launching you can retry it from a command line which lets you see the program's output. It's not the way I'd write a Windows program but it can be useful if I'm converting a program that was originally written for Linux.

On Windows you can use OutputDebugString and DebugView to achieve that.

Well then, try "Thinking in Windows" and get rid of linux-specific stuff. ;)

[ later edit ]

I think, D_Drmmr got better what you want to accomplish. This case, you don't need console at all..

Quote:

---

Originally Posted by ovidiucucu

Well then, try "Thinking in Windows" and get rid of linux-specific stuff. ;)

---

Oh, if only life were that simple.... :) I'm being slowly driven mad by Linux and its quirks but just occasionally, it has some neat ideas! :D

Quote:

---

Originally Posted by ovidiucucu

[ later edit ]

I think, D_Drmmr got better what you want to accomplish. This case, you don't need console at all..

---

Unfortunately, the same code (i.e. the printfs) still need to still work on Linux and OS-X.

But if someone could come up with a cross-platform version of DebugView. Hmmm.... that's a money spinning opportunity if ever I heard one..! :thumb:

Quote:

---

Originally Posted by John E

But if someone could come up with a cross-platform version of DebugView.

---

You mean something like printf? It's quite portable... :D

Anyway, I think that the *nix way of doing something "similar" to DebugView is syslog (vast more than just a DebugView). Google for syslog client.

Quote:

---

Originally Posted by S_M_A

You mean something like printf? It's quite portable... :D.

---

:D - no, I meant that a solution using OutputDebugString() wouldn't be suitable for the other platforms.

I just had to post that because of the Windows focus on that post. It would be an amusing moment to watch someone tell Linus that they really need to add OutputDebugString functionality to the kernel :D

I've never seen any cross platform libraries that route log text to either OutputDebugString or syslog depending on platform but that shouldn't be hard to do (or to console if possible).

Quote:

---

Originally Posted by John E

Unfortunately, the same code (i.e. the printfs) still need to still work on Linux and OS-X.

---

Then you need to abstract the calls to printf. Separate the I/O from the rest of the program. Then you can use something like a callback function to configure how the output is treated. If you're on windows, set the callback to a function that calls OutputDebugString, otherwise set it to a function that calls printf.

Additional reading, for tricks like using a .com and .exe - http://blogs.msdn.com/b/oldnewthing/...1/9259142.aspx

gg

Thanks everyone. I eventually made it work quite simply by using a combination of the suggestions here. The app's Linux build uses the traditional main() entry point which does very little, apart from calling a function called app_main(). The Windows build uses the traditional WinMain() which builds some argc and argv info and then passes it to the same app_main() function. I just needed to add these blue lines to make it all work:-

Code:

---

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
int  ret  = (-1);

        // Some stuff here to create argc and argv info

        BOOL bConsole; FILE *pStdOut = NULL, *pStdErr = NULL;
        if ((bConsole = AttachConsole(ATTACH_PARENT_PROCESS)) != 0)
        {
                // This only gets reached if we started from a console
                pStdOut = freopen( "CONOUT$", "w", stdout );
                pStdErr = freopen( "CONOUT$", "w", stderr );
        }
               
        ret = app_main (argc, argv);

        if (pStdOut)
                fclose (pStdOut);
        if (pStdErr)
                fclose (pStdErr);
        if (bConsole)
                FreeConsole();

        return ret;
}

---

Seems to be working a treat so far. When started from a console, the app sends its output to the console window and it also closes down if I close the console, which is quite neat. The only (very minor) niggle is that the app doesn't detach itself cleanly from the console if I close the GUI app but leave the console open. After the app closes I need to select the console window and type a carriage return before I see the DOS prompt again. That's only a minor problem though. Apart from that it works great. :thumb:

Quote:

---

Originally Posted by John E

I need to select the console window and type a carriage return before I see the DOS prompt again. That's only a minor problem though. Apart from that it works great.

---

This is what ~cConsoleInitializer did

Code:

---

~cConsoleInitializer()
{
    if( File )
    {
        INPUT_RECORD InputRecord;

        InputRecord.EventType = KEY_EVENT;
        InputRecord.Event.KeyEvent.bKeyDown = TRUE;
        InputRecord.Event.KeyEvent.dwControlKeyState = 0;
        InputRecord.Event.KeyEvent.uChar.UnicodeChar = VK_RETURN;
        InputRecord.Event.KeyEvent.wRepeatCount = 1;
        InputRecord.Event.KeyEvent.wVirtualKeyCode = VK_RETURN;
        InputRecord.Event.KeyEvent.wVirtualScanCode =  MapVirtualKey( VK_RETURN, 0 );

        DWORD Written = 0;
        WriteConsoleInput( GetStdHandle( STD_INPUT_HANDLE ), &InputRecord, 1, &Written );

        fclose( File );

        FreeConsole();
    }
}

---

Thanks Joeman, that extra code is what I needed. It does seem a bit strange the FreeConsole() doesn't do the job cleanly but no matter, adding those extra lines has fixed the problem. :thumb:

You're welcome :).
Also my code made sure it didn't break the command:
EXENAME > echo.txt
To make sure your app doesn't break that command, you need to adapt IsAConsole at the least like:

Code:

---


    HANDLE StdOut = GetStdHandle(STD_OUTPUT_HANDLE);
    if ((bConsole = AttachConsole(ATTACH_PARENT_PROCESS)) != 0 && IsAConsole(StdOut))

---

This way it will still redirect to a file instead of printing out to the console

Thanks again. I made that amendment but when I initially tested the redirection feature, I was surprised to find that the file only contained text from stdout - but no text from stderr.

So I did a bit of googling and realised that to redirect both stdout and stderr, the old DOS syntax was:-

Code:

---

EXENAME > echo.txt 2<&1

---

(which does actually work, BTW).

Well, I never knew that..! It's amazing what you learn once you start delving into things.... :)