Kami memperbaiki lingkungan pengembangan native Windows

(marler8997.github.io)

8 poin oleh GN⁺ 2026-02-16 | 5 komentar | Bagikan ke WhatsApp

Pengembangan native Windows rumit dan tidak efisien karena ketergantungan pada instalasi Visual Studio
Ukuran instalasi puluhan GB, manajemen komponen yang tidak transparan, dan masalah ketidakcocokan versi menurunkan produktivitas developer
Untuk mengatasinya, dikembangkan alat CLI ringan msvcup yang dapat menginstal otomatis toolchain MSVC dan Windows SDK secara terisolasi per versi
msvcup menyediakan lingkungan build yang reproducible melalui parsing manifest JSON, pengaturan lingkungan otomatis (autoenv), dan dukungan lock file
Pendekatan ini memungkinkan sistem build otomatis penuh berbasis skrip tanpa bergantung pada Visual Studio Installer

Masalah dalam pengembangan native Windows

Pendekatan lama yang mengharuskan instalasi Visual Studio membebani developer karena proses instalasi yang kompleks dan manajemen dependensi yang tidak stabil
- Perlu memilih detail seperti workload “Desktop development with C++”, versi SDK tertentu, dan jika salah memilih build bisa gagal
- Ukuran instalasi mencapai 50GB, dan bahkan setelah dihapus masih menyisakan entri registry dan layanan latar belakang
Di Linux, toolchain bisa diinstal dengan satu perintah package manager, tetapi di Windows pengguna harus memilih ribuan komponen secara manual
Visual Studio memiliki struktur tunggal yang mengikat editor, compiler, dan SDK, sehingga versioning dan reproduksi lingkungan menjadi sulit
Akibatnya, ketidaksesuaian seperti “berjalan di PC saya” sering terjadi, dan ini menjadi hambatan masuk untuk pengembangan native

msvcup: pendekatan baru

msvcup adalah alat CLI open-source yang mengunduh dan menginstal langsung toolchain MSVC dan Windows SDK tanpa instalasi Visual Studio
- Setiap versi diinstal ke direktori terisolasi di bawah C:\msvcup\, sehingga beberapa versi bisa dipakai berdampingan tanpa konflik
- Instalasi selesai dalam hitungan menit, dan alat cross-compile ARM juga otomatis disertakan
Perintah msvcup install menginstal paket yang diperlukan, dan perintah autoenv membuat direktori lingkungan otomatis
- Direktori ini berisi file executable pembungkus yang mengatur variabel lingkungan secara otomatis serta file toolchain.cmake, sehingga proyek CMake juga bisa dibuild tanpa konfigurasi tambahan
Dalam contoh skrip build.bat, program “Hello, World” dapat dibuild tanpa Visual Studio melalui msvcup
- Berjalan di Windows 10 ke atas hanya dengan curl dan tar

Cara kerja internal

Alat ini mem-parsing manifest JSON komponen Visual Studio yang didistribusikan Microsoft untuk mengidentifikasi hanya paket yang dibutuhkan
- Hanya elemen inti seperti compiler, linker, header, dan library yang diunduh langsung dari Microsoft CDN
Komponen yang terinstal dikelola dengan lock file, sehingga seluruh tim dapat memakai paket dengan versi yang sama
Perintah install dan autoenv bersifat idempotent, sehingga jika sudah terinstal proses selesai dalam beberapa milidetik

Contoh penerapan nyata

Tuple (aplikasi pair programming) mengintegrasikan msvcup ke sistem build CI mereka untuk menghapus kebutuhan pra-instalasi Visual Studio
- Ratusan proyek C/C++, termasuk WebRTC, dapat dibuild dengan toolchain/SDK yang sama
- Mendukung build x86_64 dan ARM
Keunggulan
- Instalasi per direktori versi memungkinkan manajemen multi-versi secara paralel dan reinstalasi yang mudah
- Dukungan cross-compile otomatis, tanpa konfigurasi tambahan
- Reproducibility terjamin berbasis lock file, dan perubahan dari pihak Microsoft bisa segera terdeteksi
- Eksekusi cepat, tanpa reinstalasi yang tidak perlu

Batasan dan perluasan

msvcup dirancang dengan fokus pada toolchain kompilasi, sehingga jika tetap membutuhkan IDE Visual Studio itu sendiri, instalasi resmi masih diperlukan
Namun, untuk sebagian besar workflow pengembangan native, alat ini menyediakan lingkungan build lengkap bahkan tanpa IDE
Skrip build raylib yang ditunjukkan sebagai contoh dapat menginstal SDK dan toolchain secara otomatis lalu membuild proyek tanpa Visual Studio
- Seluruh proses build sepenuhnya otomatis hanya dari command line tanpa GUI

Kesimpulan

msvcup menghilangkan kompleksitas Visual Studio Installer dan menyediakan lingkungan build native ringan yang dapat dikelola per versi
Pendekatan ini mengubah pengembangan native Windows menjadi reproducible dan terotomatisasi, serta membantu developer lepas dari ketergantungan pada IDE
Repo : https://github.com/marler8997/msvcup

5 komentar

GN⁺ 2026-02-16

Komentar Hacker News

Ini terlihat lebih rumit daripada yang saya lakukan
cukup pasang LTSC Visual Studio Build Tools, lalu taruh perintah seperti cl yourprogram.c /link user32.lib advapi32.lib ... di file cmd
Saya mengedit dengan vim dan sudah membangun berbagai utilitas dengan cara seperti ini
Di toolchain Visual Studio ada LTSC dan versi stabil, tetapi kebanyakan orang tidak mengetahuinya
Untuk lingkungan kolaboratif, lebih baik memakai versi tetap dari dokumen riwayat rilis resmi
seperti dulu saat satu perusahaan mengunci penggunaan versi toolchain yang sama
- Kanal LTSC hanya bisa diakses jika punya lisensi Visual Studio Professional atau lebih tinggi
  jadi mahasiswa atau pengembang hobi sering tidak tahu soal ini
  sebaliknya, orang yang memakai VS di perusahaan umumnya sudah tahu
- Visual Studio 2026 masih belum punya rilis LTSC
  ada yang tahu kapan akan keluar?
Toolchain Linux juga tidak bebas dari neraka dependensi
saat memasang paket npm tiba-tiba butuh cmake, atau terjadi konflik versi glibc, atau proyek C++ meminta boost terbaru, dan seterusnya…
Saya juga masih ingat saat menambal openSSL ketika heartbleed
Visual Studio memang merepotkan, tetapi neraka yang sesungguhnya adalah kekacauan versi .NET Framework
versi .NET yang terpasang berbeda-beda di setiap versi Windows, dan tidak jelas aplikasi akan berjalan di runtime yang mana
Karena itu, dalam deployment skala besar, kami harus membuat shim untuk pengecekan versi .NET dengan C++ agar aplikasi dijalankan dengan runtime yang benar
- Kalau sampai glibc sendiri menimbulkan masalah dependensi, itu termasuk sangat jarang sampai saya pun ingin mendengarnya
  tim glibc sangat ketat soal kompatibilitas mundur dan maju
  artikel LWN menunjukkan kapan terakhir kali kompatibilitas itu dirusak
  masalahnya adalah orang sering salah melakukan pinning versi glibc
  glibc memang tidak boleh dipinning
  GCC memang beberapa kali merusak kompatibilitas, tetapi kebanyakan karena perubahan standar C++
- .NET belakangan ini sudah benar-benar berbeda
  .NET Framework sekarang sudah legacy, dan setelah .NET 5 masalah seperti ini tidak ada lagi
  hanya saja masih banyak aplikasi yang bergantung pada versi lama
- Dulu, dalam pengembangan C/C++, system package manager saja sudah cukup, tetapi karena masalah versi terbaru muncullah package manager per bahasa
  itu memang menyelesaikan masalah, tetapi sekaligus menciptakan kompleksitas baru
  kadang saya ingin kembali saja ke masa system package manager
- Friksi UX build di C/C++ adalah hal yang menyebalkan, terlepas dari isu memory safety
  di lingkungan embedded, rust + probe-rs jauh lebih nyaman
Installer Visual Studio mendukung instalasi tanpa interaksi lewat parameter command line
dijelaskan di dokumentasi resmi
Pada 2018, saat saya bekerja di jaringan satelit dengan internet lambat, saya memakai cara ini karena harus membuat paket instalasi offline
- Saya sudah mencobanya, tetapi download yang tidak perlu terlalu banyak, dan instalasinya tetap butuh hak administrator
- (koneksi high-latency ya… sepertinya istilah “high-latency” memang lebih tepat)
Melihat skripnya, ada bagian seperti
curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...
seperti itu
tetapi saya enggan memasang file eksekusi dari akun GitHub yang tidak jelas asalnya tanpa verifikasi hash
Kondisi Windows memang tidak seburuk yang dibilang blog itu, tetapi ini terasa bukan solusi melainkan skrip instalasi berisiko lain
- Tidak perlu benar-benar memasang file eksekusi
  cukup baca dan audit skripnya sendiri
  pendekatan curl|sh pada akhirnya juga cuma mengunduh source code, jadi tidak lebih berbahaya daripada langsung memasang file eksekusi
- Jonathan Marler dikenal lewat presentasi terkait Zig dan pekerjaan binding win32 API
  proyeknya zigwin32 juga ditautkan dari win32metadata milik Microsoft
  jadi dia orang yang bisa dipercaya
Tulisan ini terasa seperti ditulis AI
struktur kalimat seperti “it’s not just X, but Y” dan daftar penekanan terasa seperti gaya LLM yang khas
Saya jadi penasaran seberapa banyak proyek ini benar-benar dibuat manusia
- Agak lucu juga nama panggilanmu “its_notjack”
- Saya juga sempat curiga pada awalnya
  struktur daftarnya terasa canggung dan kurang konsisten
  tetapi kalau memang ditulis LLM, itu juga bisa jadi bukti bahwa kualitas LLM sekarang sudah cukup naik
  bisa juga pengaruh alat seperti Grammarly
- Mungkin orang-orang mulai meniru gaya LLM
  karena memang lebih mudah dibaca oleh pembaca
- Ungkapan seperti “The key insight is…” terasa seperti gaya yang sering dipakai Claude
  sejujurnya saya cuma berharap mereka terbuka soal penggunaan AI
Sebagai upaya memperbaiki DX Visual Studio, msvcup terasa sangat menyegarkan
seandainya dulu saat kuliah ada hal seperti ini
Alternatifnya juga ada pendekatan memasang Build Tools di container
Tinggal pasang saja dengan winget
winget install --id Microsoft.VisualStudio.2022.BuildTools
kalau butuh fitur WinRT
winget install --id Microsoft.WindowsSDK.10.0.18362
winget install --id Microsoft.WindowsAppRuntime.1.8 juga bisa ditambahkan
- Dulu saya pernah mendukung paket-paket ini, tetapi kenyataannya tidak sesederhana itu
  kita juga harus menentukan workload mana yang akan dipasang, dan kalau tidak tahu proyeknya, jadi banyak trial and error
  .vsconfig memang agak membantu, tetapi belum sempurna
Saya berharap proyek open source tidak menghalangi dukungan MinGW
ini compiler yang bagus dan bisa berjalan baik tanpa DLL tambahan
Saya tidak paham kenapa open source harus memaksa compiler berpemilik
- MinGW tidak kompatibel dengan sebagian library khusus Windows (WIL)
  WIL adalah library yang sering dipakai pengembang kernel untuk sangat meningkatkan keamanan dan kenyamanan kode
- Saat harus melakukan link ke library MSVC yang dibangun dari luar, MinGW bukan pilihan
  misalnya Steamworks SDK memang bisa dibangun dengan MinGW, tetapi akan crash saat runtime
- Saya juga berharap dukungan MinGW lebih luas
  sayang sekali tulisan blog ini bahkan tidak menyebutkannya sama sekali
- Saya tidak suka MinGW
  kombinasi Clang + MSVC STL + WinSDK jauh lebih rapi
Atau bisa sesederhana ini
"winget install Microsoft.VisualStudio.BuildTools"
"winget install Microsoft.WindowsSDK.10.0.26100"
- Saya juga selalu melakukannya seperti ini
  saya suka karena stabilitas dibanding usaha yang dikeluarkan sangat bagus
- Tetapi instalasi seperti ini berlaku untuk seluruh sistem, jadi merepotkan kalau tiap proyek butuh versi berbeda
  saya berharap semua bahasa punya alat isolasi versi seperti Python uv
- Banyak kritik terhadap Windows sebenarnya adalah cerita 20 tahun lalu
  hal seperti Bing, Copilot, dan iklan memang pantas dikritik, tetapi kebanyakan bisa dimatikan

click 2026-02-16

Saya juga membangun di Ubuntu 24.04 dan saat mencoba menjalankannya di CentOS 6 atau 7, muncul masalah dependensi glibc.
Sepertinya masalahnya adalah secara default versi glibc dari lingkungan build ikut terbawa.

penza1 2026-02-18

Ketergantungan pada glibc memang tidak bisa dihindari..
Untuk hal-hal yang bukan bahasa skrip seperti python/jv/.net/js, ketergantungan pada glibc memang tak terelakkan.
Itu juga alasan library didistribusikan per masing-masing distro.
Jika dibangun setidaknya pada glibc minimum, maka selama tidak ada dependensi khusus, itu cukup bisa dijalankan juga di distro versi yang lebih tinggi.

geekbini 2026-02-16

Dengan WSL2 dan Ubuntu, Windows memang jadi jauh lebih enak untuk dipakai ngembangin banyak hal. Tapi kalau lingkungannya Visual Studio, bukan VSCode, sepertinya ini lumayan bisa membantu. Meski begitu, kayaknya lewat package manager seperti choco atau winget di Windows tetap tidak bisa ya.