20.04 WDK is borked if you need to submit a DVL.

I don’t know why you get such bad performance.

I have bad VS performance, too. Maybe not so bad as Tim but bad enough. It takes tens seconds, maybe a minute, I’ve never bothered to measure it as I use it only if there is no other possibility. VS 2017 and it was so since the very beginning even before installing WDK.

I just ran VS 2015 for the first time in several weeks. The splash screen comes up in 2 or 3 seconds (so I exaggerated), but it was 3 minutes before the IDE was ready to accept clicks. That’s not really fair, so I killed it and tried again immediately. The splash screen was up at 0:03, the main window painted at 0:50, and the menu responded to clicks at 1:05. On a processor that’s doing 3 billion operations a second, that’s a heck of a lot of computing.

it was 3 minutes before the IDE was ready to accept clicks

THAT is frightening, and frankly unusable.

Peter

OK, timing Visual Studio launch times beats working…When the WDK first came with VS2015 I found it to be horribly slow and decided that I was way more efficient with SlickEdit and the command line. Newer versions are much better though and I’ve completely lost my passion for that argument.

For example, I just double clicked a solution with two projects and VS2019 was entirely usable in 12 seconds. This system isn’t anything terribly special: Xeon Bronze 3104 1.7GHz, 16GB RAM, 1TB SanDisk Ultra SSD.

Hey, Scott, you’re very experienced developer. You know well “works for me” or “can’t reproduce” isn’t an argument. It always depends. On something which can be very simple or really strange. I’ve seen crazy things and I’m sure you did, too. Everybody involved in this discussion is able to find it out but why bother? It takes time and usually a lot of time. Personally, I’d try it only if I have to use VS every day. Which isn’t a case, fortunately.

I in no way condone, support, or suggest anyone try to root cause their VS performance issues. I am also in no way suggesting that the everyone else is wrong and VS is the greatest piece of software ever written. Just throwing in my experience that while VS being slow used to be high on my list of reasons to dislike VS it is now no longer in the top 10 :slight_smile:

This thread did inspire me to at least install VSCode and see what the fuss was all about. It installs with Dark Mode as the default theme though so it might be a bit to hip for me…

I think I have now finished the derailment of this thread. Stay healthy everyone!

It isn’t really a derailment Scott.

Let’s start with the fact that the WDK continues to be an afterthought
appendage to visual studio, so that crap like the screwed up release of the
20.04 WDK just flies under whatever quality gates are in place.

The WDK, and in fact C/C++ development are not the focus of VS anymore, and
haven’t been for quite a while, and it shows. If you are developing for C#
VS is the right tool. I no longer think that is even remotely true for
C/C++.

The EWDK goes back to what was really good about the last few releases of
the pre-vs-integration WDK: a self-contained toolchain released on a
‘slow-lane’ release cycle, well suited for CI/CD integration (and even
k8-erization), and easily integrated with any code editor/ide.

Mark Roddy

VSCode is pretty hip, for better or for worse. It is an Electron app, which means it is a Javascript web application running inside the Chrome browser. The window itself is owned and managed by Chrome. Ordinarily, that would cause me to laugh heartily at the foolishness, but I have to admit they’ve suckered me in. I find myself reaching for it instead of gvim. I really like the whole project view, and I like that features are discoverable.

@Mark_Roddy said:
It isn’t really a derailment Scott.

Let’s start with the fact that the WDK continues to be an afterthought
appendage to visual studio, so that crap like the screwed up release of the
20.04 WDK just flies under whatever quality gates are in place.

+1

There was a released update to VS2019 that was seriously hosed for building drivers. It was great fun to feel like I was the first person who had ever tried building a driver using that particular toolchain…

The EWDK goes back to what was really good about the last few releases of
the pre-vs-integration WDK: a self-contained toolchain released on a
‘slow-lane’ release cycle, well suited for CI/CD integration (and even
k8-erization), and easily integrated with any code editor/ide.

The EWDK is a great thing. We ended up not using it for CI because it choked on the user mode components of the driver projects we were working on at the time. I don’t at all remember the details but probably worth going back and seeing if things are different these days.

The EWDK goes back to what was really good about the last few releases of the pre-vs-integration WDK

I agree that the EWDK is a good thing. Nobody could argue that.

However, the EWDK is still missing what I valued as the best features of the old (pre-VS-integration) WDK. That is the synchronization of the tool chain with that used to build a given OS release, FREEZING that tool chain in place for the lifetime of a Windows version, and the extensive testing that tool chain received, from end to end, before it found its way into the WDK.

The old WDK included build tools and a compiler and linker that had been tested tens of thousands of times (at least) before release, because it was exercised every day, by every MSFT dev, every time they built something for Windows. And there was ONE actual, specific, guy whose responsibility it was to worry over the features and options in the stable compiler and stable linker, and be certain that those features worked properly to build a working OS (sometimes with secret-sauce in the form of undocumented switches and options, but we’ll ignore this for now). AND there were people who tested the “about-to-be-released” set of OS-version-specific headers/libs with the stable compiler and stable linker to be sure everything worked together, and produced working drivers for Windows.

When a version of Windows was about to be released, the entire tool chain that was used to build that version of Windows was frozen… and THAT was the tool chain that was distributed in the WDK and used to build drivers for that version of Windows forever.

THESE days… you get a random compiler, a random linker, a random set of build tools, and some headers and libs that correspond to SOMEthing I’m sure but I have no idea what. And these tools are improved and gain features at a random rate, and for random reasons. Yes… the EWDK removes this last bit of random change. And that can avoid a source of annoyance and frustration of the “my build environment stopped working sometime between Monday and today” sort, which DOES… I admit… happen frequently.

But when I long for the old days, I long for the long tested, well-proven, One True and Everlasting Tool Chain, for use forever for a given version of Windows.

Peter

And then we have this:

fatal error C1252: Circular or missing dependency between plugins: ‘PREfast Drivers Plugin’ requires GUID ‘{EB170136-3433-4C16-AE1D-8998BA5CAB16}’.

Which is (at least part of) what started this whole mess. Command line, EWDK, or in VS… can’t run SDV no how, no way.

Peter

Have you ever worked with MDAC? All of these complaints are old hat; not that they may not be valid, just that you know, evey other paradigm of devleopement has handled this same problem at some point

Did it ever occur to anyone to report one of these glaring problems to Microsoft and have an expectation they would make a fix?

Did it ever occur to you that some of us talk with the folks at MSFT regularly?

Did you read the link Mr. Roddy posted? Did you not see that it’s BY a MSFT person, who is kindly keeping the community informed of existing WDK issues?

Peter

Actually it isn’t just the 20.04 wdk. At least the prior release also has
the busted dvl.exe. At the moment the only thing working for me is the EWDK
from last year.

And yes I did obviously check to see if this was a known issue. Not that
msft makes it particularly easy to figure that out. (Nor do other closed
source software companies.)

Mark Roddy

It isn’t just start times. It is, in no particular order, and off the top of my head:

  • poor integration with VStudio, for example the WDK continues to not be available like normal components from the installer.
  • over-complicated project templates that make standardized settings for large projects more difficult than they need to be.
  • ridiculous rev locking. I get why I can’t build up-rev WDK projects with down-rev VS, but I should be able to build, without modification, down rev WDK projects with up-rev VS.
  • steering developers to wrong approaches - like for example the awful driver debugging in VS and the awful workflow of that interface.
  • arbitrary UI changes - in VS2019 the ‘Driver’ menu option disappeared from the top menu and migrated to the drop down Extensions menu.
  • gargantuan size of VS. Even the allegedly stripped down toolset of the EWDK occupies 2G.
  • we’ve moved back to a commandline/api world, and away from over-complicated all-purpose gui behemoth apps

Mr. @Mark_Roddy … there is nothing in your list that I do not agree with.

I mean, I personally couldn’t care less about the size of VS or about where they put the “Driver” menu. But your complaints are certainly valid.

What I want and value most, above all those things, is an easy, powerful, and helpful coding interface. This is probably because I am either lazy or stupid… but when I create a function:

     void
     fred(int bob) {
     
     // rest of code here 
    
     }

I love it when my editor tells me that I should probably make it:

     void
     fred(const int & bob) { 
     
     // rest of code here
     
     }

That’s, of course, a ridiculous simplification… but I hope you get my point.

For this kind of help, and an interface that lets me move easily from KM C/C++ to UM C/C++ to UM C# to UM Python or whatever… I’m personally willing to ignore, if not forgive, a great deal.

Peter

but clearly it should be like this so the warnings will have been effecive at improving your style

void
fred(int const bob) {

 // rest of code here

 }

@“Peter_Viscarola_(OSR)” said:
And then we have this:

fatal error C1252: Circular or missing dependency between plugins: ‘PREfast Drivers Plugin’ requires GUID ‘{EB170136-3433-4C16-AE1D-8998BA5CAB16}’.

Which is (at least part of) what started this whole mess. Command line, EWDK, or in VS… can’t run SDV no how, no way.

Peter

Did you ever find a workaround for it? I’m now being hit by it with the latest WDK.

You know that you’re resurrecting a thread that’s long dead, right? And that’s seriously discouraged/frowned-upon/prohibited here?

Especially when there a thread specifically asking people with their experience with the latest WDK.

Post there, please. And I’ll answer your question there.

Peter

(thread locked)