Re: xterm is a console program?

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

"Alexander Gottwald" <alexander.gottwald@s1999.tu-chemnitz.de> wrote:
> It was said a hundred times before. You either have a console application
or
> a gui application.

I'm well aware of the various flavors of Windows executables.  There's also
POSIX subsystem (such as they are), native API, and there used to be an OS/2
subsystem as well, IIRC.  But this is an implementation detail.  The
behavior of X applications is what is important.

>
> The console application has a console (which it may detach, but this also
> detaches it from the running cmd.exe)
> The GUI window has no own console but can create one. But this is not
connected
> to the starting cmd.exe.
>
> On linux the output of the program goes either to a logfile, the console
from
> where the X11 session was started or to /dev/null. On linux this very
easy.

In other words, on Linux (and the various Unices out there), starting an X
app does *not* cause a new console to be created.  Said app will re-use its
parent's console or use /dev/null.  Ergo, the same ought to be made true on
Windows.

Unfortunately, on Windows, for an application to send output to its parent
console, it must be a console application and must be spawned into the same
process group.  A negative side effect of this is that if such an
application is an X app, and is spawned from anywhere other than a console,
Windows will allocate a console on its behalf.

So we have a catch-22; either the program is made a console application, in
which case it will have a console appear (bad), or it is made a GUI
application, in which it will never be able to output to its parent's
console (also bad).

The current way to break out of the catch-22 requires human intervention:
rather than running the app you want to run, run "run" instead, and let
"run" run the app you want to run.

My suggested break-out requires no human intervention other than an update
to some library: have each X app detect that the only reason it has a
console is that Windows allocated one for it and hide the console in such a
situation.

The only other approach I can see is to find a way to find the parent
process and somehow connect to its console.  I posted a link to a system
internals utility that can find the parent process, but that still leaves
connecting to its console an open problem.  Unless that console is a cygwin
app, in which case you could create some kind of IPC endpoint in the cygwin
dll to handle this, a very messy proposition, IMHO, that was rightly
rejected.

> The evil hack is to include the code into the X11 library. This is the
last
> place where I want to see code that detaches the console. The correct
place
> is in cygwin1.dll, in the startup code. And this issue should be discussed
> on the cygwin-devel mailing list.

I originally thought about it going in cygwin1.dll but dismissed that before
posting. The reason was that if you put it in cygwin1.dll, then any cygwin
app would drop its console if launched in this manner, including non-X
clients like bash.  That would clearly be Wrong so I suggested having it in
the X11 client library.  I'm still unconvinced that the X11 client library
is the appropriate place for this, but I haven't seen any better
alternatives suggested yet.

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