Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


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/


Cmake vs .sln for building drivers?

sn99sn99 Member Posts: 5
edited October 30 in NTDEV

Hi, I am new to minifilters but recently came across a thought about using cmake instead of using .sln for building and signing minifilters.

I found a few projects that might help with it:

At the same time I saw a few negatives around using cmake to compile drivers:

A few points about the projects:

  • I do not intend to modify the minifilter often
  • I made a lot of tweaks in "build configuration" in Visual Studio
  • I do not intend to use linux or any other distro while building and working on minifilter

I see a few cons and pros:

  • cmake makes it easier to have CI/CD
  • You no longer need to use visual studio for dev if you want

But:

  • There is little to no "official" documentation on how to use cmake for drivers from microsoft
  • Microsoft assumes you are using Visual Studio in every article/documentation
  • You can make a lot for more tweaks from Visual Studio build configurations
  • There is a certain "guarantee" that you are doing things the correct way (aka microsoft way) then going off on your own

Overall my gut feelings says to do as Microsoft does it and I will probably run into fewer problems down the line. Cmake feels like an hammer for a screw. But at same time having CI/CD will be nice that is cross platform. The project in questions is fsfilter-rs.

Post edited by Peter_Viscarola_(OSR) on

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,043

    (Moved to NTDEV)

    Peter Viscarola
    OSR
    @OSRDrivers

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,043

    Why not use .sln? I mean... what possible reason would you want to use cmake, when .sln is designed to do the job. You KNOW that you don't have to use VS to build your driver, right? And you don't need to use it as your IDE if you don't like it. You can build from the command line using msbuild, and you can use the Enterprise WDK.

    Peter Viscarola
    OSR
    @OSRDrivers

  • sn99sn99 Member Posts: 5

    @Peter_Viscarola_(OSR) said:
    Why not use .sln? I mean... what possible reason would you want to use cmake, when .sln is designed to do the job. You KNOW that you don't have to use VS to build your driver, right? And you don't need to use it as your IDE if you don't like it. You can build from the command line using msbuild, and you can use the Enterprise WDK.

    Why not use .sln? I mean... what possible reason would you want to use cmake, when .sln is designed to do the job.

    Ah, my current intern requires me to use cmake so I wanted to know is this better or more correct way of doing things or not.

    You KNOW that you don't have to use VS to build your driver, right? And you don't need to use it as your IDE if you don't like it.

    I understand that, I mean changing vcxproj file using "build configuration" is something that is easy to do in Visual Studio. I have nothing against Visual Studio though.

    I do have a question about msbuild: I understand that the flags I see under "build configuration" are the ones that I need to put after msbuild ?

    Enterprise WDK.

    Ah, I guess it should be as simple as this?

    Thanks for help, appreciate it.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,043

    my current intern requires me to use cmake

    While you can do it, the "better and more correct" way of building drivers for a Microsoft operating system is the one that the operating system vendor documents and supports. In other words, .sln, .vcxproj, and msbuild (with our without Visual Studio the IDE).

    Ah, I guess it should be as simple as this?

    Well, I would have said it's as easy as this. But... there's plenty of examples and documentation around.

    Peter Viscarola
    OSR
    @OSRDrivers

  • sn99sn99 Member Posts: 5

    @Peter_Viscarola_(OSR) said:

    my current intern requires me to use cmake

    While you can do it, the "better and more correct" way of building drivers for a Microsoft operating system is the one that the operating system vendor documents and supports. In other words, .sln, .vcxproj, and msbuild (with our without Visual Studio the IDE).

    Ah, I guess it should be as simple as this?

    Well, I would have said it's as easy as this. But... there's plenty of examples and documentation around.

    building drivers for a Microsoft operating system is the one that the operating system vendor documents and supports

    Yep I agree, this was my original thought too but again lack of experience in this field had me second guessing which I don't think is bad in itself.

    My takeaway is:

    • Use .sln, .vcxproj, and msbuild when possible
    • Use EWDK (with msbuild) for CI/CD

    Thanks for the help again, appreciate it.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,403

    Well, remember that cmake is a meta-tool -- it creates vcxproj and sln files and then runs them. (It can also build makefiles, but that's beside the point.) The current process relies on using canned template files, either from sample projects or from the VS IDE, that happen to work, with little understanding of why they work. cmake, if anything, reduces the mystery.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • MBond2MBond2 Member Posts: 494

    Tim

    i'm confused by your comment. Meta tools (tools that make input and then invoke other tools) increase the mystery when the results are unexpected. There is an additional layer of indirection in the error messages at least

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Writing WDF Drivers TBD 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online