alt Hacker NewsI Fixed Windows Native Development
Comments
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.
> 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!
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.
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.
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’ve found that just installing LLVM, CMake and Ninja is enough to get started developing on Windows for most things C/C++.
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...
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`
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.
Or... you can
"winget install Microsoft.VisualStudio.BuildTools"
"winget install Microsoft.WindowsSDK.10.0.26100"
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.
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)
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.
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)
> No Visual Studio installation. No GUI. No prayer. Just a script that does exactly what it says.
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...
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.
What we did for out build agents was to just install the required version of build tools via chocolatey. But cool approach!
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.
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.
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
> 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...
* 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.
I hope it would work with wine. Then cross compiling Win64 binaries from Linux would become convenient without requiring spinning up a Windows VM.
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?
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.
> 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.
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.
c3 does this automatically, I implemented the same thing :)
Came in getting ready to hate on this article, but was actually pleasantly surprised, this is great. Good work OP.
Please add also the support for the clang-cl[1][2].
And here I was messing with MingW64…
This is fantastic and someone at Microslop should take notes.
“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?
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.
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...
Perhaps winget is enough?
winget install Microsoft.VisualStudio.2022.BuildTools
You can also install visual studio build tools via the built in winget package manager.
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]
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++.
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-...
mmozeiko "fixed" windows native development, just use their script. Also PortableBuildTools already exists https://github.com/Data-Oriented-House/PortableBuildTools
Were you around before the new installer came out? It was light speed compared to what was before!
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.
> 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 will never cease to be amused by these 'Unixhead has to do windev. Reinvents the wheel' blog posts.
If you are looking to rapidly build windows native apps just use Delphi. Superlative tool for this. Been using since ‘95
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.
next, wrap it with wine and eventually share a bottle/winetrick
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?
Thank you, this might be a great way to improve the developer experience in the conda/conda-forge ecosystem.
> 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 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...