IFS Kit and Visual Studio 2005

I know this has been asked about earlier versions of Visual Studio.
However, with VS 2005 is it now possible to convert the x64 samples into
“true” VS projects? Thanks.

Mark Roddy has an excellent method for creating VS projects for drivers that
follow the correct rules supported by WHQL and the WDK team. It is
possible, but unadvisable to do builds only within the VS environment. The
two compilers are not always in sync and from history I know that the VS or
Visual C & C++ releases frequently broke kernel mode compiles or linking.
It is far better, IMHO, to use the tools as designed. The IFS Kit no longer
exists when considering Vista or the soon to be required WHQL DTM. It is a
free part of the WDK now as the last IFS Kit was for Windows Server 2003 SP1
that also created Windows XP x64 which is really based upon Server 2003 SP1
and not XP SP2. There are methods to accomplish almost anything you desire
and maybe someone can help if you have a specific request.


David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation

“Neil Weicher” wrote in message news:xxxxx@ntfsd…
>I know this has been asked about earlier versions of Visual Studio.
>However, with VS 2005 is it now possible to convert the x64 samples into
>“true” VS projects? Thanks.
>
>
>

Using “true” VS project for a driver is a bad idea. If you will have an
issue - then nobody will help.

Also, since you cannot use VS’s debugger in a driver, and since VS’s
project settings UI is a toy compared to SOURCES file, this has no value.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Neil Weicher” wrote in message news:xxxxx@ntfsd…
> I know this has been asked about earlier versions of Visual Studio.
> However, with VS 2005 is it now possible to convert the x64 samples into
> “true” VS projects? Thanks.
>
>
>

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
Reply To: Windows File Systems Devs Interest List
Sent: Monday, May 14, 2007 4:22 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IFS Kit and Visual Studio 2005

The two compilers are not always in sync and from history I know that the VS or
Visual C & C++ releases frequently broke kernel mode compiles or linking.

My memory probably leaks but I don’t remember any such an issue. Can you mention few? It shouldn’t be hard if they were frequent.

I quite agree WDK compiler should be used to build drivers and attempt to use VS compiler are at least unreasonable. But for a bit different reasons (makefile.def).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

I remember some from the VxD area where the newest version of Visual C had a
linker where the correct bits were not set in the VxD executable image. It
would not load. My memory goes back to the late 80’s where the DOS C
compiler began to place structures on the stack but computed offsets
incorrectly. The code was not ‘correct’ but worked with the earlier
compiler. If anyone from Microsoft would like to comment, I am sure they
know of the instances that caused them to add the compiler to the XP and
later DDKs. The 2000 DDK was the last that didn’t include a compiler.

“Michal Vodicka” wrote in message
news:xxxxx@ntfsd…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
> Reply To: Windows File Systems Devs Interest List
> Sent: Monday, May 14, 2007 4:22 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] IFS Kit and Visual Studio 2005
>
> The two compilers are not always in sync and from history I know that the
> VS or
> Visual C & C++ releases frequently broke kernel mode compiles or linking.
>
My memory probably leaks but I don’t remember any such an issue. Can you
mention few? It shouldn’t be hard if they were frequent.

I quite agree WDK compiler should be used to build drivers and attempt to
use VS compiler are at least unreasonable. But for a bit different reasons
(makefile.def).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

I definitely can not speak authoritatively here, and I don’t use VS, but
I haven’t used BUILD.EXE for at least four years, and I haven’t had any
problems, at least of which I know. I frequently have unusual
requirements over which I have little control and for which BUILD.EXE is
not very helpful, but I can’t say that some of BUILD.EXE’s preferences
clashing with mine doesn’t figure in to most of the cases. In any case,
even though I haven’t had any issues, I can’t say that I would ever
recommend it, but if the dev wishes to go this route, it’s pretty easy
to do it safely from the command line (I don’t know what the deal with
VS is). Just build a driver and copy the settings for the tools from
the log, including which tools to use, instead of using the VS compiler,
although I believe that the DDK compiler is one of the VS 2003 versions.
It certainly is true that the potential exists for different drivers
having radically different settings, but I have never seen that. The
biggest issue I have with BUILD.EXE is having to organize my source code
around it. Certainly, for the tool to be of use and make things easier,
it is unavoidable, but the trade off in a large code base, and moreover
in the case of shared code or existing code doesn’t seem at all worth it
to me, if this sort of things bothers you. Aside from the issue of
potential problems (perhaps ones that actually have occurred), the other
apparent issue is that it is “not supported by Microsoft.” I believe
that means that you can’t use of (for most of us) two MSDN support
incidents, which to me is a non-issue. The real issue, I think, is that
no one on this list, including me, is likely to be willing to help under
these circumstances. This is why I wouldn’t recommend it. The other
one is that, when the WDK, changes, one might have to updatge the build
rules. Assuming you know what you are doing, this isn’t hard, but you
definitely have to know to at least check for this possibility. But I
think Michal is correct here - not advisable in most cases, but it
certainly is possible.

mm

>> xxxxx@yoshimuni.com 2007-05-14 17:18:04 >>>
I remember some from the VxD area where the newest version of Visual C
had a
linker where the correct bits were not set in the VxD executable image.
It
would not load. My memory goes back to the late 80’s where the DOS C
compiler began to place structures on the stack but computed offsets
incorrectly. The code was not ‘correct’ but worked with the earlier
compiler. If anyone from Microsoft would like to comment, I am sure
they
know of the instances that caused them to add the compiler to the XP
and
later DDKs. The 2000 DDK was the last that didn’t include a compiler.

“Michal Vodicka” wrote in message
news:xxxxx@ntfsd…
> ----------
> From:
>
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]

> on behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
> Reply To: Windows File Systems Devs Interest List
> Sent: Monday, May 14, 2007 4:22 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] IFS Kit and Visual Studio 2005
>
> The two compilers are not always in sync and from history I know that
the
> VS or
> Visual C & C++ releases frequently broke kernel mode compiles or
linking.
>
My memory probably leaks but I don’t remember any such an issue. Can
you
mention few? It shouldn’t be hard if they were frequent.

I quite agree WDK compiler should be used to build drivers and attempt
to
use VS compiler are at least unreasonable. But for a bit different
reasons
(makefile.def).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

There are some of us who have drivers that are found ‘in the box’. Source
code is submitted to Microsoft and new operating systems ship with drivers
made from those sources. Not playing by the rules will not help make your
hardware the choice of major OEMs.


David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation

“Martin O’Brien” wrote in message
news:xxxxx@ntfsd…
>I definitely can not speak authoritatively here, and I don’t use VS, but
> I haven’t used BUILD.EXE for at least four years, and I haven’t had any
> problems, at least of which I know. I frequently have unusual
> requirements over which I have little control and for which BUILD.EXE is
> not very helpful, but I can’t say that some of BUILD.EXE’s preferences
> clashing with mine doesn’t figure in to most of the cases. In any case,
> even though I haven’t had any issues, I can’t say that I would ever
> recommend it, but if the dev wishes to go this route, it’s pretty easy
> to do it safely from the command line (I don’t know what the deal with
> VS is). Just build a driver and copy the settings for the tools from
> the log, including which tools to use, instead of using the VS compiler,
> although I believe that the DDK compiler is one of the VS 2003 versions.
> It certainly is true that the potential exists for different drivers
> having radically different settings, but I have never seen that. The
> biggest issue I have with BUILD.EXE is having to organize my source code
> around it. Certainly, for the tool to be of use and make things easier,
> it is unavoidable, but the trade off in a large code base, and moreover
> in the case of shared code or existing code doesn’t seem at all worth it
> to me, if this sort of things bothers you. Aside from the issue of
> potential problems (perhaps ones that actually have occurred), the other
> apparent issue is that it is “not supported by Microsoft.” I believe
> that means that you can’t use of (for most of us) two MSDN support
> incidents, which to me is a non-issue. The real issue, I think, is that
> no one on this list, including me, is likely to be willing to help under
> these circumstances. This is why I wouldn’t recommend it. The other
> one is that, when the WDK, changes, one might have to updatge the build
> rules. Assuming you know what you are doing, this isn’t hard, but you
> definitely have to know to at least check for this possibility. But I
> think Michal is correct here - not advisable in most cases, but it
> certainly is possible.
>
> mm
>
>
>>>> xxxxx@yoshimuni.com 2007-05-14 17:18:04 >>>
> I remember some from the VxD area where the newest version of Visual C
> had a
> linker where the correct bits were not set in the VxD executable image.
> It
> would not load. My memory goes back to the late 80’s where the DOS C
> compiler began to place structures on the stack but computed offsets
> incorrectly. The code was not ‘correct’ but worked with the earlier
> compiler. If anyone from Microsoft would like to comment, I am sure
> they
> know of the instances that caused them to add the compiler to the XP
> and
> later DDKs. The 2000 DDK was the last that didn’t include a compiler.
>
>
> “Michal Vodicka” wrote in message
> news:xxxxx@ntfsd…
>> ----------
>> From:
>>
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
>
>> on behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
>> Reply To: Windows File Systems Devs Interest List
>> Sent: Monday, May 14, 2007 4:22 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] IFS Kit and Visual Studio 2005
>>
>> The two compilers are not always in sync and from history I know that
> the
>> VS or
>> Visual C & C++ releases frequently broke kernel mode compiles or
> linking.
>>
> My memory probably leaks but I don’t remember any such an issue. Can
> you
> mention few? It shouldn’t be hard if they were frequent.
>
> I quite agree WDK compiler should be used to build drivers and attempt
> to
> use VS compiler are at least unreasonable. But for a bit different
> reasons
> (makefile.def).
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Excellent point. I have no experience in such areas.

>> xxxxx@yoshimuni.com 2007-05-15 11:01:53 >>>
There are some of us who have drivers that are found ‘in the box’.
Source
code is submitted to Microsoft and new operating systems ship with
drivers
made from those sources. Not playing by the rules will not help make
your
hardware the choice of major OEMs.


David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation

“Martin O’Brien” wrote in message
news:xxxxx@ntfsd…
>I definitely can not speak authoritatively here, and I don’t use VS,
but
> I haven’t used BUILD.EXE for at least four years, and I haven’t had
any
> problems, at least of which I know. I frequently have unusual
> requirements over which I have little control and for which BUILD.EXE
is
> not very helpful, but I can’t say that some of BUILD.EXE’s
preferences
> clashing with mine doesn’t figure in to most of the cases. In any
case,
> even though I haven’t had any issues, I can’t say that I would ever
> recommend it, but if the dev wishes to go this route, it’s pretty
easy
> to do it safely from the command line (I don’t know what the deal
with
> VS is). Just build a driver and copy the settings for the tools
from
> the log, including which tools to use, instead of using the VS
compiler,
> although I believe that the DDK compiler is one of the VS 2003
versions.
> It certainly is true that the potential exists for different drivers
> having radically different settings, but I have never seen that.
The
> biggest issue I have with BUILD.EXE is having to organize my source
code
> around it. Certainly, for the tool to be of use and make things
easier,
> it is unavoidable, but the trade off in a large code base, and
moreover
> in the case of shared code or existing code doesn’t seem at all worth
it
> to me, if this sort of things bothers you. Aside from the issue of
> potential problems (perhaps ones that actually have occurred), the
other
> apparent issue is that it is “not supported by Microsoft.” I
believe
> that means that you can’t use of (for most of us) two MSDN support
> incidents, which to me is a non-issue. The real issue, I think, is
that
> no one on this list, including me, is likely to be willing to help
under
> these circumstances. This is why I wouldn’t recommend it. The
other
> one is that, when the WDK, changes, one might have to updatge the
build
> rules. Assuming you know what you are doing, this isn’t hard, but
you
> definitely have to know to at least check for this possibility. But
I
> think Michal is correct here - not advisable in most cases, but it
> certainly is possible.
>
> mm
>
>
>>>> xxxxx@yoshimuni.com 2007-05-14 17:18:04 >>>
> I remember some from the VxD area where the newest version of Visual
C
> had a
> linker where the correct bits were not set in the VxD executable
image.
> It
> would not load. My memory goes back to the late 80’s where the DOS
C
> compiler began to place structures on the stack but computed offsets
> incorrectly. The code was not ‘correct’ but worked with the earlier
> compiler. If anyone from Microsoft would like to comment, I am sure
> they
> know of the instances that caused them to add the compiler to the XP
> and
> later DDKs. The 2000 DDK was the last that didn’t include a
compiler.
>
>
> “Michal Vodicka” wrote in message
> news:xxxxx@ntfsd…
>> ----------
>> From:
>>
>
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]

>
>> on behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
>> Reply To: Windows File Systems Devs Interest List
>> Sent: Monday, May 14, 2007 4:22 AM
>> To: Windows File Systems Devs Interest List
>> Subject: Re:[ntfsd] IFS Kit and Visual Studio 2005
>>
>> The two compilers are not always in sync and from history I know
that
> the
>> VS or
>> Visual C & C++ releases frequently broke kernel mode compiles or
> linking.
>>
> My memory probably leaks but I don’t remember any such an issue. Can
> you
> mention few? It shouldn’t be hard if they were frequent.
>
> I quite agree WDK compiler should be used to build drivers and
attempt
> to
> use VS compiler are at least unreasonable. But for a bit different
> reasons
> (makefile.def).
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

I vaguelly remember VxD case. Wasn’t it VS 4.1? Rather old case and I expected you mean something related to NT.

WDK contains the same compiler as VS although a bit different version. Theoretically there could be a VS compiler bug which breaks kernel build but IMO it is very unlikely. Drivers are just PE binaries, anyway.

Using VS compiler for driver development isn’t a good idea unless one has a very good reason. Wanting to use VS IDE isn’t a good reason in any way. However, we should use better arguments than rumors about compiler incompatibilities. As you did later in this thread although this one doesn’t influence too much developers. What argument? Compiler and linker settings in makefile.def. Possible settings change after WDK update (and a need to change VS project). Preprocessor directives in WDK includes which check for exact compiler version to enable some features. Better project management and automation.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
Reply To: Windows File Systems Devs Interest List
Sent: Monday, May 14, 2007 11:18 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] IFS Kit and Visual Studio 2005

I remember some from the VxD area where the newest version of Visual C had a
linker where the correct bits were not set in the VxD executable image. It
would not load. My memory goes back to the late 80’s where the DOS C
compiler began to place structures on the stack but computed offsets
incorrectly. The code was not ‘correct’ but worked with the earlier
compiler. If anyone from Microsoft would like to comment, I am sure they
know of the instances that caused them to add the compiler to the XP and
later DDKs. The 2000 DDK was the last that didn’t include a compiler.

“Michal Vodicka” wrote in message
> news:xxxxx@ntfsd…
> > ----------
> > From:
> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> > on behalf of David J. Craig[SMTP:xxxxx@yoshimuni.com]
> > Reply To: Windows File Systems Devs Interest List
> > Sent: Monday, May 14, 2007 4:22 AM
> > To: Windows File Systems Devs Interest List
> > Subject: Re:[ntfsd] IFS Kit and Visual Studio 2005
> >
> > The two compilers are not always in sync and from history I know that the
> > VS or
> > Visual C & C++ releases frequently broke kernel mode compiles or linking.
> >
> My memory probably leaks but I don’t remember any such an issue. Can you
> mention few? It shouldn’t be hard if they were frequent.
>
> I quite agree WDK compiler should be used to build drivers and attempt to
> use VS compiler are at least unreasonable. But for a bit different reasons
> (makefile.def).
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@upek.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>