Screen flash when using cl.exe

[Owen]

I'm using an application (a Tcl/Tk app) that uses cl.exe to compile code in the
background. One very annoying feature is that a DOS box is flashed to the
screen and then withdrawn during linking. Imagine using this application to
link thousands of executables and trying to use the machine while thousands of
temporary DOS boxes appear and temporarily take focus away from the application
you are using.

The only other time that I have seen this is with using Intel's Fortran
f90com.exe compiler (see Issue 185355). Intel is aware of the bug and maybe the
same bug exists with Microsoft's cl.exe compiler.

Here's the discussion of the issue with Intel Support. Maybe you Microsoft
developers can implement this change in the code for Visual C++ as well?

---- BEGIN ISSUE DETAILS WITH INTEL ----

In talking with Mr Lionel, I learned that your code uses _spawnvp to invoke
f90com.exe. I request that it be replaced with CreateProcess. Here's a detailed
response that I gave Steve:

I've been able to create a stand-alone use case. An individual on the
comp.lang.tcl newsgroup was kind enough to provide the explanation (which may I
note appears in other applications which start without a console):

--- BEGIN EXPLANATION ---

When Windows starts a subprocess, it will try and attach it to a console unless
the CreateProcess() call specifies that the child is "detached". Windows
attaches the new process to the parent's console, if it has one; otherwise it
creates a new console window for the child.

Wish (the interpreter for Tk) starts subprocesses as "detached" children, which
means that they do not have a console. If the child (make, in your example) then
starts another process but doesn't provide the detached flag, Windows will
create a console for this grandchild process. The implementation of _spawnXX()
in Microsoft's libraries does not normally provide the detached flag.

--- END EXPLANATION ---

To exercise this explanation, I wrote two applications. The 1st use case had the
first application launch the second application using _spawnXX using a WISH. The
behavior I see with "ifl" launching "f90com" was reproduced. Then I modified the
first application to use CreateProcess instead. Since Windows was going to
create the console regardless, I set a flag (SW_HIDE) in CreateProcess to not
show the window.

How would I go about requesting for Intel to create an optional command-line for
"ifl" (say /suppressSubconsoleWindowCreation) which would use CreateProcess
(similar to the code below) instead of _spawnvp when launching f90com?

Here's my code for launching the application via CreateProcess instead of
_spawnvp. Note that stdout, stdin, and stderr are inherited from the parent.

char command[] = "f90com.exe";

STARTUPINFO si;
PROCESS_INFORMATION pi;

ZeroMemory(&si, sizeof(si));
si.cb = sizeof(si);
si.dwFlags = STARTF_USESHOWWINDOW | STARTF_USESTDHANDLES;
si.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE);
si.hStdError = GetStdHandle(STD_ERROR_HANDLE);
si.hStdInput = GetStdHandle(STD_INPUT_HANDLE);
si.wShowWindow = SW_HIDE;

ZeroMemory(&pi, sizeof(pi));

// New process inherits handles from the calling process
if (!CreateProcess(NULL, command, NULL, NULL,
TRUE,
NULL, NULL, NULL,
&si, &pi)) {
//
// Big bad error
//
} else {
WaitForSingleObject(pi.hProcess, INFINITE);
}

CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);

[Owen]

PS This problem exists with the Visual C++ .NET 2003 compiler.
Owen wrote:

I'm using an application (a Tcl/Tk app) that uses cl.exe to compile code
in the background. One very annoying feature is that a DOS box is
flashed to the screen and then withdrawn during linking. Imagine using
this application to link thousands of executables and trying to use the
machine while thousands of temporary DOS boxes appear and temporarily
take focus away from the application you are using.

The only other time that I have seen this is with using Intel's Fortran
f90com.exe compiler (see Issue 185355). Intel is aware of the bug and
maybe the same bug exists with Microsoft's cl.exe compiler.

Here's the discussion of the issue with Intel Support. Maybe you
Microsoft developers can implement this change in the code for Visual
C++ as well?

---- BEGIN ISSUE DETAILS WITH INTEL ----

In talking with Mr Lionel, I learned that your code uses _spawnvp to
invoke f90com.exe. I request that it be replaced with CreateProcess.
Here's a detailed response that I gave Steve:

I've been able to create a stand-alone use case. An individual on the
comp.lang.tcl newsgroup was kind enough to provide the explanation
(which may I note appears in other applications which start without a
console):

--- BEGIN EXPLANATION ---

When Windows starts a subprocess, it will try and attach it to a console
unless the CreateProcess() call specifies that the child is "detached".
Windows attaches the new process to the parent's console, if it has one;
otherwise it creates a new console window for the child.

Wish (the interpreter for Tk) starts subprocesses as "detached"
children, which means that they do not have a console. If the child
(make, in your example) then starts another process but doesn't provide
the detached flag, Windows will create a console for this grandchild
process. The implementation of _spawnXX() in Microsoft's libraries does
not normally provide the detached flag.

--- END EXPLANATION ---

To exercise this explanation, I wrote two applications. The 1st use case
had the first application launch the second application using _spawnXX
using a WISH. The behavior I see with "ifl" launching "f90com" was
reproduced. Then I modified the first application to use CreateProcess
instead. Since Windows was going to create the console regardless, I set
a flag (SW_HIDE) in CreateProcess to not show the window.

How would I go about requesting for Intel to create an optional
command-line for "ifl" (say /suppressSubconsoleWindowCreation) which
would use CreateProcess (similar to the code below) instead of _spawnvp
when launching f90com?

Here's my code for launching the application via CreateProcess instead
of _spawnvp. Note that stdout, stdin, and stderr are inherited from the
parent.

char command[] = "f90com.exe";

STARTUPINFO si;
PROCESS_INFORMATION pi;

ZeroMemory(&si, sizeof(si));
si.cb = sizeof(si);
si.dwFlags = STARTF_USESHOWWINDOW | STARTF_USESTDHANDLES;
si.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE);
si.hStdError = GetStdHandle(STD_ERROR_HANDLE);
si.hStdInput = GetStdHandle(STD_INPUT_HANDLE);
si.wShowWindow = SW_HIDE;

ZeroMemory(&pi, sizeof(pi));

// New process inherits handles from the calling process
if (!CreateProcess(NULL, command, NULL, NULL,
TRUE,
NULL, NULL, NULL,
&si, &pi)) {
//
// Big bad error
//
} else {
WaitForSingleObject(pi.hProcess, INFINITE);
}

CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);

[Carl Daniel [VC++ MVP]]

Owen wrote:

PS This problem exists with the Visual C++ .NET 2003 compiler.

If the problem is that you don't like how cl.exe invokes link.exe, why not
just invoke the linker yourself, using CreateProccess as you're suggesting?

-cd