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
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.
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
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
@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
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.
@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:
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.
@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.