Building drivers with Visual Studio 2022

Is vs2022 supported for building drivers at this time and if not is there an idea when it might be? It is surprising the WDK download page has no mention of vs2022 either way as guidance for developers.

vs2022 is the first visual studio ever that is 64-bits. VS can run in a web browser so you can develop code without installing anything. Quite a few other nice features included.

There will be a new WDK that works specifically, and solely, with VS 2022. As of this writing, it has not yet been released (VS 2022 was only released today)… but I expect it to be released soon.

The new WDK will bring with it new features as well as some new restrictions. Having said that, I’m expect we here at OSR will be sticking with the VS 2019 Windows 11 WDK for “a while.”

Peter

1 Like

vs2022 is the first visual studio ever that is 64-bits.

That has exactly zero impact on a developer’s life. It’s an implementation detail, not a feature.

Driver writers generally do not want to live on the cutting edge, because the cost of even a small compatibility problem is so high.

2 Likes

Do yourself a favor and switch to the latest EWDK toolset for building
drivers. These releases are all ‘LTS’ and do not suffer from the plague of
chronic iteration update syndrome that has enveloped most software
development.

You can even rid yourself of the massively bloated Visual Studio and use
something reasonable like vscode or emacs or whatever source editor floats
your boat.

Mark Roddy

1 Like

The EWDK can be a massive simplification, and is greatly under appreciated and under utilized.

Having said that, if your Solutions include both drivers and (anything but the simplest) user-mode code, the EWDK is not a solution that’ll work for you.

Peter

So in the case where, for example, you have .net projects and driver
projects, just separate those into two ‘solutions’ and build them with
their appropriate toolsets. The build requirements for .net and the rest of
modern userland is vastly different from the requirements for legacy c/c++
driver and service development. Mixing those two is generally a Real Bad
Idea.

Mark Roddy

1 Like

@Tim_Roberts said:

vs2022 is the first visual studio ever that is 64-bits.

That has exactly zero impact on a developer’s life. It’s an implementation detail, not a feature.

It seems you are only thinking in terms of address space, but not considering x64 speed improvements. People who don’t examine machine code or were not there at the time may not know that when AMD invented x64, they didn’t just add address space. They also added a bunch of brand new CPU registers to the instruction set. Everyone knows the more you can do in registers the quicker your code will be. And 64-bit wide registers also offer more performance advantages over 32-bit registers. Thus, it is no surprise that going 64-bits MS boasts faster loading and better UI performance, attributes people here have complained of on numerous occasions. Thus, vs2022 being 64-bits offers a compelling feature for driver developers who are tired of waiting 10 seconds for their 10K driver project to load.

Visual Studio is slower than a turtle stampeding through molasses on a cold winter day not because it is 32bit, it’s because they insist on creating impossibly sized data structures as “features” and then dig through those for every project/ solution load. It’s not uncommon for a project .vs file to be hundreds of megabytes, sometimes gigabytes in size.

Moving to 64bit, or 128bit, or 256bit won’t affect solution/ project load times one bit because those huge “feature” databases live on the disk that gets read back and forth; the biggest performance increase you can do is get a fast SSD or a memory cache such as PrimoCache. Same with build times; the bottleneck isn’t in the address space, it’s in the disk thrashing and same solution; fast SSD or memory cache

Given MS’s track record as of late with releasing development studio’s (such as this [ https://community.osr.com/discussion/292924/rtlstringcchprintfexw-vs-snwprintf ] or the bug that OSR found with ExAllocatePool2 where a block of memory that was supposed to be cleared wasn’t and for software releases in general, like Win11 being released with expired cert’s on some of it’s programs, I’m looking forward to VS2022 about as expectantly as I am the next change in the tax laws …

VS2019 has been out for almost four years now and is still getting nearly weekly updates as they fix things; I’m glad that you’re going to be using VS2022 so that you can step on all the landmines rather than me. I’ll probably shift to it a) when it has a feature that actually makes a difference and b) after a few dozen updates are under it’s belt …

We (OSR) are usually among the earliest of adopters, so we can let the community know “how it goes” and… well… just cuz it gives us something new to play with.

But we’re going to be holding off moving to VS 2022 for “a while.”

Peter

The fact that MSFT release frequent updates to VS 2019 does not really imply that it is any buggier than any other software. It simply means that they release frequent updates.

" The fact that MSFT release frequent updates to VS 2019 does not really
imply that it is any buggier than any other software."

The entire industry is obsessed with continuously releasing updates to
everything. It isn’t that VS is particularly buggy, instead software
engineering has been infected with a process-virus formerly known as
‘agile’.

Mark Roddy

1 Like

What Mr. Roddy said.

This continuous release shit is a curse. Maybe it’s awesome for some amusing web app. But when it impacts your fundamental tools, and causes you to have to reboot your machine once a week as an added bonus, it’s ridiculous.

Peter

Nothing is more disruptive than windows updates. Updates can break fundamental contracts with device drivers and invalidate testing without notice. Updates rudely shut off machines without giving the user a chance to stop it from happening resulting in data loss of running apps. How is this acceptable? Windows updates also have the audacity to turn on a machine arbitrarily if they so choose. Again, how is this acceptable? Windows updates as a whole are unwelcome and show a lack of care and lack of ability to get it right the first time.

VS updates on the other hand are welcome. They often add improvements that are noticeable and worthwhile. Over the last year for instance they slowly rolled out c++20 language features rather than waiting a year and dumping them all at once. Thus, we were able to start benefitting early on each incremental improvement. Unlike Windows, VS updates are totally optional, come with clear and easy to read release notes, and are performed only by specifically clicking if and when you want to update.

This is a very strange thread. Microsoft announced they made vs2022 faster, something everyone wished for, and oddly that angered a lot of folks to jump in and start bashing away.

I also want to add a voice that not everyone likes the bad old days of non-visual studio development or the EWDK incarnation of this dinosaur methodology. Hey, some may prefer going back to a Dos prompt and running edlin. More power to you. Most I would imagine have moved forward and tapped into many productivity advantages developing drivers using VS. I have done both and am firmly in the latter group.

I agree completely except for the word ‘engineering’. Engineering is not being done when a new release updates the icons and the colour scheme.

“I also want to add a voice that not everyone likes the bad old days of non-visual studio development or the EWDK incarnation of this dinosaur methodology. Hey, some may prefer going back to a Dos prompt and running edlin. More power to you. Most I would imagine have moved forward and tapped into many productivity advantages developing drivers using VS. I have done both and am firmly in the latter group.”

I kind of like VSCode a lot. I see no reason why I need Visual Studio at all for driver or service development. And if I was writing web/cloud app/stack shit the bloaty studio is also about the last tool I would opt for. The point is that what ide you are fond of really ought to not depend on what tools you are building with.

1 Like

@Rourke that’s a classic “straw man” argument, you know? We complain about VS updates, and you counter that Windows Update is terrible. Awesome point.

It is hard to argue, I think, that having a big, powerful, IDE that does “everything” is not convenient. It certainly is. As I have said many times before, I am totally addicted to ReSharper for C++ and my code is better for it.

But I’m sick to death of the constant updates, of never being able to count on the behavior or usability of the strange, obscure, and annoying pile that is Code Analysis, and the random breakage of vital components in my tool chain. I’m tired of the constant regressions in the IDE, where parsing breaks, chroma-coding fails, or some weird situation or another requires that I exit and restart the IDE for a given Solution.

I don’t like building my drivers with arbitrary, ever changing, versions of the compiler… a version which is not the same one that was used to build the operating system. I don’t like headers and libs that are “shared” changing arbitrarily.

The WDK is saddled with this mess, and trying to get what should be little things fixed requires negotiation with the behemoth that is “the people who own VS.”

Having tried vscode, the only things I can say in its favor are it’s extensible, and it’s not vim.

In short, I think MSFT has fucked-up VS and CA… making it all things to all people but not really ever fully working for any one use. And the WDK get layered, like peanut butter, on top of this pile. And it makes it hard for me to get my work done.

Is the VS editor, with ReSharper, better than CodeWright or SlickEdit (what I used to use before VS)? Tough call, but probably. Does that make it a joy to use on a daily basis? Not even close.

Peter

@Mark_Roddy
Are you using EWDK with VSCode ? If so would you mind telling me what I need to configure so that VSCode has access to the additional headers etc. ? As currently it automatically falls back to my VS22 install for includes and the compiler.

PS: I am currently trying to get my hands into Driver development and test some stuff. I had to update to VS22 to get some .NET features that are not available in Rider yet and also VS is super slow and creates super big index files etc. So I am not super familiar with the whole WDK environment.

One very large problem with the constant stream of updates is that it makes the whole regression testing thing much more difficult … if there is a new problem found, is it the fault of the driver or a new “feature” of the OS? Before you immediately say “driver”, let me remind folks of the break that required _NO_CRT_STDIO_INLINE to fix, or the “allocate and clear” function that the OSR folks found didn’t exactly “allocate and clear”. Now I get to have to verify that the compiler isn’t broken in addition to verifying the driver isn’t broken …

The new “update daily” thing is especially vexing with a device driver in the medical or industrial automation space, where you need to be able to reproduce that exact binary that produced the driver a bug was found in, sometimes years after it was shipped, to do proper regression testing. Back before Windows began to upgrade incessantly (and, as pointed out, if you like it or not) and VS joined the upgrade of the week club regression testing was relatively easy: use a VM to build the final production driver, once it gets signed box up that image and spin it up as needed

Now, however, you need to watch the machine carefully because as soon as it starts up it will phone home and try to update itself, polluting the image. No problem, you say, simply air-gap the machine and that indeed fixes the problem … until you try to debug it and need to get at the MS symbol server, which required the internet and oh look, there’s another update forcing its way onto the system …

I’m already getting folks asking “when are you going to start using VS2022” and my response is a curt “when VS2022 has a capability that VS2019 does not and which I need to make forward progress on the project” …

… sigh …

@Max1338 said:
@Mark_Roddy
Are you using EWDK with VSCode ? If so would you mind telling me what I need to configure so that VSCode has access to the additional headers etc. ? As currently it automatically falls back to my VS22 install for includes and the compiler.

PS: I am currently trying to get my hands into Driver development and test some stuff. I had to update to VS22 to get some .NET features that are not available in Rider yet and also VS is super slow and creates super big index files etc. So I am not super familiar with the whole WDK environment.

There are two issues here:

  1. building your code using the EWDK in VSCode.
  2. ‘intellisense’ for editing your code inside VSCode.

Not sure which one you are asking about, maybe both? Anyway, I’m -slowly- working on a github repo that will doc how to do both of these things, and also how to use github to build your drivers either using github build agents or your own build agents.

The short answer to (1) is ‘write a simple bat or psh script to run msbuild within the EWDK build environment’. (2) is more complicated.

1 Like

@craig_howard said:
One very large problem with the constant stream of updates is that it makes the whole regression testing thing much more difficult

Windows updates make the situation you describe far more difficult and severe. VS updates are optional, windows updates are often force fed onto machines without notice and are known to break drivers quite badly, even if such drivers follow all best practices and have been fully tested and certified a week ago.

I’m already getting folks asking “when are you going to start using VS2022” and my response is a curt “when VS2022 has a capability that VS2019 does not and which I need to make forward progress on the project”

All I can say is I feel sorry for you. I for one look forward to every single vs update and often find in them great ways to improve productivity. The language and features just keep getting better. Productivity and driver quality go up.