This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: xterm is a console program?


On Sat, May 17, 2003 at 02:24:00PM -0500, 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.
>
>> > 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.
>
>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.
>
>Isn't this something that cygwin1.dll could offer?

If the process was started from a cygwin shell, then it would know its
parent via getppid.

It should be a doable
>task.  See
>
>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?

And what will that prove?

>An alternative solution could be to have cygwin1.dll check a special
>environment variable, say "PTY_CONSOLE_HANDLE" which would be

You're proposing a lot ideas and work just to avoid the annoyance of a
console flashing.  You're also treading on territory where other
talented people have trod.

If you want to see change, your best bet is to start producing patches
rather than speculating and offering ideas.  We're all pretty imaginative
people here.  We can all imagine ways that this could be fixed.  What
is needed is someone to actually provide the work.

I will give you a hint that I'll never accept a proposal that involves
setting a PTY_CONSOLE_HANDLE environment variable however.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]