I've built a load of utilities that do that just fine. I use vim as an editor.
The Visual Studio toolchain does have LTSC and stable releases - no one seems to know about them though. see: https://learn.microsoft.com/en-gb/visualstudio/releases/2022... - you should use these if you are not a single developer and have to collaborate with people. Back like in the old days when we had pinned versions of the toolchain across whole company.
> The Visual Studio toolchain does have LTSC and stable releases - no one seems to know about them though.
You only get access to the LTSC channel if you have a license for at least Visual Studio Professional (Community won't do it); so a lot of hobbyist programmers and students are not aware of it.
On the other hand, its existence is in my experience very well-known among people who use Visual Studio for work at some company.
That's not correct. You don't have to give your credit card details or even be logged in but you are still required to have any Visual Studio license. For hobbyists and startups the VS Community license is enough but larger companies need a VS Professional license even for the VS Build Tools.
How strict Microsoft is with enforcement of this license is another story.
You do not need a Professional or Enterprise license to use the Visual Studio Build Tools:
> Previously, if the application you were developing was not OSS, installing VSBT was permitted only if you had a valid Visual Studio license (e.g., Visual Studio Community or higher).
The license doesn't actually permit OSS development. Only compilation of near-unmodified third party OSS libraries.
You may not compile OSS software developed by your own organisation.
The OSS software must be unmodified, "except, and only to the extent, minor modifications are necessary so that the Open Source Dependencies can be compiled and built with the software."
Using VS build tools for open source development is covered by the Community licence [0], separate from this Build Tools licence change. That license is more open than you might expect, working as an individual it even permits proprietary development for commercial purposes.
Under that usage, the Community license counts as a valid Visual Studio license for Build Tools purposes, hence the second paragraph:
> This change expands user rights to the Build Tools and does not limit the existing Visual Studio Community license provisions around Open-Source development. If you already are a developer contributing to OSS projects, you can continue to use Visual Studio and Visual Studio Build Tools together for free, just like before.
That just confirms the parent comment's point. If you're just using the build tools directly, you're fine. If need to develop "with Visual Studio" i.e. the IDE, not just the command line tools, then you need the paid license.
It's actually not. It's complicated, but they're explicitly allowing Build Tools to be used to compile open source dependencies of closed source projects that do not need the MSVC toolchain for proprietary components.
It's why the example they give in the article is a Node.js application with native open source dependencies (e.g. sqlite3).
EDIT: it's clearer when read in context of the opening paragraph:
> Visual Studio Build Tools (VSBT) can now be used for compiling open-source C++ dependencies from source without requiring a Visual Studio license, even when you are working for an enterprise on a commercial or closed-source project.
I wish the post was clearer (though I'm not sure what that looks like). I've made the same mistake interpreting it, then had to go back and reread it a few times.
Well, let's say this is the world view of all companies about open-source software. Then what happens. If people "tend to not give crap" about licenses, all the nice guarantees of GPL etc also disappear.
GPL was made in response to restrictive commercial licensing. Yes is uses the same legal document (a license): but is made in response!
So is propriety seizes to exist, then it's not a problem GPL also seizes to exist.
Also: it's quite obvious to me that IP-law nowadays too much. It may have been a good idea at first, but now it's a monster (and people seem to die because of it: Aaron Swartz and Suchir Balaji come to mind).
There are zero guarantees and commercial software uses GPLd software as parts of their products all the time. Licenses do not work and you shouldn't respect them whenever you can.
The Visual Studio Build Tools are installable with winget (`winget search buildtools`).
There are licensing constraints, IANL but essentially you need a pro+ license on the account if you're going to use it to build commercial software or in a business environment.
I worked with VC++ 6.0 up until Windows 11 when it really, really wouldn't run any more, then switched to VS 2008. The code is portable across multiple systems so it didn't really matter which version of VS it's developed with, and VC++ 6.0 would load, build the project, and have it ready to run while VS 2022 was still struggling through its startup process.
VS 2008 is starting to show the elephantine... no, continental land-mass bloat that VS is currently at, and has a number of annoying bugs, but it's still vastly better than anything after about VS 2012. And the cool thing is that MS can'tfuckwithitanymore. When I fire up VS tomorrow it'll be the exact same VS I used today, not with half a dozen features broken, moved around, gone without a trace, ...
VS2026 is even worse. And if you thought the CoPilot enshittification in 2022 was bad, wait'll you see 2026. We only use it for final builds now, so develop under a bloated but at least not enshittified yet version, then do release builds and testing with whatever the latest version is before shipping.
They've completely reworked release plans. 2026 LTSC will come out a year after the initial VS 2026 release (at the same time as VS 2027) and be supported for 1 more year. You pretty much have to get on the rolling updates train for the IDE, which is why the C++ toolchain now follows a different schedule and you're supposed to be able to install any specific toolchain side by side.
Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... python in another realm here as well. That shiny c++ project that needs a bleeding edge boost version that is about 6 months away from being included in your package manager. Remember patching openSSL when heartbleed came around (libssHELL).
Visual studio is a dog but at least it's one dog - the real hell on windows is .net framework. The sheer incongruency of what version of windows has which version of .net framework installed and which version of .net your app will run in when launched... the actual solution at scale for universal windows compatibility on your .net app is to build a c++ shim that checks for .net beforehand and executes it with the correct version in the event of multiple version conflict - you can literally have 5 fully unique runtimes sharing the same .net target.
> glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow...
If you somehow experience an actual dependency issue that involves glibc itself, I'd like to hear about it. Because I don't think you ever will. The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it: https://lwn.net/Articles/605607/
Now, if you're saying it's a dependency issue resulting from people specifying wrong glibc version constraints in their build… yeah, sure. I'm gonna say that happens because people are getting used to pinning dependency versions, which is so much the wrong thing to do with glibc it's not even funny anymore. Just remove the glibc pins if there are any.
As far as the toolchain as a whole is concerned… GCC broke compatibility a few times, mostily in C++ due to having to rework things to support newer C++ standards, but I vaguely remember there was a C ABI break somewhere on some architecture too.
Glibc has been a source of breakage for proprietary software ever since I started using Linux. How many codebases had to add this line around 2014 (the year I brought my first laptop)?
dlopen and dlmopen no longer make the stack executable if a shared library requires it
I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a "change in glibc that makes things not work anymore". You also can't execute a.out binaries anymore, eh. And I don't think I would call something that affects primarily closed source binaries (and mono on i386) a "huge" issue either.
The fix is trivial ("execstack -s <binary>") and doesn't involve any change to installed versions of anything.
> __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5");
A 12 year old forward compatibility issue that is fixed by upgrading glibc, okay. (Note this is the same timeframe as the s390 thing I linked.) I guess people shipping binaries need to be aware of it if they want to support glibc pre-2.2.14. That said, the general rule of shipping binaries is that you need to assume whatever you build against becomes the minimum required version, anything else is a gift.
I think my point about never pinning glibc stands, and how many other things do you know where you need to go back 12 years to find an ABI break?
A few recent examples: many distros changed the flag for emuTLS on Windows, which gcc implemented as a hard ABI break for no essential reason. If you compile for enough platforms, it will print various notes that various alignments have changed in the struct, which has caused grief numerous times in the past few years for people I work with (many of the changes don’t come with notes, they just change alignment since new hardware comes out that has new features which need more and/or there were bugs previously, so they silently change it). There’s also win32 or posix threading, and sjlj vs structured exceptions, all of which are mutually incompatible. Oh, and then don’t get me started on ARM v6 atomics, which is some weird decided-based-on-compiler-flags-to-record-heuristics-detected-during-configure-of-some-auxiliary-header time, instead of using the current target’s ABI
Sure, the ABI does not change at all, if you know in advance where the landmines are. Though it does have quite few, especially for a large project with a huge surface area
I was talking about glibc; none of the things you mention relate to that. (Note glibc is not used on Windows.) I'm painfully aware of some of the breakage GCC occasionally causes (the atomics fall into that — but to be fair ARMv6 is also >10 years ago at this point, unless you're doing embedded, in which case you generally build the whole system anyway and don't care about these breaks.)
Also, just in case it's not clear, glibc has nothing to do with GCC.
You can have one of "they're so serious about forward and backward compat you should remove version pins because things won't ever break" and "well, I'm not counting intentional breaks" but not both.
I don't know much about glibc's specifics, but in general: Security comes before a lot of things but not before accidental breakage. If you say "our compat guarantees are so strong you shouldn't keep track of versions at all", I expect this to mean that APIs and ABIs will never change, or at least not without a massive awareness campaign and transition plan being announced before - because such a breakage would take out my project or might even introduce new vulnerabilities.
A security update that also does breaking changes is sort of the worst case, because dependents are essentially damned if they apply it and damned if they don't. They can't always be avoided if an API is so insecure it's beyond repair - but then dependents will have to update in their own time because they will also have to fix their own implementations. So this would be an argument for version pins in that case.
> Security comes before a lot of things but not before accidental breakage.
It didn't really sound accidental, though the bugzilla report sounds like they underestimated the impact. But I'm quite sure they were aware this would break at least some old software, it's not like it's hard to understand what exactly is happening here. Old software (or rather, builds) used executable stacks by default, and some edge cases used them for some time after that. I'll say they probably should've done a warning period.
> If you say "our compat guarantees are so strong you shouldn't keep track of versions at all",
What I said was you should never pin a glibc version, not to not keep track of versions at all :). I will admit this is hazy if you build binaries to distribute; in that case you probably want to intentionally use an old glibc. But that's not exactly a "pin", that's a "what's the oldest you want to support". The software being built basically makes no difference; glibc will do what it does, the only limit will be placed by features added in newer glibc versions. The binaries produced from that, running on a new system with any newer glibc, have AFAIK last broken during that S390 incident I linked. (e.g. you wouldn't have gotten executables requiring executable stacks out of a normal GNU tool chain for quite some time by now. It's still possible to intentionally mangle your code and build options to get that result, but you need to either be trying, or do relatively cursed things [like Mono probably some binary loading shenanigans]).
Either way — never pin glibc. And if your cmake or whatever complains about a glibc version conflict, remove the pins and use the newest version involved.
(And about the execstack thing — I'm happy to hear your complaints if and only if you show up with an actual report of breakage that you encountered. No 3rd party phoning. Because what's at question in this case is the actual impact size, which to me seems quite limited.)
> A security update that also does breaking changes is sort of the worst case, because dependents are essentially damned if they apply it and damned if they don't. They can't always be avoided if an API is so insecure it's beyond repair - but then dependents will have to update in their own time because they will also have to fix their own implementations. So this would be an argument for version pins in that case.
That's not how DSO versioning works. Unless it was a horrible disaster, the old functions would remain available, but you'd be required to jump through hoops to build new software against it.
Because glibc ships basically their entire version history in the library binary. That's the thing with DSO versioning.
I do wonder if they could've done some versioning trick with the execstack thing, the problem there is that it's more about global system behavior than actual exposed ABIs. (By the way, libc isn't even what you would be "pinning" there, it's libdl. Splitting hairs though, as that's part of glibc.)
This is the attitude that will always prevent GNU/Linux from becoming prevalent for personal computing. There is a such a lack of empathy for users' hardships and it shows.
When was the last time you actually used. NET? Because that's absolutely not how it is. The. NET runtime is shipped by default with Windows and updated via WU. Let alone that you're talking about .NET Framework which has been outdated for years.
.NET Framework is a Windows system component, but it's been deprecated and Microsoft is moving away from it. The modern .NET ships as either a downloadable runtime/SDK, or can be bundled with your application, meaning your app has no dependencies.
Yes and in the wild believe it or not you'll find windows 7 and windows 8.
We had just deprecated support for XP in 2020 - this was for a relatively large app publisher ~10M daily active users on windows. The installer was a c++ stub which checked the system's installed .NET versions and manually wrote the app.config before starting the .net wrapper (or tried to install portable .NET framework installer if it wasn't found at all).
The app supported .NET 3.5* (2.0 base) and 4 originally, and the issue was there was a ".NET Framework Client Profile" install on as surprising amount of windows PCs out there, and that version was incompatible with the app. If you just have a naked .NET exe, when you launch it (without an app.config in the current folder) the CLR will decide which version to run your app in - usually the "highest" version if several are detected... which in this case would start the app in the lightweight version and error out. Also, in the app.config file you can't tell it to avoid certain versions you basically just say "use 4 then 2" and you're up to the mercy of the CLR to decide which environment it starts you in.
This obviated overrides in a static/native c++ stub that did some more intelligent verifications first before creating a tailored app.config and starting the .net app.
I feel for those who have to support an OS no longer supported by the vendor. That's a tough position to be in, not only if a customer comes across a bug that is due to the OS, but it keeps you from advancing your desktop application forward.
You can always have legacy builds for older systems and use shiny new features inside conditional compilation blocks. Or check at runtime and let newer operating systems use the new features. Yes it takes care and a little more testing to keep supporting older operating systems but your users will love you for it.
I’m always kind of sad when a developer says to a customer “your OS is too old. We are dropping you on the floor.”
Point? I’m SRE on .Net project, we have been through 6-8-10 and its cost us about 2ish hours of work each time. As long as you don’t get crazy, .Net upgrades is just matter of new SDK and runtime and away you go.
This was a sidecar application distributed by literally millions of installs per day - so having a 25MB "self contained" build was out of the question - we were targeting KB-sized distributables not 10's of MB.
>Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath?
That seems more a property of npm dependency management than linux dependency management.
To play devil's advocate, the reason npm dependency management is so much worse than kernel/os management, is because their scope is much bigger, 100x more package, each package smaller, super deep dependency chains. OS package managers like apt/yum prioritize stability more and have a different process.
Since .NET 10 still doesn't support Type Libraries quite a few new Windows projects must be written in .NET Framework.
Microsoft sadly doesn't prioritize this so this might still be the case for a couple of years.
One thing I credit MS for is that they make it very easy to use modern C# features in .NET Framework. You can easily write new Framework assemblies with a lot of C# 14 features. You can also add a few interfaces and get most of it working (although not optimized by the CLR, e.g. Span). For an example see this project: https://www.nuget.org/packages/PolySharp/
It's also easy to target multiple framework with the same code, so you can write libraries that work in .NET programs and .NET Framework programs.
Most likely never will, because WinRT is the future and WinRT has replaced type libraries with .NET metadata. At least from MS point of view.
The current solution is to use the CLI tools just like C++.
However have you looked into ComWrappers introduced in .NET 8, with later improvements?
I still see VB 6 and Delphi as the best development experience for COM, in .NET it wasn't never that great, there are full books about doing COM in .NET.
Because that’s pretty much any freaking thing - oh Python, oh PHP, oh driving a fork lift, oh driving a car.
Once you invest time in using and learning it is non issue.
I do get pissed off when I want to use some Python lib bit it just doesn’t work out of the box, but there is nothing that works out the box without investing some time.
Just like a car get a teenager into a car he will drive into first tree.
Posting BS on Facebook shouldn’t be benchmark for how easy things should be.
This is one of the things that tilts me about C and C++ that has nothing to do with mem safety: The compile/build UX is high friction. It's a mess for embedded (No GPOS) too in comparison to rust + probe-rs.
That hasn't been my experience at all. Cross-compiling anything on Rust was an unimaginable pain (3 years or so ago). While GCCs approach of having different binaries with different targets does have its issues, cross compiling just works.
Ah sorry. I should clarify. Not referring to specifically cross compiling; just general compiling. In rust weather PC or embedded, I run Cargo run. For C or C++, it's who knows. A provincial set of steps for each project, error messages, makes me get frustrated. I keep a set of notes for each one I touch to supplement the project's own docs. I am maybe too dumb or inexperienced in some cases, but I am having a hard time understanding why someone would design that as the UX.
I want to focus on the project itself; not jump through hoops in the build process. It feels hostile.
For cross compiling to ARM from a PC in rust in particular, you do one CLI cmd to add the target. Then cargo run, and it compiles, flashes, with debug output.
These are from anecdotes. I am probably doing something wrong, but it is my experience so far.
I’m the opposite: I want my development tools to use my operating system’s package manager. Nothing enrages me quite like how, when I want to pull in a Python dependency, I have to reach for Python’s parallel package manager. Now I have to keep track of what apt installed and what pip installed. Then I move to do a rust project and there’s now another parallel package manager I need to use to install those dependencies! Yuck!
apt install build-essential or whatever the rpm equivalent is, gets you most of the way to building a C or C++ project.
If I understand correctly, this makes your program and/or its build system tied to an OS. Depending on the details (You mention interpreted and compiled languages), it's not clear if this would provincialize the build only, or running the application as well. (With complications beyond executable ABI compatibility)
My perspective: I want from the OS: An allocator, threading, filesystem support, dates/times, and in some cases hardware access like for GPUs, USB etc.
I do not want my software to be dependent on a specific OS's package manager. I don't want a headache when I change the PC I'm compiling on, and really don't want to deal with a separate package manager for each OS I distribute the application for. Especially so given that there are so many linux distros.
I don't care if my package manager is provided by my OS or by some third party--I only want to deal with one package manager. Currently we have these Matryoshka dolls where there are package managers inside package managers, and each of them manage their own distinct trees of dependencies.
I went from POP OS (Ubuntu) to EndeavourOS (Arch) Linux because some random software with an appimage or whatever refused to run with Ubuntus “latest” GLIBC and it ticked me off, I just want to run more modern tooling, havent had any software I couldnt just run on Arch, going on over a year now.
Indeed. As late as 2 hours ago I had to change the way I build a private Tauri 2.0 app (bundled as .AppImage) because it wouldn't work on latest Kubuntu, but worked on Fedora and EndeavourOS. So now I have to build it on Ubuntu 22.04 via Docker. Fun fun.
Had fewer issues on EndeavourOS (Arch) compared to Fedora overall though... I will stay on Arch from now on.
Well, traditionally, there was no Python/pip, JS/npm in Linux development, and for C/C++ development, the package manager approach worked surprisingly well for a long time.
However, there were version problems: some Linux distributions had only stable packages and therefore lacked the latest updates, and some had problems with multiple versions of the same library. This gave rise to the language-specific package managers. It solved one problem but created a ton of new ones.
Sometimes I wish we could just go back to system package managers, because at times, language-specific package managers do not even solve the version problem, which is their raison d'être.
Nix devShells works quite well for Python development (don't know about JS)
Nixpkgs is also quite up to date.
I haven't looked back, since adopting Nix for my dev environments.
.NET does have flags to include the necessary dependencies with the executable these days so you can just run the .exe and don't need to install .net on the host machine. Granted that does increase the size of the app (not to mention adding shitton of dll's if you don't build as single executable) but this at least is a solved problem.
They do now, after .net core and several other iterations. You'll also be shipping a huge executable compared to a clr linked .net app (which can be surprisingly small).
I have never experienced issues with pip, and I’m not sure it’s whether I’m doing something that pip directly supports and avoiding things it doesn’t help with.
I’d really love to understand why people get so mad about pip they end up writing a new tool to do more or less the same thing.
4. It automatically activates the venv before running commands.
5. It supports a lock file out of the box.
6. It lets you specify the index for private packages. This fixes a major security issue with pip that they continue to ignore.
7. It installs your code in the venv in editable more by default.
8. It lets you install Python tools outside the venv (`uv tool install`).
9. It works reliably.
There's probably more that I've forgotten. If pip had all of that nobody would have felt the need for a rewrite. And if you've never run into any of those issues I guess you either haven't used Python much or didn't consider that there might be a less shitty way to do things.
That’s very subjective. I have ADHD and I’m very sensitive to things that break my flow, but I don’t run pip frequently while I’m writing code, and the couple extra seconds it takes to do its job don’t bother me that much.
> 3. It automatically sets up venvs.
Remember: explicit is better than implicit.
> 4. It automatically activates the venv before running commands.
Again: explicit is better than implicit.
> 5. It supports a lock file out of the box.
Some (me included) would say it’s a bug, not a feature.
> 6. It lets you specify the index for private packages. This fixes a major security issue with pip that they continue to ignore.
This is good - a lot of organisations concerned with that will block access to PyPI altogether and offer a selected cache for approved dependencies. Alternatively you can declare private dependencies as Git URLs with tags, bypassing the need for a private index.
> 7. It installs your code in the venv in editable more by default.
That’s a nice touch, but goes against the explicit/implicit rule- a different behaviour automatically triggered by something environmental.
> 8. It lets you install Python tools outside the venv (`uv tool install`).
I always recommend not messing with the system’s Python.
> 9. It works reliably.
I’ll need you to elaborate on that. I might be used to the way pip works, but it’s been a while since I had it fail to do something I asked without there being a very good reason (an impossible conflicting requirement).
This brings me to another concern - I wouldn’t want Python development to become more like JavaScript post-npm. Every external dependency you bring in must be justified and understood. This goes for simple ones and especially for complex ones with lots of secondary dependencies. Any external dependency you bring is now your responsibility to manage forever. I’m fine not having to reimplement NumPy’s MSE function or Django’s ORM, but I’ve moved away from things like click because they save me just a little extra work at the cost of having to remember it’s there forever.
> And if you've never run into any of those issues I guess you either haven't used Python much or didn't consider that there might be a less shitty way to do things.
Or, perhaps, I’ve been using Python since 1.5 and have a deep understanding of why things are the way they are, having experimented with different ways, and just learned that new and convenient isn’t always the best in the long term.
It's not implicit. When you run `uv run ...` or `uv sync` you are explicitly asking it to automatically set up a venv.
> Some (me included) would say it’s a bug, not a feature.
Some (you included) would be wrong.
> This is good
What is good? That Pip doesn't have a way to avoid dependency confusion? What??
> but goes against the explicit/implicit rule
No it doesn't. It just does the right thing by default.
> I always recommend not messing with the system’s Python.
The reasons to avoid `pip install pre-commit` (outside a venv) are precisely because Pip can't do that in a sane way! `uv tool install pre-commit` suffers from none of the reasons to avoid `pip install pre-commit`.
You definitely have stockholm syndrome. Give uv a try.
Very clearly a better option than continuing to use Pip. Even if they do change the license in a few years I will definitely take several years of not being shat on by Pip over the comparatively minor inconvenience of having to switch to an open fork of uv when they rug-pull. If they ever do.
Continuing to use Pip because Astral might stop maintaining uv in future is stupidly masochistic.
The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit.
And when it inevitably leads to all kinds of weird issues the packagers of course can't be reached for support, so users end up harassing the upstream maintainer about their "shitty broken application" and demanding they fix it.
Sure, the various language toolchains suck, but so do those of Linux distros. There's a reason all-in-one packaging solutions like Docker, AppImage, Flatpak, and Snap have gotten so popular, you know?
> The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit.
This is only the case for debian and derivatives, lol. Rolling-release distributions do not have this problem. This is why most of the new distributions coming out are arch linux based.
Agreed, but I don't think that has to do with either it's "vanillaness" or the 6 month release schedule. Fedora does a lot of compatibility work behind the scenes that distros not backed by a large company more than likely couldn't afford.
> ...every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar.
Applying non-vanilla flavor (patches) to libraries in able to make new packages work with old packages. (It's not just a library thing of course--I've run into packages on Debian where some component gets shimmed out by some script that calls out to some script to dynamically build or download a component. But I digress.)
Maybe I'm just out of the loop here, but I'm not aware of this being a general practice in Fedora. Yes, Fedora does a lot of compatibility work of course, but afaik the general practice isn't to add Fedora-flavored patches.
> with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar.
Quite frankly, as someone started distro-hopping around ~2009 & only stopped around 2020, I have experienced a lot of Linux distributions, as well as poked at a lot of maintainer pipelines — it is simply categorically untrue for the majority of non-Debian derived Linux distributions.
It used to be that a decent number of Linux distributions (Slackware, Debian, RedHat, whatever) put in a lot of work to ensure "stability", yes. However "stability" was, for the most part, simply backporting urgent security fixes to stable libraries and to their last three or so versions. The only system that is very well known for shipping "a decades old version" of a system library would be Debian (or its biggest derivative, Ubuntu), because it's release cycle is absolutely glacial, and most other Linux distributions do give somewhat of a shit about keeping relatively close to upstream. If only because maintaining a separate tree for a program just so you can use an ancient library is basically just soft-forking it, which incurs a metric shitton of effort and tech-debt that accrues over time.
One of the reasons I switched to and then ran at least one single Arch Linux installation for the back half of the 2010s (and used other computers or a dual boot for distrohopping) was partly for the challenge (I used to forget to read the NEWS before upgrading and got myself into at least one kernel panic that way lol), and partly because it was the only major rolling-release distribution at the time. In the last 6 years that's changed a lot, and now there's a whole slew of rolling-release distributions to choose from. The biggest is probably Steam's Holo distribution of Arch, but KDE's new distribution (replacing Kubuntu as the de-facto "KDE Distro") is based on Arch as well, along with I think Bazzite and CachyOS; Arch has always had a reputation (since before the 2010s) for keeping incredibly close to upstream in it's package distributions, and I think that ideology has mostly won-out now that a lot of Linux software is more generally stable and interacts reasonably well (Whereas, back when Pipewire was a thing... that was not the case).
Now, sure, I'm not going to the effort of compiling my decade+ experience of Linux into a spreadsheet of references of every major distribution I tried in the last ten years, just to prove all of this on an internet forum, but hopefully that write-up will suffice. Furthermore, as far as I can see, the burden of proof is not on me, but on `crote` to prove the claim they made.
Also, I get how if you've only ever used Debian-derivatives, all of this may appear to be incorrect. I would suggest, uh, not doing that — if only because it's a severely limiting view of what Linux systems are like. Personally, I've been a big fan of using Alpine's Edge release since before they had to drop linux-hardened and it's a really nice system to use as a daily driver.
The real kicker is when old languages also fall for this trap. The latest I'm aware of is GHC, which decided to invent it's own build system and install script. I don't begrudge them from moving away from Make, but they could have used something already established.
The purpose isn't information, the purpose is drama.
Er, sorry. I meant: the purpose isn't just drama—it's a declaration of values, a commitment to the cause of a higher purpose, the first strike in a civilizational war of independence standing strong against commercialism, corporatism, and conformity. What starts with a single sentence in an LLM-rewritten blog post ends with changing the world.
See? And I didn't even need an LLM to write that. My own brain can produce slop with an em dash just as well. :)
This is actually the scariest part. Because lately even authors and creators who are not using LLM are starting to pick up some of these ways of expressing themselves.
That style of writing has been around forever. LLM's learned it from us. I'd basically call it "American sales pitch". It's a little bit product landing page, a little bit political opinion column, a little bit self-help book or motivational blogger.
It's always been a style of writing that tries to maximize engagement. The issue is that now we see it creeping into areas that never used to use it. It's not how developers tend to write. But now developers toss their original draft into an LLM asking it to "punch it up for engagement" -- or the LLM has just been trained to assume that's what someone wants by default -- and so now it stands out like a sore thumb.
And obviously, it's an appeal to emotion. Whereas developers tend to be looking for just the cold hard facts. So it's doubly off-putting.
Humans invented writing, not LLMs. They are copying us not the other way around. You can’t jump on 1 sentence that vaguely sounds like an LLM and say it’s written by AI. It’s so silly. I understand the aversion to AI slop but this is not that.
people run on heuristics and no amount of our righteousness will change that. the entire article absolutely reeks of LLM style so the original commentor isnt off the mark. to address your point, LLMs are copying that which leads to the most human engagement, so the way you expressed things makes it seem like you are defending junk food as real food. which of course it is, however it is designed to make someone money at the cost of human health. that's not something i'd be defending personally.
I don't think the article "reeks of LLM style" at all. It's actually very obviously written by a human in my eyes, there are several phrases that LLMs would not write. I see this accusation leveled at basically any piece of writing that is long and not very casual now, it just doesn't make any sense.
Had to do this back in 2018, because I worked with a client with no direct internet access on it's DEV/build machines (and even when there was connectivity it was over traditional slow/low-latency satellite connections), so part of the process was also to build an offline install package.
Well - "run as admin" wasn't a problem for that scenario - as I was also configuring the various servers.
(And - it is better on a shared-machine to have everything installed "machine-wide" rather than "per-user", same as PowerShell modules - had another client recently who had a small "C:" drive provisioned on their primary geo-fenced VM used for their "cloud admin" team and every single user was gobbling too much space with a multitude of "user-profile" specific PowerShell modules...)
But - yes, even with a highly trimmed workload it resulted in a 80gb+ offline installer. ... and as a server-admin, I also had physical data-center access to load that installer package directly onto the VM host server via external drive.
No thanks. I’m not going to install executables downloaded from an unknown GitHub account named marler8997 without even a simple hash check.
As others have explained the Windows situation is not as bad as this blog post suggests, but even if it was this doesn’t look like a solution. It’s just one other installation script that has sketchy sources.
You don't have to install executables downloaded from an unknown GitHub account named marler8997. You can download that script and read it just like any other shell script.
Just like those complaining about curl|sh on Linux, you are confusing install instructions with source code availability. Just download the script and read it if you want. The curl|sh workflow is no more dangerous that downloading an executable off the internet, which is very common (if stupid) and attracts no vitriol. In no way does it imply that you can not actually download and read the script - something that actually can't be done with downloaded executables.
> You don't have to install executables downloaded from an unknown GitHub account named marler8997. You can download that script and read it just like any other shell script.
You do because the downloaded ZIP contains an EXE, not a readable script, that then downloads the compiler. Even if you skip that thinking "I already have VS set up", the actual build line calls `cl` from a subdirectory.
I'm not going to reconstruct someone's build script. And that's just the basic example of a one file hello world, a real project would call `cl` several times, then `link`, etc.
Just supplying a SLN + VCXPROJ is good enough. The blog post's entire problem is also solved by the .vsconfig[1] file that outlines requirements. Or you can opt for CMake. Both of these alternatives use a build system I can trust over randomgithubproject.exe, along with a text-readable build/project file I can parse myself to verify I can trust it.
It is somewhat different when your system forces binaries to be signed... but yeah, largely agreed. The abject refusal of curl|sh is strange to me, unless the refusers are also die-hard GPL adherents. Binaries are significantly more opaque and easier to hide malware in, in almost all cases.
Wait till they find out what the Visual Studio Installer itself does :) I guess this person just trusts a big company like Microsoft who keeps their source hidden more than a single developer who publishes all their source?
If any of this is relevant to you, you're already running Windows, which means Microsoft already has root on your machine, which means it's futile to try to limit the extent to which you trust their binaries.
>The curl|sh workflow is no more dangerous that downloading an executable off the internet
It actually is for a lot of subtle reasons, assuming you were going to check the executable checksum or something, or blindly downloading + running a script.
The big thing is that it can serve you up different contents if it detects it's being piped into a shell which is in theory possible, but also because if the download is interrupted you end up with half of the script ran, and a broken install.
If you are going to do this, its much better to do something like:
sh -c "$(curl https://foo.bar/blah.sh)"
Though ideally yes you just download it and read it like a normal person.
I know Jonathan Marler for some of his Zig talks and his work in the win32 api bindings for Zig[0], they are even linked from Microsoft's own repo[1] (not sure why he has 2 github users/orgs but you can see it's the same person in the commits).
Is this post AI-written? The repeated lists with highlighted key points, the "it's not just [x], but [y]" and "no [a] just [b]" scream LLM to me. It would be good to know how much of this post and this project was human-built.
I was on the fence about such an identification. The first "list with highlighted key points" seemed quite awkward to me and definitely raised suspicion (the overall list doesn't have quite the coherence I'd expect from someone who makes the conscious choice; and the formatting exactly matches the stereotype).
But if this is LLM content then it does seem like the LLMs are still improving. (I suppose the AI flavour could be from Grammarly's new features or something.)
It's interesting... Different LLM models seem to have a few sentence structures that they seem to vastly overprefer. GPT seems to love "It's not just X, it's Y", Claude loves "The key insight is..." and Gemini, for me, in every second response, uses the phrase "X is the smoking gun". I hear the smoking gun phrase around 5 times a day at this point.
It's hated by everyone, why would people imitate it? You're inventing a rationale that either doesn't exist or would be stupider than the alternative. The obvious answer here it they just used an LLM.
I think that the style itself is very clear and has its advantages, it's hated only because it's from LLMs, which are not liked when used without judgement (which is often the case).
So, someone who falls on the side of not completely hating LLMs for everything (which is most people), could easily copy the style by accident.
I love the style it was written in. I felt a bit like reading a detective novel, exploring all terrible things that happened and waiting for a plot twist and hero comming in and saving the day.
Real humans write like that though. And LLMs are trained on text not speech. Maybe they should get trained on movie subtitles, but then movie characters also don't speak like real humans.
"LinkedIn Standard English" is just the overly-enthusiastic marketing speak that all the wannabe CEOs/VCs used to spout. LLMs had to learn it somewhere
No, they do it because they're mode-collapsed, use similar training algorithms (or even distillation on each other's outputs) and have a feedback loop based on scraping the web polluted with the outputs of previous gen models. This makes annoying patterns come and go in waves. It's pretty likely that in the next generation of models the "it's not just X, it's Y" pattern will disappear entirely, but another will annoy everyone.
This is purely an artifact of training and has nothing to do with real human writing, which has much better variety.
"What if you can't tell the difference?" Yeah, what if it becomes impossible to spot who's a lazy faker who outsourced their thinking? Doesn't that sound great?!
What's exhausting is getting through a ten-paragraph article and realising there was only two paragraphs of actual content, then having to wade back through it to figure out which parts came from the prompt, and which parts were entirely made up by the automated sawdust injector.
That's not an AI problem, it's a a general blog post problem. Humans inject their own sawdust all the time. AI, however, can write concisely if you just tell it to. Perhaps you should call this stuff "slop" without the AI and then it doesn't matter who/what wrote it because it's still slop regardless.
I completely agree with your parent that it's tedious seeing this "fake and gay" problem everywhere and wonder what an unwinnable struggle it must be for the people who feel they have to work out if everything they read was AI written or not.
It used to require some real elbow grease to write blogspam, now it's much easier.
I hardly ever go through a post fisking it for AI tells, they leap out at me now whether I want them to or not. As the density of them increases my odds of closing the tab approach one.
It's not a pleasant time to read Show HNs but it just seems to be what's happening now.
It never used to be a general blog post problem. It was a problem with the kinds of blogs I'd never read to begin with, but "look, I made a thing!" was generally worth reading. Now, I can't even rely on "look, I made a thing!" blog posts to accurately describe the author's understanding of the thing they made.
I see your point. You need to recalibrate how to decide what to read since the proxy has changed its meaning. I found a similar issue when monetized Youtubers started making things. It used to be amazing to see some hobby project that was a little bit sophisticated but now big stars have lots of money and their full-time job is doing incredible projects just to make videos of them. It's not AI but it's something that didn't used to exist. I'm thinking channels like "Stuff Made Here" and "I Did A Thing" that sound humble but doing difficult, expensive projects that have no purpose except to look good on a video.
I came back around 2017*, expecting the same nice experience I had with VB3 to 6.
What a punch in the face it was...
I honestly cannot fathom anyone developing natively for windows (or even OSX) at this day and age.
Anything will be a webapp or a rust+egui multi-plataform developed on linux, or nothing. It's already enough the amount of self-hate required for android/ios.
* not sure the exact date. It was right in the middle of the WPF crap being forced as "the new default".*
I analyzed the test using Pangram, which is apparently reliable, it say "Fully human Written" without ambiguity.[1]
I personally like the content and the style of the article. I never managed to accept going through the pain to install and use Visual Studio and all these absurd procedures they impose to their users.
These days I'm always wondering whether what I'm reading is LLM-slop or the actual writing of a person who contracted AI-isms by spending hours a day talking to them.
I wish open source projects would support MingW or at least not actively blocking it's usage. It's a good compiler that provides an excellent compatibility without the need of any extra runtime DLLs.
I don't understand how open source projects can insist on requiring a proprietary compiler.
There are some pretty useful abstractions and libraries that MinGW doesn't work with. Biggest example is the WIL[1], which Windows kernel programmers use and is a massive improvement in ergonomics and safety when writing native Windows platform code.
'MinGW' is not GCC; it's an ABI, and from the developer perspective it is also the headers and the libraries. You can have GCC MinGW, Clang MinGW, Rust MinGW, Zig MinGW, C# AOT MinGW.
if you want to link msvc built libraries (that are external/you dont have source), mingw may not be an option. for an example you can get steamworks sdk to build with mingw but it will crash at runtime
From the capitalization I can tell you and the parent might not be aware it's "minimal GNU for Windows" which I would tend to pronounce "min g w" and capitalize as "MinGW." I used to say ming. Now it's my little friend. Say hello to my little friend, mang.
I've been shipping Windows software for 20+ years. Not one project I have ever worked on was based on MinGW. It's a gross hack that is ABI incompatible with the predominate ecosystem.
In the year 2026 there is no reason to use MinGW. Just use Clang and target MSVC ABI. Cross-compiling Linux->Windows is very easy. Cross-compiling Windows->Linux is 1000x harder because Linux userspace is a clusterfuck of terrible design choices.
If a project "supports Windows" by only way of MinGW then it doesn't really support Windows. It's fundamentally incompatible with how almost all Windows software is developed. It's a huge red flag and a clear indicator that the project doesn't actually care about supporting Windows.
If I'm writing some cross-platform bit of software, my interest in supporting Windows is naturally in producing binaries that run on Windows.
Why on earth should I give a flying toss how "almost all Windows software is developed", or which kinds of ABIs are BillG-kissed and approved? Good god. Talk about fetishising process over outcome.
I just eyerolled so hard I gave myself a migraine.
If your focus is on outcome that I promise and assure you that using MinGW will make producing a positive outcome significantly harder and more frustrating.
With modern Clang there really isn’t a justifiable reason to use MinGW.
I think the issues you're referring to are related to C++ ABI which is inherently incompatible between different compilers (and sometimes versions). This can be sometimes issue for plugins, though sane programs always use C wrappers.
I never had issues with C ABI, calling into other DLLs, creating DLLs, COM objects, or whatever. I fail to see what is fundamentally incompatible here.
Yes if you go pure C API and write libraries that conform to this and don’t pass owned memory around then sure that works.
MSVC is ABI stable since 2015. Many libraries that distribute pre-compiled binaries that rely on this stability. ~None of them include MinGW binaries in their matrix. (Debug/release X MT/MD).
Being a good citizen means meeting people where they are. Libraries and programs should expect to be integrated into other build systems and environments. I have literally never ever in my career worked in a Windows dev environment that used MinGW. The ~only reason to use MinGW is because you primarily use Linux and you want to half-ass do the bare minimum.
Interestingly I've never used Visual Studio on Windows (only for a brief time for ARM based PDAs where I could experience the infamous MFC which was okay to me despite the hate).
I've used Borland C++ and Watcom C/C++ back in the day and MinGW after that. Also COM was invented for interoperation between languages/compilers.
Being a good citizen means to not use the inherently unstable C++ ABI directly. You can use C API or even COM for that. Relying on it is cute but it's accidental and it will break in the future. Microsoft can't guarantee that it will stay stable because C++ is always evolving, forcing to break the compatibility.
Open source projects shouldn't depend on proprietary compilers (they can support them, but not as the only option). It just undermines the purpose of it.
The reasons I use MinGW is because it produces better compatible binaries on Windows, allowing me to support all Windows versions from Windows 2000 to latest with a single binary (and sometimes 64bit if there is a need/advantage) and it doesn't require me to bundle dozens of DLLs (or worse, installing them system-wide) and artifically limit the compatibility for no reason.
Breaking the compatibility is hostile to the users who can't or want to always use the latest Windows.
If you need the Windows(/App) SDK too for the WinRT-features, you can add `winget install --id Microsoft.WindowsSDK.10.0.18362` and/or `winget install --id Microsoft.WindowsAppRuntime.1.8`
Having been the person that used to support those packages, it’s not that simple. You need to pass what workloads you need installed too, and if it’s a project you’re not familiar with god help you.
I used to just install the desktop development one and then work through the build errors until I got it to work, was somewhat painful. (Yes, .vsconfig makes this easier but it still didn’t catch everything when last I was into Windows dev).
At $workplace, we have a script that extracts a toolchain from a GitHub actions windows runner, packages it up, stuffs it into git LFS, which is then pulled by bazel as C++ toolchain.
This is the more scalable way, and I assume it could still somewhat easily be integrated into a bazel build.
Keeping CI entirely out of windows desktop development is the biggest efficiency and cost improvement I've seen in the last 15 years. Our CI toolchain broke so we moved back to a release manager doing it manually. It takes him 20x less time to build it and distribute it (scripted) than it does to maintain the CI pipeline and his desktop machine is several times faster than any cloud CI node we can get hold of.
Edit: Uses a shit load less actual energy than full-building a product thousands of times that never gets run.
It starts by not looking into Windows through UNIX developer glasses.
The only issue currently plaguing Windows development is the mess with WinUI and WinAppSDK since Project Reunion, however they are relatively easy to ignore.
>It starts by not looking into Windows through UNIX developer glasses.
People don't need any UNIX biases to just want multiple versions of MSVS to work the way Microsoft advertises. For example, with every new version of Visual Studio, Microsoft always says you can install it side-by-side with an older version.
But every time, the new version of VS has a bug in the install somewhere that changes something that breaks old projects. It doesn't break for everybody or for all projects but it's always a recurring bug report with new versions. VS2019 broke something in existing VS2017 installs. VS2022 broke something in VS2019. etc.
The "side-by-side-installs-is-supposed-to-work-but-sometimes-doesn't" tradition continues with the latest VS2026 breaking something in VS2022. E.g. https://github.com/dotnet/sdk/issues/51796
I once installed VS2019 side-by-side with VS2017 and when I used VS2017 to re-open a VS2017 WinForms project, it had red squiggly lines in the editor when viewing cs files and the build failed. I now just install different versions of MSVS in totally separate virtual machines to avoid problems.
I predict that a future version VS2030 will have install bugs that breaks VS2026. The underlying issue that causes side-by-side bugs to re-appear is that MSVS installs are integrated very deeply into Windows. Puts files in c:\windows\system32, etc. (And sometimes you also get the random breakage with mismatched MSVCRT???.DLL files) To avoid future bugs, Microsoft would have to re-architect how MSVS works -- or "containerize" it to isolate it more.
In contrast, gcc/clang can have more isolation without each version interfering with each other.
I'm not arguing this thread's msvcup.exe tool is necessary but I understand the motivations to make MSVS less fragile and more predictable.
Note that this also doesn't work on Linux - your system's package manager probably has no idea how to install and handle having multiple versions of packages and headers.
That's why docker build environments are a thing - even on Windows.
Build scripts are complex, and even though I'm pretty sure VS offers pretty good support for having multiple SDK versions at the same time (that I've used), it only takes a single script that wasn't written with versioning in mind, to break the whole build.
> Note that this also doesn't work on Linux - your system's package manager probably has no idea how to install and handle having multiple versions of packages and headers.
But this isn’t true. Many distros package major versions of GCC/LLVM as separate packages, so you install and use more than one version in parallel, no Docker/etc required
It can indeed be true for some things-such as the C library-but often not for the compilers
The closest thing I saw to this was some vendors shipping their SDKs with half the desktop userland (in a similar 'blob' fashion the post complains about), with shell scripts setting up paths so that their libs and tools are found before system ones.
this seems to be the same approach I saw with other SDKs (for example Qt), which I wrote about in my previous post - the official versions ship half the userland dependencies in a directory under /opt/
and use some scripts (chroot or LD_LIBRARY_PATH maybe, not an expert) to create a separate environment for the given toolset.
In RHEL8/9, there is a command "scl" which works by updating the PATH... so you can run "scl enable gcc-toolset-9 bash" to start a new bash shell using GCC 9.
In RHEL10, instead of "scl", each toolset has an independent command (actually just a shell script) like "gcc-toolset-9-env bash" which does the same thing
chroot or LD_LIBRARY_PATH isn't necessary, changing PATH is enough
Or in fact – this isn't RHEL scl system, but some other distros – some distros install alternative compilers using a prefix, so you just do `CC=PREFIX-gcc` (assuming you have a Makefile configured with the standard conventions)
e.g. for hobbyist/recreational reasons, I have done MS-DOS software development under Linux before. The DOS cross-compiler gets installed as "i586-pc-msdosdjgpp-gcc" so I just do "CC=i586-pc-msdosdjgpp-gcc make" to build my project for DOS instead of Linux.
Similarly, different clang versions are often installed with a version suffix. So in another project I had, I'd do "CC=clang-11 make" when I wanted to use clang 11 and "CC=clang-15 make" when I wanted to use clang 15. (You can tell from the version numbers I haven't touched that hobby project of mine for quite a while now.)
Guix and Nix can do that. They were built from the ground up to be able to have multiple, simultaneous versions of everything installed in separate store, and you can request on a per shell basis what you want in your environment.
Why? You may end up with something that doesn't get much attention anymore, but none of the official gui approaches have ever been removed as far as I know. Win32, MFC, winforms, wpf, winui, maui are all still available and apps using them are functional. Even winjs still works apparently, even if it was handed over.
I wouldn't start an app in most of them today, but I wouldn't rewrite one either without a good reason.
Well a number of them have horrific bugs in them which have zero attention. At least win32 has an abstraction level which allows you to work around them.
There’s a fun bug on WPF and form backgrounds for example which means on fractional DPI screens the background is tiled unpredictably. Had to patch that one up rather quickly one day and it was a mess due to how damn complicated WPF is.
I don't believe we'll get any toolkit without bugs in our lifetime. There are bugs in everything, but it doesn't prevent millions of different apps running using WPF every day.
I thought for a moment I was missing something here. I always just use winget for this sort of thing as well. It may kickoff a bunch of things, but it’s pretty low effort and reliable.
> What if you have two different project with different requirements at the same time?
Install multiple versions of Windows SDK. They co-exist just fine; new versions don’t replace old ones. When I was an independent contractor, I had 4 versions of visual studio and 10 versions of windows SDK all installed at once, different projects used different ones.
Windows SDKs, WDKs (driver dev), Visual Studio releases, and .NET SDKs all coexist peacefully on a machine. If a project build breaks due to newer SDKs, it's because it was configured with "use newest version". (Which is usually fine but sometimes requires pinning if you're using more "niche" things like WDK)
Nearly all of the Windows hate i see comes from 20 year old takes . ( the bing/cortana / copilot / ads slop criticism is warranted, but is also easily disabled).
For big C++ projects, the .vsconfig import/export way of handling Visual Studio components has worked well for the large teams I'm on. Tell someone to import a .vsconfig and the Visual Studio Installer does everything. Only times we've had issues is from forgetting to update it with components/SDK changes.
Yeah, seems like this is just ignorance around .vsconfig files. Makes life way easier. You can also just use the VS Build Tools exe to install things instead of the full VS installer, if you plan to use a different IDE.
Exporting this way might be possible but it wouldn't be as useful seeing as it would just grab everything you have installed instead of some minimal set used by some project.
One day I decided to port my text editor to Windows. Since it depends on pcre2 and treesitter, these two libraries had to be provided by the system.
In the span of ~2hrs I didn't manage to find a way to please Zig compiler to notice "system" libraries to link against.
Perhaps I'm too spoiled by installing a system wide dependency in a single command. Or Windows took a wrong turn a couple of decades ago and is very hostile to both developers and regular users.
I think providing purely-functional libraries as system dependencies that's tied to the whole tool chain at the time was the wrong decision by the Unix world.
The system libraries should only ship system stuff: interaction with the OS (I/O, graphics basics, process management), accessing network (DNS, IP and TLS). They should have stable APIs and ABIs.
Windows isn't hostile. It has a differnt paradigm and Unix (or more correctly usually GNU/Linux) people do not want to give up their worldview.
PCRE is basically only your apps's dependency. It has nothing else to do the rest of the operating system. So it is your responsibility to know how to build and package it.
If you depend on a library and can't figure out how you would compile against it, it's probably better for the end user that you don't make anything because you'll still need to package it up later unless you link statically.
I suspect the pitfall is how you or the zig compiler is linking. Unless you're involving things which vary by OS like hardware interaction, networking, file systems etc, you should not, with a new Lang in 2026, need to do anything special for cross-platform capabilities.
My understanding that "linkSystemLibrary" abstraction in build.zig only holds for Unix systems. And this in turn makes it impossible to build my program on Windows without modifying the build script.
Nitpick, "Windows Native Development" also refers to the NT native subsystem, which would be basically coding against private APIs instead of Win32. From the title I thought that's what this was. Then I realized it was about avoiding full use of Visual Studio when building C projects (something that a lot of people already do by the way)
> It’s so vast that Microsoft distributes it with a sophisticated GUI installer where you navigate a maze of checkboxes, hunting for which “Workloads” or “Individual Components” contain the actual compiler. Select the wrong one and you might lose hours installing something you don’t need.
I have a vague memory of stumbling upon this hell when installing the ldc compiler for dlang [1].
> On Linux, the toolchain is usually just a package manager command away. On the other hand, “Visual Studio” is thousands of components.
That package manager command, at the very least, pulls in 50+ packages of headers, compilers, and their dependencies from tens of independent projects, nearly each of them following its own release schedule. Linux distributions have it much harder orchestrating all of this, and yet it's Microsoft that cannot get its wholly-owned thing together.
Actually not that complicated: You simply check in a global.json [0] where you specify the sdk and workload versions.
Then you also specify target platform sdk versions in the .csproj file and VS will automatically prompt the developer to install the correct toolchain.
* I wonder if Microsoft intentionally doesn't provide this first party to force everyone to install VS, especially the professional/enterprise versions. One could imagine that we'd have a vsproject.toml file similar to pyproject.toml that just does everything when combined with a minimal command line tool. But that doesn't exist for some reason.
Microsoft doesn't seem to care unless you're a company. That's the reason community edition is free. Individual licenses would be pennies to them, and they gain more than that by having a new person making things in their ecosystem. It's in their interest to make their platform accessible as possible.
For Visual Studio components that are versioned (like the C++ compilers/libraries), the version number is included in the component name.
You still have to install the tool that processes pyproject.toml so that doesn’t seem fair to hold against it. You are right that you still have to know whether to install 2022 or 2026.
WOW such a great work. Myself I have been struggling with Mingw just to compile from source. Of course it works much cleaner then the hated visual studio, but then when it comes to cuda compile, that´s it.
Visual studio or the magority our there, It is invasive and full of bloatware like you say.
Same struggle with electron.
How to match it with cuda to compile from source the repos?
In the 1990s, I taught GUI programming with the following two books (not necessarily those editions). Is this post the tool chain to do that program
creation from the command line for these? Now that I am retired
from a third of a century as a computer science faculty member, I would like
to resurrect those notes for a comprehensive learning module on GUI programming.
(At the turn of the century, my University had me teach GUI programming
with Java Swing.)
In my opinion, all are wonderful as is old-fashioned x-Windows GUI programming and Visual Basic form development, both of
which I briefly introduced to my students.
Programming Windows with MFC, Second Edition Subsequent Edition
by Jeff Prosise (Author)
Programming Windows®, Fifth Edition (Microsoft Programming Series) Subsequent Edition
by Charles Petzold (Author)
I was just setting up a new machine and was setting up the Rust environment. The very first thing rustup-init asked was to install Visual Studio before proceeding. It was like 20-30gb of stuff installed before moving forward.
This tool would be a great help if I knew beforehand.
No. You cannot even do direct compilation on the same host and target with clang only.
LLVM doesn't come with the C library headers (VCRuntime) or the executable runtime startup code (VCStartup).Both of which are under Visual Studio proprietary licenses. So to use Clang on Windows without Mingw, you need Visual Studio.
I use MingW without any extra libs (no msys), it just uses the ancient msvcrt.dll that is present in all Windows versions, so my programs work even on Windows 2000.
Additionally the cross-compiler on Linux also produces binaries with no extra runtime requirements.
But that's the point, I don't want the same style executable as Visual Studio. Having to distribute bunch of DLLs and having worse compatibility is pretty bad.
A major part of the incompatibility with older versions of Windows is just because newer VS runtimes cut the support artifically. That's it. Many programs would otherwise work as-is or with just a little help.
yeah, you can get away with this now a days because Git itself installs 2/3rds of the things you need anyway. You just need to finish the job by getting the package and putting the binaries in your git folder. Bam! mingw64, clang, what ever cc you need. It all links to standard windows stuff because you have to tell the linker where your win32.lib is. But this is true no matter the compiler, it's just Visual Studio supplies this in some god awful Program Files path.
MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw.
Git installs its own Mingw and Msys2 stuff but mostly compiled for a Mingw environment so they consume Windows paths natively instead of using MSYS2/Cygwin path conversion. That's why when you have mixed PATH variable all hell breaks loose with Git.
I do appreciate it as a daily user of MSYS2. However the bigger thing that enabled them is indeed Cygwin project since it unlocked the path to build things that are using strict Unix tooling. autoconf, Make, bash etc cannot run under a pure Windows environment. They are too dependent to the underlying system being a Unix. To use pacman, bash and make in MSYS2, you need msys-2.0.dll. Even they cite Cygwin's URL in the runtime package [1]. And they basically patch Cygwin to enable this [2]
Without Cygwin enabling the path, it wouldn't be possible to build GCC for Windows without completely changing its build system. It would be a DOA fork while Mingw and PE32+ support is a part of GCC nowadays.
The nice and genius part of MSYS2 is that it is there to primarily encourage you to develop native Windows software that has better cross-platform behavior rather than Cygwin alone. If Microsoft made a better, free of charge C compiler in early 2000s that is adhering to the standards better, we wouldn't probably need Mingw to build cross-platform apps. Now MSVC is still free of charge for only open source and individuals.
They all have to use MSVCRT or UCRT to stay compatible with other Windows programs and APIs like COM. And AFAIK nobody has developed a C library that's purely dependent on Win32 system APIs (it is possible just really hard). The difference is that Cygwin is trying to create this semi-isolated Unix environment to programs to think they are running under a complete Unix system like Wine does.
MSYS2 is there to just provide the basics so you can develop programs that are Windows native but use some of the tools that have really strong Unix dependence like shells or Make. They depend on the existence of syscalls like `fork` or forward slash being the directory seperator.
It was not clear what the parent commenter was addressing; I was under the impression they meant 'compile against the MSYS2 environment', which is broadly Cygwin, yes, which should not be forced onto a user.
Okay, but that just seems to be perpetuating the misunderstanding of what MSYS2 is intended for.
It gives you a *nix-like shell/dev environment and tools, but you build native software that runs on Windows systems that don’t have or need to have all/parts of MSYS2/Cygwin installed.
I built a network daemon using the MSYS2 CLANG64 environment and llvm toolchain on Windows 10.
Windows 7 x64 users could download the compiled single-file executable and run it just fine, so long as they installed Microsoft’s Universal C Runtime, which is a free download from Microsoft’s website.
I get your point. Although my point is that there is actually zero need for MSYS at all for this, even as a developer, and especially not with the 'CLANG64' environment. These binaries themselves are built to run in the MSYS2 environment This is how I cross-compile from Windows... to Windows with LLVM-MinGW[1]:
I think you have it backwards, but I may misunderstand what you're saying.
I'm certain I haven't misunderstood the point of MSYS2's CLANG64 and other environments.
> These binaries themselves are built to run in the MSYS2 environment
I'm not sure if you're referring to the toolchain binaries or the binaries one produce's with them.
The CLANG64, etc. environments are 100% absolutely for certain for building software that can run outside of any MSYS2 environment!
You can, of course, build executables specifically intended to run inside those environments, but that’s not the primary use case.
> (gci Env:PATH).Value.Split(';') | sort
I don't want to use PowerShell or Cmd.exe when doing dev stuff on Windows. I want to do CLI work and author scripts in and for modern Bash, just like I would for Linux and macOS. I want to write Makefiles for GNU make, just like...
Now, sometimes there are bumps and sharp edges you have to deal with via `if [[ -v MSYSTEM ]]; then`, similar in Makefile, cygpath conversion, template/conditional code in sources, and so on. But that's a small price to pay, from my perspective, for staying in the same mental model for how to build software.
I'll just keep using Mārtiņš Možeiko's script, portable-msvc.py, that this tool is based upon. It does everything this does, except a lock file and the autoenv. I'm not particularly interested in the former, and definitely not the latter.
I am not exactly bounding with eagerness and time to contribute to an open source project but the few times I have looked I stop at the "how do I configure my dev environment to match" step.
Just give me a VM. Then you will know, and I will know, every facet of the environment the work was done in.
I don't get why people go through all these flaming hoops and hurdles to deal with MSVC when MinGW and MinGW-w64/MSYS2 are options. In the latter case you even still get (mostly complete) MSVC ABI-compatibility if you compile with clang.
MinGW and MinGW-64/MSYS2 are just as inscrutable, fragile and new-user-hostile. The fact that you have to choose between MinGW (which has a 64 bit version) or MinGW64 (completely separate codebases maintained by different people as far as I can tell) is just the first in a long obstacle course of decisions, traps, and unexplained acronyms/product names. There are dozens of different versions, pre-built toolchains and packages to throw you off-course if you choose the wrong one.
If you're just a guy trying to compile a C application on Windows, and you end up on the mingw-w64 downloads page, it's not exactly smooth sailing: https://www.mingw-w64.org/downloads/
> If you're just a guy trying to compile a C application on Windows, and you end up on the mingw-w64 downloads page, it's not exactly smooth sailing: https://www.mingw-w64.org/downloads/
One of the options on that page is MSYS2, which I specifically listed above alongside MinGW-w64. And that download page is much smoother sailing: https://www.msys2.org/
There are other options on the MinGW-w64 page, but most of those are for cross-compiling from non-Windows operating systems (which conceivably could include something running on WSL these days), and of the Windows-host options, the only two with “many” packages are Cygwin and MSYS2 (though WinLibs looks interesting).
MinGW/MSYS2 are flaming poop hurdles. That’s the bending over backwards to fake a hacky ass bad dev environment. Projects that only support MinGW on Windows are projecting “don’t take windows seriously”.
Supporting Windows without MinGW garbage is really really easy. Only supporting MinGW is saying “I don’t take this platform seriously so you should probably just ignore this project”.
Say what you want about coding agents, when the cost of writing code goes to near-zero, the cost of wrangling tools becomes a much bigger fraction of development effort. This is an amazing opportunity to address long-standing frictions.
Last I checked the license for the headless toolchain requires that a full licensed copy of Visual Studio be installed somewhere. So I think this violates the license terms.
A bug got opened against the rustup installing the headless toolchain by itself at some point. I'll see if I can find it
I don't really use Windows OS much, but why not just use MinGW? Then you have Clang on all platforms you can think of: Android, all the various Darwin flavors and of course Linux and Windows; as well as on platforms you can't think of like FreeBSD or even Haiku maybe? Like honestly what's the point of supporting MSVC at all?? Maybe I'm just not enough of a Windows nerd to understand? (so I'm basically wondering if mingw has any drawbacks)
If you have a self-contained project, where you don't depend on anyone else and others don't depend on you, MinGW works great. Problems arise when you have dependencies that don't work with it. I'd love to see if MinGW could find a way to be binary compatible with MSVC-compiled binaries. Right now it's kind of an all or nothing solution which makes it hard to adopt.
Ah, binary-only dependencies, right… That's very specific though, so unless you need to drive some proprietary hardware, why bother using stuff that forces you into MSVC hell lol? Also wouldn't LLVM based MinGW benefit from Clang's MSVC compat? Not sure about this at all, that's why I'm asking, heh… ^^"
As someone who has been doing Win32 development for literally decades, I'm not particularly convinced this is a problem that needs more code to solve. You don't need VS to get the compiler (which is available as a separate download called something like "build tools", I believe); and merely unpacking the download and setting a few environment variables is enough to get it working. It's easy to create a portable package of it.
We manage Visual Studio on our CI machines using Ansible. Chocolatey installs the full Visual Studio and then we use the APIs provided to manage components via Ansible. See our action here: https://galaxy.ansible.com/ui/repo/published/kitware/visuals...
The winget installer just downloads vs_buildtools.exe and runs it, which first installs vs_setup.exe and then that one prompts you for the workloads you want. I believe passing --silent to the winget installer will install vs_setup unattended but not any workloads from the Build Tools.
To install it all in a single step, and beware I haven't tested this, you're better off downloading and running yourself
Then you'll need to locate and run vcvarsall.bat to setup the environment, which will require some clever code if you're doing it from PowerShell instead of a .bat, and then you can finally call the compiler.
I am not too into windows dev but I am currently using msvc at work. We are told to import a config file into the installer and it automatically selects all of the components any of our projects will need. Wouldn't that solve the problem too? Just distribute a project level config file and add documentation for how to import and install the stuff.
Does it? Admittedly, it has been a while but I don't remember it differing too much from the good old ./configure && make paradigm with a few flags to both commands.
Windows Native is fine. People in that space are comfortable with it.
What needs to be fixed is the valley between unix and windows development for cross-os/many-compiler builds, so one that does both can work seamlessly.
It's not an easy problem and there are lots of faux solutions that seem to fix it all but don't (in builds, the devil is in edge cases).
I seriously doubt that people who get confused by the MSVC++ Installer will be able to handle a CLI app that installs a mystery MSVC++ toolchain version to a versioned directory. They're still going to click the Visual Studio icon on their desktop and scratch their head why your script didn't magically fix their problems.
The ironic part is that Visual Studio may be the best product Microsoft has ever made. Compared to the rest of their offerings, it is nothing short of amazing. It boggles the mind to know that this was developed in-house - well most of it anyways.
> You spend less time on your project because you’re too busy being a human-powered dependency resolver for a 50GB IDE.
Really? A 50GB IDE? How the heck one knows what goes in there?
My beloved FreeBSD 15.0 PLUS its Linux VM PLUS its docker env PLUS its dependencies and IDE are close to 26Gb and pretty sure I'm taking into account a lot of things I shouldn't, so the actual count is much less than that.
Developing software under a Windows platform is something that I cannot understand, since many many many years ago.
As someone who is out of the loop on Windows development, is this related to the Windows Driver Kit (WDK, I think it used to be DDK)? That's a certain type of hell I don't wish upon most.
No one should use any of these weird Frankenstein monstrosities in 2026. And a batch script? :( PowerShell exists.
Install:
- contrary to the blog post, the entirety of Visual Studio, because the IDE and debugger is *really damn good*.
- LLVM-MinGW[1]
Load the 'VSDevShell' DLL[2] for PowerShell, and you're good to go, with three different toolchains now:
cl.exe from VS
clang-cl.exe—you don't need to install this separately in VS; just use the above-mentioned llvm-mingw clang.exe as `clang.exe --driver=cl /winsysroot <path\to\Windows SDK> /vctoolsdir <path\to\VC>`. Or you can use it in GNU-driver-style mode, and use -Xmicrosoft-windows-sys-root. This causes it to target the Windows ABI and links against the VS SDK/VC tools
`clang.exe` that targets the Itanium ABI and links against the MinGW libraries and LLVM libc++.
Done and dusted. Load these into a CMake toolchain and never look at them again.
People really like overcomplicating their lives.
At the same time, learn the drawbacks of all toolchains and use what is appropriate for your needs. If you want to write Windows drivers, then forget about anything non-MSVC (unless you really want to do things the hard way for the hell of it). link.exe is slow as molasses, but can do incremental linking natively. cl.exe's code gen is (sometimes) slightly worse than Clang's. The MinGW ABI does not understand things like SAL annotations[3], and this breaks very useful libraries like WIL[4] (or libraries built on top of them, like the Azure C++ SDK[5] The MinGW headers sometimes straight up miss newer features that the Windows SDK comes with, like cfapi.h[6].
LLVM-MinGW sounds external to Microsoft though. I think the blog focused on in-Microsoft solutions. And I am not sure the "contrary to the blog content" is valid - compared to Linux, the Microsoft stack is much more annoying to install. I installed it, but it was annoying to no ends and took ages.
> compared to Linux, the Microsoft stack is much more annoying to install.
Not really. It's just different. As a cross-platform dev, all desktop OSs have their own idiosyncracies that add up to a net of 'they are all equally rather bad'.
I dunno, it has its uses when porting software written for UNIX-first. Plus, I pointed out Clang, rather than GCC, because Clang is natively a cross-compiler. I don't like to be dogmatic about stuff; if it's useful then it's useful. If it isn't then I will say why (as I explained why there's no need for MSYS2/Cygwin below).
Unix-first software on Windows is extremely irritating. Do it right or don’t do it at all. Especially when doing it right is actually super easy. You just have to care.
it's been 14 years since i've used msvc for anything real. iirc the philosophy back then was yearly versioned releases with rolling intermediate updates.
this seems to go down the road towards attempts at determinsticish builds which i think is probably a bad idea since the whole ecosystem is built on rolling updates and a partial move towards pinning dependencies (using bespoke tools) could get complicated.
I literally came to post the exact same line as my indicator that this was AI-generated. I ctrl-f'd first and sure enough I'm not alone in using 'key insight' as the canary.
Another option is explore winget and chocolaty. Most build tools and compilers can be installed via the command line on windows. Ask your favorite LLM to create a powershell script to install them all.
I don't understand, just use scite editor with tcc. About a couple of megs download, no install required and your apps will run on everything from win 98 to linux with wine. And if the answer is c++ support then you get all the pain you deserve using that cursed language
To me it seems as if Microsoft wants to make it deliberately harder to have
software developers. Now - I installed all the required things and compiled
on Windows too, but it is very annoying compared to Linux. Microsoft should
simply have ONE default build, e. g. "download this and 80% of developers
will be happy". No need for a gazillion checkboxes.
Fair question! Nope. I'm not endorsing it, and certainly don't know (or even suspect) it would solve this issue. I just recently installed NixOS and was surprised to see Windows mentioned on the downloads page, so looked into it a bit. Maybe soon.
Okay well, if you do, good luck with glibc (and likely other) issues. WSL1 feels kind of dead unfortunately, neither Windows wants to support newer Linux syscalls nor do Linux projects seem to care for including fallbacks.
Trollish usernames aren't allowed on HN, so we've banned this account*. If you want to pick a different username that isn't trollish, we can rename the account and unban it. It would be best to email hn@ycombinator.com for this, to make sure we get the message.
(It would have been better for us to catch this sooner, but in this case someone had to explain the name to me. Out of respect for HN's many Francophone readers, I think it's best to apply the rule.)
TLDR: I don't understand my native command line, see how lost I got when I tried to do my thing in a different environment.
- Not a unique problem to Windows or even MSVC; He's gonna hate XCode,
- Making Python a bootstrap dependency = fail,
- Lacks self-awareness to recognize aversion vs avoidance,
My background is distinctly non-Windows, but I survive around Windows so well that people think I'm a Mickeysoft type. And no, I don't use mingw, cygwin, ...
If any of the obstacles this user faced were legitimate, nobody would ever make any money on Windows, including and especially Microsoft - a company whose developers have the same challenges.
I'm being harsh because _mea quondam culpa_ and it's correctable.
Everything this user went thru is the result of aversion instead of avoidance.
To _avoid_ long deep dives into Windows, you need to recognize there is a different vocabulary and a radically different jargon dialect at play.
1. Learn a tiny minimum of Powershell; it's based on the same POSIX spec as bash and zsh, but like Python, Javascript, etc, instead of byte as the fundamental unit, they use objects. So there's less to learn to reach a greater level of convenience than soiling yourself with DOS/CMD/BAT. On Windows, pwsh has a default set of linux-like aliases to minimize the learning required for minimal operability. And never have to type \ instead of / for a directory separator.
2. Microsoft make money from training. To sell their meat-free steak (* ingredient: saw dust), they feed the suits an all-you-can-eat calorie, nutrition, and protein free buffet of documenting everything in great detail and routinely "streamlining" the names and terminology.
Development on Windows is in a different reference frame, but relative to their own reference frames, they're ultimately not all that different.
Approach in your "foreign language" mindset; English alphabet but the words mean different things.
3. What not how. "How do I grep" means you are trying to random access bytes out of a random access character stream. "What's the command to search for text in files?" well, if you're bloody mindedly using cmd, then it's "find".
4. Seriously, learn a little Powershell.
I only approached Powershell hoping to gain material for a #SatansSphincter anti-ms rant while using it as a Rosetta Stone for porting shell scripts in our CI for Windows.
I mean, it is based on the same POSIX spec as sh, bash, and zsh, with a little Perl thrown in. That can't not go horribly, insidiously, 30-rock wrong in the hands of MS, right?
Turned out, it's the same paradigm shift perl/shell users have to make when coming into Python:
from `system("ps | grep hung")` to `"hung" in system("ps")`;
from `system("ifconfig -a | sed 's/\<192\.168\.0\./10.0.0./g'")` to `system("ifconfig -a").replace("192.168.0.", "10.0.0.")`
`grep` is a command that applies an assumption to a byte stream, often the output of a command.
In powershell, executing a command is an expression. In the case of a simple command, like "ps", that expression resolves to a String, just like system(...) does in Python.
Learning even a small amount of Powershell is immensely helpful in better understanding your enemy if you're going to have to deal with Windows. The formal names for official things use "verb-singularnoun".
That last part of the convention is the magic: the naming of things on Windows is madness designed to sell certifications, so crazy even MS ultimately had to provide themselves a guide.
At the risk of being that guy, I haven't had any issues onboarding people onto native projects written in Rust. rustup does a great job of fetching the required toolchains without issue. I'd imagine the same is also true of Go or Zig.
While Microsoft <3 Rust, there are still some quality tooling parity to reach versus Visual Studio abilities for .NET, Python and C++.
Incremental compilation, and linking, parallel builds, hot code reloading, REPL, graphical debugging optimised builds, GPU debugging....
Go is better left for devops stuff like Docker and Kubernetes, and Zig remains to be seen when it becomes industry relevant beyond HN and Reddit forums.
I'm pretty people who write and build C++ on Windows do it for good reasons, often reasons that are out of their control. Your comment is not going to make any difference.
You have to do this for certain rust things too. I can't remember which, but I inevitably run into a need to install the MSVC toolchain to compile rust. I think it might be related to FFI, or libs which use FFI? The same thing comes up in Linux, but the process to install it is different.
I got anxiety reading the article, describing exactly why it sucks. It's nice to know from the article and comments here there are ways around it, but the way I have been doing it was the "hope I check the right checkboxes and wait a few hours" plan. There is usually one "super checkbox" that will do the right things.
I have to do this once per OS [re]install generally.
I'm just asking, but is there really a need for a native programs anymore? Where I worked a decade ago, we started porting all our native programs over to the browser and this was when MVC beta was just being released. At this point with Electron and Tauri, is there even a need to write a native program
Now with AI, I would think that porting a native program to the browser wouldn't be the chore it once was.
Yes, very definitely. There has always been a need for high performance native applications. Even in the beginning of the desktop computing revolution, these questions have been asked .. and yes, there is a balance between native and cloud/browser-based computing - some of it is personal, much of it is industrial and corporate, and yet more of the spectrum where both methods are applicable exists, even still, decades later.
> is there really a need for a native programs anymore
As long as you don't give a shit about the fact that your baseline memory consumption is now 500MB instead of 25MB, and that 80% of your CPU time is wasted on running javascript through a JIT and rendering HTML instead of doing logic, no.
If you don't give a shit about your users or their time, there's indeed no longer a need to write native programs.
I use COM and DLLs to extend software/automate. Using Visual Studio gives me some really nice debugging options.
I did try using python and js but the variable explorer is garbage due to 'late binding'.
I thought this was just my ignorance, but I've asked experts, AI, and google searched and they unfortunately agree. That said, some people have created their own log/prints so they don't need to deal with it.
This is harder than what I do. Just install LTSC Visual Studio build tools from [1], then chuck this in a cmd file:
I've built a load of utilities that do that just fine. I use vim as an editor.The Visual Studio toolchain does have LTSC and stable releases - no one seems to know about them though. see: https://learn.microsoft.com/en-gb/visualstudio/releases/2022... - you should use these if you are not a single developer and have to collaborate with people. Back like in the old days when we had pinned versions of the toolchain across whole company.
[1] https://download.visualstudio.microsoft.com/download/pr/5d23...
> The Visual Studio toolchain does have LTSC and stable releases - no one seems to know about them though.
You only get access to the LTSC channel if you have a license for at least Visual Studio Professional (Community won't do it); so a lot of hobbyist programmers and students are not aware of it.
On the other hand, its existence is in my experience very well-known among people who use Visual Studio for work at some company.
You can install the LTSC toolchain without a license. Just not the IDE.
That's not correct. You don't have to give your credit card details or even be logged in but you are still required to have any Visual Studio license. For hobbyists and startups the VS Community license is enough but larger companies need a VS Professional license even for the VS Build Tools.
How strict Microsoft is with enforcement of this license is another story.
You do not need a Professional or Enterprise license to use the Visual Studio Build Tools:
> Previously, if the application you were developing was not OSS, installing VSBT was permitted only if you had a valid Visual Studio license (e.g., Visual Studio Community or higher).
From (https://devblogs.microsoft.com/cppblog/updates-to-visual-stu...). For OSS, you do not even need a Community License anymore.
The license doesn't actually permit OSS development. Only compilation of near-unmodified third party OSS libraries.
You may not compile OSS software developed by your own organisation.
The OSS software must be unmodified, "except, and only to the extent, minor modifications are necessary so that the Open Source Dependencies can be compiled and built with the software."
https://visualstudio.microsoft.com/license-terms/vs2026-ga-d...
Using VS build tools for open source development is covered by the Community licence [0], separate from this Build Tools licence change. That license is more open than you might expect, working as an individual it even permits proprietary development for commercial purposes.
Under that usage, the Community license counts as a valid Visual Studio license for Build Tools purposes, hence the second paragraph:
> This change expands user rights to the Build Tools and does not limit the existing Visual Studio Community license provisions around Open-Source development. If you already are a developer contributing to OSS projects, you can continue to use Visual Studio and Visual Studio Build Tools together for free, just like before.
[0] https://visualstudio.microsoft.com/license-terms/vs2022-ga-c...
This does not apply if you're developing closed source:
> if you and your team need to compile and develop proprietary C++ code with Visual Studio, a Visual Studio license will still be required.
That just confirms the parent comment's point. If you're just using the build tools directly, you're fine. If need to develop "with Visual Studio" i.e. the IDE, not just the command line tools, then you need the paid license.
It's actually not. It's complicated, but they're explicitly allowing Build Tools to be used to compile open source dependencies of closed source projects that do not need the MSVC toolchain for proprietary components.
It's why the example they give in the article is a Node.js application with native open source dependencies (e.g. sqlite3).
EDIT: it's clearer when read in context of the opening paragraph:
> Visual Studio Build Tools (VSBT) can now be used for compiling open-source C++ dependencies from source without requiring a Visual Studio license, even when you are working for an enterprise on a commercial or closed-source project.
Ok that does sound a bit different.
I wish the post was clearer (though I'm not sure what that looks like). I've made the same mistake interpreting it, then had to go back and reread it a few times.
Is the fancy text editor compiling, or the toolchain?
I don’t need visual to write, read, compile, or link any code using the toolchain.
[flagged]
Well, let's say this is the world view of all companies about open-source software. Then what happens. If people "tend to not give crap" about licenses, all the nice guarantees of GPL etc also disappear.
Very weird comparison.
GPL was made in response to restrictive commercial licensing. Yes is uses the same legal document (a license): but is made in response!
So is propriety seizes to exist, then it's not a problem GPL also seizes to exist.
Also: it's quite obvious to me that IP-law nowadays too much. It may have been a good idea at first, but now it's a monster (and people seem to die because of it: Aaron Swartz and Suchir Balaji come to mind).
There are zero guarantees and commercial software uses GPLd software as parts of their products all the time. Licenses do not work and you shouldn't respect them whenever you can.
And a VS license isn't too expensive if you really want to buy one. Stack Social have legit licenses discounted to $15:
https://www.stacksocial.com/sales/microsoft-visual-studio-pr...
This definetly looks like some sort of scam. Like a volume key license being resold against EULA or some such.
> Like a volume key license being resold against EULA or some such.
At least in the EU, this is legal.
Through which means?
I can only provide articles that are in German:
An article about court decision by the EuGH from 2012:
https://www.heise.de/hintergrund/EuGH-Gebrauchte-Softwareliz...
Another court decision from the BGH (the highest German civil court) from 2014 that builds on this EuGH decision:
https://www.heise.de/news/BGH-begruendet-Rechtmaessigkeit-de...
The Visual Studio Build Tools are installable with winget (`winget search buildtools`).
There are licensing constraints, IANL but essentially you need a pro+ license on the account if you're going to use it to build commercial software or in a business environment.
I worked with VC++ 6.0 up until Windows 11 when it really, really wouldn't run any more, then switched to VS 2008. The code is portable across multiple systems so it didn't really matter which version of VS it's developed with, and VC++ 6.0 would load, build the project, and have it ready to run while VS 2022 was still struggling through its startup process.
VS 2008 is starting to show the elephantine... no, continental land-mass bloat that VS is currently at, and has a number of annoying bugs, but it's still vastly better than anything after about VS 2012. And the cool thing is that MS can't fuck with it any more. When I fire up VS tomorrow it'll be the exact same VS I used today, not with half a dozen features broken, moved around, gone without a trace, ...
Yeah recent VS is awful. I recently tried VS2022. What a mess.
VS2026 is even worse. And if you thought the CoPilot enshittification in 2022 was bad, wait'll you see 2026. We only use it for final builds now, so develop under a bloated but at least not enshittified yet version, then do release builds and testing with whatever the latest version is before shipping.
I noticed Visual Studio 2026 doesn't have an LTSC release yet. Any idea when that will come out?
They've completely reworked release plans. 2026 LTSC will come out a year after the initial VS 2026 release (at the same time as VS 2027) and be supported for 1 more year. You pretty much have to get on the rolling updates train for the IDE, which is why the C++ toolchain now follows a different schedule and you're supposed to be able to install any specific toolchain side by side.
So in this new Microsoft world, “long term” means “one or two years, depending on how you count”? Ohhkay.
No, LTCS means the version after the end of public beta.
Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath? glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow... python in another realm here as well. That shiny c++ project that needs a bleeding edge boost version that is about 6 months away from being included in your package manager. Remember patching openSSL when heartbleed came around (libssHELL).
Visual studio is a dog but at least it's one dog - the real hell on windows is .net framework. The sheer incongruency of what version of windows has which version of .net framework installed and which version of .net your app will run in when launched... the actual solution at scale for universal windows compatibility on your .net app is to build a c++ shim that checks for .net beforehand and executes it with the correct version in the event of multiple version conflict - you can literally have 5 fully unique runtimes sharing the same .net target.
> glibc dependencies that can't be resolved because you need two different versions simultaneously in the same build somehow...
If you somehow experience an actual dependency issue that involves glibc itself, I'd like to hear about it. Because I don't think you ever will. The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it: https://lwn.net/Articles/605607/
Now, if you're saying it's a dependency issue resulting from people specifying wrong glibc version constraints in their build… yeah, sure. I'm gonna say that happens because people are getting used to pinning dependency versions, which is so much the wrong thing to do with glibc it's not even funny anymore. Just remove the glibc pins if there are any.
As far as the toolchain as a whole is concerned… GCC broke compatibility a few times, mostily in C++ due to having to rework things to support newer C++ standards, but I vaguely remember there was a C ABI break somewhere on some architecture too.
> The glibc people are so serious about backward and forward compatibility, you can in fact easily look up the last time they broke it
What? There was a huge breakage literally last year: https://sourceware.org/bugzilla/show_bug.cgi?id=32653
Glibc has been a source of breakage for proprietary software ever since I started using Linux. How many codebases had to add this line around 2014 (the year I brought my first laptop)?
> https://sourceware.org/bugzilla/show_bug.cgi?id=32653
dlopen and dlmopen no longer make the stack executable if a shared library requires it
I'm not counting intentional breakage to improve system security. I'm not even sure I'd call it an ABI breakage; by a wide definition I guess it is a "change in glibc that makes things not work anymore". You also can't execute a.out binaries anymore, eh. And I don't think I would call something that affects primarily closed source binaries (and mono on i386) a "huge" issue either.
The fix is trivial ("execstack -s <binary>") and doesn't involve any change to installed versions of anything.
> __asm__ (".symver memcpy, memcpy@GLIBC_2.2.5");
A 12 year old forward compatibility issue that is fixed by upgrading glibc, okay. (Note this is the same timeframe as the s390 thing I linked.) I guess people shipping binaries need to be aware of it if they want to support glibc pre-2.2.14. That said, the general rule of shipping binaries is that you need to assume whatever you build against becomes the minimum required version, anything else is a gift.
I think my point about never pinning glibc stands, and how many other things do you know where you need to go back 12 years to find an ABI break?
A few recent examples: many distros changed the flag for emuTLS on Windows, which gcc implemented as a hard ABI break for no essential reason. If you compile for enough platforms, it will print various notes that various alignments have changed in the struct, which has caused grief numerous times in the past few years for people I work with (many of the changes don’t come with notes, they just change alignment since new hardware comes out that has new features which need more and/or there were bugs previously, so they silently change it). There’s also win32 or posix threading, and sjlj vs structured exceptions, all of which are mutually incompatible. Oh, and then don’t get me started on ARM v6 atomics, which is some weird decided-based-on-compiler-flags-to-record-heuristics-detected-during-configure-of-some-auxiliary-header time, instead of using the current target’s ABI
Sure, the ABI does not change at all, if you know in advance where the landmines are. Though it does have quite few, especially for a large project with a huge surface area
I was talking about glibc; none of the things you mention relate to that. (Note glibc is not used on Windows.) I'm painfully aware of some of the breakage GCC occasionally causes (the atomics fall into that — but to be fair ARMv6 is also >10 years ago at this point, unless you're doing embedded, in which case you generally build the whole system anyway and don't care about these breaks.)
Also, just in case it's not clear, glibc has nothing to do with GCC.
You can have one of "they're so serious about forward and backward compat you should remove version pins because things won't ever break" and "well, I'm not counting intentional breaks" but not both.
Why? Is it not normal to have a first priority and a second priority? Does it not make sense for security to come before other things?
I don't know much about glibc's specifics, but in general: Security comes before a lot of things but not before accidental breakage. If you say "our compat guarantees are so strong you shouldn't keep track of versions at all", I expect this to mean that APIs and ABIs will never change, or at least not without a massive awareness campaign and transition plan being announced before - because such a breakage would take out my project or might even introduce new vulnerabilities.
A security update that also does breaking changes is sort of the worst case, because dependents are essentially damned if they apply it and damned if they don't. They can't always be avoided if an API is so insecure it's beyond repair - but then dependents will have to update in their own time because they will also have to fix their own implementations. So this would be an argument for version pins in that case.
> Security comes before a lot of things but not before accidental breakage.
It didn't really sound accidental, though the bugzilla report sounds like they underestimated the impact. But I'm quite sure they were aware this would break at least some old software, it's not like it's hard to understand what exactly is happening here. Old software (or rather, builds) used executable stacks by default, and some edge cases used them for some time after that. I'll say they probably should've done a warning period.
> If you say "our compat guarantees are so strong you shouldn't keep track of versions at all",
What I said was you should never pin a glibc version, not to not keep track of versions at all :). I will admit this is hazy if you build binaries to distribute; in that case you probably want to intentionally use an old glibc. But that's not exactly a "pin", that's a "what's the oldest you want to support". The software being built basically makes no difference; glibc will do what it does, the only limit will be placed by features added in newer glibc versions. The binaries produced from that, running on a new system with any newer glibc, have AFAIK last broken during that S390 incident I linked. (e.g. you wouldn't have gotten executables requiring executable stacks out of a normal GNU tool chain for quite some time by now. It's still possible to intentionally mangle your code and build options to get that result, but you need to either be trying, or do relatively cursed things [like Mono probably some binary loading shenanigans]).
Either way — never pin glibc. And if your cmake or whatever complains about a glibc version conflict, remove the pins and use the newest version involved.
(And about the execstack thing — I'm happy to hear your complaints if and only if you show up with an actual report of breakage that you encountered. No 3rd party phoning. Because what's at question in this case is the actual impact size, which to me seems quite limited.)
> A security update that also does breaking changes is sort of the worst case, because dependents are essentially damned if they apply it and damned if they don't. They can't always be avoided if an API is so insecure it's beyond repair - but then dependents will have to update in their own time because they will also have to fix their own implementations. So this would be an argument for version pins in that case.
That's not how DSO versioning works. Unless it was a horrible disaster, the old functions would remain available, but you'd be required to jump through hoops to build new software against it.
Because glibc ships basically their entire version history in the library binary. That's the thing with DSO versioning.
I do wonder if they could've done some versioning trick with the execstack thing, the problem there is that it's more about global system behavior than actual exposed ABIs. (By the way, libc isn't even what you would be "pinning" there, it's libdl. Splitting hairs though, as that's part of glibc.)
> Because what's at question in this case is the actual impact size, which to me seems quite limited.
It was widely covered in media. Some of the most popular games and software broke:
1. https://www.gamingonlinux.com/2025/02/the-glibc-2-41-update-...
2. https://www.phoronix.com/news/Glibc-WA-Steam-Exec-Stack
This is the attitude that will always prevent GNU/Linux from becoming prevalent for personal computing. There is a such a lack of empathy for users' hardships and it shows.
When was the last time you actually used. NET? Because that's absolutely not how it is. The. NET runtime is shipped by default with Windows and updated via WU. Let alone that you're talking about .NET Framework which has been outdated for years.
.NET runtime is not shipped with Windows, but once installed can be updated by WU.
Only the latest .NET Framework 4.8 is shipped with Windows at this point.
.NET Framework is a Windows system component, but it's been deprecated and Microsoft is moving away from it. The modern .NET ships as either a downloadable runtime/SDK, or can be bundled with your application, meaning your app has no dependencies.
The issue is in supporting older windows versions - which sadly is still a reality for most large-scale app developers.
https://github.com/dotnet/core/blob/main/release-notes/10.0/...
.NET 10 supports a Windows 10 build from 10 years ago.
Yes and in the wild believe it or not you'll find windows 7 and windows 8.
We had just deprecated support for XP in 2020 - this was for a relatively large app publisher ~10M daily active users on windows. The installer was a c++ stub which checked the system's installed .NET versions and manually wrote the app.config before starting the .net wrapper (or tried to install portable .NET framework installer if it wasn't found at all).
The app supported .NET 3.5* (2.0 base) and 4 originally, and the issue was there was a ".NET Framework Client Profile" install on as surprising amount of windows PCs out there, and that version was incompatible with the app. If you just have a naked .NET exe, when you launch it (without an app.config in the current folder) the CLR will decide which version to run your app in - usually the "highest" version if several are detected... which in this case would start the app in the lightweight version and error out. Also, in the app.config file you can't tell it to avoid certain versions you basically just say "use 4 then 2" and you're up to the mercy of the CLR to decide which environment it starts you in.
This obviated overrides in a static/native c++ stub that did some more intelligent verifications first before creating a tailored app.config and starting the .net app.
Hey I have a PC running 98SE ;-)
I feel for those who have to support an OS no longer supported by the vendor. That's a tough position to be in, not only if a customer comes across a bug that is due to the OS, but it keeps you from advancing your desktop application forward.
You can always have legacy builds for older systems and use shiny new features inside conditional compilation blocks. Or check at runtime and let newer operating systems use the new features. Yes it takes care and a little more testing to keep supporting older operating systems but your users will love you for it.
I’m always kind of sad when a developer says to a customer “your OS is too old. We are dropping you on the floor.”
Sure, you can take on that technical debt! ;-)
.NET versions are faster outdated then .Net Framework 4.8
Point? I’m SRE on .Net project, we have been through 6-8-10 and its cost us about 2ish hours of work each time. As long as you don’t get crazy, .Net upgrades is just matter of new SDK and runtime and away you go.
A .net framework 4.8 app has zero hours of work.
Why is it ok that you have to invest 2 times number of apps hours just because MS has such a short life cycle for its .NET versions.
You're talking about .net for server applications right? The discussion above is for client apps being distributed for windows endusers.
Just ship a self contained build?
This was a sidecar application distributed by literally millions of installs per day - so having a 25MB "self contained" build was out of the question - we were targeting KB-sized distributables not 10's of MB.
We have a small MAUI part of the application, it's not massive but it's working fine with .Net Upgrades.
>Toolchains on linux are not clear from dependency hell either - ever install an npm package that needs cmake underneath?
That seems more a property of npm dependency management than linux dependency management.
To play devil's advocate, the reason npm dependency management is so much worse than kernel/os management, is because their scope is much bigger, 100x more package, each package smaller, super deep dependency chains. OS package managers like apt/yum prioritize stability more and have a different process.
Which has been fixed on .NET 5 and later.
.NET Framework should only be used for legacy applications.
Unfortunately there are still many around that depend on .NET Framework.
Since .NET 10 still doesn't support Type Libraries quite a few new Windows projects must be written in .NET Framework.
Microsoft sadly doesn't prioritize this so this might still be the case for a couple of years.
One thing I credit MS for is that they make it very easy to use modern C# features in .NET Framework. You can easily write new Framework assemblies with a lot of C# 14 features. You can also add a few interfaces and get most of it working (although not optimized by the CLR, e.g. Span). For an example see this project: https://www.nuget.org/packages/PolySharp/
It's also easy to target multiple framework with the same code, so you can write libraries that work in .NET programs and .NET Framework programs.
Most likely never will, because WinRT is the future and WinRT has replaced type libraries with .NET metadata. At least from MS point of view.
The current solution is to use the CLI tools just like C++.
However have you looked into ComWrappers introduced in .NET 8, with later improvements?
I still see VB 6 and Delphi as the best development experience for COM, in .NET it wasn't never that great, there are full books about doing COM in .NET.
.Net Framework 4.8 has a longer life cycle as the current .NET version
When I first worked with dot NET I was confused with the naming and version numbers.
This argument against .NET annoys me.
Because that’s pretty much any freaking thing - oh Python, oh PHP, oh driving a fork lift, oh driving a car.
Once you invest time in using and learning it is non issue.
I do get pissed off when I want to use some Python lib bit it just doesn’t work out of the box, but there is nothing that works out the box without investing some time.
Just like a car get a teenager into a car he will drive into first tree.
Posting BS on Facebook shouldn’t be benchmark for how easy things should be.
It does, but current versions can be shipped with the application.
Thus this should be less of a problem.
.NET Framework 5 or .NET Core 5?
There is no .NET Framework 5. .NET Core 5 is just .NET 5.
This is one of the things that tilts me about C and C++ that has nothing to do with mem safety: The compile/build UX is high friction. It's a mess for embedded (No GPOS) too in comparison to rust + probe-rs.
That hasn't been my experience at all. Cross-compiling anything on Rust was an unimaginable pain (3 years or so ago). While GCCs approach of having different binaries with different targets does have its issues, cross compiling just works.
Ah sorry. I should clarify. Not referring to specifically cross compiling; just general compiling. In rust weather PC or embedded, I run Cargo run. For C or C++, it's who knows. A provincial set of steps for each project, error messages, makes me get frustrated. I keep a set of notes for each one I touch to supplement the project's own docs. I am maybe too dumb or inexperienced in some cases, but I am having a hard time understanding why someone would design that as the UX.
I want to focus on the project itself; not jump through hoops in the build process. It feels hostile.
For cross compiling to ARM from a PC in rust in particular, you do one CLI cmd to add the target. Then cargo run, and it compiles, flashes, with debug output.
These are from anecdotes. I am probably doing something wrong, but it is my experience so far.
I’m the opposite: I want my development tools to use my operating system’s package manager. Nothing enrages me quite like how, when I want to pull in a Python dependency, I have to reach for Python’s parallel package manager. Now I have to keep track of what apt installed and what pip installed. Then I move to do a rust project and there’s now another parallel package manager I need to use to install those dependencies! Yuck!
apt install build-essential or whatever the rpm equivalent is, gets you most of the way to building a C or C++ project.
If I understand correctly, this makes your program and/or its build system tied to an OS. Depending on the details (You mention interpreted and compiled languages), it's not clear if this would provincialize the build only, or running the application as well. (With complications beyond executable ABI compatibility)
My perspective: I want from the OS: An allocator, threading, filesystem support, dates/times, and in some cases hardware access like for GPUs, USB etc.
I do not want my software to be dependent on a specific OS's package manager. I don't want a headache when I change the PC I'm compiling on, and really don't want to deal with a separate package manager for each OS I distribute the application for. Especially so given that there are so many linux distros.
I don't care if my package manager is provided by my OS or by some third party--I only want to deal with one package manager. Currently we have these Matryoshka dolls where there are package managers inside package managers, and each of them manage their own distinct trees of dependencies.
That sounds like you don't have a build system for C/C++.
I went from POP OS (Ubuntu) to EndeavourOS (Arch) Linux because some random software with an appimage or whatever refused to run with Ubuntus “latest” GLIBC and it ticked me off, I just want to run more modern tooling, havent had any software I couldnt just run on Arch, going on over a year now.
Indeed. As late as 2 hours ago I had to change the way I build a private Tauri 2.0 app (bundled as .AppImage) because it wouldn't work on latest Kubuntu, but worked on Fedora and EndeavourOS. So now I have to build it on Ubuntu 22.04 via Docker. Fun fun.
Had fewer issues on EndeavourOS (Arch) compared to Fedora overall though... I will stay on Arch from now on.
Well, traditionally, there was no Python/pip, JS/npm in Linux development, and for C/C++ development, the package manager approach worked surprisingly well for a long time.
However, there were version problems: some Linux distributions had only stable packages and therefore lacked the latest updates, and some had problems with multiple versions of the same library. This gave rise to the language-specific package managers. It solved one problem but created a ton of new ones.
Sometimes I wish we could just go back to system package managers, because at times, language-specific package managers do not even solve the version problem, which is their raison d'être.
Nix devShells works quite well for Python development (don't know about JS) Nixpkgs is also quite up to date. I haven't looked back, since adopting Nix for my dev environments.
.NET does have flags to include the necessary dependencies with the executable these days so you can just run the .exe and don't need to install .net on the host machine. Granted that does increase the size of the app (not to mention adding shitton of dll's if you don't build as single executable) but this at least is a solved problem.
They do now, after .net core and several other iterations. You'll also be shipping a huge executable compared to a clr linked .net app (which can be surprisingly small).
Mine is 33mb. Could be smaller, but it does the trick.
> python in another realm here as well
uv has more of less solved this (thank god). Night and day difference from Pip (or any of the other attempts to fix it honestly).
At this point they should just deprecate Pip.
I have never experienced issues with pip, and I’m not sure it’s whether I’m doing something that pip directly supports and avoiding things it doesn’t help with.
I’d really love to understand why people get so mad about pip they end up writing a new tool to do more or less the same thing.
The problems with pip that uv fixes:
1. It's easy to install.
2. It's not dog slow.
3. It automatically sets up venvs.
4. It automatically activates the venv before running commands.
5. It supports a lock file out of the box.
6. It lets you specify the index for private packages. This fixes a major security issue with pip that they continue to ignore.
7. It installs your code in the venv in editable more by default.
8. It lets you install Python tools outside the venv (`uv tool install`).
9. It works reliably.
There's probably more that I've forgotten. If pip had all of that nobody would have felt the need for a rewrite. And if you've never run into any of those issues I guess you either haven't used Python much or didn't consider that there might be a less shitty way to do things.
> 2. It's not dog slow.
That’s very subjective. I have ADHD and I’m very sensitive to things that break my flow, but I don’t run pip frequently while I’m writing code, and the couple extra seconds it takes to do its job don’t bother me that much.
> 3. It automatically sets up venvs.
Remember: explicit is better than implicit.
> 4. It automatically activates the venv before running commands.
Again: explicit is better than implicit.
> 5. It supports a lock file out of the box.
Some (me included) would say it’s a bug, not a feature.
> 6. It lets you specify the index for private packages. This fixes a major security issue with pip that they continue to ignore.
This is good - a lot of organisations concerned with that will block access to PyPI altogether and offer a selected cache for approved dependencies. Alternatively you can declare private dependencies as Git URLs with tags, bypassing the need for a private index.
> 7. It installs your code in the venv in editable more by default.
That’s a nice touch, but goes against the explicit/implicit rule- a different behaviour automatically triggered by something environmental.
> 8. It lets you install Python tools outside the venv (`uv tool install`).
I always recommend not messing with the system’s Python.
> 9. It works reliably.
I’ll need you to elaborate on that. I might be used to the way pip works, but it’s been a while since I had it fail to do something I asked without there being a very good reason (an impossible conflicting requirement).
This brings me to another concern - I wouldn’t want Python development to become more like JavaScript post-npm. Every external dependency you bring in must be justified and understood. This goes for simple ones and especially for complex ones with lots of secondary dependencies. Any external dependency you bring is now your responsibility to manage forever. I’m fine not having to reimplement NumPy’s MSE function or Django’s ORM, but I’ve moved away from things like click because they save me just a little extra work at the cost of having to remember it’s there forever.
> And if you've never run into any of those issues I guess you either haven't used Python much or didn't consider that there might be a less shitty way to do things.
Or, perhaps, I’ve been using Python since 1.5 and have a deep understanding of why things are the way they are, having experimented with different ways, and just learned that new and convenient isn’t always the best in the long term.
> Remember: explicit is better than implicit.
It's not implicit. When you run `uv run ...` or `uv sync` you are explicitly asking it to automatically set up a venv.
> Some (me included) would say it’s a bug, not a feature.
Some (you included) would be wrong.
> This is good
What is good? That Pip doesn't have a way to avoid dependency confusion? What??
> but goes against the explicit/implicit rule
No it doesn't. It just does the right thing by default.
> I always recommend not messing with the system’s Python.
The reasons to avoid `pip install pre-commit` (outside a venv) are precisely because Pip can't do that in a sane way! `uv tool install pre-commit` suffers from none of the reasons to avoid `pip install pre-commit`.
You definitely have stockholm syndrome. Give uv a try.
Ah yes let's all depend on some startup that will surely change the license at some point.
Very clearly a better option than continuing to use Pip. Even if they do change the license in a few years I will definitely take several years of not being shat on by Pip over the comparatively minor inconvenience of having to switch to an open fork of uv when they rug-pull. If they ever do.
Continuing to use Pip because Astral might stop maintaining uv in future is stupidly masochistic.
pip is really bad though so UV has a long ways to fall before you aren't still net better off :^)
.net has been able to ship the runtime with your app for years.
> Toolchains on linux are not clear from dependency hell either - ever install an npm package.
That's where I stopped.
Toolchains on linux distributions with adults running packaging are just fine.
Toolchains for $hotlanguage where the project leaders insist on reinventing the packaging game, are not fine.
I once again state these languages need to give up the NIH and pay someone mature and responsible to maintain packaging.
The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit.
And when it inevitably leads to all kinds of weird issues the packagers of course can't be reached for support, so users end up harassing the upstream maintainer about their "shitty broken application" and demanding they fix it.
Sure, the various language toolchains suck, but so do those of Linux distros. There's a reason all-in-one packaging solutions like Docker, AppImage, Flatpak, and Snap have gotten so popular, you know?
> The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit.
This is only the case for debian and derivatives, lol. Rolling-release distributions do not have this problem. This is why most of the new distributions coming out are arch linux based.
I'm going to need a source for both of those claims.
It sure sounds very Debian-ish, at least. I’m a Fedora user, and Fedora stays veeeery close to upstream. It’s not rolling, but is very vanilla.
Agreed, but I don't think that has to do with either it's "vanillaness" or the 6 month release schedule. Fedora does a lot of compatibility work behind the scenes that distros not backed by a large company more than likely couldn't afford.
"Vanillaness" is exactly what's in-scope here:
> ...every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar.
Applying non-vanilla flavor (patches) to libraries in able to make new packages work with old packages. (It's not just a library thing of course--I've run into packages on Debian where some component gets shimmed out by some script that calls out to some script to dynamically build or download a component. But I digress.)
Maybe I'm just out of the loop here, but I'm not aware of this being a general practice in Fedora. Yes, Fedora does a lot of compatibility work of course, but afaik the general practice isn't to add Fedora-flavored patches.
`crote` claimed:
> with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar.
Quite frankly, as someone started distro-hopping around ~2009 & only stopped around 2020, I have experienced a lot of Linux distributions, as well as poked at a lot of maintainer pipelines — it is simply categorically untrue for the majority of non-Debian derived Linux distributions.
It used to be that a decent number of Linux distributions (Slackware, Debian, RedHat, whatever) put in a lot of work to ensure "stability", yes. However "stability" was, for the most part, simply backporting urgent security fixes to stable libraries and to their last three or so versions. The only system that is very well known for shipping "a decades old version" of a system library would be Debian (or its biggest derivative, Ubuntu), because it's release cycle is absolutely glacial, and most other Linux distributions do give somewhat of a shit about keeping relatively close to upstream. If only because maintaining a separate tree for a program just so you can use an ancient library is basically just soft-forking it, which incurs a metric shitton of effort and tech-debt that accrues over time.
One of the reasons I switched to and then ran at least one single Arch Linux installation for the back half of the 2010s (and used other computers or a dual boot for distrohopping) was partly for the challenge (I used to forget to read the NEWS before upgrading and got myself into at least one kernel panic that way lol), and partly because it was the only major rolling-release distribution at the time. In the last 6 years that's changed a lot, and now there's a whole slew of rolling-release distributions to choose from. The biggest is probably Steam's Holo distribution of Arch, but KDE's new distribution (replacing Kubuntu as the de-facto "KDE Distro") is based on Arch as well, along with I think Bazzite and CachyOS; Arch has always had a reputation (since before the 2010s) for keeping incredibly close to upstream in it's package distributions, and I think that ideology has mostly won-out now that a lot of Linux software is more generally stable and interacts reasonably well (Whereas, back when Pipewire was a thing... that was not the case).
Now, sure, I'm not going to the effort of compiling my decade+ experience of Linux into a spreadsheet of references of every major distribution I tried in the last ten years, just to prove all of this on an internet forum, but hopefully that write-up will suffice. Furthermore, as far as I can see, the burden of proof is not on me, but on `crote` to prove the claim they made.
Also, I get how if you've only ever used Debian-derivatives, all of this may appear to be incorrect. I would suggest, uh, not doing that — if only because it's a severely limiting view of what Linux systems are like. Personally, I've been a big fan of using Alpine's Edge release since before they had to drop linux-hardened and it's a really nice system to use as a daily driver.
The real kicker is when old languages also fall for this trap. The latest I'm aware of is GHC, which decided to invent it's own build system and install script. I don't begrudge them from moving away from Make, but they could have used something already established.
> The build.bat above isn’t just a helper script; it’s a declaration of independence from the Visual Studio Installer.
I am so fed up with this! Please if you're writing an article using LLMs stop writing like this!
I never understood this sentence structure, it adds zero information, it always goes like:
“This isn’t just [what the thing literally is]; it’s [hyperbole on what the thing isn’t].”
It’s a perfectly fine sentence structure. It’s been around for years and years. That’s why LLMs use it!
In the UK, Marks and Spencer have a long-running ad campaign built around it (“it’s not just food, it’s...”)
Em dashes are fine too.
> long-running ad campaign
So you confirm the previous point about zero information
The purpose isn't information, the purpose is drama.
Er, sorry. I meant: the purpose isn't just drama—it's a declaration of values, a commitment to the cause of a higher purpose, the first strike in a civilizational war of independence standing strong against commercialism, corporatism, and conformity. What starts with a single sentence in an LLM-rewritten blog post ends with changing the world.
See? And I didn't even need an LLM to write that. My own brain can produce slop with an em dash just as well. :)
This is actually the scariest part. Because lately even authors and creators who are not using LLM are starting to pick up some of these ways of expressing themselves.
Oh, I didn't learn it from LLM's, believe me.
That style of writing has been around forever. LLM's learned it from us. I'd basically call it "American sales pitch". It's a little bit product landing page, a little bit political opinion column, a little bit self-help book or motivational blogger.
It's always been a style of writing that tries to maximize engagement. The issue is that now we see it creeping into areas that never used to use it. It's not how developers tend to write. But now developers toss their original draft into an LLM asking it to "punch it up for engagement" -- or the LLM has just been trained to assume that's what someone wants by default -- and so now it stands out like a sore thumb.
And obviously, it's an appeal to emotion. Whereas developers tend to be looking for just the cold hard facts. So it's doubly off-putting.
I wonder where did LLM learnt that...
Humans invented writing, not LLMs. They are copying us not the other way around. You can’t jump on 1 sentence that vaguely sounds like an LLM and say it’s written by AI. It’s so silly. I understand the aversion to AI slop but this is not that.
people run on heuristics and no amount of our righteousness will change that. the entire article absolutely reeks of LLM style so the original commentor isnt off the mark. to address your point, LLMs are copying that which leads to the most human engagement, so the way you expressed things makes it seem like you are defending junk food as real food. which of course it is, however it is designed to make someone money at the cost of human health. that's not something i'd be defending personally.
I don't think the article "reeks of LLM style" at all. It's actually very obviously written by a human in my eyes, there are several phrases that LLMs would not write. I see this accusation leveled at basically any piece of writing that is long and not very casual now, it just doesn't make any sense.
For vibe-writing, the vibes aren't even that good!
It's so common, I wonder how no one made an extension that filters this AI slop
I'm really considering it
While this is great - Visual Studio installer has a set of "command-line parameters" for unattended installs.
You can then build a script/documentation that isolates your specific requirements and workloads:
https://learn.microsoft.com/en-us/visualstudio/install/use-c...
Had to do this back in 2018, because I worked with a client with no direct internet access on it's DEV/build machines (and even when there was connectivity it was over traditional slow/low-latency satellite connections), so part of the process was also to build an offline install package.
I tried this once. It downloaded way more stuff than needed and still required admin to actually install.
Well - "run as admin" wasn't a problem for that scenario - as I was also configuring the various servers.
(And - it is better on a shared-machine to have everything installed "machine-wide" rather than "per-user", same as PowerShell modules - had another client recently who had a small "C:" drive provisioned on their primary geo-fenced VM used for their "cloud admin" team and every single user was gobbling too much space with a multitude of "user-profile" specific PowerShell modules...)
But - yes, even with a highly trimmed workload it resulted in a 80gb+ offline installer. ... and as a server-admin, I also had physical data-center access to load that installer package directly onto the VM host server via external drive.
(ugh - "high-latency" connections...)
[dead]
Looking at the script:
> curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/download/v2026...
No thanks. I’m not going to install executables downloaded from an unknown GitHub account named marler8997 without even a simple hash check.
As others have explained the Windows situation is not as bad as this blog post suggests, but even if it was this doesn’t look like a solution. It’s just one other installation script that has sketchy sources.
You don't have to install executables downloaded from an unknown GitHub account named marler8997. You can download that script and read it just like any other shell script.
Just like those complaining about curl|sh on Linux, you are confusing install instructions with source code availability. Just download the script and read it if you want. The curl|sh workflow is no more dangerous that downloading an executable off the internet, which is very common (if stupid) and attracts no vitriol. In no way does it imply that you can not actually download and read the script - something that actually can't be done with downloaded executables.
> You don't have to install executables downloaded from an unknown GitHub account named marler8997. You can download that script and read it just like any other shell script.
You do because the downloaded ZIP contains an EXE, not a readable script, that then downloads the compiler. Even if you skip that thinking "I already have VS set up", the actual build line calls `cl` from a subdirectory.
I'm not going to reconstruct someone's build script. And that's just the basic example of a one file hello world, a real project would call `cl` several times, then `link`, etc.
Just supplying a SLN + VCXPROJ is good enough. The blog post's entire problem is also solved by the .vsconfig[1] file that outlines requirements. Or you can opt for CMake. Both of these alternatives use a build system I can trust over randomgithubproject.exe, along with a text-readable build/project file I can parse myself to verify I can trust it.
1: https://learn.microsoft.com/en-us/visualstudio/install/impor...
It is somewhat different when your system forces binaries to be signed... but yeah, largely agreed. The abject refusal of curl|sh is strange to me, unless the refusers are also die-hard GPL adherents. Binaries are significantly more opaque and easier to hide malware in, in almost all cases.
Wait till they find out what the Visual Studio Installer itself does :) I guess this person just trusts a big company like Microsoft who keeps their source hidden more than a single developer who publishes all their source?
If any of this is relevant to you, you're already running Windows, which means Microsoft already has root on your machine, which means it's futile to try to limit the extent to which you trust their binaries.
>The curl|sh workflow is no more dangerous that downloading an executable off the internet
It actually is for a lot of subtle reasons, assuming you were going to check the executable checksum or something, or blindly downloading + running a script.
The big thing is that it can serve you up different contents if it detects it's being piped into a shell which is in theory possible, but also because if the download is interrupted you end up with half of the script ran, and a broken install.
If you are going to do this, its much better to do something like:
Though ideally yes you just download it and read it like a normal person.I know Jonathan Marler for some of his Zig talks and his work in the win32 api bindings for Zig[0], they are even linked from Microsoft's own repo[1] (not sure why he has 2 github users/orgs but you can see it's the same person in the commits).
[0] https://github.com/marlersoft/zigwin32 [1] https://github.com/microsoft/win32metadata
I would guess one of his accounts is his corporate employee account and his other is personal.
Is this post AI-written? The repeated lists with highlighted key points, the "it's not just [x], but [y]" and "no [a] just [b]" scream LLM to me. It would be good to know how much of this post and this project was human-built.
I was on the fence about such an identification. The first "list with highlighted key points" seemed quite awkward to me and definitely raised suspicion (the overall list doesn't have quite the coherence I'd expect from someone who makes the conscious choice; and the formatting exactly matches the stereotype).
But if this is LLM content then it does seem like the LLMs are still improving. (I suppose the AI flavour could be from Grammarly's new features or something.)
> "The key insight is..."
This was either written by Claude or someone who uses Claude too much.
I wish they could be upfront about it.
It's interesting... Different LLM models seem to have a few sentence structures that they seem to vastly overprefer. GPT seems to love "It's not just X, it's Y", Claude loves "The key insight is..." and Gemini, for me, in every second response, uses the phrase "X is the smoking gun". I hear the smoking gun phrase around 5 times a day at this point.
Perhaps people have mimicked the style because LLMs have popularized it and clearly it serves some benefit to readers.
Perhaps LLMs have mimicked the style because authors have popularized it and clearly it serves some benefit to readers.
It's a cycle.
> have popularized it
It's hated by everyone, why would people imitate it? You're inventing a rationale that either doesn't exist or would be stupider than the alternative. The obvious answer here it they just used an LLM.
> and clearly it serves some benefit to readers.
What?
I think that the style itself is very clear and has its advantages, it's hated only because it's from LLMs, which are not liked when used without judgement (which is often the case).
So, someone who falls on the side of not completely hating LLMs for everything (which is most people), could easily copy the style by accident.
> It's hated by everyone, why would people imitate it?
It could be involuntary. People often adopt the verbal tics of the content they read and the people they talk with.
Then why does every vibe-coded "Show HN" app have it in README.md? Surely authors would edit it out if it was true that everyone hates it.
Maybe vibe-coding Show HN apps is correlated with low effort and bad taste.
Life imitates art, even when that art is slop
I love the style it was written in. I felt a bit like reading a detective novel, exploring all terrible things that happened and waiting for a plot twist and hero comming in and saving the day.
you know why LLMs repeat those patterns so much? because that's how real humans speak
Real humans don't speak in LinkedIn Standard English
Real humans write like that though. And LLMs are trained on text not speech. Maybe they should get trained on movie subtitles, but then movie characters also don't speak like real humans.
Movie characters also don't speak like movie subtitles: the subtitles omit a lot of their speech.
"LinkedIn Standard English" is just the overly-enthusiastic marketing speak that all the wannabe CEOs/VCs used to spout. LLMs had to learn it somewhere
Humans don't, but cocaine does speak "LinkedIn Standard English".
> LinkedIn Standard English
We need a dictionary like this :D
The old Unsuck-it page comes pretty close. I’m not a huge fan of the newer page though. https://www.unsuck-it.com/classics
LinkedIn and its robotic tone existed long before generative AI.
Know what's more annoying than AI posts? Seeing accusations of AI slop for every. last. god. damned. thing.
Yes that's the point. LLMs pretty much speak LinkedInglish. That existed before LLMs, but only on LinkedIn.
So if you see LinkedInglish on LinkedIn, it may or may not be an LLM. Outside of LinkedIn... probably an LLM.
It is curious why LLMs love talking in LinkedInglish so much. I have no idea what the answer to that is but they do.
It is at least thematically appropriate, of course a corporate-built language machine speaks like LinkedIn.
The actual mechanism, I have no clue.
No, they do it because they're mode-collapsed, use similar training algorithms (or even distillation on each other's outputs) and have a feedback loop based on scraping the web polluted with the outputs of previous gen models. This makes annoying patterns come and go in waves. It's pretty likely that in the next generation of models the "it's not just X, it's Y" pattern will disappear entirely, but another will annoy everyone.
This is purely an artifact of training and has nothing to do with real human writing, which has much better variety.
Yup, the first models always added "however it's important to note that..." at the end
[flagged]
"No Visual Studio installation. No GUI. No prayer. Just a script that does exactly what it says."
https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...
https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...
The shitty AI writing is so distracting I had to stop reading.
> Is this post AI-written?
What if it was?
What if it wasn't?
What if you never find out definitely?
Do you wonder that about all content?
If so, doesn't that get exhausting?
Yeah, it does. Congratulations, you figured out why the future is going to be fucking awful.
"What if you can't tell the difference?" Yeah, what if it becomes impossible to spot who's a lazy faker who outsourced their thinking? Doesn't that sound great?!
What's exhausting is getting through a ten-paragraph article and realising there was only two paragraphs of actual content, then having to wade back through it to figure out which parts came from the prompt, and which parts were entirely made up by the automated sawdust injector.
That's not an AI problem, it's a a general blog post problem. Humans inject their own sawdust all the time. AI, however, can write concisely if you just tell it to. Perhaps you should call this stuff "slop" without the AI and then it doesn't matter who/what wrote it because it's still slop regardless.
I completely agree with your parent that it's tedious seeing this "fake and gay" problem everywhere and wonder what an unwinnable struggle it must be for the people who feel they have to work out if everything they read was AI written or not.
It used to require some real elbow grease to write blogspam, now it's much easier.
I hardly ever go through a post fisking it for AI tells, they leap out at me now whether I want them to or not. As the density of them increases my odds of closing the tab approach one.
It's not a pleasant time to read Show HNs but it just seems to be what's happening now.
It never used to be a general blog post problem. It was a problem with the kinds of blogs I'd never read to begin with, but "look, I made a thing!" was generally worth reading. Now, I can't even rely on "look, I made a thing!" blog posts to accurately describe the author's understanding of the thing they made.
I see your point. You need to recalibrate how to decide what to read since the proxy has changed its meaning. I found a similar issue when monetized Youtubers started making things. It used to be amazing to see some hobby project that was a little bit sophisticated but now big stars have lots of money and their full-time job is doing incredible projects just to make videos of them. It's not AI but it's something that didn't used to exist. I'm thinking channels like "Stuff Made Here" and "I Did A Thing" that sound humble but doing difficult, expensive projects that have no purpose except to look good on a video.
> and wonder what an unwinnable struggle it must be for the people who feel they have to work out if everything they read was AI written or not
Exactly!
Have you noticed that your username is literally "its_notjack"?
I'm so fucking tired of this
I last developed for windows in the late 90s.
I came back around 2017*, expecting the same nice experience I had with VB3 to 6.
What a punch in the face it was...
I honestly cannot fathom anyone developing natively for windows (or even OSX) at this day and age.
Anything will be a webapp or a rust+egui multi-plataform developed on linux, or nothing. It's already enough the amount of self-hate required for android/ios.
* not sure the exact date. It was right in the middle of the WPF crap being forced as "the new default".*
And yet without Proton there are no Linux games.
what that have to do with anything?
does proton make current vb development as straight forward as it was on vb6?
Proton allows Linux users to enjoy Windows games, developed on Windows, with Visual Studio and DirectX.
Yes. It appears that way
I analyzed the test using Pangram, which is apparently reliable, it say "Fully human Written" without ambiguity.[1]
I personally like the content and the style of the article. I never managed to accept going through the pain to install and use Visual Studio and all these absurd procedures they impose to their users.
[1] https://www.pangram.com/history/300b4af2-cd58-4767-aced-c4d2...
This honestly just tells me that Panagram is hot garbage
These days I'm always wondering whether what I'm reading is LLM-slop or the actual writing of a person who contracted AI-isms by spending hours a day talking to them.
Fantastic work! It's a long-needed breath of fresh air for the Visual Studio DX. I wish msvcup was existed when they made us use it back during Uni.
Alternatively, there's this:
Install Visual Studio Build Tools into a container to support a consistent build system | Microsoft Learn
https://learn.microsoft.com/en-us/visualstudio/install/build...
I wish open source projects would support MingW or at least not actively blocking it's usage. It's a good compiler that provides an excellent compatibility without the need of any extra runtime DLLs.
I don't understand how open source projects can insist on requiring a proprietary compiler.
There are some pretty useful abstractions and libraries that MinGW doesn't work with. Biggest example is the WIL[1], which Windows kernel programmers use and is a massive improvement in ergonomics and safety when writing native Windows platform code.
[1]: https://github.com/microsoft/wil
I fail to see why this would not work with gcc if it works with clang. The runtime?
'MinGW' is not GCC; it's an ABI, and from the developer perspective it is also the headers and the libraries. You can have GCC MinGW, Clang MinGW, Rust MinGW, Zig MinGW, C# AOT MinGW.
To answer your question, the headers.
if you want to link msvc built libraries (that are external/you dont have source), mingw may not be an option. for an example you can get steamworks sdk to build with mingw but it will crash at runtime
Agreed I also like to see more support for MingW especially from open source projects. Not even a passing mention in this blog post.
Eww no. MingW is evil and no project should ever use it.
Just use Clang + MSVC STL + WinSDK. Very simple.
From the capitalization I can tell you and the parent might not be aware it's "minimal GNU for Windows" which I would tend to pronounce "min g w" and capitalize as "MinGW." I used to say ming. Now it's my little friend. Say hello to my little friend, mang.
I typically refer to it as “piece of garbage poop I don’t let infect my system”.
>MingW is evil
Care to elaborate?
I've been shipping Windows software for 20+ years. Not one project I have ever worked on was based on MinGW. It's a gross hack that is ABI incompatible with the predominate ecosystem.
In the year 2026 there is no reason to use MinGW. Just use Clang and target MSVC ABI. Cross-compiling Linux->Windows is very easy. Cross-compiling Windows->Linux is 1000x harder because Linux userspace is a clusterfuck of terrible design choices.
If a project "supports Windows" by only way of MinGW then it doesn't really support Windows. It's fundamentally incompatible with how almost all Windows software is developed. It's a huge red flag and a clear indicator that the project doesn't actually care about supporting Windows.
>> It's a gross hack
*taps on the name of this site*
If I'm writing some cross-platform bit of software, my interest in supporting Windows is naturally in producing binaries that run on Windows.
Why on earth should I give a flying toss how "almost all Windows software is developed", or which kinds of ABIs are BillG-kissed and approved? Good god. Talk about fetishising process over outcome.
I just eyerolled so hard I gave myself a migraine.
If your focus is on outcome that I promise and assure you that using MinGW will make producing a positive outcome significantly harder and more frustrating.
With modern Clang there really isn’t a justifiable reason to use MinGW.
I think the issues you're referring to are related to C++ ABI which is inherently incompatible between different compilers (and sometimes versions). This can be sometimes issue for plugins, though sane programs always use C wrappers.
I never had issues with C ABI, calling into other DLLs, creating DLLs, COM objects, or whatever. I fail to see what is fundamentally incompatible here.
Yes if you go pure C API and write libraries that conform to this and don’t pass owned memory around then sure that works.
MSVC is ABI stable since 2015. Many libraries that distribute pre-compiled binaries that rely on this stability. ~None of them include MinGW binaries in their matrix. (Debug/release X MT/MD).
Being a good citizen means meeting people where they are. Libraries and programs should expect to be integrated into other build systems and environments. I have literally never ever in my career worked in a Windows dev environment that used MinGW. The ~only reason to use MinGW is because you primarily use Linux and you want to half-ass do the bare minimum.
Interestingly I've never used Visual Studio on Windows (only for a brief time for ARM based PDAs where I could experience the infamous MFC which was okay to me despite the hate).
I've used Borland C++ and Watcom C/C++ back in the day and MinGW after that. Also COM was invented for interoperation between languages/compilers.
Being a good citizen means to not use the inherently unstable C++ ABI directly. You can use C API or even COM for that. Relying on it is cute but it's accidental and it will break in the future. Microsoft can't guarantee that it will stay stable because C++ is always evolving, forcing to break the compatibility.
Open source projects shouldn't depend on proprietary compilers (they can support them, but not as the only option). It just undermines the purpose of it.
The reasons I use MinGW is because it produces better compatible binaries on Windows, allowing me to support all Windows versions from Windows 2000 to latest with a single binary (and sometimes 64bit if there is a need/advantage) and it doesn't require me to bundle dozens of DLLs (or worse, installing them system-wide) and artifically limit the compatibility for no reason.
Breaking the compatibility is hostile to the users who can't or want to always use the latest Windows.
Why not use winget to do it?
`winget install --id Microsoft.VisualStudio.2022.BuildTools`.
If you need the Windows(/App) SDK too for the WinRT-features, you can add `winget install --id Microsoft.WindowsSDK.10.0.18362` and/or `winget install --id Microsoft.WindowsAppRuntime.1.8`
Having been the person that used to support those packages, it’s not that simple. You need to pass what workloads you need installed too, and if it’s a project you’re not familiar with god help you.
I used to just install the desktop development one and then work through the build errors until I got it to work, was somewhat painful. (Yes, .vsconfig makes this easier but it still didn’t catch everything when last I was into Windows dev).
You can do a lot of "native" windows development from modern C#/.NET via win32 interop.
Newer C# features like ref returns, structs, spans, et. al., make the overhead undetectable in many cases.
https://github.com/prasannavl/WinApi
https://github.com/microsoft/CsWin32
Exactly, the major pain point remains the .NET allergy from Windows team, but it is workable.
This is amazing.
At $workplace, we have a script that extracts a toolchain from a GitHub actions windows runner, packages it up, stuffs it into git LFS, which is then pulled by bazel as C++ toolchain.
This is the more scalable way, and I assume it could still somewhat easily be integrated into a bazel build.
Keeping CI entirely out of windows desktop development is the biggest efficiency and cost improvement I've seen in the last 15 years. Our CI toolchain broke so we moved back to a release manager doing it manually. It takes him 20x less time to build it and distribute it (scripted) than it does to maintain the CI pipeline and his desktop machine is several times faster than any cloud CI node we can get hold of.
Edit: Uses a shit load less actual energy than full-building a product thousands of times that never gets run.
This is really interesting. Do you think it’s possible server-deployed software could also get similar efficiencies with adequate testing?
Yeah it really doesn’t matter where you build stuff. The big push to CI is from companies that want to sell you a service to do it.
Software should build and test the same everywhere. If you have to use it, CI should only wrap that.
It starts by not looking into Windows through UNIX developer glasses.
The only issue currently plaguing Windows development is the mess with WinUI and WinAppSDK since Project Reunion, however they are relatively easy to ignore.
>It starts by not looking into Windows through UNIX developer glasses.
People don't need any UNIX biases to just want multiple versions of MSVS to work the way Microsoft advertises. For example, with every new version of Visual Studio, Microsoft always says you can install it side-by-side with an older version.
But every time, the new version of VS has a bug in the install somewhere that changes something that breaks old projects. It doesn't break for everybody or for all projects but it's always a recurring bug report with new versions. VS2019 broke something in existing VS2017 installs. VS2022 broke something in VS2019. etc.
The "side-by-side-installs-is-supposed-to-work-but-sometimes-doesn't" tradition continues with the latest VS2026 breaking something in VS2022. E.g. https://github.com/dotnet/sdk/issues/51796
I once installed VS2019 side-by-side with VS2017 and when I used VS2017 to re-open a VS2017 WinForms project, it had red squiggly lines in the editor when viewing cs files and the build failed. I now just install different versions of MSVS in totally separate virtual machines to avoid problems.
I predict that a future version VS2030 will have install bugs that breaks VS2026. The underlying issue that causes side-by-side bugs to re-appear is that MSVS installs are integrated very deeply into Windows. Puts files in c:\windows\system32, etc. (And sometimes you also get the random breakage with mismatched MSVCRT???.DLL files) To avoid future bugs, Microsoft would have to re-architect how MSVS works -- or "containerize" it to isolate it more.
In contrast, gcc/clang can have more isolation without each version interfering with each other.
I'm not arguing this thread's msvcup.exe tool is necessary but I understand the motivations to make MSVS less fragile and more predictable.
Note that this also doesn't work on Linux - your system's package manager probably has no idea how to install and handle having multiple versions of packages and headers.
That's why docker build environments are a thing - even on Windows.
Build scripts are complex, and even though I'm pretty sure VS offers pretty good support for having multiple SDK versions at the same time (that I've used), it only takes a single script that wasn't written with versioning in mind, to break the whole build.
> Note that this also doesn't work on Linux - your system's package manager probably has no idea how to install and handle having multiple versions of packages and headers.
But this isn’t true. Many distros package major versions of GCC/LLVM as separate packages, so you install and use more than one version in parallel, no Docker/etc required
It can indeed be true for some things-such as the C library-but often not for the compilers
The closest thing I saw to this was some vendors shipping their SDKs with half the desktop userland (in a similar 'blob' fashion the post complains about), with shell scripts setting up paths so that their libs and tools are found before system ones.
To give a concrete example of what I was talking about, RHEL has “gcc-toolset” for installing multiple GCC versions in parallel:
https://developers.redhat.com/articles/2025/04/16/gcc-and-gc...
this seems to be the same approach I saw with other SDKs (for example Qt), which I wrote about in my previous post - the official versions ship half the userland dependencies in a directory under /opt/
and use some scripts (chroot or LD_LIBRARY_PATH maybe, not an expert) to create a separate environment for the given toolset.
In RHEL8/9, there is a command "scl" which works by updating the PATH... so you can run "scl enable gcc-toolset-9 bash" to start a new bash shell using GCC 9.
In RHEL10, instead of "scl", each toolset has an independent command (actually just a shell script) like "gcc-toolset-9-env bash" which does the same thing
chroot or LD_LIBRARY_PATH isn't necessary, changing PATH is enough
Or in fact – this isn't RHEL scl system, but some other distros – some distros install alternative compilers using a prefix, so you just do `CC=PREFIX-gcc` (assuming you have a Makefile configured with the standard conventions)
e.g. for hobbyist/recreational reasons, I have done MS-DOS software development under Linux before. The DOS cross-compiler gets installed as "i586-pc-msdosdjgpp-gcc" so I just do "CC=i586-pc-msdosdjgpp-gcc make" to build my project for DOS instead of Linux.
Similarly, different clang versions are often installed with a version suffix. So in another project I had, I'd do "CC=clang-11 make" when I wanted to use clang 11 and "CC=clang-15 make" when I wanted to use clang 15. (You can tell from the version numbers I haven't touched that hobby project of mine for quite a while now.)
Until the day there is that symlink, or environment variable with the incorrect value.
Guix and Nix can do that. They were built from the ground up to be able to have multiple, simultaneous versions of everything installed in separate store, and you can request on a per shell basis what you want in your environment.
Yes. Any user interface toolkit that isn't at least 10 years old should be ignored on windows unless you want to rewrite everything one day.
Why? You may end up with something that doesn't get much attention anymore, but none of the official gui approaches have ever been removed as far as I know. Win32, MFC, winforms, wpf, winui, maui are all still available and apps using them are functional. Even winjs still works apparently, even if it was handed over.
I wouldn't start an app in most of them today, but I wouldn't rewrite one either without a good reason.
Well a number of them have horrific bugs in them which have zero attention. At least win32 has an abstraction level which allows you to work around them.
There’s a fun bug on WPF and form backgrounds for example which means on fractional DPI screens the background is tiled unpredictably. Had to patch that one up rather quickly one day and it was a mess due to how damn complicated WPF is.
I don't believe we'll get any toolkit without bugs in our lifetime. There are bugs in everything, but it doesn't prevent millions of different apps running using WPF every day.
I wonder if people still use WinForms, MFC and WPF...
We still use win32!
(granted we made our own MFC around it)
Still migrating an enterprise app off WPF to this day.
What are you moving to out of interest? I’ve seen people talking of moving ours to Electron which seems to just be more problems waiting.
They certainly do.
I'd guess WinForms is still the most popular widget library in Windows.
Or... you can
"winget install Microsoft.VisualStudio.BuildTools"
"winget install Microsoft.WindowsSDK.10.0.26100"
I thought for a moment I was missing something here. I always just use winget for this sort of thing as well. It may kickoff a bunch of things, but it’s pretty low effort and reliable.
But those are installed system wide. What if you have two different project with different requirements at the same time?
Every language should have a tool like Python uv.
> What if you have two different project with different requirements at the same time?
Install multiple versions of Windows SDK. They co-exist just fine; new versions don’t replace old ones. When I was an independent contractor, I had 4 versions of visual studio and 10 versions of windows SDK all installed at once, different projects used different ones.
You can provide custom options to winget, and in there where to install it too (and additional components you need).
Windows SDKs, WDKs (driver dev), Visual Studio releases, and .NET SDKs all coexist peacefully on a machine. If a project build breaks due to newer SDKs, it's because it was configured with "use newest version". (Which is usually fine but sometimes requires pinning if you're using more "niche" things like WDK)
Nearly all of the Windows hate i see comes from 20 year old takes . ( the bing/cortana / copilot / ads slop criticism is warranted, but is also easily disabled).
it's not ideal, but much much much better!
For big C++ projects, the .vsconfig import/export way of handling Visual Studio components has worked well for the large teams I'm on. Tell someone to import a .vsconfig and the Visual Studio Installer does everything. Only times we've had issues is from forgetting to update it with components/SDK changes.
Yeah, seems like this is just ignorance around .vsconfig files. Makes life way easier. You can also just use the VS Build Tools exe to install things instead of the full VS installer, if you plan to use a different IDE.
Can you use .vsconfig to tell Build Tools what your project needs?
Can you generate .vsconfig with Build Tools?
You pass in the --config param to import it.
Exporting this way might be possible but it wouldn't be as useful seeing as it would just grab everything you have installed instead of some minimal set used by some project.
One day I decided to port my text editor to Windows. Since it depends on pcre2 and treesitter, these two libraries had to be provided by the system.
In the span of ~2hrs I didn't manage to find a way to please Zig compiler to notice "system" libraries to link against.
Perhaps I'm too spoiled by installing a system wide dependency in a single command. Or Windows took a wrong turn a couple of decades ago and is very hostile to both developers and regular users.
I think providing purely-functional libraries as system dependencies that's tied to the whole tool chain at the time was the wrong decision by the Unix world.
The system libraries should only ship system stuff: interaction with the OS (I/O, graphics basics, process management), accessing network (DNS, IP and TLS). They should have stable APIs and ABIs.
Windows isn't hostile. It has a differnt paradigm and Unix (or more correctly usually GNU/Linux) people do not want to give up their worldview.
PCRE is basically only your apps's dependency. It has nothing else to do the rest of the operating system. So it is your responsibility to know how to build and package it.
If you depend on a library and can't figure out how you would compile against it, it's probably better for the end user that you don't make anything because you'll still need to package it up later unless you link statically.
System wide dependencies is fundamentally an awful idea that is wrong and you should never ever do it.
All dependencies should be vendored into your project.
This is the answer. I don’t know what is the best practise but for windows the easiest solution is to put the DLL in the same directory as the exe
I suspect the pitfall is how you or the zig compiler is linking. Unless you're involving things which vary by OS like hardware interaction, networking, file systems etc, you should not, with a new Lang in 2026, need to do anything special for cross-platform capabilities.
My understanding that "linkSystemLibrary" abstraction in build.zig only holds for Unix systems. And this in turn makes it impossible to build my program on Windows without modifying the build script.
What we did for out build agents was to just install the required version of build tools via chocolatey. But cool approach!
Nowadays you can also use winget for it.
Same. Choco solves this with a one-liner for me.
Nitpick, "Windows Native Development" also refers to the NT native subsystem, which would be basically coding against private APIs instead of Win32. From the title I thought that's what this was. Then I realized it was about avoiding full use of Visual Studio when building C projects (something that a lot of people already do by the way)
I would also read "Windows Native Development" as driver development or compiling directly with `nmake` (neither of which are described there).
> No Visual Studio installation. No GUI. No prayer. Just a script that does exactly what it says.
Yeah its obvious clanker writing. I don't even mind using LLM for code but this rubs the wrong way.
> It’s so vast that Microsoft distributes it with a sophisticated GUI installer where you navigate a maze of checkboxes, hunting for which “Workloads” or “Individual Components” contain the actual compiler. Select the wrong one and you might lose hours installing something you don’t need.
I have a vague memory of stumbling upon this hell when installing the ldc compiler for dlang [1].
1. https://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_u...
> On Linux, the toolchain is usually just a package manager command away. On the other hand, “Visual Studio” is thousands of components.
That package manager command, at the very least, pulls in 50+ packages of headers, compilers, and their dependencies from tens of independent projects, nearly each of them following its own release schedule. Linux distributions have it much harder orchestrating all of this, and yet it's Microsoft that cannot get its wholly-owned thing together.
Actually not that complicated: You simply check in a global.json [0] where you specify the sdk and workload versions.
Then you also specify target platform sdk versions in the .csproj file and VS will automatically prompt the developer to install the correct toolchain.
[0] https://learn.microsoft.com/en-us/dotnet/core/tools/global-j...
global.json is only for .NET toolchains.
What you’re actually wanting here is .vsconfig https://learn.microsoft.com/en-us/visualstudio/install/impor...
[dead]
> On Linux, the toolchain is usually just a package manager command away.
If you are compiling for your native system, yes.
But as soon as you try cross-compiling, you are in for a lot of pain.
I hope it would work with wine. Then cross compiling Win64 binaries from Linux would become convenient without requiring spinning up a Windows VM.
Just use Clang. Cross-compiling Linux->Windows is super duper easy.
Clang is a compiler, not a whole toolchain.
Yeah I noticed wine wasn't able to execute the MSI files. It also had a problem with the lock files. Both problems should be fixable though.
* Is this allowed per VS' ToS?
* I wonder if Microsoft intentionally doesn't provide this first party to force everyone to install VS, especially the professional/enterprise versions. One could imagine that we'd have a vsproject.toml file similar to pyproject.toml that just does everything when combined with a minimal command line tool. But that doesn't exist for some reason.
Microsoft doesn't seem to care unless you're a company. That's the reason community edition is free. Individual licenses would be pennies to them, and they gain more than that by having a new person making things in their ecosystem. It's in their interest to make their platform accessible as possible.
Visual Studio does have that functionality, via vsconfig files: https://learn.microsoft.com/en-us/visualstudio/install/impor...
Doesn't look like it's versioned, or installs Visual Studio itself.
For Visual Studio components that are versioned (like the C++ compilers/libraries), the version number is included in the component name.
You still have to install the tool that processes pyproject.toml so that doesn’t seem fair to hold against it. You are right that you still have to know whether to install 2022 or 2026.
Curl the VS Build tools exe, then run the build tools command to install what's in the .vsconfig.
WOW such a great work. Myself I have been struggling with Mingw just to compile from source. Of course it works much cleaner then the hated visual studio, but then when it comes to cuda compile, that´s it. Visual studio or the magority our there, It is invasive and full of bloatware like you say. Same struggle with electron.
How to match it with cuda to compile from source the repos?
Please add also the support for the clang-cl[1][2].
[1] https://clang.llvm.org/docs/MSVCCompatibility.html
[2] https://clang.llvm.org/docs/UsersManual.html#clang-cl
In the 1990s, I taught GUI programming with the following two books (not necessarily those editions). Is this post the tool chain to do that program creation from the command line for these? Now that I am retired from a third of a century as a computer science faculty member, I would like to resurrect those notes for a comprehensive learning module on GUI programming. (At the turn of the century, my University had me teach GUI programming with Java Swing.) In my opinion, all are wonderful as is old-fashioned x-Windows GUI programming and Visual Basic form development, both of which I briefly introduced to my students.
Programming Windows with MFC, Second Edition Subsequent Edition by Jeff Prosise (Author)
Programming Windows®, Fifth Edition (Microsoft Programming Series) Subsequent Edition by Charles Petzold (Author)
Came in getting ready to hate on this article, but was actually pleasantly surprised, this is great. Good work OP.
I was just setting up a new machine and was setting up the Rust environment. The very first thing rustup-init asked was to install Visual Studio before proceeding. It was like 20-30gb of stuff installed before moving forward.
This tool would be a great help if I knew beforehand.
And here I was messing with MingW64…
This is fantastic and someone at Microslop should take notes.
Exacly.. I avoid Visual Studio.. I try to build everthing using Mingw..
Clang is the better alternative to MinGW because it can use standard Windows libraries and avoids the need for additional runtime.
Can you actually do cross compilation (on Linux host to win64 binary) with clang in the same way as MingW does out of the box though?
No. You cannot even do direct compilation on the same host and target with clang only.
LLVM doesn't come with the C library headers (VCRuntime) or the executable runtime startup code (VCStartup).Both of which are under Visual Studio proprietary licenses. So to use Clang on Windows without Mingw, you need Visual Studio.
I use MingW without any extra libs (no msys), it just uses the ancient msvcrt.dll that is present in all Windows versions, so my programs work even on Windows 2000.
Additionally the cross-compiler on Linux also produces binaries with no extra runtime requirements.
You can use Mingw-w64 UCRT or CLANG environments that come with MSYS2.
Compared to older Mingw64 environments those link with the latest UCRT so you get almost the same style executable as Visual Studio.
The only difference for C is that it uses Mingw exception handling and global initialization code, and it uses Itanium ABI for C++.
But that's the point, I don't want the same style executable as Visual Studio. Having to distribute bunch of DLLs and having worse compatibility is pretty bad.
A major part of the incompatibility with older versions of Windows is just because newer VS runtimes cut the support artifically. That's it. Many programs would otherwise work as-is or with just a little help.
yeah, you can get away with this now a days because Git itself installs 2/3rds of the things you need anyway. You just need to finish the job by getting the package and putting the binaries in your git folder. Bam! mingw64, clang, what ever cc you need. It all links to standard windows stuff because you have to tell the linker where your win32.lib is. But this is true no matter the compiler, it's just Visual Studio supplies this in some god awful Program Files path.
Just msys2 it all
MSYS2 is horrible. It brings a massive runtime environment and is a bad idea to foist on users.
Aren’t you thinking of Cygwin, or the MSYS2 shell (dev tooling)?
The Windows-native software you build with MSYS2 can be shipped to and run by users that don’t have anything of MSYS2 installed.
He must be thinking of Cygwin as half of this is installed when you install git ;) Git Bash, etc…
MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw.
Git installs its own Mingw and Msys2 stuff but mostly compiled for a Mingw environment so they consume Windows paths natively instead of using MSYS2/Cygwin path conversion. That's why when you have mixed PATH variable all hell breaks loose with Git.
I think you’re underestimating or discounting the work the MSYS2 team put into their layered environments mechanism:
https://www.msys2.org/docs/environments/
I do appreciate it as a daily user of MSYS2. However the bigger thing that enabled them is indeed Cygwin project since it unlocked the path to build things that are using strict Unix tooling. autoconf, Make, bash etc cannot run under a pure Windows environment. They are too dependent to the underlying system being a Unix. To use pacman, bash and make in MSYS2, you need msys-2.0.dll. Even they cite Cygwin's URL in the runtime package [1]. And they basically patch Cygwin to enable this [2]
Without Cygwin enabling the path, it wouldn't be possible to build GCC for Windows without completely changing its build system. It would be a DOA fork while Mingw and PE32+ support is a part of GCC nowadays.
The nice and genius part of MSYS2 is that it is there to primarily encourage you to develop native Windows software that has better cross-platform behavior rather than Cygwin alone. If Microsoft made a better, free of charge C compiler in early 2000s that is adhering to the standards better, we wouldn't probably need Mingw to build cross-platform apps. Now MSVC is still free of charge for only open source and individuals.
[1] "Cygwin POSIX emulation engine", https://packages.msys2.org/base/msys2-runtime [2] https://github.com/msys2/MSYS2-packages/tree/master/msys2-ru...
Thank you for this insightful comment.
> MSYS2 just enough development environment
Doesn't it come with `pacman` too?
You need to update stuff somehow. `pacman` is a beautifully simple package manager. It covers the complexity just enough without going overboard.
Yes, it’s wonderful.
A repacked Cygwin is one environment, but the default uses the UCRT from Microsoft.
They all have to use MSVCRT or UCRT to stay compatible with other Windows programs and APIs like COM. And AFAIK nobody has developed a C library that's purely dependent on Win32 system APIs (it is possible just really hard). The difference is that Cygwin is trying to create this semi-isolated Unix environment to programs to think they are running under a complete Unix system like Wine does.
MSYS2 is there to just provide the basics so you can develop programs that are Windows native but use some of the tools that have really strong Unix dependence like shells or Make. They depend on the existence of syscalls like `fork` or forward slash being the directory seperator.
It was not clear what the parent commenter was addressing; I was under the impression they meant 'compile against the MSYS2 environment', which is broadly Cygwin, yes, which should not be forced onto a user.
Okay, but that just seems to be perpetuating the misunderstanding of what MSYS2 is intended for.
It gives you a *nix-like shell/dev environment and tools, but you build native software that runs on Windows systems that don’t have or need to have all/parts of MSYS2/Cygwin installed.
Example:
I built a network daemon using the MSYS2 CLANG64 environment and llvm toolchain on Windows 10.
Windows 7 x64 users could download the compiled single-file executable and run it just fine, so long as they installed Microsoft’s Universal C Runtime, which is a free download from Microsoft’s website.
> MSYS2 CLANG64
I get your point. Although my point is that there is actually zero need for MSYS at all for this, even as a developer, and especially not with the 'CLANG64' environment. These binaries themselves are built to run in the MSYS2 environment This is how I cross-compile from Windows... to Windows with LLVM-MinGW[1]:
[1]: https://github.com/mstorsjo/llvm-mingwI think you have it backwards, but I may misunderstand what you're saying.
I'm certain I haven't misunderstood the point of MSYS2's CLANG64 and other environments.
> These binaries themselves are built to run in the MSYS2 environment
I'm not sure if you're referring to the toolchain binaries or the binaries one produce's with them.
The CLANG64, etc. environments are 100% absolutely for certain for building software that can run outside of any MSYS2 environment!
You can, of course, build executables specifically intended to run inside those environments, but that’s not the primary use case.
> (gci Env:PATH).Value.Split(';') | sort
I don't want to use PowerShell or Cmd.exe when doing dev stuff on Windows. I want to do CLI work and author scripts in and for modern Bash, just like I would for Linux and macOS. I want to write Makefiles for GNU make, just like...
Now, sometimes there are bumps and sharp edges you have to deal with via `if [[ -v MSYSTEM ]]; then`, similar in Makefile, cygpath conversion, template/conditional code in sources, and so on. But that's a small price to pay, from my perspective, for staying in the same mental model for how to build software.
All msys2 does is give you a unified BSD experience and toolchain for compiling applications for any architecture and platform. Windows included.
There. I think that sums it up.
MSYS2 UCRT also uses the native Windows libraries (aka. UCRT).
I'll just keep using Mārtiņš Možeiko's script, portable-msvc.py, that this tool is based upon. It does everything this does, except a lock file and the autoenv. I'm not particularly interested in the former, and definitely not the latter.
https://gist.github.com/mmozeiko/7f3162ec2988e81e56d5c4e22cd...
I’ve found that just installing LLVM, CMake and Ninja is enough to get started developing on Windows for most things C/C++.
I am not exactly bounding with eagerness and time to contribute to an open source project but the few times I have looked I stop at the "how do I configure my dev environment to match" step.
Just give me a VM. Then you will know, and I will know, every facet of the environment the work was done in.
I like the tool, I like the article, but I'd prefer it it was half as long but without AI touch.
I don't get why people go through all these flaming hoops and hurdles to deal with MSVC when MinGW and MinGW-w64/MSYS2 are options. In the latter case you even still get (mostly complete) MSVC ABI-compatibility if you compile with clang.
MinGW and MinGW-64/MSYS2 are just as inscrutable, fragile and new-user-hostile. The fact that you have to choose between MinGW (which has a 64 bit version) or MinGW64 (completely separate codebases maintained by different people as far as I can tell) is just the first in a long obstacle course of decisions, traps, and unexplained acronyms/product names. There are dozens of different versions, pre-built toolchains and packages to throw you off-course if you choose the wrong one.
If you're just a guy trying to compile a C application on Windows, and you end up on the mingw-w64 downloads page, it's not exactly smooth sailing: https://www.mingw-w64.org/downloads/
> If you're just a guy trying to compile a C application on Windows, and you end up on the mingw-w64 downloads page, it's not exactly smooth sailing: https://www.mingw-w64.org/downloads/
One of the options on that page is MSYS2, which I specifically listed above alongside MinGW-w64. And that download page is much smoother sailing: https://www.msys2.org/
There are other options on the MinGW-w64 page, but most of those are for cross-compiling from non-Windows operating systems (which conceivably could include something running on WSL these days), and of the Windows-host options, the only two with “many” packages are Cygwin and MSYS2 (though WinLibs looks interesting).
Because it's fewer hoops and hurdles than using MinGW, in my experience.
MinGW/MSYS2 are flaming poop hurdles. That’s the bending over backwards to fake a hacky ass bad dev environment. Projects that only support MinGW on Windows are projecting “don’t take windows seriously”.
Supporting Windows without MinGW garbage is really really easy. Only supporting MinGW is saying “I don’t take this platform seriously so you should probably just ignore this project”.
Say what you want about coding agents, when the cost of writing code goes to near-zero, the cost of wrangling tools becomes a much bigger fraction of development effort. This is an amazing opportunity to address long-standing frictions.
Last I checked the license for the headless toolchain requires that a full licensed copy of Visual Studio be installed somewhere. So I think this violates the license terms.
A bug got opened against the rustup installing the headless toolchain by itself at some point. I'll see if I can find it
edit: VSCode bug states this more clearly https://github.com/microsoft/vscode/issues/95745
I don't really use Windows OS much, but why not just use MinGW? Then you have Clang on all platforms you can think of: Android, all the various Darwin flavors and of course Linux and Windows; as well as on platforms you can't think of like FreeBSD or even Haiku maybe? Like honestly what's the point of supporting MSVC at all?? Maybe I'm just not enough of a Windows nerd to understand? (so I'm basically wondering if mingw has any drawbacks)
If you have a self-contained project, where you don't depend on anyone else and others don't depend on you, MinGW works great. Problems arise when you have dependencies that don't work with it. I'd love to see if MinGW could find a way to be binary compatible with MSVC-compiled binaries. Right now it's kind of an all or nothing solution which makes it hard to adopt.
Ah, binary-only dependencies, right… That's very specific though, so unless you need to drive some proprietary hardware, why bother using stuff that forces you into MSVC hell lol? Also wouldn't LLVM based MinGW benefit from Clang's MSVC compat? Not sure about this at all, that's why I'm asking, heh… ^^"
As someone who has been doing Win32 development for literally decades, I'm not particularly convinced this is a problem that needs more code to solve. You don't need VS to get the compiler (which is available as a separate download called something like "build tools", I believe); and merely unpacking the download and setting a few environment variables is enough to get it working. It's easy to create a portable package of it.
We manage Visual Studio on our CI machines using Ansible. Chocolatey installs the full Visual Studio and then we use the APIs provided to manage components via Ansible. See our action here: https://galaxy.ansible.com/ui/repo/published/kitware/visuals...
Perhaps winget is enough?
winget install Microsoft.VisualStudio.2022.BuildTools
The Build Tools installer first installs the Visual Studio tool to select the workloads you want as well.
Let's say I want to compile a helloworld.cpp with no build tools installed yet.
What is the minimal winget command to get everything installed, ready for : cl main.cpp ?
Ps: I mean a winget command which does not ask anything, neither in command line, nor GUI ? Totally unattenfed.
The winget installer just downloads vs_buildtools.exe and runs it, which first installs vs_setup.exe and then that one prompts you for the workloads you want. I believe passing --silent to the winget installer will install vs_setup unattended but not any workloads from the Build Tools.
To install it all in a single step, and beware I haven't tested this, you're better off downloading and running yourself
adding whatever workloads you need.Then you'll need to locate and run vcvarsall.bat to setup the environment, which will require some clever code if you're doing it from PowerShell instead of a .bat, and then you can finally call the compiler.
Wondering....
Has anyone tried doing this on ReactOS? I know this is a touch DIY, but it would be interesting to know if Win sofware could be built on ReactOS...
I am not too into windows dev but I am currently using msvc at work. We are told to import a config file into the installer and it automatically selects all of the components any of our projects will need. Wouldn't that solve the problem too? Just distribute a project level config file and add documentation for how to import and install the stuff.
“Build Requirements: Install Visual Studio”.
You’ve never experienced genuine pain in your life. Have you tried to change the GCC compiler version in Linux?
If it’s not packaged and you’ve got to build it yourself, Godspeed. An if you’ve got to change libc versions…
GCC is surprisingly simple to build, fortunately.
Yeah it’s not too bad, but it does pull away from “so trivial it fits in a flippant HN comment”
Does it? Admittedly, it has been a while but I don't remember it differing too much from the good old ./configure && make paradigm with a few flags to both commands.
It’d fit in a comment, but not a flippant one ;)
Windows Native is fine. People in that space are comfortable with it.
What needs to be fixed is the valley between unix and windows development for cross-os/many-compiler builds, so one that does both can work seamlessly.
It's not an easy problem and there are lots of faux solutions that seem to fix it all but don't (in builds, the devil is in edge cases).
I seriously doubt that people who get confused by the MSVC++ Installer will be able to handle a CLI app that installs a mystery MSVC++ toolchain version to a versioned directory. They're still going to click the Visual Studio icon on their desktop and scratch their head why your script didn't magically fix their problems.
The ironic part is that Visual Studio may be the best product Microsoft has ever made. Compared to the rest of their offerings, it is nothing short of amazing. It boggles the mind to know that this was developed in-house - well most of it anyways.
Were you around before the new installer came out? It was light speed compared to what was before!
I'm not trying to diminish or take away from this post but Visual Studio is an IDE and is not necessary to build an App.
You just need the required build tools.
If you've ever had to setup a CI/CD pipeline for a Visual Studio project then you've had to do this.
You can also install visual studio build tools via the built in winget package manager.
> You spend less time on your project because you’re too busy being a human-powered dependency resolver for a 50GB IDE.
Really? A 50GB IDE? How the heck one knows what goes in there?
My beloved FreeBSD 15.0 PLUS its Linux VM PLUS its docker env PLUS its dependencies and IDE are close to 26Gb and pretty sure I'm taking into account a lot of things I shouldn't, so the actual count is much less than that.
Developing software under a Windows platform is something that I cannot understand, since many many many years ago.
As someone who is out of the loop on Windows development, is this related to the Windows Driver Kit (WDK, I think it used to be DDK)? That's a certain type of hell I don't wish upon most.
No one should use any of these weird Frankenstein monstrosities in 2026. And a batch script? :( PowerShell exists.
Install:
Load the 'VSDevShell' DLL[2] for PowerShell, and you're good to go, with three different toolchains now: Done and dusted. Load these into a CMake toolchain and never look at them again.People really like overcomplicating their lives.
At the same time, learn the drawbacks of all toolchains and use what is appropriate for your needs. If you want to write Windows drivers, then forget about anything non-MSVC (unless you really want to do things the hard way for the hell of it). link.exe is slow as molasses, but can do incremental linking natively. cl.exe's code gen is (sometimes) slightly worse than Clang's. The MinGW ABI does not understand things like SAL annotations[3], and this breaks very useful libraries like WIL[4] (or libraries built on top of them, like the Azure C++ SDK[5] The MinGW headers sometimes straight up miss newer features that the Windows SDK comes with, like cfapi.h[6].
[1]: https://github.com/mstorsjo/llvm-mingw
[2]: https://learn.microsoft.com/en-gb/visualstudio/ide/reference...
[3]: https://learn.microsoft.com/en-gb/cpp/c-runtime-library/sal-...
[4]: https://github.com/microsoft/wil
[5]: https://github.com/Azure/azure-sdk-for-cpp
[6]: https://learn.microsoft.com/en-gb/windows/win32/cfapi/build-...
LLVM-MinGW sounds external to Microsoft though. I think the blog focused on in-Microsoft solutions. And I am not sure the "contrary to the blog content" is valid - compared to Linux, the Microsoft stack is much more annoying to install. I installed it, but it was annoying to no ends and took ages.
Good to know LLVM works on windows too though.
> compared to Linux, the Microsoft stack is much more annoying to install.
Not really. It's just different. As a cross-platform dev, all desktop OSs have their own idiosyncracies that add up to a net of 'they are all equally rather bad'.
CMD.EXE is fine. I'd rather use bash than the abomination that is PowersHell.
MinGW is the most monstrous of monstrosity. Never in a million years touch that garbage.
I dunno, it has its uses when porting software written for UNIX-first. Plus, I pointed out Clang, rather than GCC, because Clang is natively a cross-compiler. I don't like to be dogmatic about stuff; if it's useful then it's useful. If it isn't then I will say why (as I explained why there's no need for MSYS2/Cygwin below).
Unix-first software on Windows is extremely irritating. Do it right or don’t do it at all. Especially when doing it right is actually super easy. You just have to care.
next, wrap it with wine and eventually share a bottle/winetrick
Please people, stop trying to fix windows and just let it die.
> msvcup is inspired by a small Python script written by Mārtiņš Možeiko.
This script is great. Just use it. The title saying “I fixed” is moderately offensive glory stealing.
it's been 14 years since i've used msvc for anything real. iirc the philosophy back then was yearly versioned releases with rolling intermediate updates.
this seems to go down the road towards attempts at determinsticish builds which i think is probably a bad idea since the whole ecosystem is built on rolling updates and a partial move towards pinning dependencies (using bespoke tools) could get complicated.
I havent run into this problem yet... but my oldest .net software is only 1 year old... Is this something that happens over the course of a few years?
This is about native development (C++), not .NET.
Thank you
these seems overly dramatic...i just setup a windows 11 box and installed the needed tools quite quickly via winget and I was up and running
So this fixes the problem when msvc is the required compiler. Does the zig C++ compiler bring anything to the table when clang is an option?
You still need headers and libraries that ship with MSVC.
If you are looking to rapidly build windows native apps just use Delphi. Superlative tool for this. Been using since ‘95
mmozeiko "fixed" windows native development, just use their script. Also PortableBuildTools already exists https://github.com/Data-Oriented-House/PortableBuildTools
>The key insight
are we doomed to only read AI slop from now on? to get a couple paragraphs in and suddenly be hit with the realization that is AI?
it's all so tiresome
I literally came to post the exact same line as my indicator that this was AI-generated. I ctrl-f'd first and sure enough I'm not alone in using 'key insight' as the canary.
Thank you, this might be a great way to improve the developer experience in the conda/conda-forge ecosystem.
“Don’t do it”
I fixed windows native development. Band together friends, force WSL3 as the backbone of Windows.
Another option is explore winget and chocolaty. Most build tools and compilers can be installed via the command line on windows. Ask your favorite LLM to create a powershell script to install them all.
c3 does this automatically, I implemented the same thing :)
https://github.com/c3lang/c3c/pull/2854
I don't understand, just use scite editor with tcc. About a couple of megs download, no install required and your apps will run on everything from win 98 to linux with wine. And if the answer is c++ support then you get all the pain you deserve using that cursed language
I thought the title was clickbait, but no, he really did fix it! Nice
Step 1. Wipe computer
Step 2. Install your preferred flavor of Linux
Step 3. Set-up dev tools
Step 4. Profit??
> Hours-long waits: You spend an afternoon watching a progress bar download 15GB just to get a 50MB compiler.
What year is it?! Also, haven't heard any complaints regarding VS on MacOS, how ironic...
This is a serious quality of life improvement for people forced to deal with Windows! Great job.
Why not just use Linux?
Because some developers would like to make money at some point.
Then why would they make applications for a dying platform? Is there some budding market for native win32 apps that I'm not aware of?
To play devils advocate, Linux does pose some issues as far as a stable platform base. They don't even guarantee glibc compatibility afaik.
To me it seems as if Microsoft wants to make it deliberately harder to have software developers. Now - I installed all the required things and compiled on Windows too, but it is very annoying compared to Linux. Microsoft should simply have ONE default build, e. g. "download this and 80% of developers will be happy". No need for a gazillion checkboxes.
just use w64devkit, it's nice
> I fixed
> msvcup is inspired by a small Python script written by Mārtiņš Možeiko.
No. Martins fixed. OP made a worse layer on top of Martins great script.
rm -fr /
[dead]
[dead]
I will never cease to be amused by these 'Unixhead has to do windev. Reinvents the wheel' blog posts.
[dead]
Nix on Windows when...
Since roughly September 2022 with the release of WSL 0.67.6!
Have you actually attempted to use it recently? Are you familiar with the WSL1 bugs that surface when running random Linux distros?
(To be clear, I haven't tried this with Nix, but I have with other distros.)
Fair question! Nope. I'm not endorsing it, and certainly don't know (or even suspect) it would solve this issue. I just recently installed NixOS and was surprised to see Windows mentioned on the downloads page, so looked into it a bit. Maybe soon.
Okay well, if you do, good luck with glibc (and likely other) issues. WSL1 feels kind of dead unfortunately, neither Windows wants to support newer Linux syscalls nor do Linux projects seem to care for including fallbacks.
Let me paraphrase: nix FOR windows
[dead]
[dead]
Trollish usernames aren't allowed on HN, so we've banned this account*. If you want to pick a different username that isn't trollish, we can rename the account and unban it. It would be best to email hn@ycombinator.com for this, to make sure we get the message.
(It would have been better for us to catch this sooner, but in this case someone had to explain the name to me. Out of respect for HN's many Francophone readers, I think it's best to apply the rule.)
* https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
Gross ignorance and incompetence.
TLDR: I don't understand my native command line, see how lost I got when I tried to do my thing in a different environment.
- Not a unique problem to Windows or even MSVC; He's gonna hate XCode, - Making Python a bootstrap dependency = fail, - Lacks self-awareness to recognize aversion vs avoidance,
My background is distinctly non-Windows, but I survive around Windows so well that people think I'm a Mickeysoft type. And no, I don't use mingw, cygwin, ...
If any of the obstacles this user faced were legitimate, nobody would ever make any money on Windows, including and especially Microsoft - a company whose developers have the same challenges.
I'm being harsh because _mea quondam culpa_ and it's correctable.
Everything this user went thru is the result of aversion instead of avoidance.
To _avoid_ long deep dives into Windows, you need to recognize there is a different vocabulary and a radically different jargon dialect at play.
1. Learn a tiny minimum of Powershell; it's based on the same POSIX spec as bash and zsh, but like Python, Javascript, etc, instead of byte as the fundamental unit, they use objects. So there's less to learn to reach a greater level of convenience than soiling yourself with DOS/CMD/BAT. On Windows, pwsh has a default set of linux-like aliases to minimize the learning required for minimal operability. And never have to type \ instead of / for a directory separator.
2. Microsoft make money from training. To sell their meat-free steak (* ingredient: saw dust), they feed the suits an all-you-can-eat calorie, nutrition, and protein free buffet of documenting everything in great detail and routinely "streamlining" the names and terminology.
Development on Windows is in a different reference frame, but relative to their own reference frames, they're ultimately not all that different.
Approach in your "foreign language" mindset; English alphabet but the words mean different things.
3. What not how. "How do I grep" means you are trying to random access bytes out of a random access character stream. "What's the command to search for text in files?" well, if you're bloody mindedly using cmd, then it's "find".
4. Seriously, learn a little Powershell.
I only approached Powershell hoping to gain material for a #SatansSphincter anti-ms rant while using it as a Rosetta Stone for porting shell scripts in our CI for Windows.
I mean, it is based on the same POSIX spec as sh, bash, and zsh, with a little Perl thrown in. That can't not go horribly, insidiously, 30-rock wrong in the hands of MS, right?
Turned out, it's the same paradigm shift perl/shell users have to make when coming into Python:
from `system("ps | grep hung")` to `"hung" in system("ps")`; from `system("ifconfig -a | sed 's/\<192\.168\.0\./10.0.0./g'")` to `system("ifconfig -a").replace("192.168.0.", "10.0.0.")`
`grep` is a command that applies an assumption to a byte stream, often the output of a command.
In powershell, executing a command is an expression. In the case of a simple command, like "ps", that expression resolves to a String, just like system(...) does in Python.
Learning even a small amount of Powershell is immensely helpful in better understanding your enemy if you're going to have to deal with Windows. The formal names for official things use "verb-singularnoun".
That last part of the convention is the magic: the naming of things on Windows is madness designed to sell certifications, so crazy even MS ultimately had to provide themselves a guide.
Is this even legal?
I just avoid Windows and Windows development. If I get paid to do it I don't mind the shittyness.
At the risk of being that guy, I haven't had any issues onboarding people onto native projects written in Rust. rustup does a great job of fetching the required toolchains without issue. I'd imagine the same is also true of Go or Zig.
While Microsoft <3 Rust, there are still some quality tooling parity to reach versus Visual Studio abilities for .NET, Python and C++.
Incremental compilation, and linking, parallel builds, hot code reloading, REPL, graphical debugging optimised builds, GPU debugging....
Go is better left for devops stuff like Docker and Kubernetes, and Zig remains to be seen when it becomes industry relevant beyond HN and Reddit forums.
I'm pretty people who write and build C++ on Windows do it for good reasons, often reasons that are out of their control. Your comment is not going to make any difference.
Before rustup can run, the very first message rustup-init spits out is asking to install the visual studio tool chain.
You have to do this for certain rust things too. I can't remember which, but I inevitably run into a need to install the MSVC toolchain to compile rust. I think it might be related to FFI, or libs which use FFI? The same thing comes up in Linux, but the process to install it is different.
I got anxiety reading the article, describing exactly why it sucks. It's nice to know from the article and comments here there are ways around it, but the way I have been doing it was the "hope I check the right checkboxes and wait a few hours" plan. There is usually one "super checkbox" that will do the right things.
I have to do this once per OS [re]install generally.
It makes use of MSVC linking infrastructure, and import libraries.
You can't really use Rust in the real world without interfacing a lot of C/C++ libraries, so yes this is still relevant.
I'm just asking, but is there really a need for a native programs anymore? Where I worked a decade ago, we started porting all our native programs over to the browser and this was when MVC beta was just being released. At this point with Electron and Tauri, is there even a need to write a native program
Now with AI, I would think that porting a native program to the browser wouldn't be the chore it once was.
Yes, very definitely. There has always been a need for high performance native applications. Even in the beginning of the desktop computing revolution, these questions have been asked .. and yes, there is a balance between native and cloud/browser-based computing - some of it is personal, much of it is industrial and corporate, and yet more of the spectrum where both methods are applicable exists, even still, decades later.
> is there really a need for a native programs anymore
As long as you don't give a shit about the fact that your baseline memory consumption is now 500MB instead of 25MB, and that 80% of your CPU time is wasted on running javascript through a JIT and rendering HTML instead of doing logic, no.
If you don't give a shit about your users or their time, there's indeed no longer a need to write native programs.
what if caring about users means giving them features instead of fighting with obsolete unproductive native GUI frameworks
funny how Electron apps tend to have many more users than their native "performant" counterparts, isn't it?
Where do you think Linux gamers get their Proton powered games from?
I use COM and DLLs to extend software/automate. Using Visual Studio gives me some really nice debugging options.
I did try using python and js but the variable explorer is garbage due to 'late binding'.
I thought this was just my ignorance, but I've asked experts, AI, and google searched and they unfortunately agree. That said, some people have created their own log/prints so they don't need to deal with it.