使用VS编译器和链接器构建Windows驱动程序
每当我重新审视使用 Visual Studio 的编译器和链接器构建 Windows 驱动程序的主题时，我都会想到两件事：
它没有得到官方支持。事实上，整个 Internet 的共识是：构建 Windows 驱动程序的正确方法是使用 Windows 驱动程序工具包中包含的编译器、链接器和构建工具。但是，Visual Studio 2008 包含 /DRIVER 链接器选项，其描述如下：
使用 /DRIVER 链接器选项构建 Windows NT 内核模式驱动程序。它有什么作用？如果不建议使用它来构建驱动程序，为什么将它包含在 Visual Studio 中？它有效。我几乎不敢大声说出这一点，以免招致正义的内核开发人员的愤怒，但事实是，使用 Visual Studio 构建的驱动程序确实有效。我们在我的工作场所多年来一直以这种方式构建它们，生成的二进制文件已部署在数百台机器上，并且没有任何问题。不过，我知道没有证据并不代表没有证据，而且到目前为止没有出现任何问题并不一定意味着使用 VS 构建驱动程序是安全的。
真正让我困扰的是缺乏信息。互联网上有一些使用 VS 构建驱动程序的人的帖子，它们总是得出相同的反应 - 不支持，不要这样做，如果你真的想要的话，可以通过 makefile 项目将 WDK 与 VS 集成使用VS的IDE。然而，我还没有找到任何回复指出你不应该使用 VS 构建驱动程序的具体原因。
那么，有人知道如果你使用 VS 来构建你的驱动程序会发生什么吗？可能会出什么问题？什么情况下？我知道你必须自己设置所有编译器和链接器选项，这没关系，但是如果我设置错误会发生什么？驱动程序是否会编译失败，或者链接失败，或者如果构建良好，它会彻底崩溃还是只有当星星正确对齐时才会崩溃？为什么会这样，是什么原因造成的？除了没有得到官方支持这一事实之外，还有什么理由停止使用 VS 构建我们的驱动程序吗？多年来，VS 一直魅力十足。如果官方不支持，为什么要在VS中放置/DRIVER开关呢？
Two things come to my mind whenever I revisit the subject of using Visual Studio's compiler and linker to build Windows drivers:
It is not officially supported. Indeed, the consensus all over the Internet is that the right way to build Windows drivers is to use the compiler, linker and BUILD tool included in the Windows Driver Kit. However, Visual Studio 2008 includes the /DRIVER linker option, which is described as follows:
Use the /DRIVER linker option to build a Windows NT kernel mode driver.What does it do? Why was it included in Visual Studio if using it for building drivers is not recommended?It works. I'm almost afraid to say this out loud lest I incur the wrath of the righteous kernel developers, but the truth of the matter is that drivers built with Visual Studio do work. We've been building them this way for years at my workplace, the produced binaries have been deployed on hundreds of machines, and there haven't been any problems. However, I am aware that the absense of evidence is not evidence of absense, and that the lack of any problems so far doesn't necessary mean that building drivers with VS is safe.
What really bothers me here is the lack of information. There are a few posts over the Internet from people who use VS to build their drivers, which invariably draw the same response - it is not supported, do not do it, integrate WDK with VS by means of a makefile project if you really want to use VS's IDE. However, I haven't found a single reply which points out a concrete reason why you shouldn't build drivers with VS.
So, does anyone know what would happen if you use VS to build your drivers? What could go wrong? Under what circumstances? I know that you have to set all compiler and linker options yourself, and it's allright, but what happens if I set them wrong? Will the driver fail to compile, or will it fail to link, or If it builds fine will it crash outright or only when the stars align right? Why would it do that, what causes it? Is there any reason to stop building our drivers with VS which has worked like a charm for years, apart from the fact that it is not officially supported? If it is not officially supported, why put the /DRIVER switch in VS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是常识的原因是因为由此产生的缺陷可能很微妙。不过，自从出现实际问题以来，其中大部分都是货物崇拜。如果我没记错的话，那是在 2005 年之前（即第一个包含编译器的 DDK）。如果我错了请纠正我。
一般来说，我没有看到太多反对使用 VS 编译器的言论。对于链接器，您还必须设置正确的子系统值（即无）等等......这很乏味。
但是，请记住，在任何给定时间，WDK 编译器和工具通常都领先于最新 VS 中的编译器和工具。考虑一下：WDK 包含的内容是您可以获取用于构建 Windows 本身的内容的结尾。因此，人们更倾向于使用 WDK 中的工具。
从技术上来说是可以做到的。但是，如果您在新闻组发帖并提及这一事实，那么如果您首先听到有关该主题的课程而不是您的实际问题，请不要感到惊讶；）
The reason this is common-sense is because the resulting flaws can be subtle. Most of this has been cargo cult, though ... ever since there was an actual problem. And if I remember correctly that would have been before 2005 (i.e. the first DDKs at all containing a compiler). Correct me if I'm wrong.
Generally, I don't see a lot that speaks against using the VS compiler though. For the the linker you also have to set the proper subsystem value (i.e. none) and so on ... it's just tedious.
However, keep in mind that the WDK compilers and tools are usually ahead of those in the latest VS at any given time. Consider this: what the WDK contains is a close as you can get to what is used to build Windows itself. Hence the preference for the tools from the WDK.
Technically it can be done. But if you post to a newsgroup and mention the fact, don't be surprised if you first get to hear a lesson on that topic rather than your actual question ;)
这不是将开关插入VS的问题，而是将其取出的问题。
WDK 和 VS 附带的 C++ 编译器/链接器是由 Microsoft 内部的同一团队从相同的源代码库（可能来自不同的分支、在不同的时间点，但相同的源代码库）构建的。他们能否配置其构建，以便
/DRIVER开关不会出现在 VS 提供的链接器中？当然。维护单独的构建配置并检查 WDK 和 VS 是否分别提供了正确的构建变体是否值得？可能不会。至于为什么它最初没有得到官方支持...验证驱动程序开发工具集的专业知识属于 Windows 团队，而不是 VS 团队。 Windows 团队最不想做的事情就是让 VS 版本有资格进行驱动程序开发（Windows 最终也必须帮助支持），而该版本的时间表不符合要求与 Windows 一起使用。
再加上驱动程序开发针对的受众相对较少，并且通过 IDE 构建驱动程序可以提供额外的功能和测试场景，因此对于它没有得到官方支持，我并不感到惊讶。
It's not a matter of putting the switch in to VS, it is a matter of taking it out.
The C++ compiler/linker that ship with WDK and VS are built from the same source base (perhaps from different branches and at different points in time, but the same source base), by the same team inside Microsoft. Could they configure their builds so that the
/DRIVERswitch doesn't appear in the linker delivered with VS? Sure. Is it worth the cost of maintaining a separate build configuration and checking that the right build variants are delivered with the WDK and VS, respectively? Probably not.As to why it isn't officially supported in the first place... The expertise of validating a toolset for driver development lies within the Windows team, not the VS team. The last thing the Windows team wants to do is to be on the hook to qualify a release of VS for driver development (which Windows would ultimately have to help support, as well), when that release is on a schedule that doesn't line up with Windows.
Combine that with the fact that driver development is targeted at a relatively small audience, and building drivers through IDE opens up additional features and test scenarios, and it is very unsurprising to me that it is not officially supported.