Arreglé el entorno nativo de desarrollo en Windows

(marler8997.github.io)

8 puntos por GN⁺ 2026-02-16 | 5 comentarios | Compartir por WhatsApp

El desarrollo nativo en Windows es complejo e ineficiente debido a la dependencia de instalar Visual Studio
Decenas de GB de instalación, gestión opaca de componentes y problemas de incompatibilidad de versiones reducen la productividad de los desarrolladores
Para resolverlo, se desarrolló la herramienta CLI ligera msvcup, que permite instalar automáticamente el toolchain de MSVC y el Windows SDK por versión y de forma aislada
msvcup ofrece un entorno de compilación reproducible mediante análisis de manifiestos JSON, configuración automática del entorno (autoenv) y soporte para archivos de bloqueo
Este enfoque permite un sistema de compilación totalmente automatizado y basado en scripts sin depender de Visual Studio Installer

Problemas del desarrollo nativo en Windows

El método tradicional, que exige instalar Visual Studio, representa una carga para los desarrolladores debido a un proceso de instalación complejo y una gestión inestable de dependencias
- Hay que elegir detalles como la carga de trabajo “Desktop development with C++” y versiones específicas del SDK; si se selecciona algo incorrectamente, la compilación falla
- La instalación puede ocupar hasta 50 GB y, aun después de desinstalar, quedan entradas residuales en el registro y servicios en segundo plano
En Linux, el toolchain puede instalarse con una sola línea en el gestor de paquetes, pero en Windows hay que seleccionar manualmente miles de componentes
Visual Studio tiene una estructura monolítica donde editor, compilador y SDK están entrelazados, lo que dificulta gestionar versiones y reproducir entornos
Como resultado, son frecuentes las inconsistencias del tipo “en mi PC sí funciona”, lo que se convierte en una barrera de entrada para el desarrollo nativo

msvcup: un nuevo enfoque

msvcup es una herramienta CLI de código abierto que descarga e instala directamente el toolchain de MSVC y el Windows SDK sin necesidad de instalar Visual Studio
- Cada versión se instala en un directorio aislado dentro de C:\msvcup\, por lo que es posible usar varias versiones en paralelo sin conflictos
- La instalación se completa en pocos minutos e incluye automáticamente herramientas de compilación cruzada para ARM
El comando msvcup install instala los paquetes necesarios, y el comando autoenv crea un directorio de entorno automático
- Ese directorio incluye ejecutables wrapper que configuran automáticamente las variables de entorno y un archivo toolchain.cmake, por lo que los proyectos con CMake pueden compilarse sin configuración adicional
En el ejemplo del script build.bat, es posible compilar un programa “Hello, World” sin Visual Studio usando msvcup
- Funciona en entornos con Windows 10 o superior con solo curl y tar

Cómo funciona internamente

Analiza los manifiestos JSON de componentes de Visual Studio distribuidos por Microsoft para identificar solo los paquetes necesarios
- Descarga directamente desde el CDN de Microsoft solo los elementos esenciales: compilador, linker, headers, bibliotecas, etc.
Los componentes instalados se gestionan con un archivo de bloqueo (lock file), lo que permite que todo el equipo comparta exactamente las mismas versiones de paquetes
Los comandos install y autoenv son idempotentes, y si todo ya está instalado terminan en apenas unos milisegundos

Casos reales de uso

Tuple (app de programación en pareja) integró msvcup en su sistema de compilación CI, eliminando el requisito de tener Visual Studio preinstalado
- Esto permite compilar cientos de proyectos en C/C++, incluido WebRTC, con el mismo toolchain/SDK
- Soporta tanto compilaciones x86_64 como ARM
Ventajas
- La instalación en directorios por versión permite gestionar varias versiones en paralelo y reinstalar fácilmente
- Soporte automático para compilación cruzada, sin configuración extra
- Reproducibilidad garantizada basada en archivos de bloqueo, con detección inmediata si Microsoft cambia algo
- Ejecución rápida, sin reinstalaciones innecesarias

Limitaciones y expansión

msvcup está diseñado con foco en el toolchain de compilación, por lo que si se necesita el IDE de Visual Studio como tal, la instalación oficial sigue siendo necesaria
Sin embargo, en la mayoría de los flujos de trabajo de desarrollo nativo, ofrece un entorno de compilación completo incluso sin IDE
El script de compilación de raylib presentado como ejemplo instala automáticamente el SDK y el toolchain, y compila el proyecto sin Visual Studio
- Realiza un proceso de compilación totalmente automatizado solo desde la línea de comandos, sin GUI

Conclusión

msvcup elimina la complejidad de Visual Studio Installer y ofrece un entorno ligero de compilación nativa con control de versiones
Este enfoque transforma el desarrollo nativo en Windows en un proceso reproducible y automatizado, y ayuda a los desarrolladores a liberarse de la dependencia del IDE
Repo : https://github.com/marler8997/msvcup

5 comentarios

GN⁺ 2026-02-16

Comentarios de Hacker News

Esto se ve más complicado que lo que yo hago
simplemente instalas LTSC Visual Studio Build Tools, y pones un comando como cl yourprogram.c /link user32.lib advapi32.lib ... en un archivo cmd
yo edito con vim y he compilado varias utilidades así
el toolchain de Visual Studio tiene LTSC y versiones estables, pero la mayoría no lo sabe
en un entorno colaborativo, conviene usar una versión fija de la documentación oficial del historial de lanzamientos
como en los viejos tiempos, cuando toda la empresa fijaba la misma versión del toolchain
- El canal LTSC solo está disponible con una licencia de Visual Studio Professional o superior
  por eso muchos estudiantes o desarrolladores hobby no lo conocen
  en cambio, la mayoría de la gente que usa VS en una empresa sí lo sabe
- Visual Studio 2026 todavía no tiene una versión LTSC
  ¿alguien sabe cuándo saldrá?
El toolchain de Linux tampoco está libre del infierno de dependencias
instalas un paquete de npm y de repente necesitas cmake, o aparece un conflicto de versión de glibc, o un proyecto de C++ exige la versión más reciente de boost...
todavía recuerdo cuando tocó parchear openSSL por heartbleed
Visual Studio también es incómodo, pero el verdadero infierno es la confusión de versiones de .NET Framework
la versión de .NET instalada cambia según la versión de Windows, y tampoco está claro en qué runtime va a ejecutarse una app
por eso, en despliegues grandes, hay que hacer un shim para verificar la versión de .NET en C++ y así ejecutar con el runtime correcto
- Si glibc en sí te está causando problemas de dependencias, es tan raro que hasta me daría curiosidad escucharlo
  el equipo de glibc es muy estricto con la compatibilidad hacia atrás y hacia adelante
  en este artículo de LWN se puede ver cuándo fue la última vez que rompieron compatibilidad
  el problema es que la gente fija mal la versión (pinning) de glibc
  glibc no se debe fijar a una versión
  GCC sí ha roto compatibilidad algunas veces, pero casi siempre por cambios en el estándar de C++
- .NET reciente es completamente distinto
  .NET Framework ya es legacy, y desde .NET 5 estos problemas ya no existen
  aunque todavía hay muchas apps que dependen de versiones viejas
- Antes, para desarrollar en C/C++, bastaba con el gestor de paquetes del sistema, pero los problemas con versiones recientes hicieron que surgieran gestores de paquetes por lenguaje
  resolvieron el problema, pero al mismo tiempo crearon nueva complejidad
  a veces dan ganas de volver a la época del gestor de paquetes del sistema
- La fricción en la UX de compilación en C/C++ es irritante aparte del tema de la seguridad de memoria
  en entornos embebidos, rust + probe-rs se siente mucho más cómodo
El instalador de Visual Studio permite instalación desatendida con parámetros de línea de comandos
está explicado en la documentación oficial
en 2018, cuando trabajaba en una red satelital con internet lento, usé ese método porque tenía que crear un paquete de instalación offline
- Lo intenté, pero había demasiadas descargas innecesarias, y la instalación seguía requiriendo permisos de administrador
- (¿Una conexión de alta latencia...? Creo que “high-latency” sería una expresión más precisa)
Viendo el script, aparece algo como
curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...
así
pero me incomoda instalar un ejecutable de una cuenta desconocida de GitHub sin verificar ni siquiera el hash
la situación en Windows no es tan mala como dice el blog, pero esto parece más otro script de instalación riesgoso que una solución
- No hace falta instalar un ejecutable
  simplemente puedes leer y revisar el script tú mismo
  al final, el método curl|sh solo descarga código fuente; no es más riesgoso que instalar directamente un ejecutable
- Jonathan Marler es conocido por sus charlas sobre Zig y su trabajo de bindings para la API de win32
  su proyecto zigwin32 incluso está enlazado desde win32metadata de Microsoft
  o sea, es alguien confiable
Este texto se siente como si lo hubiera escrito una IA
estructuras como “it’s not just X, but Y” o las listas con énfasis son muy típicas del estilo de un LLM
me da curiosidad saber cuánto del proyecto fue realmente hecho por una persona
- Da un poco de risa que tu nick sea “its_notjack”
- Yo también lo sospeché al principio
  la estructura de las listas era rara y poco consistente
  pero si lo escribió un LLM, podría ser prueba de que la calidad de los LLM ya subió bastante
  también podría ser por herramientas como Grammarly
- Tal vez la gente simplemente está imitando el estilo de los LLM
  porque a los lectores les resulta más fácil de leer
- Expresiones como “The key insight is...” suenan mucho al estilo que usa Claude, por eso da esa impresión
  la verdad, estaría bien que solo dijeran con honestidad si usaron IA o no
Como intento de mejorar el DX de Visual Studio, msvcup se siente realmente fresco
ojalá hubiera existido algo así cuando estaba en la universidad
como alternativa, también está la opción de instalar Build Tools en un contenedor
Simplemente se puede instalar con winget
winget install --id Microsoft.VisualStudio.2022.BuildTools
si necesitas funciones de WinRT, puedes agregar
winget install --id Microsoft.WindowsSDK.10.0.18362
winget install --id Microsoft.WindowsAppRuntime.1.8
- Antes daban soporte a estos paquetes, pero no es tan simple
  también hay que especificar qué workload se va a instalar, y si no conoces el proyecto, toca prueba y error
  .vsconfig ayuda un poco, pero no es perfecto
Ojalá los proyectos open source no bloquearan el soporte para MinGW
es un buen compilador que funciona bien incluso sin DLL adicionales
no entiendo por qué el open source tendría que imponer un compilador privativo
- MinGW no es compatible con algunas bibliotecas exclusivas de Windows (WIL)
  WIL es una biblioteca muy usada por desarrolladores del kernel, y mejora bastante la seguridad y la comodidad del código
- Cuando hay que enlazar bibliotecas MSVC compiladas externamente, MinGW no es opción
  por ejemplo, el SDK de Steamworks compila con MinGW, pero se cae en runtime
- Yo también quisiera que hubiera más soporte para MinGW
  me decepciona que ni siquiera lo mencionen en esta entrada del blog
- No me gusta MinGW
  la combinación de Clang + MSVC STL + WinSDK es mucho más limpia
O también se puede hacer así de simple
"winget install Microsoft.VisualStudio.BuildTools"
"winget install Microsoft.WindowsSDK.10.0.26100"
- Yo siempre lo hago así
  lo prefiero porque tiene buena estabilidad en relación con el esfuerzo
- Pero esa instalación queda a nivel sistema, así que se vuelve incómodo cuando cada proyecto necesita versiones distintas
  ojalá todos los lenguajes tuvieran una herramienta de aislamiento de versiones como Python uv
- Muchas de las críticas a Windows son historias de hace 20 años
  cosas como Bing, Copilot o la publicidad sí merecen críticas, pero casi todo se puede desactivar

click 2026-02-16

A mí también me pasó un problema de dependencia con glibc cuando compilé en Ubuntu 24.04 y luego intenté ejecutarlo en CentOS 6 o 7.
Parece que el problema es que, por defecto, toma la versión de glibc del entorno de compilación.

penza1 2026-02-18

No queda otra que depender de glibc..
A diferencia de lenguajes de script como python/jv/.net/js, es inevitable depender de glibc.
Esa es también la razón por la que se distribuyen bibliotecas para cada distribución.
Si se compiló al menos con una glibc, entonces, si no tiene dependencias especiales, puede ejecutarse sin problema en otras distribuciones con versiones superiores.

geekbini 2026-02-16

Con WSL2 y Ubuntu, Windows sí se volvió mucho mejor para desarrollar. Pero si tu entorno es Visual Studio y no VS Code, esto parece que al menos podría ayudar un poco. Aunque bueno, parece que no se puede hacer en Windows con gestores de paquetes como choco o winget.