ผมได้แก้สภาพแวดล้อมการพัฒนาแบบเนทีฟบน Windows แล้ว

 (marler8997.github.io)
8 คะแนน โดย GN⁺ 2026-02-16 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • การพัฒนาแบบเนทีฟบน Windows มีความซับซ้อนและไม่มีประสิทธิภาพเพราะ ต้องพึ่งพาการติดตั้ง Visual Studio
  • ขนาดติดตั้งหลายสิบ GB, การจัดการคอมโพเนนต์ที่ไม่โปร่งใส, ปัญหาเวอร์ชันไม่ตรงกัน เป็นต้น ล้วนทำให้ประสิทธิภาพการทำงานของนักพัฒนาลดลง
  • เพื่อแก้ปัญหานี้ จึงพัฒนาเครื่องมือ CLI แบบน้ำหนักเบา msvcup ที่สามารถ ติดตั้ง MSVC toolchain และ Windows SDK แบบอัตโนมัติ แยกตามเวอร์ชันและแยกสภาพแวดล้อม
  • msvcup มอบสภาพแวดล้อมการบิลด์ที่ทำซ้ำได้ผ่าน การพาร์ส JSON manifest, การตั้งค่าสภาพแวดล้อมอัตโนมัติ (autoenv) และ การรองรับ lock file
  • แนวทางนี้ทำให้สามารถสร้าง ระบบบิลด์อัตโนมัติเต็มรูปแบบที่อิงสคริปต์ ได้โดยไม่ต้องพึ่ง Visual Studio Installer

ปัญหาของการพัฒนาแบบเนทีฟบน Windows

  • วิธีเดิมที่ต้องติดตั้ง Visual Studio สร้างภาระให้กับนักพัฒนา เพราะมี ขั้นตอนติดตั้งที่ซับซ้อนและการจัดการ dependency ที่ไม่เสถียร
    • ต้องเลือกอย่างละเอียด เช่น เวิร์กโหลด “Desktop development with C++” หรือเวอร์ชัน SDK เฉพาะ และหากเลือกผิดอาจทำให้บิลด์ล้มเหลว
    • ขนาดติดตั้งสูงถึง 50GB และแม้ลบออกแล้วก็ยังมี รายการค้างในรีจิสทรีและบริการเบื้องหลัง เหลืออยู่
  • บน Linux สามารถติดตั้ง toolchain ได้ด้วยคำสั่ง package manager เพียงบรรทัดเดียว แต่บน Windows กลับต้องเลือกคอมโพเนนต์หลายพันรายการด้วยตนเอง
  • Visual Studio เป็น โครงสร้างแบบรวมศูนย์ที่ผูก editor, compiler และ SDK เข้าด้วยกัน ทำให้จัดการเวอร์ชันและทำสภาพแวดล้อมให้ทำซ้ำได้ยาก
  • ผลลัพธ์คือความไม่ตรงกันแบบ “เครื่องฉันใช้ได้” เกิดขึ้นบ่อย และกลายเป็น กำแพงในการเริ่มต้นพัฒนาแบบเนทีฟ

msvcup: แนวทางใหม่

  • msvcup เป็นเครื่องมือ CLI โอเพนซอร์สที่ ดาวน์โหลดและติดตั้ง MSVC toolchain และ Windows SDK โดยตรง โดยไม่ต้องติดตั้ง Visual Studio
    • แต่ละเวอร์ชันจะถูกติดตั้งใน ไดเรกทอรีแยกกัน ใต้ C:\msvcup\ ทำให้ใช้งานหลายเวอร์ชันคู่ขนานกันได้โดยไม่ชนกัน
    • การติดตั้งเสร็จได้ภายใน ไม่กี่นาที และรวมเครื่องมือ cross-compile สำหรับ ARM ให้อัตโนมัติด้วย
  • คำสั่ง msvcup install จะติดตั้งแพ็กเกจที่จำเป็น และคำสั่ง autoenv จะสร้าง ไดเรกทอรีสภาพแวดล้อมอัตโนมัติ
    • ในไดเรกทอรีนี้จะมี wrapper executable ที่ตั้งค่า environment variable ให้อัตโนมัติ และไฟล์ toolchain.cmake ทำให้โปรเจกต์ CMake สามารถบิลด์ได้โดยไม่ต้องตั้งค่าเพิ่มเติม
  • ในตัวอย่างสคริปต์ build.bat สามารถบิลด์โปรแกรม “Hello, World” ผ่าน msvcup ได้ โดยไม่ต้องใช้ Visual Studio
    • ใช้งานได้บน Windows 10 ขึ้นไป หากมีเพียง curl และ tar

หลักการทำงานภายใน

  • พาร์ส JSON manifest ของคอมโพเนนต์ Visual Studio ที่ Microsoft แจกจ่าย เพื่อระบุเฉพาะแพ็กเกจที่จำเป็น
    • ดาวน์โหลดเฉพาะองค์ประกอบหลัก เช่น compiler, linker, header และ library จาก Microsoft CDN โดยตรง
  • คอมโพเนนต์ที่ติดตั้งแล้วจะถูกจัดการด้วย lock file ทำให้ทั้งทีมสามารถใช้แพ็กเกจเวอร์ชันเดียวกันร่วมกันได้
  • คำสั่ง install และ autoenv มีคุณสมบัติ idempotent คือหากติดตั้งไว้แล้วจะทำงานเสร็จภายในไม่กี่มิลลิวินาที

กรณีใช้งานจริง

  • Tuple (แอป pair programming) ได้ผนวก msvcup เข้ากับระบบบิลด์ CI เพื่อตัดข้อกำหนดการติดตั้ง Visual Studio ล่วงหน้าออกไป
    • สามารถบิลด์โปรเจกต์ C/C++ หลายร้อยรายการรวมถึง WebRTC ด้วย toolchain/SDK ชุดเดียวกัน
    • รองรับทั้งการบิลด์ x86_64 และ ARM
  • ข้อดี
    • การติดตั้งแบบแยกไดเรกทอรีตามเวอร์ชัน ทำให้ จัดการหลายเวอร์ชันพร้อมกันและติดตั้งใหม่ได้ง่าย
    • รองรับ cross-compile อัตโนมัติ โดยไม่ต้องตั้งค่าเพิ่ม
    • รับประกันความสามารถในการทำซ้ำด้วย lock file และรับรู้ได้ทันทีหากฝั่ง Microsoft มีการเปลี่ยนแปลง
    • ทำงานได้รวดเร็ว โดยไม่มีการติดตั้งซ้ำที่ไม่จำเป็น

ข้อจำกัดและการต่อยอด

  • msvcup ถูกออกแบบมาโดยเน้น toolchain สำหรับคอมไพล์ ดังนั้นหากยังต้องใช้ Visual Studio IDE เอง ก็ยังจำเป็นต้องติดตั้งแบบทางการอยู่
  • อย่างไรก็ตาม ในเวิร์กโฟลว์การพัฒนาแบบเนทีฟส่วนใหญ่ มันสามารถมอบ สภาพแวดล้อมการบิลด์ที่สมบูรณ์ได้โดยไม่ต้องมี IDE
  • ตัวอย่าง สคริปต์บิลด์ raylib ที่นำเสนอ แสดงให้เห็นว่าสามารถติดตั้ง SDK และ toolchain แบบอัตโนมัติและบิลด์โปรเจกต์ได้โดยไม่ต้องใช้ Visual Studio
    • ดำเนินกระบวนการบิลด์แบบ อัตโนมัติเต็มรูปแบบผ่านบรรทัดคำสั่ง โดยไม่ต้องมี GUI

บทสรุป

  • msvcup ช่วยตัดความซับซ้อนของ Visual Studio Installer ออกไป และมอบ สภาพแวดล้อมการบิลด์แบบเนทีฟที่มีน้ำหนักเบาและจัดการเวอร์ชันได้
  • แนวทางนี้เปลี่ยนการพัฒนาแบบเนทีฟบน Windows ให้เป็นรูปแบบที่ ทำซ้ำได้และทำงานอัตโนมัติ มากขึ้น ช่วยให้นักพัฒนาหลุดพ้นจากการพึ่งพา IDE
  • Repo : https://github.com/marler8997/msvcup

บทความที่เกี่ยวข้อง

5 ความคิดเห็น

 
GN⁺ 2026-02-16
ความคิดเห็นจาก Hacker News

  • ดูซับซ้อนกว่างานที่ฉันทำอีก
    แค่ติดตั้ง LTSC Visual Studio Build Tools แล้วใส่คำสั่งแบบ cl yourprogram.c /link user32.lib advapi32.lib ... ลงในไฟล์ cmd ก็พอ
    ฉันแก้โค้ดด้วย vim และสร้างยูทิลิตีหลายตัวด้วยวิธีนี้มาตลอด
    ใน toolchain ของ Visual Studio มีทั้ง LTSC และเวอร์ชันเสถียร แต่คนส่วนใหญ่ไม่ค่อยรู้
    ถ้าทำงานร่วมกันเป็นทีม ก็ควรใช้เวอร์ชันคงที่จาก เอกสารประวัติการออกรีลีสอย่างเป็นทางการ
    เหมือนสมัยก่อนที่ทั้งบริษัทตรึงใช้ toolchain เวอร์ชันเดียวกันนั่นแหละ

    • การเข้าถึงช่อง LTSC ต้องมี ไลเซนส์ Visual Studio Professional ขึ้นไป
      เพราะงั้นนักเรียนหรือนักพัฒนาเล่นๆ หลายคนเลยไม่ค่อยรู้จัก
      แต่คนที่ใช้ VS ในบริษัทส่วนใหญ่จะรู้เรื่องนี้
    • Visual Studio 2026 ยังไม่มี LTSC release
      มีใครรู้ไหมว่าจะออกเมื่อไหร่?

  • toolchain ของ Linux ก็ไม่ได้รอดพ้นจาก dependency hell
    ติดตั้งแพ็กเกจ npm แล้วดันต้องใช้ cmake บ้าง, ชนกับเวอร์ชัน glibc บ้าง, หรือเป็นโปรเจ็กต์ C++ ที่ต้องการ boost เวอร์ชันล่าสุด ฯลฯ
    ฉันยังจำตอนแพตช์ openSSL ช่วง heartbleed ได้อยู่เลย
    Visual Studio ก็ใช้งานลำบาก แต่ขุมนรกจริงๆ คือ ความสับสนเรื่องเวอร์ชัน .NET Framework
    แต่ละเวอร์ชันของ Windows มี .NET ที่ติดตั้งมาไม่เหมือนกัน และก็ไม่ชัดเจนว่าแอปจะรันบน runtime ไหน
    เพราะงั้นเวลาปล่อยใช้งานวงกว้างก็ต้องทำ shim สำหรับตรวจเวอร์ชัน .NET ด้วย C++ เพื่อให้ไปรันบน runtime ที่ถูกต้อง

    • ถ้าปัญหา dependency เกิดจากตัว glibc เอง นั่นหายากมากจนแทบอยากฟังเป็นกรณีศึกษา
      ทีม glibc เข้มงวดมากเรื่อง ความเข้ากันได้ย้อนหลังและไปข้างหน้า
      ใน บทความของ LWN มีบอกไว้ว่าครั้งล่าสุดที่มีการทำลายความเข้ากันได้คือเมื่อไร
      ปัญหาจริงคือคนชอบ pin เวอร์ชัน glibc ผิดๆ
      glibc ไม่ควรถูก pin เวอร์ชัน
      ส่วน GCC เคยทำลายความเข้ากันได้อยู่บ้าง แต่ส่วนใหญ่เป็นเพราะการเปลี่ยนแปลงของมาตรฐาน C++
    • .NET ยุคนี้เปลี่ยนไปหมดแล้ว
      .NET Framework เป็นของ legacy ไปแล้ว และหลัง .NET 5 ก็ไม่มีปัญหาแบบนี้
      แต่ก็ยังมีแอปจำนวนมากที่พึ่งพาเวอร์ชันเก่าอยู่
    • เมื่อก่อนการพัฒนา C/C++ ใช้แค่ system package manager ก็พอ แต่เพราะปัญหาเรื่องต้องการเวอร์ชันใหม่กว่า จึงเกิด package manager รายภาษา
      มันแก้ปัญหาได้ก็จริง แต่ก็สร้าง ความซับซ้อนแบบใหม่ ขึ้นมาพร้อมกัน
      บางทีก็อยากกลับไปยุค system package manager อย่างเดียว
    • แรงเสียดทานด้าน UX ตอน build ของ C/C++ เป็นเรื่องน่าหงุดหงิดแยกต่างหากจากประเด็น memory safety
      ในสาย embedded ฝั่ง rust + probe-rs ใช้งานสบายกว่ามาก

  • ตัวติดตั้ง Visual Studio รองรับการติดตั้งแบบไร้ผู้ดูแลผ่าน พารามิเตอร์บรรทัดคำสั่ง
    มีอธิบายไว้ในเอกสารทางการ
    ตอนปี 2018 ฉันเคยทำงานบนเครือข่ายดาวเทียมที่เน็ตช้า เลยใช้วิธีนี้เพราะต้องสร้างแพ็กเกจติดตั้งแบบออฟไลน์

    • ลองแล้ว แต่มี การดาวน์โหลดที่ไม่จำเป็น เยอะมาก และการติดตั้งก็ยังต้องใช้สิทธิ์แอดมินอยู่ดี
    • (ถ้าเป็นการเชื่อมต่อที่ latency สูง… ใช้คำว่า “high-latency” น่าจะตรงกว่า)

  • ดูจากสคริปต์แล้ว
    curl -L -o msvcup.zip https://github.com/marler8997/msvcup/releases/...
    มันเป็นแนวนี้
    แต่ฉันไม่ค่อยอยากติดตั้ง ไฟล์ปฏิบัติการจากบัญชี GitHub ที่ไม่รู้ที่มา โดยไม่ตรวจสอบ hash
    สถานการณ์บน Windows อาจไม่ได้แย่อย่างที่บล็อกพูด แต่สิ่งนี้ดูไม่ใช่วิธีแก้ปัญหาเท่าไร มันเหมือนสคริปต์ติดตั้งเสี่ยงๆ อีกตัวมากกว่า

    • ไม่จำเป็นต้องติดตั้งไฟล์ปฏิบัติการก็ได้
      แค่อ่านและ ตรวจทานสคริปต์ด้วยตัวเอง ก็พอ
      วิธีแบบ curl|sh สุดท้ายก็คือการดาวน์โหลดซอร์สโค้ด ไม่ได้เสี่ยงไปกว่าการติดตั้งไฟล์ปฏิบัติการโดยตรง
    • Jonathan Marler เป็นที่รู้จักจากงานบรรยายเกี่ยวกับ Zig และ งานทำ binding ของ win32 API
      โปรเจ็กต์ของเขา zigwin32 ยังถูกลิงก์จาก win32metadata ของ Microsoft ด้วย
      พูดอีกแบบคือเป็นคนที่น่าเชื่อถือ

  • บทความนี้ ให้ความรู้สึกเหมือน AI เขียน
    โครงประโยคแบบ “it’s not just X, but Y” หรือรายการเน้นประเด็นต่างๆ เป็นสไตล์ LLM ชัดเจน
    เลยสงสัยว่าโปรเจ็กต์นี้มีส่วนที่มนุษย์ทำเองมากแค่ไหน

    • ชื่อแอ็กเคานต์คุณเป็น “its_notjack” นี่ก็ตลกดี
    • ตอนแรกฉันก็สงสัยเหมือนกัน
      โครงสร้างรายการดูแปลกและความสม่ำเสมอก็ไม่ค่อยมี
      แต่ถ้า LLM เป็นคนเขียนจริง ก็อาจเป็น หลักฐานว่าคุณภาพ LLM ทุกวันนี้ดีขึ้นมาก
      หรืออาจเป็นผลจากเครื่องมืออย่าง Grammarly ก็ได้
    • บางทีผู้คนอาจกำลัง เลียนแบบ สไตล์ของ LLM อยู่ก็ได้
      เพราะมันอ่านง่ายสำหรับผู้อ่าน
    • สำนวนอย่าง “The key insight is...” เป็นโทนที่ Claude ชอบใช้บ่อย เลยให้ความรู้สึกแบบนั้น
      เอาจริงๆ แค่อยากให้เปิดเผยไปตรงๆ ว่าใช้ AI หรือเปล่า

  • ในฐานะความพยายามปรับปรุง DX ของ Visual Studio, msvcup นี่สดใหม่มาก
    ถ้าสมัยเรียนมหาวิทยาลัยมีอะไรแบบนี้ก็คงดี
    อีกทางเลือกหนึ่งคือ ติดตั้ง Build Tools ลงในคอนเทนเนอร์

  • ติดตั้งด้วย winget ก็จบแล้ว
    winget install --id Microsoft.VisualStudio.2022.BuildTools
    ถ้าต้องใช้ฟีเจอร์ WinRT ก็เพิ่ม
    winget install --id Microsoft.WindowsSDK.10.0.18362
    winget install --id Microsoft.WindowsAppRuntime.1.8 ได้

    • ฉันเคยรองรับแพ็กเกจพวกนี้อยู่ แต่มันไม่ได้ง่าย
      ต้องระบุด้วยว่าจะติดตั้ง workload ไหน และถ้าไม่รู้โปรเจ็กต์ก็ต้องลองผิดลองถูกเยอะ
      .vsconfig ช่วยได้บ้าง แต่ก็ไม่สมบูรณ์

  • อยากให้โปรเจ็กต์โอเพนซอร์สต่างๆ ไม่กีดกันการรองรับ MinGW
    มันเป็นคอมไพเลอร์ที่ดีและทำงานได้เยี่ยมโดยไม่ต้องมี DLL เพิ่ม
    ไม่เข้าใจว่าทำไมโอเพนซอร์สถึงต้องบังคับใช้คอมไพเลอร์แบบปิดด้วย

    • MinGW เข้ากันไม่ได้กับ ไลบรารีเฉพาะทางของ Windows (WIL) บางตัว
      WIL เป็นไลบรารีที่นักพัฒนาเคอร์เนลนิยมใช้ และช่วยเพิ่มทั้งความปลอดภัยของโค้ดกับความสะดวกได้มาก
    • ถ้าต้องลิงก์กับ ไลบรารี MSVC ที่ build มาจากภายนอก MinGW ก็ใช้ไม่ได้
      ตัวอย่างเช่น Steamworks SDK build ด้วย MinGW ได้ แต่พอรันจริงกลับ crash
    • ฉันก็อยากให้มีการรองรับ MinGW มากกว่านี้เหมือนกัน
      เสียดายที่แม้แต่ในบล็อกโพสต์นี้ก็ยังไม่พูดถึงเลย
    • ฉันไม่ชอบ MinGW
      ใช้ Clang + MSVC STL + WinSDK มันสะอาดกว่ามาก

  • หรือจะทำแบบนี้ง่ายๆ ก็ได้
    "winget install Microsoft.VisualStudio.BuildTools"
    "winget install Microsoft.WindowsSDK.10.0.26100"

    • ฉันก็ใช้แบบนี้ตลอด
      ชอบตรงที่ เสถียรเมื่อเทียบกับความพยายามที่ลงไป
    • แต่การติดตั้งแบบนี้เป็นระดับทั้งระบบ ถ้าโปรเจ็กต์แต่ละตัวต้องการคนละเวอร์ชันก็ลำบาก
      อยากให้ทุกภาษามี เครื่องมือแยกเวอร์ชันแบบ Python uv
    • คำวิจารณ์ Windows หลายอย่างเป็นเรื่องเมื่อ 20 ปีก่อน
      เรื่องอย่าง Bing, Copilot หรือโฆษณาก็สมควรถูกวิจารณ์อยู่ แต่ส่วนใหญ่ก็ ปิดได้
 
click 2026-02-16

ผมก็เจอปัญหา dependency ของ glibc เหมือนกันตอนบิลด์บน Ubuntu 24.04 แล้วพอจะไปรันบน CentOS 6 หรือ 7
ดูเหมือนว่าปัญหาคือมันดึงเวอร์ชัน glibc ของสภาพแวดล้อมที่ใช้บิลด์มาเป็นค่าเริ่มต้น
 
penza1 2026-02-18

ยังไงก็หลีกเลี่ยงการพึ่งพา glibc ไม่ได้ครับ..
ถ้าไม่ใช่ภาษาสคริปต์อย่าง python/jv/.net/js ก็เลี่ยงการพึ่งพา glibc ไม่ได้อยู่แล้ว
และนี่ก็เป็นเหตุผลว่าทำไมถึงต้องแจกจ่ายไลบรารีแยกตามแต่ละดิสโทร
อย่างน้อย ถ้าบิลด์บน glibc ขั้นต่ำมา และไม่มี dependency อื่นเป็นพิเศษ ก็สามารถรันบนดิสโทรเวอร์ชันที่สูงกว่าตัวอื่น ๆ ได้สบายครับ
 
geekbini 2026-02-16

บน WSL2 ที่ใช้ Ubuntu ก็ทำให้การพัฒนาบน Windows ดีขึ้นมากเหมือนกันครับ แต่ถ้าเป็นสภาพแวดล้อมของ Visual Studio ไม่ใช่ VS Code ก็ดูเหมือนว่านี่น่าจะพอช่วยได้อยู่บ้างนะครับ แต่ก็เหมือนว่าบน Windows จะใช้แพ็กเกจเมเนเจอร์อย่าง choco หรือ winget ไม่ได้สินะครับ
 
click 2026-02-16

ดูเหมือนว่าตัวจัดการแพ็กเกจจะโฟกัสที่ผลลัพธ์สุดท้ายมากกว่า SDK
อย่าง vcredist เอง นักพัฒนาส่วนใหญ่ก็มักตั้งค่าให้ติดตั้งภายในสคริปต์ของตัวจัดการแพ็กเกจ
แต่ถ้าเป็นสภาพแวดล้อมสำหรับการบิลด์ก็จะเป็นอีกเรื่องหนึ่ง