This file was about 400 lines before we started adding these comments. You might think that's way too much code to do something as simple as finding a few library and executable paths. I agree. However, Microsoft's own solution to this problem, called "vswhere", is a mere EIGHT THOUSAND LINE PROGRAM, spread across 70 files, that they posted to github unironically. I am not making this up: https://github.com/Microsoft/vswhere
Such a seemingly simple problem and yet we have two very complicated solutions. Just goes to show how convoluted things can get at Microsoft scale.
> vswhere is included with the installer as of Visual Studio 2017 version 15.2 and later, and can be found at the following location: %ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe
The irony is that there is absolutely no guarantee that this path is stable so in 2025 I'm sure there will be a wherevswhere.exe
https://www.pcmag.com/news/windows-10-the-last-version-of-wi...: a developer evangelist said it at their Ignite conference in 2015, and a subsequent official statement by a spokesperson clarified the context of that statement in a way that strongly implied that it was indeed official policy at the time, but with the explicit caveat that it could change again (“We aren’t speaking to future branding at this time”).
I know this quote. It was said once and the official statement was neither a confirmation or a denial. Which makes sense because why would Microsoft want to commit themselves either way?
Eh. They're basically right. Windows "11" is just rebranding. There's no reason why it couldn't have been a Windows 10 feature update, except that they wanted to drop support for older hardware.
Why would they store it under the "Installer" path?
This is a pattern that bothers me with Microsoft software on Windows.
They leave the stuff they needed to use ALSO for installer stuff in an installer directory, not under my path, not even in a place I might know of. You could have said
Reminds me of something I read earlier mentioning "design by consortium" where the complexity of something goes up because there's so many people working on it and not enough straightforward documentation
And sometimes (which is I think what most applies to Microsoft) too many authorities that must be pleased and nobody with imperial power to say "In the interests of simplifying, we're going to piss off key stakeholders for a period of time." Microsoft's OS team has, at points in the past, rebuilt data structures from C++ to C with very specific memory footprints rather than break, for example, Photoshop (which was getting more performance from running its own OS structure allocator instead of calling the APIs designed to allocate structures).
Simple ecosystems and simple software usually have the same thing in common: they are either young, or they've recently survived an extinction-level-event. Older systems with many dynamic constraints breed complex webs.
> Simple ecosystems and simple software usually have the same thing in common: they are either young, or they've recently survived an extinction-level-event. Older systems with many dynamic constraints breed complex webs.
At the risk of digression, I wish some of the "small government" crowd would realize this.
Such a seemingly simple problem and yet we have two very complicated solutions. Just goes to show how convoluted things can get at Microsoft scale.