This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: xterm is a console program?
Early Ehlinger wrote:
"Karl Waclawek" <karl@waclawek.net> wrote:
Case one
4) Double-clicked X apps should not open a command-prompt window at all.
This is rather easy to implement, as I mentioned in my thread-starting
post - simply have a WinMain that parses GetCommandLine() and then calls
main(). This could even be put into a lib file that the application links
against via makefile magic.
The only reason I haven't already done this is lack of time.
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.
Case two
3) *CRUCIAL PART* The X app, being very smart, notices that it was
launched from a console window and attaches its text output to that very
same console window. NO NEW CONSOLE IS CREATED.
4) Any text error messages (via printf, etc.) from the X app go to the
command prompt window that the X app was launched from.
Can't an X app check GetConsoleWindow()? If it returns a value other than
NULL, do not create a Console, and attach text output to it - simply use
CreateFile with "$CONOUT" for console output, and "$CONIN" for console
input. Granted, it can't see who actually "owns" the console, but it can
certainly attach to it.
Oh sure, you can use GetConsoleWindow, but you might have missed this
form the MSDN documentation:
Client: Included in Windows XP, Windows 2000 Professional.
Server: Included in Windows .NET Server 2003, Windows 2000 Server.
You see, GetConsoleWindow is only supported in 3 of the 7 versions of
Windows that we support... thus, it is not really a solution at all.
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.
Now, when the console isn't a console in the Windows sense (e.g., it's an
xterm), this stuff will not help and you'll need to have an IPC mechanism of
some sort to determine who the parent process is, but:
I can do 2) but not 1), since on Windows there is no such concept
as a parent process, so you can't find out which process is your parent
and check if it has a console associated with it. Otherwise you could
simply free your console when the parent didn't have one.
On NT/2000 it might be possible using the NtQueryInformationProcess() API,
which also returns the ID of the "parent" process from which the
process inherited.
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.
Isn't this something that cygwin1.dll could offer? It should be a doable
task. See
No. We are talking about how to implement this in Windows. If it isn't
doable in Windows, then Cygwin cannot implement it either. As Chris
mentioned, he investigated the same thing for Cygwin proper before, but
came to the same conclusion that I did.
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml
Which appears to display the process tree on windows 9x and NT/2k/xp. I
haven't tried it on 9x, since I have no 9x boxes (275 computers and not a
single one running Windows 9x :-) , but the page suggests that it will work
there. Perhaps somebody with a downrev Windows version will take the time
to try it out and report the results back here?
I think that focusing on the getting the parent process id is kind of
off-topic here. Having the parent process id doesn't help much.
An alternative solution could be to have cygwin1.dll check a special
environment variable, say "PTY_CONSOLE_HANDLE" which would be
Must have hit Ctrl+Enter, eh? :)
Harold