Hi,
I encountered a nasty issue and found a solution to it (the hard way).
So I thought it would be a good idea to share it.
I use a build script (similar to ddkbuild.bat from OSR or hollistech) to
run the DDK build from within the VS2005 IDE. With the WDK (build 6000)
I encountered the following problem:
Command line arguments passed to compiler and linker are echoed in the
VS output window rather than written to the build.log file. When I run
my script from a console window then arguments are written to the log
and not echoed on screen. After some investigation I found that VS2005
sets an environment variable VS_UNICODE_OUTPUT in each cmd instance it
launches. Obviously, this variable causes the compiler to format its
output in UNICODE which cannot be filtered out by build.exe and thus
will not be redirected to the log.
The solution is to remove this variable by adding
set VS_UNICODE_OUTPUT=
to the build script.
Udo
Udo Eberhardt wrote:
Command line arguments passed to compiler and linker are echoed in the
VS output window rather than written to the build.log file. When I run
my script from a console window then arguments are written to the log
and not echoed on screen. After some investigation I found that VS2005
sets an environment variable VS_UNICODE_OUTPUT in each cmd instance it
launches. Obviously, this variable causes the compiler to format its
output in UNICODE which cannot be filtered out by build.exe and thus
will not be redirected to the log.
Sort of. That variable actually causes cl.exe to create two named pipes
and write Unicode output to them, instead of using stderr and stdout,
like every command-line program in history has done.
Wouldn’t the world have been better served if they had simply changed
the code page to UTF8 for their internal console windows?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
Udo Eberhardt wrote:
> Command line arguments passed to compiler and linker are echoed in the
> VS output window rather than written to the build.log file. When I run
> my script from a console window then arguments are written to the log
> and not echoed on screen. After some investigation I found that VS2005
> sets an environment variable VS_UNICODE_OUTPUT in each cmd instance it
> launches. Obviously, this variable causes the compiler to format its
> output in UNICODE which cannot be filtered out by build.exe and thus
> will not be redirected to the log.
Sort of. That variable actually causes cl.exe to create two named pipes
and write Unicode output to them, instead of using stderr and stdout,
like every command-line program in history has done.
Wouldn’t the world have been better served if they had simply changed
the code page to UTF8 for their internal console windows?
I agree, there should be no (undocumented) magic behind the scenes. This
unexpected interaction between VS and the DDK compiler is quite
confusing. I think it’s undocumented because I found no hit in msdn for
VS_UNICODE_OUTPUT. So how did you find out the details?
For years, I ran a lot of tools (e.g. lint, latex) from within the VS
IDE and did always get stdout and stderr in the output window without
any problems. VS2005 and WDK is the first combination that causes
problems, although either of them is shipped by MSFT.
Udo
Udo Eberhardt wrote:
Tim Roberts wrote:
>
> Wouldn’t the world have been better served if they had simply changed
> the code page to UTF8 for their internal console windows?
>
I agree, there should be no (undocumented) magic behind the scenes.
This unexpected interaction between VS and the DDK compiler is quite
confusing. I think it’s undocumented because I found no hit in msdn
for VS_UNICODE_OUTPUT. So how did you find out the details?
For years, I ran a lot of tools (e.g. lint, latex) from within the VS
IDE and did always get stdout and stderr in the output window without
any problems. VS2005 and WDK is the first combination that causes
problems, although either of them is shipped by MSFT.
I Googled for VS_UNICODE_OUTPUT. This hack was introduced in VS2005,
and it has caused problems for many applications that want to
post-process the results of cl.exe. There’s a blog entry from a
Microsoftie that describes the purpose.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The WDK compiler is (almost) same as in VS2005, perhaps this is why
it behaves like VS’s own CL.
Of course this strange behavior is not going to be fixed in SP1?
–PA
Pavel A. wrote:
The WDK compiler is (almost) same as in VS2005, perhaps this is why
it behaves like VS’s own CL.
Of course this strange behavior is not going to be fixed in SP1?
It’s not a bug, it’s a feature. Their answer, for people who wish to
postprocess the output, is to clear the environment variable.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.