O
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);
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);