Both a command line and GUI application at the same time?

Of course that you can attach a console to a GUI application (as has been discussed several times in this thread!), but this is NOT what I am after!

Anyway, you don't seem to be getting (or want to get) the point I am trying to get across. So, please have a look at the article I referred to and... maybe you will finally understand what I am talking about and what I was after.

Quote:

---

you don't seem to be getting (or want to get) the point I am trying to get across. So, please have a look at the article I referred to and... maybe you will finally understand what I am talking about and what I was after.

---

You should listen to your own advice.
In the link YOU provided:

Quote:

---

OK, now that I'm off my soapbox, how can you implement a combined GUI/console app? As nearly every programmer targeting Windows knows by now, Windows divides the EXE universe into two camps: console apps and GUI apps. This architecture goes back to the earliest days of Windows, when it first evolved from MS-DOS®. Nowadays, you tell the linker which kind of app you want to generate by using a switch: either /subsystem:Windows or /subsystem:console.

---

Which is what I was talking about.

Oh god, here we go again. Let me remind you, you replied to my comment that read:

Quote:

---

Basically, on Windows, an application can either be a console application or a GUI application, not both. There is no way around that.

---

and you said that this was not true, implying that one could perfectly have a Windows application that is both a console and a GUI application. From your last message quoting the link I gave:

Quote:

---

OK, now that I'm off my soapbox, how can you implement a combined GUI/console app? As nearly every programmer targeting Windows knows by now, Windows divides the EXE universe into two camps: console apps and GUI apps. This architecture goes back to the earliest days of Windows, when it first evolved from MS-DOS®. Nowadays, you tell the linker which kind of app you want to generate by using a switch: either /subsystem:Windows or /subsystem:console.

---

Now, unless I am mistaken this confirms what I said above which was, in fact, nothing more than me paraphrasing the author of the old MSDN magazine article I referenced:

Quote:

---

In short, a Windows-based app must be either a console app or a GUI app and there's no way to have your cake and eat it too. (Unless you want to write your own startup code—which is waaaay more than I'm up for tonight!) But you know it can be done because I already told you Visual Studio does it—but how?

---

From what you said in comment #7, it would seem that one can associate a console to a GUI application, and I am very happy to believe that. So, yes, you are 'right', but only in some way since I wouldn't imagine that the linker was supposed to ever be used in that way, and the fact that it can be done might be more the result of a bad design than anything else. More importantly, though, my understanding is that to use both options will result in the console window being created every time and, as mentioned in comment #9, this is not at all what I want.

I tried the following code snippet compiled with CONFIG += console set in the .pro file:

Code:

---

#include <QtGui>
#include <QApplication>
 
#include <iostream>
 
#include <windows.h>
 
using namespace std;
 
int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    QMainWindow w;
 
    if(argc < 2)
    {
    	cout << "GUI project" << endl;
    	FreeConsole();
    	w.show();
    }
    else
    {
    	cout << "Console project" << endl;
    	return 0;
    }
    return a.exec();
}

---

Running from command line without arguments just opens the empty QMainWindow. The console where I called the program from shows output "Gui project".

Running from command line with an arbitrary argument just outputs "Console project" to the calling console.

Next use Explorer to start the executable. In this case, a new console and the empty QMainWindow appear. But due to the call to FreeConsole(), the new console gets removed quickly.

So if that "flickering" of the console is ok for you, this might be a solution.

Yes, I am aware of FreeConsole(), but that flickering is not acceptable to me (I tend to be a bit of a perfectionist when it comes to user experience). Otherwise, as the author of that old MSDN Magazine article said:

Quote:

---

You can destroy the console by calling FreeConsole, but the console window flashes briefly, announcing to the whole world that you don't really know what you're doing.

---

and I must confess that I couldn't agree more! :)

Correct me if I'm wrong but you suggest to build two exactly identical applications and call one myapp.exe and the other myapp.com and then do something in your app to detect which is the case (sorry, I didn't bother to open your archive, so I'm just guessing) so that you can operate adequately, right? So how is it different from providing two binaries containing the same code but one built with subsystem:Windows and the other with subsystem:console? And what's wrong exactly with attaching a console to your running program and having a single binary?

You are correct in that the .com (console) and .exe (GUI) versions of the application I attached are identical. However, I just wanted to show, using Qt, what was described in that old MSDN Magazine article. At the end of the day, it's completely up to the developer to do whatever they want.

Now, having said all of that, in my project, the .com and .exe version of my application are not the same at all. In the case of Linux and Mac OS X, the .exe version (well, I am clearly using that naming convention only for convenience here!) I handle both the console and GUI side of my application. If one of the command line options is such that the GUI shouldn't be shown, then I don't show it, simple as that. Now, in the case of Windows, if the user specifically starts the .exe version, then I go straight into GUI mode (ignoring command line options, except for file names that were passed to the .exe file). However, if the user specifically starts the .com version (or do something like C:\>myApp), then I will first analyse the command line options and determine whether there is a need for a console or a GUI version of my application.

So, yes, I am anticipating (since I am still very much working on this project and, therefore, not everything is yet implemented in it) having my back-end code to be common to both the .com and .exe version of my application. I am thinking of having a flag that will let that code know whether it is being run in console or GUI mode, and therefore allow it to determine whether outputs to the console can/should be done or not.

With regards to providing two binaries, one with subsystem:console and the other with subsystem:Windows, there would, in principle, be no difference... as long as you make sure they are named myApp.com and the other myApp.exe, and as long as the .com version can switch to the .exe version if needed (see above).

The key point here, I think, is that the basename of the binaries is the same. If the basename was to be different, then there is, from an end-user's perspective, no point in having two different binaries. I mean that, as an end-user, just want to have to 'decide' which version of the application I need to run to get a console or a GUI behaviour. Indeed, that 'decision' ought to be made by the application, not the end-user.

Finally, with regards to attaching a console to my GUI (and thus having only one binary indeed), the problem is that when you use AttachConsole, you must then use WriteConsole/ReadConsole, and though I got something to 'work', it wasn't 'clean' (see comment #13), as once again mentioned in that old MSDN Magazine article:

Quote:

---

There's a new (for Windows XP) function that would seem to be just the ticket: AttachConsole. This function lets you "attach" your program to a console window of another process. If you use the special process ID ATTACH_PARENT_CONSOLE, AttachConsole attaches to the console from which your program was invoked. Great! But there're two problems. First, AttachConsole only exists in Windows XP, so if you want your program to run in other versions of Windows, you're out of luck; and second, AttachConsole doesn't work exactly as hoped. You can write stuff to the console, but the command prompt is all messed up after your program exits—oops!

---

I am telling you, that article is definitely worth a read for anyone who needs their their application to be a hybrid console/GUI application. :)

To sum up, attaching a console is, in my view, not the way to go (as just mentioned above). Instead, one should indeed have two binaries (one .com and one .exe) with the same basename. This implies the back-end code to be shared by both binaries, but I can't see much way around this unfortunately...?

All mixed console/GUI Windows apps I have seen for a long time were exe files. And what's wrong in wrapping ReadConsole/WriteConsole and stdin/stdout into one clean interface and using that? It's probably around 10-20 lines of code total.

Quote:

---

Originally Posted by wysota

All mixed console/GUI Windows apps I have seen for a long time were exe files. And what's wrong in wrapping ReadConsole/WriteConsole and stdin/stdout into one clean interface and using that? It's probably around 10-20 lines of code total.

---

Would any of those console/GUI Windows applications be freely available for download, so that I can try them out? I would certainly interested to see how they behave and, therefore, see whether they have any of the pitfalls that I have read about and experienced myself.

As for ReadConsole/WriteConsole, did you read the quote I just gave and my comment #13? In my experience (and that of the article author, if one is to believe what he wrote) is that it's messy. Now, I am certainly not claiming that my use of AttachConsole and WriteConsole was perfect. In other words, I am not excluding the fact that I may have done something sub-optimal, if not wrong, but in that case I would then very much appreciate some pointers to what you would consider to be the 'perfect' use of those Windows API functions.

Quote:

---

Originally Posted by agarny

Would any of those console/GUI Windows applications be freely available for download, so that I can try them out? I would certainly interested to see how they behave and, therefore, see whether they have any of the pitfalls that I have read about and experienced myself.

---

I don't know, I guess some tools Microsoft provides with Windows fall into this category but to be honest, I'm not sure.

Anyway I still fail to see what's wrong with attaching a console. Redirection works in terms of stdin/stdout and not console so it might work. At worst you can find a way to open stdout but it is so Windows specific that you have to look for help at more suited sites than ours.

Quote:

---

Originally Posted by wysota

Anyway I still fail to see what's wrong with attaching a console.

---

As I said, I may be wrong and maybe attaching a console could work. It's just that I haven't been able to get things to work to my satisfaction (again, see comment #13), and what I have found on the Internet so far seems to indicate that it might not be possible indeed. I shall certainly keep looking for it when I have time, since I would rather just have one .exe file than both a .com and a .exe file.

Quote:

---

Originally Posted by wysota

Redirection works in terms of stdin/stdout and not console so it might work.

---

I am not sure what you mean by this.

Quote:

---

Originally Posted by wysota

At worst you can find a way to open stdout but it is so Windows specific that you have to look for help at more suited sites than ours.

---

That, I can only agree with indeed!

Quote:

---

Originally Posted by agarny

I am not sure what you mean by this.

---

By redirection I mean the redirection operator (">") which associates stdout of a process with a file. Console has nothing to do with this really.

Oh, ok, got you, and yes indeed.