मैंने Windows native development environment को ठीक किया

• Windows native development, Visual Studio installation dependency की वजह से जटिल और गैर-प्रभावी हो जाता है
• दर्जनों GB install size, अपारदर्शी component management, और version mismatch problems जैसी चीज़ें developer productivity को कम करती हैं
• इसे हल करने के लिए हल्का CLI tool msvcup बनाया गया, जो MSVC toolchain और Windows SDK को version-wise, isolated form में अपने-आप install कर सकता है
• msvcup JSON manifest parsing, automatic environment setup (autoenv), और lock file support के ज़रिए reproducible build environment देता है
• यह approach Visual Studio Installer पर निर्भर हुए बिना script-based पूरी तरह automated build system को संभव बनाती है

---

Windows native development की समस्याएँ

• Visual Studio install करने वाला मौजूदा तरीका जटिल installation process और अस्थिर dependency management की वजह से developers पर बोझ डालता है
  • “Desktop development with C++” workload, खास SDK version जैसी बारीक selections करनी पड़ती हैं, और गलत चयन होने पर build fail हो सकता है
  • install size 50GB तक पहुँच जाती है, और uninstall के बाद भी registry leftovers और background services बचे रहते हैं
• Linux में package manager की एक command से toolchain install की जा सकती है, लेकिन Windows में हज़ारों components को manually चुनना पड़ता है
• Visual Studio एक single structure है जिसमें editor, compiler, और SDK आपस में उलझे होते हैं, इसलिए version management और environment reproduction मुश्किल हो जाता है
• नतीजतन “मेरे PC पर तो चलता है” जैसी असंगतियाँ अक्सर होती हैं, और यह native development में entry barrier बन जाती है

msvcup: एक नया approach

• msvcup एक open source CLI tool है, जो Visual Studio install किए बिना MSVC toolchain और Windows SDK को सीधे download और install करता है
  • हर version C:\msvcup\ के नीचे isolated directories में install होता है, इसलिए versions के बीच टकराव के बिना उन्हें साथ-साथ इस्तेमाल किया जा सकता है
  • installation कुछ ही मिनटों में पूरी हो जाती है, और ARM cross-compilation tools भी अपने-आप शामिल हो जाते हैं
• msvcup install command ज़रूरी packages install करती है, और autoenv command automatic environment directory बनाती है
  • इस directory में environment variables अपने-आप सेट करने वाले wrapper executables और toolchain.cmake file शामिल होती है, इसलिए CMake projects भी अलग configuration के बिना build हो सकते हैं
• build.bat script example में msvcup के ज़रिए “Hello, World” प्रोग्राम को Visual Studio के बिना build किया जा सकता है
  • यह Windows 10 या उससे ऊपर के environment में सिर्फ curl और tar के साथ काम करता है

अंदरूनी काम करने का तरीका

• Microsoft द्वारा वितरित Visual Studio component JSON manifests को parse करके सिर्फ ज़रूरी packages की पहचान की जाती है
  • compiler, linker, headers, libraries जैसे core elements को सीधे Microsoft CDN से download किया जाता है
• install किए गए components को lock file से manage किया जाता है, ताकि पूरी team एक ही version के packages share कर सके
• install और autoenv commands idempotent हैं, इसलिए अगर चीज़ें पहले से install हों तो ये कुछ milliseconds में पूरी हो जाती हैं

वास्तविक उपयोग के उदाहरण

• Tuple (pair programming app) ने msvcup को अपने CI build system में integrate करके Visual Studio pre-installation requirement हटा दी
  • WebRTC सहित सैकड़ों C/C++ projects को एक ही toolchain/SDK के साथ build किया जा सकता है
  • x86_64 और ARM builds दोनों supported हैं
• फायदे
  • version-wise directory installation से parallel version management और आसान reinstallation संभव
  • cross-compilation का automatic support, अलग configuration की ज़रूरत नहीं
  • lock file आधारित reproducibility की गारंटी, और Microsoft की तरफ बदलाव होने पर तुरंत पता चल सकता है
  • तेज़ execution speed, बेकार की reinstallation नहीं

सीमाएँ और विस्तार

• msvcup compiler toolchain-centric तरीके से डिज़ाइन किया गया है, इसलिए अगर Visual Studio IDE खुद चाहिए हो, तो official installation अब भी ज़रूरी है
• लेकिन ज़्यादातर native development workflows में यह IDE के बिना भी पूरा build environment देता है
• उदाहरण के तौर पर दिया गया raylib build script Visual Studio के बिना भी SDK और toolchain को अपने-आप install करके project build करता है
  • GUI के बिना सिर्फ command line से पूरी तरह automated build process चलती है

निष्कर्ष

• msvcup Visual Studio Installer की जटिलता हटाकर version-manageable, lightweight native build environment देता है
• यह तरीका Windows native development को reproducible और automated form में बदल देता है, और developers को IDE dependency से बाहर निकलने में मदद करता है
• Repo : https://github.com/marler8997/msvcup

[GN⁺]

Hacker News टिप्पणियाँ

• यह मेरे काम से भी ज़्यादा जटिल लग रहा है
  बस LTSC Visual Studio Build Tools इंस्टॉल कर लो, और cl yourprogram.c /link user32.lib advapi32.lib ... जैसा कमांड किसी cmd फ़ाइल में डाल दो
  मैं vim में एडिट करता हूँ और इसी तरह कई utilities बनाता आया हूँ
  Visual Studio toolchain में LTSC और stable version मौजूद हैं, लेकिन ज़्यादातर लोगों को इसका पता नहीं है
  collaborative environment में official release history document में दिए गए fixed version का इस्तेमाल करना बेहतर है
  बिल्कुल वैसे ही जैसे पहले कंपनी-भर में एक ही toolchain version को fix करके इस्तेमाल किया जाता था

  • LTSC channel तक पहुँचने के लिए Visual Studio Professional या उससे ऊपर का license चाहिए
    इसलिए students या hobby developers को इसके बारे में अक्सर पता नहीं होता
    वहीं कंपनियों में VS इस्तेमाल करने वाले ज़्यादातर लोग इसे जानते हैं
  • Visual Studio 2026 के लिए अभी तक कोई LTSC release नहीं है
    किसी को पता है यह कब आएगा?

• Linux का toolchain भी dependency hell से मुक्त नहीं है
  npm package इंस्टॉल करते-करते cmake की ज़रूरत पड़ जाना, glibc version conflict होना, या latest boost माँगने वाले C++ projects वगैरह…
  heartbleed के समय openSSL patch करने की याद भी है
  Visual Studio भी असुविधाजनक है, लेकिन असली नरक तो .NET Framework version confusion है
  अलग-अलग Windows versions में अलग .NET versions इंस्टॉल होते हैं, और ऐप किस runtime पर चलेगा यह भी साफ़ नहीं होता
  इसलिए बड़े पैमाने पर deployment में C++ से .NET version जाँचने वाला shim बनाना पड़ता है ताकि सही runtime में execute कराया जा सके

  • अगर glibc खुद dependency issues पैदा कर रहा हो, तो वह इतना दुर्लभ है कि सुनना ही चाहूँगा
    glibc team backward और forward compatibility को लेकर बहुत सख्त है
    LWN article देखें तो पता चलता है कि आख़िरी बार compatibility कब टूटी थी
    समस्या यह है कि लोग अक्सर glibc version को ग़लत तरह से pin कर देते हैं
    glibc को pin नहीं करना चाहिए
    GCC ने कुछ बार compatibility तोड़ी है, लेकिन ज़्यादातर C++ standard changes की वजह से
  • हाल का .NET पूरी तरह अलग है
    .NET Framework अब legacy है, और .NET 5 के बाद ऐसी समस्या नहीं है
    फिर भी अभी बहुत-से apps पुराने versions पर निर्भर हैं
  • पहले C/C++ development में सिर्फ system package manager काफ़ी था, लेकिन latest version की समस्या के कारण language-specific package managers आए
    उन्होंने समस्या हल की, लेकिन साथ ही नई जटिलता भी पैदा कर दी
    कभी-कभी मन करता है कि बस system package manager वाले दौर में लौट जाएँ
  • C/C++ का build UX friction memory safety से अलग ही परेशान करने वाली चीज़ है
    embedded environment में rust + probe-rs काफ़ी ज़्यादा आरामदायक है

• Visual Studio installer को command-line parameters के साथ unattended install के लिए चलाया जा सकता है
  इसकी जानकारी official document में दी गई है
  2018 में जब मैं धीमे satellite network वाले environment में काम कर रहा था, तब offline install package बनाना था, इसलिए मैंने यही तरीका इस्तेमाल किया था

  • मैंने कोशिश की थी, लेकिन अनावश्यक downloads बहुत ज़्यादा थे, और install के लिए फिर भी admin privileges चाहिए थे
  • (high-latency connection कहना शायद ज़्यादा सही होगा…)

• script देखी तो उसमें
  curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...
  ऐसा लिखा है
  लेकिन किसी अज्ञात GitHub account के executable को hash verification के बिना इंस्टॉल करना मुझे ठीक नहीं लगता
  Windows की हालत उतनी बुरी नहीं है जितनी blog में बताई गई है, लेकिन यह समाधान से ज़्यादा एक और risky install script जैसा लगता है

  • executable इंस्टॉल करने की ज़रूरत ही नहीं है
    बस script को खुद पढ़कर जाँच लो
    curl|sh तरीका भी आख़िरकार source code ही डाउनलोड करता है, executable को सीधे इंस्टॉल करने से ज़्यादा जोखिम भरा नहीं है
  • Jonathan Marler Zig से जुड़े talks और win32 API bindings के काम के लिए जाने जाते हैं
    उनका project zigwin32 Microsoft के win32metadata में भी linked है
    यानी वे भरोसेमंद व्यक्ति हैं

• यह लेख AI से लिखा हुआ लग रहा है
  “it’s not just X, but Y” जैसी sentence structure और emphasized lists एक typical LLM style लगती हैं
  जानना दिलचस्प होगा कि project कितना इंसानों ने बनाया है

  • तुम्हारा nickname “its_notjack” है, यह थोड़ा मज़ेदार है
  • मुझे भी शुरुआत में शक हुआ था
    list structure अजीब थी और consistency कम थी
    लेकिन अगर यह LLM ने लिखा है, तो शायद यह इस बात का सबूत भी हो सकता है कि आजकल LLM की quality काफ़ी बढ़ गई है
    Grammarly जैसे tools का असर भी हो सकता है
  • हो सकता है लोग LLM style को imitate कर रहे हों
    क्योंकि वह readers के लिए पढ़ना आसान बनाती है
  • “The key insight is…” जैसे expressions Claude की आम writing style लगते हैं, इसलिए ऐसा एहसास होता है
    बस ईमानदारी से बता दिया जाए कि AI इस्तेमाल हुआ था या नहीं, यही बेहतर होगा

• Visual Studio DX को बेहतर बनाने की कोशिश के रूप में msvcup वाकई ताज़गीभरा है
  काश मेरे college के दिनों में ऐसा कुछ होता
  एक विकल्प container में Build Tools install करना भी है

• बस winget से इंस्टॉल कर लो
  winget install --id Microsoft.VisualStudio.2022.BuildTools
  अगर WinRT features चाहिए हों तो
  winget install --id Microsoft.WindowsSDK.10.0.18362
winget install --id Microsoft.WindowsAppRuntime.1.8 भी जोड़े जा सकते हैं

  • पहले मैं इन packages को support करता था, लेकिन यह इतना simple नहीं है
    कौन-सा workload इंस्टॉल करना है यह भी बताना पड़ता है, और project की जानकारी न हो तो बहुत trial and error होता है
    .vsconfig थोड़ी मदद करता है, लेकिन यह perfect नहीं है

• काश open source projects MinGW support को block न करें
  यह बिना अतिरिक्त DLLs के भी ठीक से चलने वाला अच्छा compiler है
  समझ नहीं आता कि open source क्यों ज़बरदस्ती proprietary compiler पर निर्भर करे

  • MinGW कुछ Windows-specific libraries (WIL) के साथ compatible नहीं है
    WIL वह library है जिसे kernel developers बहुत पसंद करते हैं, क्योंकि यह code safety और convenience काफ़ी बढ़ाती है
  • जब बाहर से बने हुए MSVC libraries को link करना हो, तब MinGW कोई विकल्प नहीं रहता
    उदाहरण के लिए Steamworks SDK MinGW से build तो हो जाता है, लेकिन runtime पर crash करता है
  • मैं भी चाहता हूँ कि MinGW support ज़्यादा हो
    अफ़सोस है कि इस blog post में उसका ज़िक्र तक नहीं है
  • मुझे MinGW पसंद नहीं
    बस Clang + MSVC STL + WinSDK का combination कहीं ज़्यादा साफ़-सुथरा है

• या इसे और सरल तरीके से भी किया जा सकता है
  "winget install Microsoft.VisualStudio.BuildTools"
"winget install Microsoft.WindowsSDK.10.0.26100"

  • मैं भी हमेशा यही करता हूँ
    मेहनत के मुकाबले reliability अच्छी मिलती है, इसलिए यही पसंद है
  • लेकिन ऐसी installs system-wide होती हैं, इसलिए project-specific अलग versions चाहिए हों तो दिक्कत होती है
    काश हर language में Python uv जैसा version isolation tool होता
  • Windows की आलोचना का बड़ा हिस्सा 20 साल पुरानी बातें हैं
    Bing, Copilot, ads जैसी चीज़ें आलोचना लायक हैं, लेकिन ज़्यादातर disable की जा सकती हैं

[click]

मुझे भी Ubuntu 24.04 में build करके cents 6 या 7 में चलाने की कोशिश करते समय glibc dependency की समस्या आई थी।
लगता है कि डिफ़ॉल्ट रूप से build environment का glibc version साथ ले लेना ही समस्या है।

[penza1]

glibc पर निर्भरता तो अनिवार्य है..
python/jv/.net/js जैसी स्क्रिप्ट भाषाएँ नहीं होने पर glibc पर निर्भरता होना स्वाभाविक है
इसी वजह से हर distribution के लिए लाइब्रेरीज़ वितरित की जाती हैं
कम-से-कम glibc पर build किया गया बाइनरी, अगर कोई खास अतिरिक्त dependency न हो, तो दूसरे higher version distributions पर भी पर्याप्त रूप से चल सकता है

[geekbini]

WSL2 में Ubuntu के साथ Windows पर development करना अब काफ़ी बेहतर हो गया है। लेकिन अगर environment VSCode नहीं बल्कि Visual Studio वाला है, तो लगता है कि यह कम से कम कुछ हद तक मददगार हो सकता है। वैसे लगता है कि choco या winget जैसे package manager से Windows पर यह नहीं हो पाता।

[click]

ऐसा लगता है कि package managers, SDK की तुलना में final output पर ज़्यादा फोकस करते हैं
vcredist जैसी चीज़ों को ज़्यादातर डेवलपर्स package manager scripts के भीतर install होने के लिए सेट करते हैं
लेकिन build environment की बात थोड़ी अलग है