Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Upcoming OSR Seminars | ||
---|---|---|
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
Kernel Debugging | 9-13 Sept 2024 | Live, Online |
Developing Minifilters | 15-19 July 2024 | Live, Online |
Internals & Software Drivers | 11-15 Mar 2024 | Live, Online |
Writing WDF Drivers | 20-24 May 2024 | Live, Online |
Comments
>
> 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, [email protected]
Providenza & Boekelheide, Inc.
Tim Roberts, [email protected]
Software Wizard Emeritus
> 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
> 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, [email protected]
Providenza & Boekelheide, Inc.
Tim Roberts, [email protected]
Software Wizard Emeritus
it behaves like VS's own CL.
Of course this strange behavior is not going to be fixed in SP1?
--PA
> 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, [email protected]
Providenza & Boekelheide, Inc.
Tim Roberts, [email protected]
Software Wizard Emeritus