14

Microsoft Visual Studio's linker has a /DRIVER flag specifically for building drivers:

Use the /DRIVER linker option to build a Windows NT kernel mode driver.

However, Microsoft says:

You must not build drivers by using the compiler or linker that Microsoft Visual Studio provides.

which begs the question:

Why should I not compile/link drivers with Visual Studio?

Is the output generated by the DDK/WDK tools different from that generated by Visual Studio?
If so, how is it different?

Edit:

Notice that I'm talking about using Visual Studio's compiler and linker, not libraries!

I use the WDK headers and libraries with VS's compilers and linkers, but Microsoft specifically says that I need to avoid this:

You must not build drivers by using the compiler or linker that Microsoft Visual Studio provides.

They didn't even mention headers and libraries, so of course that's not my question.

Why?

Community
  • 1
  • 1
user541686
  • 205,094
  • 128
  • 528
  • 886
  • You can build drivers with Visual Studio, the IDE. You should avoid using the compiler and linker included with Visual Studio. – Roger Lipscombe Jun 05 '11 at 09:56
  • @Roger: Can you be more specific? What's wrong with using the included compiler and linker? – user541686 Jun 05 '11 at 12:56
  • I can't answer that. I was just trying to distinguish between using Visual Studio the IDE and building with the included compiler and linker. There's no need to break out `edlin` to write drivers. – Roger Lipscombe Jun 05 '11 at 14:46
  • possible duplicate of [Using VS compiler and linker to build Windows drivers](http://stackoverflow.com/questions/5340947/using-vs-compiler-and-linker-to-build-windows-drivers) – Hans Olsson Jun 05 '11 at 16:13
  • @ho1: Interesting duplicate, I hadn't seen that before. *However*, I'm looking for more concrete reasons than "Perhaps it's because X." or "Well, are you *sure* you never had a problem with it?! They're usually subtler than you think.", etc. The answers to that question are (IMO) more speculative than anything else, but I'm interested in a concrete answer/example. – user541686 Jun 05 '11 at 19:16

1 Answers1

6

This article put me on the right track, I think. That's because the DDK tools use different runtime libraries than Visual Studio.

Visual Studio will link the driver with the runtime libraries it provides (or optionally, the latest version of the runtime installed on the system), but a driver should arguably be linked with the exact same runtime used to build the operating system itself.

Frédéric Hamidi
  • 258,201
  • 41
  • 486
  • 479
  • That's not how I build with Visual Studio, though -- I use the WDK *libraries*, but the Visual Studio *compiler* and *linker*. Microsoft says I should avoid this, why? – user541686 Jun 05 '11 at 12:57
  • @Mehrdad, are you actually ignoring the standard CRT and explicitly linking your driver with the WDK's `msvcrt_` object file and `MSVCRT` library, as mentioned in the article I linked to? – Frédéric Hamidi Jun 05 '11 at 13:04
  • @Frederic: Yes I am. I'd actually seen that article before myself, but it seems like MS is talking about the compiler and linker, not headers and libraries. – user541686 Jun 05 '11 at 13:14
  • @Mehrdad, okay, scratch the above, I see what you mean. I cannot explain why the compiler and linker would be the culprit here, apart from default parameters. A possible explanation would be that the driver model relies on the internals of a particular compiler in such a way that a driver wouldn't work when built with another compiler. If I recall correctly, that used to be the case for a while with Linux and GCC in the nineties. – Frédéric Hamidi Jun 05 '11 at 13:14
  • @Frederic: By the way, I just noticed something silly right afterwards: I'm not supposed to link with MSVCRT, because it doesn't even exist in kernel mode (I was having issues with the driver, turned out I'd accidentally linked with msvcrt.dll). :P But everything seems to work fine otherwise. – user541686 Jun 06 '11 at 02:07