Consertei o ambiente nativo de desenvolvimento no Windows

(marler8997.github.io)

8 pontos por GN⁺ 2026-02-16 | 5 comentários | Compartilhar no WhatsApp

O desenvolvimento nativo no Windows é complexo e ineficiente por causa da dependência da instalação do Visual Studio
Dezenas de GB de instalação, gerenciamento opaco de componentes e problemas de incompatibilidade de versões reduzem a produtividade dos desenvolvedores
Para resolver isso, foi criada a ferramenta CLI leve msvcup, capaz de instalar automaticamente o toolchain MSVC e o Windows SDK de forma isolada por versão
O msvcup oferece ambientes de build reproduzíveis por meio de parsing de manifestos JSON, configuração automática de ambiente (autoenv) e suporte a lock file
Essa abordagem elimina a dependência do Visual Studio Installer e viabiliza um sistema de build totalmente automatizado baseado em scripts

Problemas do desenvolvimento nativo no Windows

O método tradicional, que exige instalar o Visual Studio, sobrecarrega os desenvolvedores com um processo de instalação complexo e gerenciamento instável de dependências
- É preciso selecionar detalhes como a workload “Desktop development with C++” e versões específicas do SDK, e escolhas incorretas podem causar falhas de build
- A instalação pode chegar a 50 GB e, mesmo após a remoção, entradas residuais no registro e serviços em segundo plano permanecem
No Linux, é possível instalar um toolchain com uma única linha no gerenciador de pacotes, mas no Windows é preciso selecionar manualmente milhares de componentes
O Visual Studio adota uma estrutura monolítica que mistura editor, compilador e SDK, o que dificulta o controle de versões e a reprodução do ambiente
Como resultado, divergências do tipo “na minha máquina funciona” são frequentes, aumentando a barreira de entrada para o desenvolvimento nativo

msvcup: uma nova abordagem

msvcup é uma ferramenta CLI open source que baixa e instala diretamente o toolchain MSVC e o Windows SDK sem precisar instalar o Visual Studio
- Cada versão é instalada em um diretório isolado dentro de C:\msvcup\, permitindo uso paralelo sem conflitos entre versões
- A instalação é concluída em poucos minutos, e as ferramentas de cross-compilation para ARM também são incluídas automaticamente
O comando msvcup install instala os pacotes necessários, e o comando autoenv gera um diretório de ambiente automático
- Esse diretório inclui executáveis wrapper que configuram automaticamente as variáveis de ambiente e um arquivo toolchain.cmake, permitindo compilar projetos CMake sem configuração adicional
No exemplo de script build.bat, é possível compilar um programa “Hello, World” sem Visual Studio usando o msvcup
- Funciona no Windows 10 ou superior com apenas curl e tar instalados

Como funciona internamente

O msvcup faz parsing dos manifestos JSON de componentes do Visual Studio distribuídos pela Microsoft para identificar apenas os pacotes necessários
- Elementos essenciais como compilador, linker, headers e bibliotecas são baixados diretamente da CDN da Microsoft
Os componentes instalados são gerenciados por meio de lock files, permitindo que toda a equipe compartilhe exatamente as mesmas versões de pacotes
Os comandos install e autoenv têm idempotência, concluindo em poucos milissegundos quando tudo já está instalado

Casos reais de uso

A Tuple (app de pair programming) integrou o msvcup ao seu sistema de build em CI, eliminando a necessidade de pré-instalar o Visual Studio
- Isso permite compilar centenas de projetos C/C++, incluindo o WebRTC, com o mesmo toolchain/SDK
- Há suporte tanto para builds x86_64 quanto ARM
Vantagens
- A instalação em diretórios por versão permite gerenciar várias versões em paralelo e reinstalar com facilidade
- Suporte automático a cross-compilation, sem configuração extra
- Reprodutibilidade garantida com base em lock files, com detecção imediata de mudanças feitas pela Microsoft
- Execução rápida, sem reinstalações desnecessárias

Limitações e expansão

O msvcup foi projetado com foco no toolchain de compilação, então, quando o próprio IDE do Visual Studio é necessário, a instalação oficial ainda é exigida
Ainda assim, na maioria dos fluxos de trabalho de desenvolvimento nativo, ele oferece um ambiente de build completo mesmo sem IDE
O script de build do raylib apresentado como exemplo instala automaticamente o SDK e o toolchain e compila o projeto sem Visual Studio
- Um processo de build totalmente automatizado é executado apenas pela linha de comando, sem GUI

Conclusão

O msvcup remove a complexidade do Visual Studio Installer e oferece um ambiente leve de build nativo com controle de versões
Essa abordagem transforma o desenvolvimento nativo no Windows em algo reproduzível e automatizado, ajudando os desenvolvedores a se libertarem da dependência do IDE
Repo : https://github.com/marler8997/msvcup

5 comentários

GN⁺ 2026-02-16

Comentários do Hacker News

Isso parece mais complicado do que o que eu faço
basta instalar o LTSC Visual Studio Build Tools e colocar um comando como cl yourprogram.c /link user32.lib advapi32.lib ... em um arquivo cmd
eu editava no vim e venho compilando vários utilitários assim
o toolchain do Visual Studio tem LTSC e versões estáveis, mas a maioria das pessoas não sabe disso
em um ambiente colaborativo, é melhor usar uma versão fixa da documentação oficial de histórico de lançamentos
como na época em que a empresa inteira fixava e usava a mesma versão do toolchain
- O canal LTSC só está disponível para quem tem licença Visual Studio Professional ou superior
  por isso estudantes e desenvolvedores por hobby muitas vezes não sabem disso
  por outro lado, quem usa VS em empresas geralmente sabe
- O Visual Studio 2026 ainda não tem uma versão LTSC
  alguém sabe quando vai sair?
O toolchain do Linux também não está livre do inferno das dependências
você instala um pacote npm e de repente precisa de cmake, ou surge conflito de versão do glibc, ou é um projeto em C++ que exige uma versão mais nova do boost...
também ainda lembro de aplicar patch no openSSL na época do heartbleed
o Visual Studio também é incômodo, mas o verdadeiro inferno é a confusão de versões do .NET Framework
cada versão do Windows vem com uma versão diferente do .NET instalada, e não fica claro em qual runtime o app vai rodar
por isso, em distribuições em larga escala, é preciso criar em C++ um shim para verificar a versão do .NET e garantir a execução no runtime correto
- Se o próprio glibc estiver causando problema de dependência, é tão raro que eu realmente gostaria de ouvir esse caso
  a equipe do glibc é muito rígida com compatibilidade retroativa e progressiva
  este artigo da LWN mostra a última vez em que a compatibilidade foi quebrada
  o problema é quando as pessoas fazem pinning errado da versão do glibc
  não se deve fixar a versão do glibc
  o GCC já quebrou compatibilidade algumas vezes, mas na maioria dos casos foi por mudanças no padrão C++
- O .NET recente é completamente diferente
  o .NET Framework já é legado, e depois do .NET 5 esse problema não existe
  só que ainda há muitos apps que dependem de versões antigas
- Antigamente, em desenvolvimento C/C++, o gerenciador de pacotes do sistema já bastava, mas por causa dos problemas com versões mais novas surgiram gerenciadores de pacotes por linguagem
  eles resolveram o problema, mas ao mesmo tempo criaram nova complexidade
  às vezes dá vontade de voltar para a era em que bastava o gerenciador de pacotes do sistema
- O atrito de UX no build em C/C++ é irritante independentemente da segurança de memória
  em ambientes embarcados, rust + probe-rs é muito mais agradável
O instalador do Visual Studio permite instalação sem interação via parâmetros de linha de comando
isso é explicado na documentação oficial
em 2018, quando eu trabalhava em uma conexão via satélite com internet lenta, usei esse método porque precisava criar um pacote de instalação offline
- Eu tentei, mas havia downloads desnecessários demais e a instalação ainda exigia privilégios de administrador
- (Já que era uma conexão de alta latência... talvez a expressão “high-latency” fosse mais apropriada)
Olhando o script, tem algo como
curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...
desse jeito
mas eu fico desconfortável em instalar um executável de uma conta desconhecida do GitHub sem nem verificar o hash
a situação do Windows não é tão ruim quanto o blog diz, mas isso parece mais outro script de instalação arriscado do que uma solução
- Não precisa necessariamente instalar um executável
  basta ler e revisar o script você mesmo
  no fim, a abordagem curl|sh também só baixa código-fonte, então não é mais perigosa do que instalar um executável diretamente
- Jonathan Marler é conhecido por palestras relacionadas a Zig e pelo trabalho com bindings da API win32
  o projeto dele, zigwin32, também é linkado pelo win32metadata da Microsoft
  ou seja, é alguém confiável
Esse texto parece ter sido escrito por IA
estruturas como “it’s not just X, but Y” e listas com ênfase são um estilo típico de LLM
fico curioso sobre quanto do projeto foi realmente feito por humanos
- É meio engraçado que o seu apelido seja “its_notjack”
- Eu também desconfiei no começo
  a estrutura das listas era estranha e faltava consistência
  mas, se foi um LLM que escreveu, isso também pode ser prova de que a qualidade dos LLMs hoje subiu bastante
  talvez seja influência de ferramentas como Grammarly
- Talvez as pessoas estejam imitando o estilo de LLM
  porque ele é mais fácil de ler para o público
- Expressões como “The key insight is...” são um jeito de escrever que o Claude usa com frequência, então passa essa impressão
  sinceramente, eu só queria que a pessoa deixasse claro se usou IA ou não
Como tentativa de melhorar a DX do Visual Studio, o msvcup é realmente algo novo e refrescante
eu gostaria que existisse algo assim na época da faculdade
como alternativa, também existe a abordagem de instalar o Build Tools em um contêiner
Dá para instalar simplesmente com winget
winget install --id Microsoft.VisualStudio.2022.BuildTools
se você precisar de recursos do WinRT, também pode adicionar
winget install --id Microsoft.WindowsSDK.10.0.18362
winget install --id Microsoft.WindowsAppRuntime.1.8
- Eu já dei suporte a esses pacotes antes, mas não é algo simples
  você também precisa especificar quais workloads instalar, e sem conhecer o projeto acaba virando tentativa e erro
  o .vsconfig até ajuda um pouco, mas não resolve tudo
Eu gostaria que os projetos open source não bloqueassem o suporte ao MinGW
é um bom compilador que funciona muito bem mesmo sem DLLs extras
não entendo por que o open source insistiria em forçar um compilador proprietário
- O MinGW não é compatível com algumas bibliotecas específicas do Windows (WIL)
  a WIL é uma biblioteca muito usada por desenvolvedores de kernel e melhora bastante a segurança e a praticidade do código
- Quando é preciso linkar com bibliotecas MSVC compiladas externamente, o MinGW não é uma opção
  por exemplo, o Steamworks SDK compila com MinGW, mas trava em runtime
- Eu também queria ver mais suporte a MinGW
  é uma pena que nem tenha sido mencionado neste post do blog
- Eu não gosto de MinGW
  a combinação Clang + MSVC STL + WinSDK é muito mais limpa
Ou dá para fazer de forma simples assim
"winget install Microsoft.VisualStudio.BuildTools"
"winget install Microsoft.WindowsSDK.10.0.26100"
- Eu também faço sempre assim
  gosto porque a estabilidade em relação ao esforço é boa
- Mas esse tipo de instalação é global no sistema, então fica complicado quando cada projeto precisa de uma versão diferente
  seria bom se todas as linguagens tivessem uma ferramenta de isolamento de versões como o Python uv
- Grande parte das críticas ao Windows é coisa de 20 anos atrás
  Bing, Copilot, anúncios e afins merecem críticas, mas em sua maioria podem ser desativados

click 2026-02-16

Eu também tive um problema de dependência do glibc ao compilar no Ubuntu 24.04 e tentar executar no CentOS 6 ou 7.
Parece que o problema é que, por padrão, ele usa a versão do glibc do ambiente de build.

penza1 2026-02-18

Não tem como não depender de glibc..
Ao contrário de linguagens de script como python/jv/.net/js, a dependência de glibc é inevitável.
Esse também é um dos motivos para distribuir bibliotecas para cada distribuição.
No mínimo, algo compilado com glibc, se não tiver dependências especiais, pode rodar tranquilamente em outras distribuições de versão superior.

geekbini 2026-02-16

Com o WSL2 e o Ubuntu, o Windows realmente ficou bem melhor para desenvolver também. Mas, se o ambiente for o Visual Studio em vez do VS Code, isso parece poder ajudar pelo menos um pouco. Só que, pelo visto, não dá para fazer isso no Windows com gerenciadores de pacotes como choco ou winget.