Windows gui with console



  • I want to make a gui program for Windows where the same executable works from the command line. If the program is run from the command line, it should show output in the same command line window. If it is run by double clicking it in Explorer, it should not display a cmd.exe window.

    I can't get both things to work on Windows. I can get it to work on Linux easily without any extra flags on the compiler, but on Windows, I apparently have to choose between having console output and having a huge black box show up when someone opens my program.


  • sockdevs

    yep! don't you love the design choice windows made for that?

    nothing you can do about that without using multiple executables....




  • Winner of the 2016 Presidential Election

    Can't you add command line flags to either the shortcut or when you call it from the command line? Or just use it in a GUI like god intended


  • sockdevs

    @jaloopa said:

    Can't you add command line flags to either the shortcut or when you call it from the command line? Or just use it in a GUI like @blakeyrat tended

    FTFY


  • Winner of the 2016 Presidential Election

    And @blakeyrat said let there be a usable interface, and lo the GUI appeared ands @blakeyrat saw that it was good


  • mod

    I had to QA a program like that. Their solution ended up having a splash screen appear from the command-line app. They didn't like that I found that unacceptable.



  • I think my solution is just going to be "windows users don't get command line output"



  • /SUBSYSTEM:CONSOLE, FreeConsole() in your entry point and hope nobody notices the flashing console window.





  • Why does it seem that the answer to "how do I do [feature every OS other than Windows has] on Windows?" is always "you can't, but here's a really hacky kludge to make something that pretends to be what you want unless you look closely"?


  • Discourse touched me in a no-no place

    Using my psychic powers, you're printing diagnostics.
    Open a window with a textarea in it. Print to it. Profit.

    Seriously, fuck standard console windows on Windows anyway. Can't even select/copy/paste without jumping through hoops.



  • @ben_lubar said:

    Why does it seem that the answer to "how do I do [feature every OS other than Windows has] on Windows?"

    Try it in Mac Classic.

    When Windows was introduced, it was assumed that GUIs would completely replace CLIs and therefore there is no need for something like this. Oh, and... hey look, they were fucking right. It's only people who love the 1980s and their brainwashed progeny who worry about this shit.

    BTW, how does this work in Unixes? Do GUI applications just get a console they never use and never shows on the screen? Isn't that a stupid performance drain for no benefit? (Trivial now, of course, but back in 1993 when this was all designed...) Seems like Microsoft did the right thing here.


  • Winner of the 2016 Presidential Election

    @ben_lubar said:

    Why does it seem that the answer to "how do I do [feature every OS other than Windows has] on Windows?" is always "you can't, but here's a really hacky kludge to make something that pretends to be what you want unless you look closely"?

    I reckon you could replace Windows with any other OS there, since they're, you know, different operating systems.

    In fact, I bet there are more than a few situations where it's between different Linux distros



  • AttachConsole(ATTACH_PARENT_PROCESS);
    	if (GetConsoleWindow() != NULL)
    	{
    		std::cout << "Test!\n";
    		std::cout << "This is a test\n";
    	}
    	else
    	{
                //do your graphics stuff here...
    

    The caveat: while you're attached to the parent process console, cmd is not detached from it. It behaves kinda odd, it's probably fixable, but I know as much about WinAPI as about MUMPS.



  • @ben_lubar said:

    Why does it seem that the answer to "how do I do some hacky cludge on Windows?" is always "you can't, but here's a really hacky kludge to make something that pretends to be what you want unless you look closely"?

    FTFY



  • @blakeyrat said:

    BTW, how does this work in Unixes? Do GUI applications just get a console they never use and never shows on the screen?

    Bzzt! Wrong!

    The 'am I bound to a console or not?' question is not answered by the app itself in *nix land, it's answered by what its parent bound stdin/stdout/stderr to. When you start an app from a terminal in *nix (even if it's a GUI/X11 app), the app inherits stdin/stdout/stderr from the shell. When a X11 app is started through the GUI, though, stdin/stdout/stderr are simply pointed at /dev/null. So, there's no actual unused console floating around, just some standard handles that point at nowhere.

    Also, Windows console support sucks in that it takes a zillion and two hoops to emulate anything close to a proper pseudo-terminal (pty). I'd rather wire my standard handles (or at least stdout/stderr) up to a pipe whose other end is connected to my logging TextArea, TYVM!



  • @tarunik said:

    When a X11 app is started through the GUI, though, stdin/stdout/stderr are simply pointed at /dev/null.

    The GUI apps on the computer I’m currently using have stdout and stderr redirected to some pseudo-terminal (/dev/pts/15). I guess it’s managed by Upstart and the output ends up somewhere, but i’m not really sure...

    In any case, the Windows behavior makes sense to me. A GUI app should not mess up with the console at all. Detaching them right away is probably the best thing to do.



  • @VinDuv said:

    In any case, the Windows behavior makes sense to me. A GUI app should not mess up with the console at all. Detaching them right away is probably the best thing to do.
    I feel like this begs the question (in the strict sense people are always yammering on about!). Why does the phrase "a GUI app" even make sense in the first place?

    For example, why not have a program that is primarily intended to be run from the console but is capable of asking for files using a file dialog or something? Or, like import, doesn't exactly have a GUI but still interacts with X programs?



  • @EvanED said:

    I feel like this begs the question (in the strict sense people are always yammering on about!). Why does the phrase "a GUI app" even make sense in the first place?

    • A GUI app interacts with the user using a windows, buttons, etc
    • A console app interacts with the user by doing I/O on a console

    I think it’s better to keep those separate because they don’t mix up well.

    @EvanED said:

    For example, why not have a program that is primarily intended to be run from the console but is capable of asking for files using a file dialog or something?

    That doesn’t sounds like a good idea...

    @EvanED said:

    Or, like import, doesn't exactly have a GUI but still interacts with X programs?

    I don’t classify that as a GUI program.


  • Discourse touched me in a no-no place

    You can have a console app display dialogs and has a normal gui plus a console just fine. What you can't do is have a gui app that conditionally also has a console.


  • Discourse touched me in a no-no place

    @EvanED said:

    For example, why not have a program that is primarily intended to be run from the console but is capable of asking for files using a file dialog or something?

    I was about to ask if you were still going for a TRWTF badge, then I looked at the badges page and saw that there isn't one.


  • sockdevs

    @antiquarian said:

    I was about to ask if you were still going for a TRWTF badge, then I looked at the badges page and saw that there isn't one.

    Because there would only be one recipient if there were.



  • @VinDuv said:

    In any case, the Windows behavior makes sense to me. A GUI app should not mess up with the console at all. Detaching them right away is probably the best thing to do.

    It makes sense to me too. I mean I kind of get what Ben L is doing here.

    But there are three distinct kinds of applications: Services, with no human interface at all, windowed apps, with a GUI, and console apps with a CLI. And generally it doesn't make sense to mix them up, even if it's technically possible. (Someone in that Old New Thing post brought up the weirdness of shutdown -i, where a console app opens a window like it ain't no thing. And we all know the WTFness of services trying to show something to the user.)



  • @EvanED said:

    For example, why not have a program that is primarily intended to be run from the console but is capable of asking for files using a file dialog or something?

    Because console applications can be run through Telnet or SSH, and unless there's been a shitload of advancement in the last few years, neither of those can open a file selection dialog on behalf of a remote system.


  • mod

    There's some weird shit you can do to make PuTTY able to open a windowing system on my local Windows machine that can fire up windowed Linux apps on behalf of the remote server. I barely understand how to set it up, let alone how it works, but somehow it does.



  • Right ok so it's technically available using one specific app yada yada. That's not the point.

    The point is "console app" should be interpreted as "app that can be run via Telnet." Since Telnet's the lowest common denominator there. Which means if you write a console app that opens windows or dialogs or any other GUI elements (even though it is technically possible in Windows), you've created a huge WTF.


  • mod

    Totally agree, I just found it fascinating that I could do that in the first place XD


  • Discourse touched me in a no-no place

    @Yamikuronue said:

    There's some weird shit you can do to make PuTTY able to open a windowing system on my local Windows machine that can fire up windowed Linux apps on behalf of the remote server.

    That's probably just rsh or something similar. You could theoretically get Windows to do that too if you put enough time into it.


  • mod

    Nah, it was this x-ming thing: http://www.straightrunning.com/XmingNotes/


  • Discourse touched me in a no-no place

    An X server is overkill compared to rsh (if you don't need GUI), but if that's the solution, then it's been around forever. I was using Exceed to run X apps on Windows in 1998 or so.



  • @blakeyrat said:

    The point is "console app" should be interpreted as "app that can be run via Telnet." Since Telnet's the lowest common denominator there. Which means if you write a console app that opens windows or dialogs or any other GUI elements (even though it is technically possible in Windows), you've created a huge WTF.

    Sorry, telnet is dead. Anyone using telnet in this day and age for remoting into systems should have all their passwords stolen from them and used to taunt them in eternal hell.

    @Yamikuronue said:

    There's some weird shit you can do to make PuTTY able to open a windowing system on my local Windows machine that can fire up windowed Linux apps on behalf of the remote server. I barely understand how to set it up, let alone how it works, but somehow it does.

    And basically all SSH clients support X11 forwarding, anyway. All you need is a bit of patience, a X11 server on one end, and an X11 client on the other.



  • @tarunik said:

    Sorry, telnet is dead.

    Ok; then SSH. That doesn't change the equation anyway, it's just pedantic dickweedery.



  • @blakeyrat said:

    That doesn't change the equation anyway, it's just pedantic dickweedery.

    See my post above...I haven't heard of an interactive SSH client that doesn't support X11 forwarding!



  • @tarunik said:

    See my post above...I haven't heard of an interactive SSH client that doesn't support X11 forwarding!

    Sure, but X11 isn't part of SSH. So that's irrelevant to the rule I laid-out above. There's a difference between "it can do X" and "X works 99.9% of the time on 99.9% of computers everywhere".

    And some OSes, including the most popular one in the world, do not have an X11 client installed by default.

    And in any case, if you're not arguing as an exercise in pure pedantic dickweed, I don't think it's that weird to suggest console apps that open GUI elements are a bad idea. If you think it's a good idea, you're gonna need a much more compelling argument than "well SSH might support that in some OSes possibly and Telnet is dead."



  • @blakeyrat said:

    And some OSes, including the most popular one in the world, do not have an X11 client installed by default.

    Nor do they have a SSH client installed by default.

    @blakeyrat said:

    And in any case, if you're not arguing as an exercise in pure pedantic dickweed, I don't think it's that weird to suggest console apps that open GUI elements are a bad idea. If you think it's a good idea, you're gonna need a much more compelling argument than "well SSH might support that in some OSes possibly and Telnet is dead."

    Is libncurses not a GUI?


  • sockdevs

    @tarunik said:

    Sorry, telnet is dead. Anyone using telnet in this day and age for remoting into systems shall have all their passwords stolen from them and used to taunt them in eternal hell.

    FTFY



  • Since nobody has any idea what the fuck I'm talking about, here's my situation:

    It's a multiplayer game. The same executable contains the server and the client. It can be started without arguments to start a server on the first available local port and connect the client to the server. It can be opened with specific command line arguments to skip either the server or the client part, or to open the level editor instead. If you only have the server argument, it does not initialize a GUI. The only use of the console is stdout/stderr for logging. For example, if the program crashes, it prints a stack trace to stderr. The only OS that has problems displaying a GUI and still allowing stdout/stderr to write to the console that started the program is Windows.



  • @tarunik said:

    Is libncurses not a GUI?

    I go back and forth on that. I think the old DOS Edit editor is close enough to be considered a GUI, but I also doubt it would run over Telnet/SSH. Could it? Maybe I'm wrong.



  • Just put your core logic in a shared library and create multiple executables. Sure it's not ideal, but it's not a huge deal either-- the server executable will be like 8k and any game is likely going to end up installing hundreds of files anyway.

    EDIT: It just occurred to me that you might be writing this in Go, which doesn't have shared libraries, and now I'm laughing SO FUCKING HARD



  • Why would I distribute a bunch of files if I can just distribute a single file?



  • @blakeyrat said:

    Just put your core logic in a shared library and create multiple executables. Sure it's not ideal, but it's not a huge deal either-- the server executable will be like 8k and any game is likely going to end up installing hundreds of files anyway.

    This is, interestingly enough, the best solution to the OP's problem, as far as I can tell, unless he wishes to abandon

    @ben_lubar said:

    The only use of the console is stdout/stderr for logging. For example, if the program crashes, it prints a stack trace to stderr.

    and use some other sort of logging facility instead -- such as a text file, or a TextArea of some sort that's been wired up to stdout/stderr using SetStdHandle() and a pipe pair. In other words -- redirecting your own output is a thing, @ben_lubar

    @blakeyrat said:

    I go back and forth on that. I think the old DOS Edit editor is close enough to be considered a GUI, but I also doubt it would run over Telnet/SSH. Could it? Maybe I'm wrong.

    I know that vim and emacs both will run happily over ssh provided your terminfos are setup correctly, so I do not see why edit.com wouldn't, unless there's some weirdness about DOS/Windows terminal emulation that makes Windows SSH servers incompatible with ncurses-style TUIs as implemented in Windows.



  • @tarunik said:

    I know that vim and emacs both will run happily over ssh provided your terminfos are setup correctly, so I do not see why edit.com wouldn't, unless there's some weirdness about DOS/Windows terminal emulation that makes Windows SSH servers incompatible with ncurses-style TUIs as implemented in Windows.

    It really depends on whether SSH/the text terminal supports only ASCII or the ANSI cursor and color extensions. (And also whether there's ANSI cursor and color extensions are standard between Windows and Linux, I don't know honestly.)

    If so, it's possible to create a GUI in a terminal window. If not, you can do... stuff, but I don't think you could do anything I'd consider a "GUI".



  • The thing is, the log messages only matter to server operators, who would be running it from a terminal anyway. I can call dup2 from Go, but it's easier to allow the server operator to do their own log redirection.


  • Discourse touched me in a no-no place

    @ben_lubar said:

    For example, if the program crashes, it prints a stack trace to stderr. The only OS that has problems displaying a GUI and still allowing stdout/stderr to write to the console that started the program is Windows.

    Well don't do that then, do this: http://dslweb.nwnexus.com/~ast/dload/guicon.htm I'm pretty sure someone already mentioned that idea.


  • Discourse touched me in a no-no place

    @ben_lubar said:

    Why would I distribute a bunch of files if I can just distribute a single file?

    Does not compute. If you can't distribute a single file, then tautological tautology is tautological and you need multiple files.



  • I can distribute multiple files, but it's easier to have the whole thing packaged as a single object that can't have parts missing at runtime.


  • mod

    @accalia said:

    yep! don't you love the design choice windows made for that?

    nothing you can do about that without using multiple executables....

    Not true!

    I've got a project around somewhere where I've done just what @ben_lubar is talking about. I'll see if I can track down the relevant code.


  • sockdevs

    With windows, you can either have a console or not, that's decided at app compile time. so your choices are either full GUI with no console or a console app with optional GUI.

    what your console app can do after being launched is spin up a GUI and then detach from the console.

    while this is possible it means that:

    • there will be a brief flash of black as the console is opened and dismissed when launched through the GUI (this can be really fast in some cases, sub 1 frame even so it might not be rendered to the screen, but it will be there)
    • Accessibility programs will likely have issues with your program as they will think the program is a console program.

  • Discourse touched me in a no-no place

    @abarker said:

    I've got a project around somewhere where I've done just what @ben_lubar is talking about.

    I didn't read the entire article I linked to at first, but I went back and did, and it has sample code. The upshot: Create a GUI window, allocate a console (you can't have more than one, it says, so my wild-ass guess is it won't "hurt" to do it, although it may give Raymond Chen a migraine in a few years) and redirect the standard handles.

    Actually a better idea is see if you NEED to redirect the standard handles, which you wouldn't need to do if you ran from a console, and then if you do need to, allocate a console and redirect.

    Shouldn't be too hard, given they gave what they claim is a sample that does exactly that. How that works in Go beats me.

    @ben_lubar, you gonna put all your images and whatnot in your executable too? Hope you're not using any libraries.

    If you feel you must only distribute one executable, do what Minecraft does and download the rest dynamically from AWS or whatever.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.