Ich habe die native Windows-Entwicklungsumgebung repariert

(marler8997.github.io)

8 Punkte von GN⁺ 2026-02-16 | 5 Kommentare | Auf WhatsApp teilen

Native Windows-Entwicklung ist durch die Abhängigkeit von der Installation von Visual Studio komplex und ineffizient
Installationsgrößen von mehreren Dutzend GB, intransparente Verwaltung von Komponenten und Probleme durch Versionsabweichungen senken die Produktivität von Entwicklern
Um das zu lösen, wurde das leichtgewichtige CLI-Tool msvcup entwickelt, mit dem sich MSVC-Toolchain und Windows SDK versionsweise und isoliert automatisch installieren lassen
msvcup bietet durch Parsing von JSON-Manifests, automatische Umgebungseinrichtung (autoenv) und Unterstützung für Lock-Dateien reproduzierbare Build-Umgebungen
Dieser Ansatz macht ein vollständig automatisiertes, skriptbasiertes Build-System möglich, ohne vom Visual Studio Installer abhängig zu sein

Probleme der nativen Windows-Entwicklung

Der bisherige Ansatz, Visual Studio installieren zu müssen, belastet Entwickler durch einen komplizierten Installationsprozess und instabiles Abhängigkeitsmanagement
- Erfordert detaillierte Auswahl wie den Workload „Desktop development with C++“ oder bestimmte SDK-Versionen; bei falscher Auswahl schlägt der Build fehl
- Die Installation kann 50 GB erreichen, und selbst nach der Deinstallation bleiben Registry-Reste und Hintergrunddienste zurück
Unter Linux lässt sich eine Toolchain mit einer einzigen Paketmanager-Zeile installieren, unter Windows müssen dagegen Tausende Komponenten manuell ausgewählt werden
Visual Studio ist eine monolithische Struktur, in der Editor, Compiler und SDK miteinander verknüpft sind, was Versionsverwaltung und reproduzierbare Umgebungen erschwert
Dadurch treten häufig Inkonsistenzen nach dem Muster „auf meinem PC funktioniert es“ auf, was als Einstiegshürde für native Entwicklung wirkt

msvcup: ein neuer Ansatz

msvcup ist ein Open-Source-CLI-Tool, das MSVC-Toolchain und Windows SDK direkt herunterlädt und installiert, ganz ohne Visual-Studio-Installation
- Jede Version wird in einem isolierten Verzeichnis unter C:\msvcup\ installiert, sodass mehrere Versionen parallel ohne Konflikte genutzt werden können
- Die Installation ist in wenigen Minuten abgeschlossen, inklusive ARM-Cross-Compile-Tools
Der Befehl msvcup install installiert die benötigten Pakete, und der Befehl autoenv erzeugt ein automatisches Umgebungsverzeichnis
- Dieses Verzeichnis enthält Wrapper-Executables, die Umgebungsvariablen automatisch setzen, sowie eine Datei toolchain.cmake, sodass sich auch CMake-Projekte ohne zusätzliche Konfiguration bauen lassen
Anzeige
Im Beispielskript build.bat lässt sich ein „Hello, World“-Programm mit msvcup ohne Visual Studio bauen
- Funktioniert unter Windows 10 oder neuer, solange curl und tar vorhanden sind

Funktionsweise im Inneren

Es werden die von Microsoft bereitgestellten JSON-Manifests für Visual-Studio-Komponenten geparst, um nur die benötigten Pakete zu identifizieren
- Kernbestandteile wie Compiler, Linker, Header und Bibliotheken werden direkt vom Microsoft-CDN heruntergeladen
Installierte Komponenten werden über eine Lock-Datei (lock file) verwaltet, sodass das gesamte Team dieselben Paketversionen gemeinsam nutzen kann
Die Befehle install und autoenv sind idempotent, und wenn bereits alles installiert ist, sind sie in wenigen Millisekunden abgeschlossen

Praxisbeispiel

Tuple (Pair-Programming-App) hat msvcup in sein CI-Build-System integriert und damit die Anforderung entfernt, Visual Studio vorab zu installieren
- Hunderte C/C++-Projekte einschließlich WebRTC lassen sich mit derselben Toolchain/demselben SDK bauen
- Unterstützt sowohl x86_64- als auch ARM-Builds
Anzeige
Vorteile
- Durch versionsweise Verzeichnisinstallation sind parallele Versionsverwaltung und einfache Neuinstallation möglich
- Automatische Unterstützung für Cross-Compilation, keine separate Konfiguration erforderlich
- Reproduzierbarkeit auf Basis von Lock-Dateien, Änderungen auf Microsoft-Seite werden sofort sichtbar
- Hohe Ausführungsgeschwindigkeit, keine unnötigen Neuinstallationen

Grenzen und Erweiterung

msvcup ist auf die Compiler-Toolchain ausgerichtet; wenn die Visual-Studio-IDE selbst benötigt wird, ist die offizielle Installation weiterhin erforderlich
In den meisten nativen Entwicklungs-Workflows bietet es jedoch eine vollständige Build-Umgebung auch ohne IDE
Das als Beispiel gezeigte raylib-Build-Skript installiert SDK und Toolchain automatisch und baut das Projekt auch ohne Visual Studio
- Vollständig automatisierter Build-Prozess nur über die Kommandozeile, ohne GUI

Fazit

msvcup beseitigt die Komplexität des Visual Studio Installers und bietet eine leichtgewichtige native Build-Umgebung mit Versionskontrolle
Dieser Ansatz macht native Windows-Entwicklung reproduzierbar und automatisiert und hilft Entwicklern, sich von der IDE-Abhängigkeit zu lösen
Repo : https://github.com/marler8997/msvcup

5 Kommentare

GN⁺ 2026-02-16

Hacker-News-Kommentare

Das wirkt komplizierter als das, was ich normalerweise mache.
Man installiert einfach die LTSC Visual Studio Build Tools und packt einen Befehl wie cl yourprogram.c /link user32.lib advapi32.lib ... in eine cmd-Datei.
Ich bearbeite mit vim und habe auf diese Weise verschiedene Utilities gebaut.
In der Visual-Studio-Toolchain gibt es LTSC- und stabile Versionen, aber die meisten wissen das nicht.
In einer Team-Umgebung ist es besser, eine feste Version aus der offiziellen Release-History-Dokumentation zu verwenden.
So wie früher, als die ganze Firma auf dieselbe Toolchain-Version festgelegt war.
- Auf den LTSC-Kanal kann man nur mit einer Visual Studio Professional-oder-höher-Lizenz zugreifen.
  Deshalb kennen Studierende oder Hobbyentwickler das oft nicht.
  Wer in Unternehmen mit VS arbeitet, weiß das dagegen meistens.
- Für Visual Studio 2026 gibt es noch kein LTSC-Release.
  Weiß jemand, wann das kommen soll?
Auch die Toolchains unter Linux sind nicht frei von der Dependency-Hölle.
Man installiert ein npm-Paket und plötzlich braucht man cmake, es gibt glibc-Versionskonflikte oder ein C++-Projekt verlangt das neueste boost usw.
Ich erinnere mich auch noch daran, wie wir zu Heartbleed-Zeiten openSSL patchen mussten.
Visual Studio ist zwar unbequem, aber die echte Hölle ist die Verwirrung rund um .NET-Framework-Versionen.
Je nach Windows-Version ist eine andere .NET-Version installiert, und oft ist unklar, unter welcher Runtime eine App laufen wird.
Deshalb muss man bei großflächigen Deployments in C++ einen Shim zur Prüfung der .NET-Version bauen, damit die Anwendung mit der richtigen Runtime startet.
- Dass glibc selbst Abhängigkeitsprobleme verursacht, ist so selten, dass ich fast schon davon hören möchte.
  Das glibc-Team ist bei Abwärts- und Aufwärtskompatibilität extrem strikt.
  Im LWN-Artikel steht, wann zuletzt die Kompatibilität gebrochen wurde.
  Das Problem ist eher, dass Leute die glibc-Version falsch pinnen.
  glibc sollte man nicht pinnen.
  GCC hat ein paar Mal die Kompatibilität gebrochen, aber meist wegen Änderungen im C++-Standard.
- Das moderne .NET ist völlig anders.
  .NET Framework ist bereits Legacy, und seit .NET 5 gibt es diese Probleme nicht mehr.
  Es gibt nur weiterhin viele Apps, die von alten Versionen abhängen.
- Früher reichte in der C/C++-Entwicklung der System-Paketmanager aus, aber wegen Problemen mit aktuellen Versionen entstanden sprachspezifische Paketmanager.
  Sie haben zwar Probleme gelöst, gleichzeitig aber neue Komplexität geschaffen.
  Manchmal möchte ich einfach zur Zeit der System-Paketmanager zurück.
- Die Build-UX-Reibung bei C/C++ ist unabhängig von Speichersicherheit einfach nervig.
  Im Embedded-Bereich ist rust + probe-rs deutlich angenehmer.
Der Visual-Studio-Installer unterstützt unbeaufsichtigte Installationen über Kommandozeilenparameter.
Das ist in der offiziellen Dokumentation beschrieben.
2018, als ich in einer Umgebung mit langsamem Satelliteninternet gearbeitet habe, habe ich diese Methode benutzt, um ein Offline-Installationspaket zu erstellen.
- Ich habe es ausprobiert, aber es wurden immer noch zu viele unnötige Downloads durchgeführt, und für die Installation brauchte man weiterhin Administratorrechte.
- (Bei einer Verbindung mit hoher Latenz … „high-latency“ wäre wohl der passendere Ausdruck.)
Wenn man sich das Skript ansieht, steht da
curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...
in dieser Art.
Aber ich installiere ungern ausführbare Dateien von einem GitHub-Account unbekannter Herkunft ohne Hash-Prüfung.
Die Lage unter Windows ist nicht ganz so schlimm, wie der Blog behauptet, aber das hier wirkt weniger wie eine Lösung als wie noch ein weiteres riskantes Installationsskript.
- Man muss nicht unbedingt eine ausführbare Datei installieren.
  Man kann das Skript einfach selbst lesen und prüfen.
  Auch der curl|sh-Ansatz lädt am Ende nur Quellcode herunter und ist nicht riskanter, als direkt eine ausführbare Datei zu installieren.
- Jonathan Marler ist durch Zig-Vorträge und seine Arbeit an win32-API-Bindings bekannt.
  Sein Projekt zigwin32 ist auch in Microsofts win32metadata verlinkt.
  Er ist also eine vertrauenswürdige Person.
Dieser Beitrag wirkt, als wäre er von einer KI geschrieben.
Satzmuster wie „it’s not just X, but Y“ oder diese hervorgehobenen Listen sind ein typischer LLM-Stil.
Ich frage mich, wie viel an dem Projekt tatsächlich von Menschen gemacht wurde.
- Dass dein Nickname „its_notjack“ ist, ist irgendwie lustig.
- Ich war anfangs auch misstrauisch.
  Die Listenstruktur wirkte seltsam und nicht besonders konsistent.
  Aber falls es tatsächlich von einem LLM geschrieben wurde, wäre das auch ein Hinweis darauf, wie stark die Qualität heutiger LLMs gestiegen ist.
  Es könnte auch am Einfluss von Tools wie Grammarly liegen.
- Vielleicht ahmen Menschen inzwischen den LLM-Stil nach.
  Er lässt sich für Leser schließlich gut konsumieren.
- Formulierungen wie „The key insight is …“ klingen nach einem Stil, den Claude oft benutzt, daher dieser Eindruck.
  Ich fände es einfach ehrlich gut, wenn man offenlegen würde, ob KI verwendet wurde.
Als Versuch, die Visual-Studio-DX zu verbessern, ist msvcup wirklich erfrischend.
So etwas hätte ich mir früher im Studium gewünscht.
Als Alternative gibt es auch den Ansatz, Build Tools in einem Container zu installieren.
Man kann es auch einfach mit winget installieren.
winget install --id Microsoft.VisualStudio.2022.BuildTools
Falls man WinRT-Funktionen braucht:
winget install --id Microsoft.WindowsSDK.10.0.18362
winget install --id Microsoft.WindowsAppRuntime.1.8 kann man zusätzlich installieren.
- Ich habe diese Pakete früher unterstützt, aber so einfach ist es nicht.
  Man muss auch festlegen, welche Workloads installiert werden sollen, und ohne Projektkenntnis gibt es viel Trial-and-Error.
  .vsconfig hilft etwas, ist aber nicht perfekt.
Ich wünschte, Open-Source-Projekte würden die MinGW-Unterstützung nicht blockieren.
Das ist ein guter Compiler, der auch ohne zusätzliche DLLs gut funktioniert.
Ich verstehe nicht, warum Open Source unbedingt einen proprietären Compiler erzwingen sollte.
- MinGW ist mit manchen Windows-spezifischen Bibliotheken (WIL) nicht kompatibel.
  WIL ist eine Bibliothek, die Kernel-Entwickler gern verwenden und die Sicherheit und Komfort des Codes stark verbessert.
- Wenn man extern gebaute MSVC-Bibliotheken linken muss, ist MinGW keine Option.
  Das Steamworks SDK lässt sich zum Beispiel mit MinGW bauen, crasht aber zur Laufzeit.
- Ich hätte auch gern mehr MinGW-Unterstützung.
  Schade, dass dieser Blogbeitrag es nicht einmal erwähnt.
- Ich mag MinGW nicht.
  Die Kombination Clang + MSVC STL + WinSDK ist einfach deutlich sauberer.
Oder man macht es einfach so:
"winget install Microsoft.VisualStudio.BuildTools"
"winget install Microsoft.WindowsSDK.10.0.26100"
- Ich mache es auch immer so.
  Wegen der guten Stabilität im Verhältnis zum Aufwand bevorzuge ich diesen Weg.
- Solche Installationen gelten aber systemweit, was problematisch ist, wenn man projektweise unterschiedliche Versionen braucht.
  Ich wünschte, es gäbe für jede Sprache ein Tool zur Versionsisolierung wie Python uv.
- Ein großer Teil der Windows-Kritik stammt noch aus Geschichten von vor 20 Jahren.
  Dinge wie Bing, Copilot oder Werbung kann man durchaus kritisieren, aber das meiste lässt sich deaktivieren.

click 2026-02-16

Ich hatte auch beim Build unter Ubuntu 24.04 und beim Versuch, es unter CentOS 6 oder 7 auszuführen, Probleme mit der glibc-Abhängigkeit.
Es scheint das Problem zu sein, dass standardmäßig die glibc-Version der Build-Umgebung übernommen wird.

penza1 2026-02-18

Auf glibc ist man zwangsläufig angewiesen..
Bei nicht skriptbasierten Sprachen wie Python/JV/.NET/JS lässt sich eine Abhängigkeit von glibc kaum vermeiden.
Das ist auch einer der Gründe, warum Bibliotheken für die einzelnen Distributionen verteilt werden.
Wenn etwas mindestens mit glibc gebaut wurde und keine besonderen Abhängigkeiten hat, kann es in der Regel auch auf anderen Distributionen mit höherer Version problemlos ausgeführt werden.

geekbini 2026-02-16

Mit WSL2 und Ubuntu ist Windows inzwischen deutlich besser zum Entwickeln geworden. Wenn man aber nicht mit VS Code, sondern in einer Visual-Studio-Umgebung arbeitet, scheint das immerhin noch etwas hilfreich zu sein. Allerdings sieht es so aus, als ob das unter Windows nicht einfach mit einem Paketmanager wie choco oder winget geht.