Is vs2026 supported / recommended for driver development? Besides development environment benefits, the new compiler has also been improved to generate faster code.
Very, very few drivers have algorithms complicated enough to benefit more than trivially from optimizer enhancements.
If I recall at the advent of x64 you also felt the need to immediately blurt out to everyone that 64-bit drivers wouldn't see improved performance over 32-bit. This didn't age well. At that time you seemed to be thinking only in terms of 64-bit math and didn't seem to factor in that x64 offered an improved instruction set with more efficient calling conventions and more registers that gave every driver a welcome boost. Similarly in this case you don't seem to have the slightest idea in what ways the vs2026 compiler code generation has been improved, yet bizarrely yet again you feel the need to immediately blurt out an opinion to everyone that it won't matter. Once again this opinion might not age well. Perhaps if you compare assembly outputs and/or do some profiling before making such a statement it would be more helpful to the group. Many developers welcome even trivial performance improvements because they are just a free recompile that happens under the covers.
Well you seem like a very pleasant person.
As usual VS has been released without integrated WDK support. Driver development is not prioritized, and support generally lags behind the public release of new versions.
It might work. I suggest you spend your time answering your own question.
1 Like
The WDK never supports a new Visual Studio right away. Since each WDK only supports a specific Visual Studio version that makes sense. Once 2026 stabilizes Iām sure we will see the WDK transition to it. When that will be though no one knows. I feel like it was quite a few months before we got one that supported Visual Studio 2022.
One thing that is true, not just for this version but all versions, is that the better the code is in the first place, the less a compiler can improve it by optimizing 
And when I say better, simpler from an abstract syntax tree point of view might be a better way to put it.
the nature of systems programming, including drivers, means that they seldom have complex AST, and provide correspondingly fewer opportunities for optimization.
Another sort of optimization is via newer instruction usage. which is also of limited applicability because most of those instructions relate to floating point and drivers rarely do those kinds of operations
Another reason to want to use new tools would be language features. But probably most drivers would compile with 20 year old compiler versions, and I for one donāt use anything except very standard and obvious C code so thatās not very compelling either.
but there is nothing stopping you from using the new compiler. or the old one from the new GUI. you just have to know how to call the right tools with the right parameters
Well you seem like a very pleasant person
Well thank you because yes I am a very pleasant person, apparently far more than you. Please keep this a technical discussion. Valid technical comments are welcome here, snide personal remarks are not.
I suggest you spend your time answering your own question.
And that's exactly what I am doing--some on my own, some asking here. In that regard let me share something. On the very day VS2026 was released, there was coincidentally a curious update made to VS2022. The release notes for this update state "updated Windows Driver Kit tools to support upcoming 26H1 release." I also contacted Microsoft insiders, but I will let them make any official statements.
...correspondingly fewer opportunities for optimization.
Drivers offer many areas for optimization. For example, the way many drivers arrange bytes and build/extract from packets poses areas compilers can improve code. USB drivers can get a lot out of a better optimizing compiler. I donāt know about others, but when I make code changes I often spend time looking at assembly listings as part of the art of perfection. For example these days we can get more work done at compile time by using constexpr and itās nice to see the compiler plop the answer in one assembly instruction eliminating complex runtime assembler code. I also compare output from different compilers for further code validation. Compilers are like engines. Some engines are very strong, others not as much. gcc for example is a very good engine. Not many people may know how much better gcc is at optimizing compared to vs2022. This can be easily verified online if there are any doubts. Thus, the headroom for driver code optimization going forward is very bright both from the optimizing compiler and better utilizing the latest language features. I have a lot of years of experience and assembly listings that back this up. Many customers care about performance. Thus I look forward to what the new vs2026 optimizing compiler may bring to drivers, no matter how small it may be because it's free.
Iām sure you do look at assembly listings. Iām sure I do too
Iām sure you do use multiple compilers and compare the results. Iām sure I do too
Iām not sure that I agree with your conclusions. Shifting work to compile time is an obvious goal, but Iām not sure why you think constexpr aids in achieving it.
Drivers have relatively fewer choices for memory layout that other kinds of code. They have to interoperate with hardware and other KM components with an established ABI. That binary interface limits what a compiler can choose to do. The same is true when it comes to optimizing across function calls and other so called whole program optimizations. And the profile guided optimizations arenāt generally applicable either
I certainly care about performance, but I have not found that any particular compiler makes nearly as much difference as the algorithms used in the code itself. And in my experience, new language features have never helped with runtime performance. They can help to reduce the propensity for developer error, and they usually make the code shorter, but they often hide performance penalties - especially for less experienced developers.
I spend most of my time these days reviewing code from others rather than writing it myself, so my priorities might be different from yours
Iām not sure that I agree with your conclusions.
I appreciate your input, but reading things you have said the reason seems obvious and understandable: you know little about c++. See further comments.
Shifting work to compile time is an obvious goal, but Iām not sure why you think constexpr aids in achieving it.
You should have googled what constexpr means before making such a comment.
And in my experience, new language features have never helped with runtime performance.
You are falling way behind:
- The optimizer and your customers will love you for using c++23's [[assume]]. Grok calls it "a hidden gem with huge perf wins in hot code." What is your experience?
- Starting with c++23 a function can return a value -or- an error code, not have to have space to return both like the old days. This offers improvements in efficiency and readability without throwing exceptions. Great for drivers. Especially cool since drivers are shackled with things like if A works do B and if B works do C and if C works do D, all the while returning back error codes. Today such constructs can get so nested and ugly that some resort to using goto. Finally c++ offers a new construct that perfectly expresses this typical driver paradigm. Grok calls it "a game changer." All new code is expected to use it for error handling. What is your experience?
- I appreciate even small things c++23 brings like the new byteswap function, a driver level workhorse. And it enjoys every single advantage over the alternatives: it's portable and can be used with any compiler, it's constexper so more evaluations can be made at compile time, and it works automatically with all integral types versus needing to hand pick from a hodge podge of legacy C _byteswap_xxx functions. Net result is better code readability, better performance potential, and portability to boot. What do you prefer for swapping bytes and how does it compare?
- The above is only a tiny sampling. The amount of new language features for making high performance drivers is way too long to list. And more come out all the time. The key question you need to ask yourself is why are your peers getting so much out of a language you have failed to find even one single way to benefit from yourself? I mean not even one? There is something wrong here.
I have not found that any particular compiler makes nearly as much difference as the algorithms used in the code itself
Certainly true, though everyone should be using the best algorithm for the job. If you are dealing with a lot of cases where sub-par algorithms are chosen and need scrapped, people should be fired. When using good algorithms like a good organization will do with good engineers, processes, benchmarking, and profiling then it will be more observable the significance that good compilers outshine other compilers. Anyone who thinks vs2022 generates perfect code that cannot be improved upon, think again. This aspect partially inspired this thread.
they often hide performance penalties - especially for less experienced developers.
True of any language. Any language can be misused: C, BASIC, COBOL, doesn't matter. I can swap horror stories about C people. One guy became known for "write only" spaghetti code because no one but him could read it. The argument that c++ "can be misused" is completely irrelevant and a feeble excuse. All languages can be misused, and they are. Modern c++ is focused on 0 cost and efficiency which is why itās so highly prized in drivers.
Now I suspect that attributing personhood was a mistake.
1 Like
This is our current guidance. Please do not use Visual Studio 2026 for Windows driver development at this time. The WDK has not yet been validated with Visual Studio 2026, and compatibility is not guaranteed. Continue using Visual Studio 2022 for all driver development. We will update this page when Visual Studio 2026 is officially supported by WDK.
1 Like
if you want to have a discussion about technical merits, Iāll bite.
If you want to tell me what I donāt know, and you have specific reasons, I always want to learn more.
If you want to tell me what you have decided about what I donāt know, I have little interest.
As an example, constexpr implies a deterministic function with no side effects. The compiler may or may not be able to do something with that information. The pre-processor always does something with that information when you write it as a macro. Macros have all kinds of problems, but constexpr is not axiomatically better. Nor can it be said that the scope differences or any of the other language āimprovementsā be said to always be better - the number absolutely trivial property accessors are evidence enough that properties arenāt axiomatically better; and the same is clearly true of goto and other constructs that āeveryone knowsā are bad.
There is a better case to be made for nullptr, but there is a significant case to be made against it too.
I spend more time these days reviewing code than writing it. Part of that means that code that was written by one of the clever developers has to be comprehensible enough to all of the other ones
1 Like
You are about 1cm away from getting your sorry ass banned from this forum. For real, OK?
And let me make some things clear to you that is apparently not clear already:
- Mr. Roddy was here before there WAS a forum. He has taught and helped, literally, thousands of people write their drivers. He has answered hundreds of questions here. He has given generously of his time over MANY years. You will show him respect, or you will gone from here for good.
- It is not, in any way, shape, manner, or form, up to you to decide what ācomments are welcome here.ā I know, because you donāt work for OSR, I do, and OSR pays the bills for this forum. That makes OSR the only people who determine what is or is not āwelcome here.ā
And, like I said, youāre about an inch from finding yourself in the āunwelcomeā column.
Your disrespect, arrogance, and snark sadly caused some of your more semi-literate comments to be lost. Your comments about some of the desirable C++ 23 language features being desirable are OK, though one could debate whether using most modern C++ language features in a Windows driver is doing the future maintainers of your driver a service. Like it or not, the use of C++ ā even Modern C++ ā in driver code remains controversial, and most driver devs are not highly conversant in C++. Really, the standard for Windows drivers remains C, plus some small C++ things as a ābetter Cā (constexpr, enum class, ranged for, a few others). But, we have to face it: The API is C Language based, and thatās what weāve got.
Until, I guess, we get a fully idiomatic Rust interface for Windows driver development (and I do mean all Rusty, and not a glorified veneer of Rust in a bunch of āunsafeā blocks calling WDF functions).
OK, Iām done. Donāt test my patience again. Please.
By whom, exactly?
Not anyone I know in the Windows driver development community. Not by anyone I know at Microsoft. And surely not anyone in the Linux driver development community.
Which also reminds me of a favorite quote: āthat which is worthless is highly prized by everyone.ā
I am going to address the elephant in the room. I posted a polite topic asking a very good question and it turns into this? Yet everything I posted is true, technically accurate, and I dealt with caustic posters with kid gloves. Some may wonder why Mr. Roberts felt it necessary to make a dejavu dispute without evidence. Or why Mr. Roddy's contribution was to tell me to go away (let's leave it at that). Or why Mr. Bond takes every chance to say c++ does nothing for him. Many readers may wonder what any of this has to do with the critical question: "When can we start using Visual Studio 2026 for driver development?" Furthermore, why are people who obviously don't even care about the question even posting here to begin with? Confused? Well here is the elephant in the room that no one can talk about. Unfortunately for them, there are still a few folks around that made bad decisions and gave bad advice about c++ and now they find themselves in the 21st century stuck with 1970's programming skills and it has become unbearable for them to cope with what could have been. It's like someone clutching a slide rule angrily lashing out because they see someone with a smartphone. Why is it such a big deal to them? Well these people can't take it if someone else gets more mileage out of a language than they did because it shines a light that their careers were not as productive as maybe they could have been and their advice was wrong. It's too late for them now, no going back and they know it so all they can think to do is keep holding the hatch firmly down. Personally I am not a c++ expert or arrogant in the least, but judging by the hecklers I apparently hold my own enough that it makes these people uncomfortable.
Peter asked "By whom, exactly?". Good question. Why not run a poll on how many use C vs C++ these days? Maybe not, could make some uncomfortable.
I want to wholeheartedly thank Microsoft for responding to this thread. They didnāt have to. It was polite and useful, matching the intent of this thread.
You knowā¦ your best move here would have been to just STFU.
But, noā¦ you had to come back, attempt to justify your rudeness, denigrate and speculate on the motives of those senior to you, and throw in a gratuitous āthank youā to Microsoft at the end to show us all what a swell guy you are.
Iām going to say this one more time. Because, apparently, you need it repeated to you in order to enable you to understand it:
I require that you treat Mr. Roberts and Mr. Roddy with respect on this forum.
This is not optional; This is regardless of your viewpoint, your interpretation, or your personal preference. You will treat this as ground truth here.
What this means, in a way that you can directly apply, is that if you disagree with anything that Mr. Roddy or Mr. Roberts say, you (a) need to rethink your position carefully and if you still disagree, (b) not say anything in reply.
Youāve managed to argue with me and irritate me before in this forum. As others whoāve been here far longer than you will know, this is not a recipe that is conducive to longevity or long-term happiness here.
Iāve so far relented from banning you simply because about 1 in 10 posts you make have some measure of useful content. The greater the noise, the more it can drown out the signal. OK?
My best advice to you at this point would be to not reply here further, unless your reply starts with āI want to deeply and sincerely apologizeā¦ā