Application Windows qui écrit éventuellement sur une console en C ++?

Je voudrais avoir une application Windows avec le comportement suivant:
1. s’il est lancé à partir d’une fenêtre de ligne de commande existante (cmd.exe), il écrit sa sortie standard sur cette console.
2. S’il est démarré en double-cliquant sur son icône, il n’ouvre pas une nouvelle console et n’écrit pas sa sortie stdout où que ce soit.

Pour atteindre seulement 1, je peux définir l’argument d’éditeur de liens /SUBSYSTEM sur CONSOLE mais si je double-clique sur l’icône de l’application, une nouvelle fenêtre de console s’ouvre.
Pour atteindre 2, je mets le même argument sur WINDOWS , mais si je lance l’application depuis la console, sa sortie standard n’est pas dirigée vers la console.
Je veux que le même exécutable ait les deux comportements.

Jusqu’à présent, j’ai trouvé que je pouvais créer un exécutable /SUBSYSTEM:WINDOWS et le faire:

 DWORD ret = AttachConsole(ATTACH_PARENT_PROCESS) if (ret != 0) { // succeeds only if the parent is cmd.exe HANDLE outh = GetStdHandle(STD_OUTPUT_HANDLE); WriteFile(outh, "Hello", 5, NULL, NULL); } 

Cela écrit Hello à la console si le processus a été démarré à partir de l’un et ne fait rien d’autre.
Maintenant, il y a juste le problème de faire en sorte que le tube cathodique prenne la forme d’une poignée pour la sortie standard. Comment puis je faire ça?

Un autre problème lié à cette option est que le fichier cmd.exe ne bloque pas le processus démarré. Une fois le nouveau processus démarré, cmd.exe revient simplement à l’invite et la chaîne Hello apparaît à l’invite. Si l’utilisateur appuie sur Entrée sur la console, une autre invite apparaît. Une idée sur comment prévenir cela?

Découvrez la réponse ici: http://dslweb.nwnexus.com/~ast/dload/guicon.htm

 DWORD ret = AttachConsole(-1); if (ret != 0) { HANDLE lStdHandle = GetStdHandle(STD_OUTPUT_HANDLE); int hConHandle = _open_osfhandle((intptr_t)lStdHandle, 0); FILE* fp = _fdopen( hConHandle, "w" ); *stdout = *fp; } 

Et pour ce qui est de l’attente de cmd.exe, cela ne semble pas possible: http://blogs.msdn.com/b/oldnewthing/archive/2009/01/01/9259142.aspx