Re: xterm is a console program?

["Early Ehlinger" <early at respower dot com>]

"Harold L Hunt II" <huntharo@msu.edu> wrote:
> Early, it is even easier than you think.  We already use the -mwindows
> parameter when linking XWin.exe to cause it to have a WinMain function
> linked in that does exactly what you described.
>
> The problem, as you cited below from my earlier post, is that you cannot
> have a WinMain AND still be able to attach to the launching console to
> print messages/errors when you are launched from a console.  Once you
> have a WinMain, you can never output to the console from which you are
> launched.

D'oh!

> Client: Included in Windows XP, Windows 2000 Professional.
> Server: Included in Windows .NET Server 2003, Windows 2000 Server.

D'oh! D'oh!

Indeed, I was reading the July 2000 copy of MSDN, which does not document
availability of this function.

> Considering that we have to choose whether or not to use a WinMain at
> link time, rather than run time, we cannot even use GetConsoleWindow to
> solve the problem on 2000/XP/2003, as doing so would reduce the
> functionality for Windows 95/98/Me and NT 4.0.

D'oh!

> No.  What I was saying is there is no way to complete that *entire*
> multi-step process.  There might be a way to complete one or two steps
> on a few versions of Windows, but there does not exist a common way to
> complete all of the steps on all of the versions of Windows that we
support.

OK.  I think I've got a decent understanding now...

There are 2 scenarios:

1. User launches app in such a manner that it is in its own process group
and therefore gets its own console.
2. User launches app in such a manner that it inherits its console from its
process group.

In case (2), the console is desired since X apps typically dump information
here such as debug messages and the like.

In case (1), the console is *not* desired since it just doesn't "feel right"
on MS Windows (hence my original complaint).

We cannot fix case 1 without breaking case 2 because a non-console Win32
program cannot attach to the parent's console (as you mentioned above).

I've attached a simple demo program that proves this last statement is
false.  Well, kind of - there's a workaround.  Case 1 can be detected - a
console-mode program can detect:

a. If it has a console
b. The console's HWND
c. If the console was allocated for it or for one of its parents

So there are 3 cases:

I. Program has a console, and owns it. The program can assume that it was
launched by a mechanism fitting with case 1.  It then simply uses
ShowWindow( hConsole, SW_HIDE ) to hide the console.  Unfortunately, the
console will appear for a brief period of time, but it's still better than
having it visible for the duration of the program.

II.  Program has a console, but does not own it.  The program can assume
that it was launched from a console or console-like program (e.g., xterm).
It does nothing with the console window.

III.  Program does not have a console.  Frankly, this should never happen.
If it did, however, I would assume that the program was launched from a
console(-like) program and do nothing additional.

While this would not totally fix scenario 1, it IMHO be better than the
current situation where X clients have visible consoles for the duration of
their run time.

> Must have hit Ctrl+Enter, eh?  :)

Not sure.  I probably walked away or got a phone call or otherwise
distracted and hit send when I got back without adequately reviewing what I
had written.  I usually proof read and edit before I send things off, but
I've been quite busy (& tired) lately.

--
-- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697
-- www.respower.com -- 500+ GHz Supercomputer Starting At USD$0.50/GHz*Hour