This is the mail archive of the cygwin mailing list for the Cygwin 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: popup consoles on Windows 7


On Fri, Jul 3, 2009 at 11:44, Corinna Vinschen wrote:
> On Jul Â3 10:18, Julio Costa wrote:
>> Let me rephrase that in three questions:
>> "What happens if we launch commands without a console created?"
>
> That's actually the same question as the next one, isn't it?
>

It is now, that I seen the answer to the next one :)

>> "What are the type of programs that really need that console?"
>
> Cygwin processes don't worry about the console. ÂThey use what they
> get as file descriptors and live with that.
>
> Native processes exist in two variations. ÂSome of them just use
> the stdio handles like Cygwin processes. ÂSome of them require to
> be run in a console becasue they use Console I/O functions directly.

Ahhh! That's the core problem... I didn't realize that there could be
applications wanting to do that... Duh!

> These applications will fail miserably in a Cygwin environment not
> attached to a console. ÂUnfortunately there are quite a lot of them
> used for Windows system administration.

Rats!

>
> At least that's as far as I rememeber this whole issue. ÂI may have
> forgotten some aspect, but I'm fairly sure that we can drop the
> hidden console business as far as only Cygwin processes are affected.
>
>> "Is it possible to identify them prior to launch them?"
>
> Cygwin checks for a Cygwin application prior to execv it.
> Not a Cygwin application == may need a console.
>
> I have some testing code which only tries to create an invisible console
> if the application to execv is not a Cygwin application. ÂIt seems to
> work nicely. ÂI'm just not sure if it's really *that* simple...
>

Thanks for the clarification!

Besides that, is it possible to distinguish if, being *not* a Cygwin
application, it would *need* direct console IO?
If I understand it correctly, knowing if an application is for
subsystem windows or console does *not* give us a foolproof answer to
if it would need the direct console IO.
That's bad. This identification could be very handy to only try
"risky" and "costly" things only when really needed...

As for the action itself, to hide the console, I've been looking in
the MS documentation and I saw some potential insteresting info about
the STARTUPINFO passed to the CreateProcess:
1) Use STARTF_USEPOSITION, with dwX = dwY = 0x8000 (similar to the
registry hack?);
2) OR, use STARTF_USESHOWWINDOW, with wShowWindow = SW_HIDE;
3) OR (far fetched) use lpDesktop with something 'WinStaHIDE\Default'

I've not tested it (I've no access to a proper build system to do
this, neither to a Win7).
Probable drawbacks:
1) I'm guessing that NO window will show after even the created by
child processess...
Is it possible to change the dwFlags field on the child process, after
it starts? That would solve it;
2) ditto;
3) It force us to do a SetProcessWindowStation and SetThreadDesktop to
something that must be stored and passed to the child, after the
AllocConsole is done ; AND, there is also the probability of Win7 just
plain ignores the lpDesktop setting.

Well, this is all I can see for now. Hope it helps somehow.

-- 
___________
Julio Costa

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


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