On 2021-03-23 07:09, Jon Turney wrote:
On 23/03/2021 12:44, Corinna Vinschen via Cygwin-patches wrote:
On Mar 23 21:32, Takashi Yano via Cygwin-patches wrote:
On Tue, 23 Mar 2021 13:17:16 +0100
Corinna Vinschen wrote:
On Mar 23 20:57, Takashi Yano via Cygwin-patches wrote:
Corinna Vinschen wrote:
On Mar 22 08:07, Takashi Yano via Cygwin-patches wrote:
And also, following cygwin apps/dlls call GetStdHandle():
ccmake.exe
cmake.exe
cpack.exe
ctest.exe
run.exe
run creates its own conin/conout handles to create a hidden console.
The code calling GetStdHandle() is only for debug purposes and never
built into the executable.
Sorry, but this was utterly wrong. run calls GetStdHandle, then
overwrites the handles, but only if it doesn't already is attached to a
console.
Looks right to me. If we patch cmake to do the right thing, do we still
need this patch, Takashi?
I don't think so. If all is well with current code, nothing to be fixed.
How do you evaluate this in light of the run behaviour above?
I try to check run.exe behaviour and noticed that
run cmd.exe
and
run cat.exe
does not work with cygwin 3.0.7 and 3.2.0 (TEST) while these
work in 3.1.7.
Is this expected behaviour?
The problem is that I never used run. I can't actually tell what
exactly is expected. I *think* run was intended to start Cygwin
applications without console window in the first place, not
native Windows apps, but I could be wrong.
I don't even know if anybody is actually, seriously using it.
'run' is used by the start menu item which starts the X server.
If that doesn't use it, a visible console window is created for the bash process
it starts (which is the parent of the X server process and lives for it's
lifetime).
(As a separate issue, I'm not sure all the complex gymnastics run does to creste
the window invisibly are doing anything useful, since we seem to briefly show
the window and then hide it)
Shortcut does:
C:\...\cygwin64\bin\run.exe --quote /usr/bin/bash.exe -l -c "cd; exec
/usr/bin/startxwin"
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
