Mail Archives: cygwin/2009/07/03/09:44:55
On Fri, Jul 3, 2009 at 11:44, Corinna Vinschen wrote:
> On Jul =C2=A03 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. =C2=A0They use what they
> get as file descriptors and live with that.
>
> Native processes exist in two variations. =C2=A0Some of them just use
> the stdio handles like Cygwin processes. =C2=A0Some 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. =C2=A0Unfortunately 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. =C2=A0I 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 =3D=3D 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. =C2=A0It seems to
> work nicely. =C2=A0I'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 =3D dwY =3D 0x8000 (similar to the
registry hack?);
2) OR, use STARTF_USESHOWWINDOW, with wShowWindow =3D 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.
--=20
___________
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
- Raw text -