Can i use vc2003 or vc2005’s cl.exe generate driver sys file ?
This has been answered many times, look for Visual Studio and drivers. The
bottom line is you would be incredibly stupid not to use the compiler that
comes with the WDK. If you want to use the GUI, get DDKBUILD from OSR or
http://www.hollistech.com/.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> Can i use vc2003 or vc2005’s cl.exe generate driver sys file ?
>
thank Don Burn .
But , I want to know VC’s cl.exe and DKK’S cl.exe this two file is same ?
They have different revisions and you should use the WDK’s revision, but yes
the compiler is the same except for the revision. You want to use the WDK
version, since it was tested with the kernel, and using the VC version even
if it is newer, can lead to subtle bugs/
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> thank Don Burn .
> But , I want to know VC’s cl.exe and DKK’S cl.exe this two file is same ?
>
Generally speaking, no, but it all depends on what versions of each
which you are talking about. Some versions of the DDK and WDK had, and
may still, the same version of CL as either VS 2003 or VS 2003 SP1; I
don’t recall which, and it doesn’t really matter, as there isn’t any
particularly good reason to not use the WDK version of CL that I can
think of, at least. The general answer to this problem if you want to
use a single compiler for everything, which is certainly understandable,
go the other way - use the WDK’s for everything.
This question comes up a lot of this list, and there are rumors of
alleged horror stories about what happens if you don’t use the WDK’s
compiler. Although I would never use VS’s for kernel mode work, for the
reason I stated above, but also because it presumably hasn’t been tested
against the kernel sources, I remain unconvinced of the existence of
these problems within at least the last three years or so, and, to me,
while I think not using it the way you wish does make sense, as far as
perceived magnitude goes, it’s also sort of an emotional issue, because
the only option that really makes sense isn’t an option at all - having
one and only one compiler. I think using the WDK’s in user mode rather
than the other way around is a better idea, for the reasons I already
stated, and, short of some evidence of actual problems, the best reason,
I think, is that not doing so essentially guarantees that you will not
be able to get help from people on this list at least, which to me is a
rather poor risk/reward scenario, as I don’t see any upside. Whether
the lack of a single compiler is for technical reasons or otherwise, I
really don’t know, but it seems awfully unlikely to me that it is the
former, partly because, in the end, it’s all just C code running on the
same machine, and there aren’t different calling conventions, et. c.
between user mode and kernel mode, et. c., and considerably bigger
problems have been solved than this. I also think it’s unlikely because
I just can’t imagine that Microsoft would be looking to advertise that
the version of CL you a lot of money for doesn’t work for everything,
but the one that’s very commonly free (on connect.microsoft.com) does
work for both, as it doesn’t appear to be like the joke version of MFC
that comes with the WDK. If one wants to get in to that sort of
conspiracy theory thing, the other way - the free one is limited makes a
lot more sense, but I’m not sure how one would go about that even if one
wanted to do so, short of legitimate sabotage, limiting the conversation
to ‘C’ only. With ‘C++’ there are some options, and the linker, sure,
but that’s never come up as an issue.
In any case, Don already gave you good advice - there’s no reason to do
this, and use DDKBUILD.BAT.
Good luck,
mm
xxxxx@gmail.com wrote:
thank Don Burn .
But , I want to know VC’s cl.exe and DKK’S cl.exe this two file is same ?
Martin,
I debugged one of those horror stories for a client. I know they paid
me a heck of a lot of money for an answer that in the end came out “It works
with the old compiler in the DDK, but not Vs2005” I also offerred to find
the actual code bug, but since they were already into to me for multiples of
$10,000 and I told them the final search would be more they passed.
I used to do compilers, and I assure you the subtle surprises that can
come in from version to version always amaze people. I would never use a
compiler that was not well tested in the environment it was targeted for.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Generally speaking, no, but it all depends on what versions of each which
> you are talking about. Some versions of the DDK and WDK had, and may
> still, the same version of CL as either VS 2003 or VS 2003 SP1; I don’t
> recall which, and it doesn’t really matter, as there isn’t any
> particularly good reason to not use the WDK version of CL that I can think
> of, at least. The general answer to this problem if you want to use a
> single compiler for everything, which is certainly understandable, go the
> other way - use the WDK’s for everything.
>
> This question comes up a lot of this list, and there are rumors of alleged
> horror stories about what happens if you don’t use the WDK’s compiler.
> Although I would never use VS’s for kernel mode work, for the reason I
> stated above, but also because it presumably hasn’t been tested against
> the kernel sources, I remain unconvinced of the existence of these
> problems within at least the last three years or so, and, to me, while I
> think not using it the way you wish does make sense, as far as perceived
> magnitude goes, it’s also sort of an emotional issue, because the only
> option that really makes sense isn’t an option at all - having one and
> only one compiler. I think using the WDK’s in user mode rather than the
> other way around is a better idea, for the reasons I already stated, and,
> short of some evidence of actual problems, the best reason, I think, is
> that not doing so essentially guarantees that you will not be able to get
> help from people on this list at least, which to me is a rather poor
> risk/reward scenario, as I don’t see any upside. Whether the lack of a
> single compiler is for technical reasons or otherwise, I really don’t
> know, but it seems awfully unlikely to me that it is the former, partly
> because, in the end, it’s all just C code running on the same machine, and
> there aren’t different calling conventions, et. c. between user mode and
> kernel mode, et. c., and considerably bigger problems have been solved
> than this. I also think it’s unlikely because I just can’t imagine that
> Microsoft would be looking to advertise that the version of CL you a lot
> of money for doesn’t work for everything, but the one that’s very commonly
> free (on connect.microsoft.com) does work for both, as it doesn’t appear
> to be like the joke version of MFC that comes with the WDK. If one wants
> to get in to that sort of conspiracy theory thing, the other way - the
> free one is limited makes a lot more sense, but I’m not sure how one would
> go about that even if one wanted to do so, short of legitimate sabotage,
> limiting the conversation to ‘C’ only. With ‘C++’ there are some options,
> and the linker, sure, but that’s never come up as an issue.
>
> In any case, Don already gave you good advice - there’s no reason to do
> this, and use DDKBUILD.BAT.
>
> Good luck,
>
> mm
>
>
>
> xxxxx@gmail.com wrote:
>> thank Don Burn .
>> But , I want to know VC’s cl.exe and DKK’S cl.exe this two file is same
>> ?
>
I never would either Don. Yours is the first the documented problem
that I have ever heard of, and it’s good to know.
Thanks,
mm
Don Burn wrote:
Martin,
I debugged one of those horror stories for a client. I know they paid
me a heck of a lot of money for an answer that in the end came out “It works
with the old compiler in the DDK, but not Vs2005” I also offerred to find
the actual code bug, but since they were already into to me for multiples of
$10,000 and I told them the final search would be more they passed.I used to do compilers, and I assure you the subtle surprises that can
come in from version to version always amaze people. I would never use a
compiler that was not well tested in the environment it was targeted for.
I have never understood the need to use one compiler for both user mode and
kernel mode. I do understand the desire to use the same program editor, it
just seems that many people confuse “editor/ide for source code” with “build
tool chain”.
You are correct that there are no recent horror stories that I am aware of
regarding using one version of microsoft’s cl rather than another. I just
can’t find the rational basis for wanting to test these limits with
production software. Why would I want to use cl.exe from VS rather than
cl.exe from the WDK?
As far as using the WDK in user mode goes - that is fine if what you want to
develop is a command line application. If you are building gui based test
tools the WDK contains some crappy old set of MFC libraries from a long time
ago and is a very poor user mode application development tool. And again -
why on earth would I want to impose the rather feeble user mode support of
the WDK on a development team when there are much better choices available?
I don’t get the one tool to rule them all thing. I can knock in screws with
a hammer, it just isn’t the best tool for the job.
On Feb 9, 2008 1:52 PM, Martin O’Brien wrote:
> Generally speaking, no, but it all depends on what versions of each
> which you are talking about. Some versions of the DDK and WDK had, and
> may still, the same version of CL as either VS 2003 or VS 2003 SP1; I
> don’t recall which, and it doesn’t really matter, as there isn’t any
> particularly good reason to not use the WDK version of CL that I can
> think of, at least. The general answer to this problem if you want to
> use a single compiler for everything, which is certainly understandable,
> go the other way - use the WDK’s for everything.
>
> This question comes up a lot of this list, and there are rumors of
> alleged horror stories about what happens if you don’t use the WDK’s
> compiler. Although I would never use VS’s for kernel mode work, for the
> reason I stated above, but also because it presumably hasn’t been tested
> against the kernel sources, I remain unconvinced of the existence of
> these problems within at least the last three years or so, and, to me,
> while I think not using it the way you wish does make sense, as far as
> perceived magnitude goes, it’s also sort of an emotional issue, because
> the only option that really makes sense isn’t an option at all - having
> one and only one compiler. I think using the WDK’s in user mode rather
> than the other way around is a better idea, for the reasons I already
> stated, and, short of some evidence of actual problems, the best reason,
> I think, is that not doing so essentially guarantees that you will not
> be able to get help from people on this list at least, which to me is a
> rather poor risk/reward scenario, as I don’t see any upside. Whether
> the lack of a single compiler is for technical reasons or otherwise, I
> really don’t know, but it seems awfully unlikely to me that it is the
> former, partly because, in the end, it’s all just C code running on the
> same machine, and there aren’t different calling conventions, et. c.
> between user mode and kernel mode, et. c., and considerably bigger
> problems have been solved than this. I also think it’s unlikely because
> I just can’t imagine that Microsoft would be looking to advertise that
> the version of CL you a lot of money for doesn’t work for everything,
> but the one that’s very commonly free (on connect.microsoft.com) does
> work for both, as it doesn’t appear to be like the joke version of MFC
> that comes with the WDK. If one wants to get in to that sort of
> conspiracy theory thing, the other way - the free one is limited makes a
> lot more sense, but I’m not sure how one would go about that even if one
> wanted to do so, short of legitimate sabotage, limiting the conversation
> to ‘C’ only. With ‘C++’ there are some options, and the linker, sure,
> but that’s never come up as an issue.
>
> In any case, Don already gave you good advice - there’s no reason to do
> this, and use DDKBUILD.BAT.
>
> Good luck,
>
> mm
>
>
>
> xxxxx@gmail.com wrote:
> > thank Don Burn .
> > But , I want to know VC’s cl.exe and DKK’S cl.exe this two file is same
> ?
> >
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
It is much better to use WDK’s cl.exe for this 
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> Can i use vc2003 or vc2005’s cl.exe generate driver sys file ?
>
> But , I want to know VC’s cl.exe and DKK’S cl.exe this two file is same ?
Nearly, the only difference is minor build numbers.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> As far as using the WDK in user mode goes - that is fine if what you want to
develop is a command line application.
UIless DLLs (which can contain the product core) are also OK for WDK.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Not long ago top driver engineers and high profile companies refused to use the built in DDK compiler because of nasty code generation bugs it had and Microsoft would not provide a patch for years until the arrival of the WDK. Before the WDK, VS 2005 was known to fix the code generation issues and not known to have any code generation issues itself. VS 2005 was widely used for building drivers, moreso than most people realize. Our company made a policy to use VS 2005 only and charge customers at least 3 times more for maintenance cycles if they did not want VS2005 builds. Some paid more, though most agreed VS 2005 was the way to go given the DDK compiler produced bad code and the conditions that triggered them were never defined. At the end of the day, driver quality was just more important than adhering to broken things. Going forward however the WDK seems a good choice towards driver quality, but it wasn’t always that way.
I think I either know of or know personally just about all the “top driver engineers” and this is news to me. Quite frankly, any code-generation bug you’re referring to would have to be the result of a very narrow special case, given that the entire operating system and every Microsoft-built in-box driver is built with the compiler that ships with the DDK.
So, I’m having trouble believing your story. Cite some REAL evidence, please, and not just nonsense.
While every tool chain has bugs, and I’m not saying the DDK tools are any exception, I don’t think posts with sweeping generalizations (“VS 2005 was widely used…”) and vague horror stories about code-gen bugs shed much light on the overall issue.
Peter
OSR
>and this is news to me. Quite frankly, any code-generation bug you’re
referring to
would have to be the result of a very narrow special case,
Such bugs really occured in 1997 in MSVC5 without SPs, but usually a very minor
source code change fixed them. With SPs installed, MSVC5 was no more buggy.
Never heard about such bugs in DDK compiler.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
>
>
> I think I either know of or know personally just about all the “top driver engineers” and this is news to me. Quite frankly,
> any code-generation bug you’re referring to would have to be the result of a very narrow special case, given that the entire
> operating system and every Microsoft-built in-box driver is built with the compiler that ships with the DDK.
>
Peter,
The DDK 3790 compiler is v.13, that is more or less same as in VC 6.
WDK 6000+ compilers are v.14 - same generation as in VS 2005.
One can find the list of issues fixed in v.14 in the VC related resources;
some serious issues were reported here and in development.device.drivers,
such as 64-bit multiplication bug reported by Cristalink.
It’s good to know that both compilers now are aligned.
Regards,
–PA
>
> So, I’m having trouble believing your story. Cite some REAL evidence, please, and not just nonsense.
>
> While every tool chain has bugs, and I’m not saying the DDK tools are any exception, I don’t think posts with sweeping
> generalizations (“VS 2005 was widely used…”) and vague horror stories about code-gen bugs shed much light on the overall
> issue.
>
> Peter
> OSR
>
>
>
>
Slightly related to compiler choice, it seems to me that every time the
compiler changes it is necessary to re-test each project. All our
development tools (user mode and kernel mode) get updated now and then and I
have learned not to rush into using the new versions until I have time to
te-test all our active projects. I worry about the inactive ones, knowing
that a “quick fix” if it is ever demanded is likely to be frustrated if the
tools have changed. Often it does not seem easy to have multiple versions of
tools installed, so it is not always easy to switch to an old project for
quick update. Ideally all projects would have their own build tools as part
of the project. BTW I am not saying the compilers actually have problems,
just that I find it hard to code without the occasional assumption about how
the compiler works. There are also many issues arising from the optimiser,
again often (but not always) my bad assumptions. So when I get an email
telling me to update the WDK for all projects I shudder to think how much it
would cost actually to do that. M
The DDK 3790 compiler is v.13, that is more or less same as in VC 6.
WDK 6000+ compilers are v.14 - same generation as in VS 2005.
One can find the list of issues fixed in v.14 in the VC related resources;
some serious issues were reported here and in development.device.drivers,
such as 64-bit multiplication bug reported by Cristalink.
It’s good to know that both compilers now are aligned.
Regards,
–PA
<
This is logical. It’s the reason that you don’t change tool chains in the middle of a development project.
Personally, I’m more concerned about the compiler deciding some previously allowed syntax is an error (and failing to compile one of my project modules) than I am about code-generation issues when changing compilers.
In my experience, code-gen issues are VASTLY over stated… sort of like CPU instruction bugs. They happen, but in most cases they turn out to be some weird edge-condition that the dev didn’t really understand or anticipate in the first place (like not declaring a variable volatile or whatever).
MAYbe. Remember: The compiler/linker that comes with the DDK/WDK is an internal Microsoft build that’s been adopted by the Windows tools/build team (actually, adopted by one specific guy who’s been responsible for this sort of thing for several years). It does not necessarily correspond to any compiler that’s part of VS. It could have other fixes, other features, or other (obviously) bugs.
Again, to be sure I’ve been clear (I’m sorta jet lagged this morning): I’m not saying that there haven’t been, or that there aren’t, bugs in the DDK/WDK tool chain. There’s bugs in ANY software (duh!). All I’m saying is, statements such as “top driver engineers and high profile companies refused to use…” or “VS 2005 was widely used for building drivers, moreso than most people realize” (how does the poster know what “most people” realize) is annoying and ridiculous on its face. Sounds like something written by somebody in marketing. “top driver engineers”?? Puluuullllleeeezzzzz!
Peter
OSR
“Mike Kemp” wrote in message news:xxxxx@ntdev…
> Often it does not seem easy to have multiple versions of tools installed, so it is not always easy to switch to an old project
> for quick update. Ideally all projects would have their own build tools as part of the project.
This is where virtual machines are very helpful.
You can package your complete development system,
including the OS and backup it for later.
Rergards,
–PA
> in the end, it’s all just C code running on the same machine,
and there aren’t different calling conventions, et.
…apart from the fact that the code is not always the same…
For example, when you call a user-mode function in your module, you can always put caller and callee to the same section, i.e. TEXT - although one can have multiple code sections in his app,
there is no objective reason for requesting something like that from a compiler when you build an app. However, a driver may have its code in INIT and PAGE sections for very good and objective practical reasons. Therefore, the very first “danger” of using VC that comes to one’s mind is that VC’s version of CL may be not-so-well suited for handling cross-section calls (please note that I am not saying this is the case - I just highlight the theoretical possibility)…
Anton Bassov
VMs are great if you really have to archive the OS as well. But even outside
of VMs, just putting your toolchain into your source code control system (or
is it a configuration management system?) accomplishes 99% of the task of
guaranteeing a reproducible build environment. Working out a mechanism for
archiving/installing/running multiple release trees with their toolchains on
both build and developer systems running a range of os releases is pretty
fundamental to a serious development organization.
On Feb 10, 2008 9:57 AM, Pavel A. wrote:
> “Mike Kemp” wrote in message news:xxxxx@ntdev…
> > Often it does not seem easy to have multiple versions of tools
> installed, so it is not always easy to switch to an old project
> > for quick update. Ideally all projects would have their own build tools
> as part of the project.
>
> This is where virtual machines are very helpful.
> You can package your complete development system,
> including the OS and backup it for later.
>
> Rergards,
> --PA
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy