สร้างแอป Todo สำหรับ Windows แบบเนทีฟด้วย C ล้วน (278KB, ไม่ใช้เฟรมเวิร์ก)

 (github.com/Efeckc17)
10 คะแนน โดย GN⁺ 2025-05-12 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Simple Todo เป็นแอป Todo สำหรับ Windows แบบเนทีฟที่สร้างด้วย C และ Win32 API เป็นโปรเจกต์ที่แสดงให้เห็นการเขียนโปรแกรม GUI บน Windows และความสามารถในการผสานกับระบบ
  • ฟีเจอร์หลักคือการสร้าง·แก้ไข·ลบ Todo, ทำเครื่องหมายว่าเสร็จแล้ว, ย่อไปที่ system tray, ตัวเลือกเริ่มทำงานอัตโนมัติพร้อม Windows และการค้นหาแบบเรียลไทม์ที่ไม่แยกตัวพิมพ์ใหญ่-เล็ก
  • ข้อมูลถูกบันทึกเป็น ไฟล์ไบนารี ที่ %APPDATA%\TodoApp\todos.dat โดยเก็บรายการ Todo ทั้งหมดและรองรับ Todo ได้สูงสุด 100 รายการ
  • การ build ต้องใช้ MinGW-w64 และ Windows SDK บน Windows หลังจากโคลน repository แล้วคอมไพล์ด้วย .\build.bat
  • โครงสร้างแบ่งเป็น main.c, todo.c, gui.c, utils/search.c โดย GUI ใช้ Win32 API·Common Controls·UXTheme

ลักษณะของโปรเจกต์

  • Simple Todo เป็นแอป Todo สำหรับ Windows แบบเนทีฟที่เขียนด้วย C และ Win32 API
  • มุ่งสร้างไฟล์ executable แบบเนทีฟที่เบา และใช้ look and feel พื้นฐานของ Windows พร้อม visual style สมัยใหม่ของ Windows
  • GUI อิงกับ Win32 API และรวมการผสานกับ system tray รวมถึงการคงอยู่ของข้อมูลผ่าน file I/O

ฟีเจอร์ Todo

  • สามารถ สร้าง แก้ไข ลบ รายการ Todo ได้
  • สามารถทำเครื่องหมายงานเป็นสถานะเสร็จแล้วได้
  • สามารถตั้งค่า ลำดับความสำคัญ ให้แต่ละ Todo ได้
  • ฟีเจอร์ค้นหาทำงานแบบเรียลไทม์และรองรับ การจับคู่แบบไม่แยกตัวพิมพ์ใหญ่-เล็ก
  • สามารถย่อแอปไปไว้ที่ system tray ได้
  • มีตัวเลือกให้รันอัตโนมัติเมื่อ Windows เริ่มทำงาน

วิธีจัดเก็บข้อมูล

  • ข้อมูล Todo ถูกบันทึกไว้ที่ %APPDATA%\TodoApp\todos.dat
  • รูปแบบการบันทึกเป็น ไฟล์ไบนารี ที่เก็บรายการ Todo ทั้งหมด
  • ความจุถูกจำกัดไว้สูงสุด 100 Todo

การ build และการรัน

  • ข้อกำหนด
    • Windows OS
    • คอมไพเลอร์ GCC MinGW-w64
    • Windows SDK ที่รวมมากับ MinGW
  • ขั้นตอนการ build
    • ติดตั้ง MinGW-w64 และเพิ่มไดเรกทอรี bin เข้าใน PATH ของระบบ
    • โคลน repository แล้วไปยังไดเรกทอรี simple-todo-c
    • รัน .\build.bat เพื่อ build
  • เริ่มรันด้วย bin/todo.exe

องค์ประกอบการพัฒนา

  • โครงสร้างโปรเจกต์แบ่งเป็นไฟล์ C ตามฟังก์ชัน
    • src/main.c: จุดเริ่มต้นของแอปพลิเคชัน
    • src/todo.c, src/todo.h: ลอจิกการจัดการ Todo และโครงสร้างข้อมูล
    • src/gui.c: การพัฒนา GUI
    • src/utils/search.c, src/utils/search.h: การพัฒนาและประกาศฟังก์ชันค้นหา
    • src/app.manifest: manifest สำหรับ visual style ของ Windows
  • องค์ประกอบหลักคือ Win32 API, Common Controls, UXTheme, File I/O
  • สำหรับการดีบัก มีคู่มือ DEBUGGING.md ที่ใช้ได้กับ Visual Studio, VS Code เป็นต้น

ไลเซนส์และการมีส่วนร่วม

  • ไลเซนส์คือ MIT License
  • รับการมีส่วนร่วมผ่าน Pull Request

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

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

 
aer0700 2025-05-13

มีความโรแมนติกดีนะ
 
GN⁺ 2025-05-12
ความคิดเห็นจาก Hacker News

  • การเขียนโปรแกรม GUI ด้วย Win32 มีบางอย่างที่ชวนให้ชอบอย่างประหลาด
    มันอาจจะแปลกอยู่บ้าง แต่ถ้าอ่านบล็อกของ Raymond Chen จะเริ่มเห็นเหตุผล
    Win32 API มีรากมาตั้งแต่ยุคโปรเซสเซอร์ 8088 จึงมีที่มาประมาณว่า ถ้าทำด้วยวิธีเฉพาะบางอย่างจะประหยัดโค้ดได้ 40 ไบต์ หรือใช้รีจิสเตอร์น้อยลงหนึ่งตัว
    เมื่อก่อนเคยทำแอป GUI ของเล่นไว้เยอะด้วย mingw กับหนังสือของ Petzold และสิ่งต่าง ๆ อย่างการเขียน custom control, การวาดกราฟิกกับข้อความ, การจัดการสกรอลล์, hit testing ล้วนสนุกพอสมควร
    เห็นในแอปใช้ strcpy, sprintf อยู่ ถ้าเป็นการเขียนโปรแกรมจริงจังควรใช้เวอร์ชันที่ตรวจสอบความยาวด้วย แปลกใจที่คอมไพเลอร์ไม่ได้พ่นคำเตือนออกมาเพียบ
    ใน Win32 API มีฟังก์ชันจำนวนมากที่ใช้แทนสิ่งที่อยู่ในไลบรารีมาตรฐาน C ได้ ถ้าอยากลดขนาดไฟล์ executable จริง ๆ ก็ลองเขียนแอปโดยไม่ใช้ไลบรารีมาตรฐาน C ได้ มี ZeroMemory() แทน memset() และ CopyMemory() แทน memcpy()
    ถึงจุดหนึ่ง การเขียนโค้ด C ล้วน ๆ เองจะเริ่มทรมาน แต่คิดว่าการลองทำด้วย C ล้วน ๆ ในช่วงแรก ๆ เป็นวิธีเรียนรู้ที่ดีที่สุด การจัดการรายละเอียดเองทำให้ระหว่างเรียนมองเห็นภาพได้ดีว่าเบื้องหลังเกิดอะไรขึ้น
    ถ้าอยากลองเขียน Win32 GUI ต่อ แนะนำให้ดู WTL(Windows Template Library) เป็น C++ wrapper ครอบ Win32 API ทำให้เข้าใจพฤติกรรมได้ง่ายขึ้นมาก

    • ผมใช้แอป PC ดี ๆ ตัวหนึ่งชื่อ AlomWare Toolbox ซึ่งแทบจะเป็นตัวอย่างคลาสสิกของการออกแบบ Win32(https://www.alomware.com/images/tab-automation.png)
      แม้จะมีฟีเจอร์เยอะมาก แต่ด้วยเหตุนี้ขนาดจึงมีแค่ประมาณ 3MB ไม่มีเฟรมเวิร์ก และมีเพียงไฟล์ executable เดียว ถ้าซอฟต์แวร์ทั้งหมดยังเป็นแบบนี้ก็คงดี
    • ทุกวันนี้ถ้าอย่างน้อยไม่ใช้ strncpy แทน strcpy ก็ต้องยอมรับว่าทั้งคนและแม้แต่ เครื่องมือ AI จะคอยบอกซ้ำ ๆ ว่าไม่ควรทำแบบนั้น
      โดยส่วนตัว เหตุผลหลักอย่างหนึ่งที่ใช้ Zig คือมันช่วยลดกับดักที่พบบ่อยเหล่านี้ได้มาก แน่นอนว่า C ก็ยังโอเค
    • แม้จะบอกว่ามี ZeroMemory() แทน memset() และ CopyMemory() แทน memcpy() แต่ MSVC intrinsic น่าจะใช้คำสั่ง rep stos/movs
      ซึ่งอาจเล็กกว่าการเรียกฟังก์ชัน เพราะการเรียกฟังก์ชันยังรวมขนาดของ entry ใน import table ด้วย
    • เคยทำงานแบบนั้นมาเยอะ และพูดตรง ๆ ว่าคิดถึงความสามารถในการพัฒนา UI แบบเนทีฟด้วยโค้ดเนทีฟ
    • ยังใช้ fopen/fread/fclose ด้วย แต่ดูเหมือนไม่ได้ใช้ Win32 API อย่าง CreateFile/ReadFile/WriteFile

  • แทนที่จะลำบากเรียก CreateWindow() ทีละคอนโทรล ตามธรรมเนียมแล้วจะจัดวาง dialog resource ไว้ในไฟล์ .rc (Visual Studio ยังมีตัวแก้ไข dialog แบบมองเห็นภาพสำหรับทำสิ่งนี้อยู่) แล้วใช้ CreateDialog() แทน CreateWindow()
    วิธีนี้จะสร้างคอนโทรลทั้งหมดให้อัตโนมัติ ถ้าเพิ่ม application manifest ก็จะได้สไตล์ UI สมัยใหม่และการรองรับ high-DPI ด้วย

    • วิธีนี้ยังได้ การย้ายโฟกัสด้วย Tab ระหว่างคอนโทรลและคีย์ลัดคีย์บอร์ดบางอย่างโดยอัตโนมัติ
      แต่ถ้าต้องการให้ปรับขนาดได้ ก็ยังต้องจัดการเองอยู่ดี ทว่าโดยทั่วไปทำได้ง่ายและโค้ดก็ไม่เกินไม่กี่ร้อยไบต์
    • ความซ้ำซ้อนระหว่างไลบรารีมาตรฐาน C กับไลบรารีของระบบปฏิบัติการนั้นแทบจะมีเฉพาะ UNIX เท่านั้น และในปี 1985 ที่ Windows 1.0 ออกมา ก็ยังไม่มีอะไรที่พอเรียกได้ว่าเป็นมาตรฐาน
      มี K&R C อยู่ก็จริง แต่ระบบปฏิบัติการแต่ละตัวนอก UNIX ต่างก็เลือกฟังก์ชันที่จะให้เองตามใจ
      อีกทั้งในที่ที่ไม่ใช่ตระกูล UNIX ยังมีธรรมเนียมว่าไลบรารีมาตรฐานเป็นความรับผิดชอบของคอมไพเลอร์ C ไม่ใช่แพลตฟอร์ม
      ดังนั้นไลบรารี C จึงถูกจัดให้โดย Borland, Watcom, Symantec, Microsoft, Green Hills, Zortech ฯลฯ
      Mac OS ก็เป็นแบบเดียวกันจนกว่าจะมี MPW และ IBM กับ Unisys, ไมโครคอมพิวเตอร์กับเมนเฟรม, รวมถึง VMS ก่อน OpenVMS ก็เช่นกัน
      ตั้งแต่ Windows 10 เป็นต้นมาก็มี Universal C Runtime ด้วย
    • แนวทางนี้สามารถย้ายไปยังภาษาที่มี foreign function interface (FFI) ที่ดีได้ง่าย และนอกนั้นก็ไม่ต้องใช้อะไรอีก
      ไม่ต้องใช้ resource compiler และไม่ต้องใช้ linker เพื่อสร้าง resource DLL
      ไฟล์ resource กับรูปแบบไบนารีของมันไม่ใช่ API ที่ดี
      ถ้ามีการเรียก CreateWindow ในภาษาระดับสูงพอสมควร ก็น่าจะใช้เมตาโปรแกรมมิงสร้าง DSL คล้าย resource ที่กลมกลืนกับภาษาได้ดี

  • เมื่อก่อนเคยทำของคล้าย ๆ กันบน Linux ด้วยแอสเซมบลีให้มีขนาด ต่ำกว่า 2KiB: https://gaultier.github.io/blog/x11_x64.html
    อย่างที่คนอื่นพูดกัน ถ้าทำด้วย C ล้วนและใช้ dynamic linking อย่างน้อยบน Linux ก็ทำให้ต่ำกว่า 20KiB ได้ง่าย Windows มีสิ่งที่รวมมากับระบบปฏิบัติการเป็นพื้นฐานมากกว่ามาก อาจจะยิ่งง่ายกว่า
    ไม่ว่าอย่างไร ก็ขอเอาใจช่วยความพยายามนี้ ลองใช้ตัวเลือกการลิงก์ที่ผมเขียนไว้ท้ายบทความของผม น่าจะช่วยลดขนาดได้

    • โปรแกรม TODO แบบ TUI ที่ใช้ ncurses ซึ่งขยายเพิ่มขึ้นมาหน่อยมีขนาด 15K เป็น Linux และไม่ใช่ static linking
      ยังไม่ได้ลอง build ncurses ด้วย musl

  • พอเห็นว่า “รูปลักษณ์และความรู้สึกแบบ Windows เนทีฟ” ก่อนรันจริงก็เลยคาดหวังว่าใน list view จะมี context menu และเมื่อดับเบิลคลิกฟิลด์บางช่อง จะมีเมนูดรอปดาวน์หรือกล่องข้อความแบบใกล้เคียง inline โผล่ขึ้นมา
    ตอนนี้ไม่รู้แล้วว่าเป็นเพราะคนไม่รู้วิธีออกแบบโปรแกรมให้เข้ากับ Win32 UI/UX หรือเป็นเพราะผมแก่เกินไป

  • พูดว่า “ไม่มีเฟรมเวิร์ก” แต่พอใช้ DPI scaling แล้วฟอนต์เบลอ, ไม่มี การรองรับ Tab, ในช่องข้อความกด Ctrl-A เพื่อเลือกทั้งหมดก็ไม่ได้, ฟีเจอร์หลายอย่างที่แม้แต่เฟรมเวิร์กยุคก่อนสมัยใหม่ยังมีให้ก็ขาดไป และยังมีข้อผิดพลาดตอนเพิ่มแถวด้วย
    ไม่รู้ว่า “สมัยใหม่” หมายถึงอะไรกันแน่

    • ตัวอย่างการตั้งค่า DPI awareness อยู่ที่นี่: https://github.com/Dwedit/GameStretcher/blob/master/Stretche...
      โค้ดนี้จะตรวจสอบแบบไดนามิกว่าใน user32:SetProcessDpiAwarenessContext, shcore:SetProcessDpiAwareness, user32:SetProcessDPIAware อันไหนใช้งานได้ แล้วเรียกใช้อันนั้น
      ถ้าเวอร์ชัน Windows เก่ามากจนไม่มีอันไหนถูก implement เลย (ก่อน Windows XP) ก็จะไม่เรียกอะไร
    • ดูเหมือนว่า “สมัยใหม่” จะหมายถึงใหญ่กว่าที่จำเป็นมาก แต่ฟีเจอร์ขาดไปเยอะ
      ฟีเจอร์ส่วนใหญ่ที่บอกว่าขาด โดยเฉพาะการย้ายโฟกัสด้วย Tab ระหว่างคอนโทรล เพิ่มได้ง่ายมาก

  • โปรแกรมเมอร์ 6502 ในตัวผมกำลังตายอยู่ข้างในเมื่อเห็นว่า 278KB เดี๋ยวนี้ถือว่าเบาแล้ว

    • ผมพยายาม reproduce ไบนารีนี้เพื่อดูว่า 278KB ถูกใช้ไปกับอะไร
      อุปสรรคแรกที่เจอคือถ้า git ตั้งค่า core.autocrlf=false ไฟล์ build.bat จะไม่ทำงาน พอเปลี่ยนเป็น core.autocrlf=true แล้ว clone ใหม่ก็ build ได้
      toolchain ที่ใช้คือ x86_64-15.1.0-release-win32-seh-msvcrt-rt_v12-rev0.7z จาก https://github.com/niXman/mingw-builds-binaries/releases/tag...
      กรณีนี้ได้ไฟล์ .exe ขนาด 102KB ซึ่งดีกว่าตั้งแต่เริ่มเมื่อเทียบกับ 278KB ที่อ้างไว้ ผู้เขียนอาจใช้ toolchain หรือการตั้งค่าอื่นก็ได้ เลยอยากให้มีขั้นตอน reproduce ที่แน่ชัด
      ถ้าส่งสวิตช์บางตัวให้ GCC ก็ลดได้อีก
      gcc -Os => 100KB
      gcc -Oz => 99KB
      gcc -flto => 101KB
      gcc -s => 51KB
      gcc -s -Oz -flto => 47KB
      ถ้าสนใจแค่ขนาด .exe เล็ก ๆ ก็ยังมีพื้นที่ให้ปรับปรุงอีกมาก
    • ส่วนใหญ่เป็นเพราะ แพลตฟอร์มและฟอร์แมตไฟล์ executable
      ถ้าไม่มีข้อมูล stack trace, โครงสร้างพื้นฐานของ dynamic linking, ตาราง exception handling อะไรพวกนี้ ก็น่าจะเบากว่านี้มาก ตาราง exception handling จำเป็นแม้ใน C เพราะ exception อาจวิ่งผ่านฟังก์ชัน C ได้
    • อาจลองยื่นคำร้องให้การแข่งขัน demoscene เปิดหมวด แอป TODO 64KB ก็ได้
    • พูดตรง ๆ แปลกใจที่มันใหญ่ขนาดนั้น คิดว่าจะเล็กกว่านี้ หรือครึ่งหนึ่งคงเป็นไอคอนของแอป
      จำได้ว่าเมื่อก่อนเคยเขียนอะไรแบบนี้แล้วมันเล็กกว่านี้ เป็นเพราะ MinGW หรือเปล่า?
    • อยู่ ๆ ก็นึกถึงยุคที่การเขียนโปรแกรม Win32 ด้วย assembly กลายเป็นเรื่องค่อนข้างฮิป
      น่าจะเป็นปฏิกิริยาต่อกระแสขนาดดาวน์โหลดของ shareware ที่ใหญ่ขึ้น เป็นยุคมืดของ MFC
      ผมจำมันได้ว่าเป็นเสียงเฮครั้งสุดท้ายของ assembly ที่ไม่ใช่ retrocomputing ควบคู่กับการเขียนโปรแกรม Palm Pilot 68k ยุคแรก ๆ

  • เพื่อน ๆ ก็แค่ลองทำดูและทำแอปนี้ขึ้นมาเล่น ๆ ความเห็นทั้งหลายก็ถูกแล้ว ของแบบนี้น่าจะทำด้วย C++ หรือภาษาอื่นได้สมเหตุสมผลกว่า

    • ตอนที่ผมทำโปรแกรม Windows ครั้งแรกเมื่อประมาณ 30 ปีก่อน ผมก็เรียนมาแบบนี้เป๊ะ ๆ เพียงแต่น่าจะใช้คอมไพเลอร์ C++
      ไม่แน่ใจว่าทำไม แต่เหมือนเอกสาร Windows API จะแนะนำให้เขียนโค้ดสไตล์ C ด้วยคอมไพเลอร์ C++ ดูเหมือน Microsoft มองว่า C++ เป็น superset ที่ปรับปรุงจาก C และเห็นว่าควรใช้แม้กับโค้ดสไตล์ C
    • ไม่ได้ล้อเล่นนะ ผมอยากใช้แอปนี้มากกว่าแอป TODO พื้นฐานของ Windows 11
    • นี่แหละคือวิธีที่ควรเป็น
      ถ้าจะใช้ Win32 API ภาษาอื่นก็ไม่ได้เปลี่ยนอะไรโดยพื้นฐาน แถมอาจทำให้งงกว่าเดิมด้วย
      คนมักติดกรอบคิดแบบ C++ และสำหรับคนที่ไม่คุ้นกับ Win32 API มันคงทำให้ภาพรวมกลายเป็นก้อนที่สับสนยิ่งขึ้น
      เป็นความพยายามที่น่ารักมาก และไม่ว่าคนอื่นจะคิดอย่างไร ความคุ้นเคยกับ Win32 API ก็เป็นทักษะพื้นฐานที่ใช้ได้ดี
    • https://github.com/Efeckc17/YoutubeGO อ้างอิง ผมจะดีใจมากถ้าช่วยรีวิวหรือดูแอปพลิเคชันนี้ด้วย
    • โปรเจกต์ native UI ที่สะอาดตา แบบนี้แหละที่เป็นแรงบันดาลใจให้ผมเรียนเขียนโปรแกรม เจ๋งดี

  • เห็นหลายคนที่ทำซอฟต์แวร์หรือเว็บไซต์ซึ่งโหลด JS หรือ C# หลาย MB เพื่อจะส่ง telemetry 278KB ทุกครั้งที่ผู้ใช้ขยับเมาส์ มาประชดประชันกันอยู่แถวนี้

    • แอปคล้าย ๆ กันที่ทำด้วย C# + WinForms มีขนาดบนดิสก์ต่ำกว่า 10KB และใช้ RAM 6MB
      แอปนี้ใช้ RAM 1.5MB และทั้งคู่เปิดขึ้นมาทันที

  • เวลาพัฒนาแอป Windows การที่ ทำทุกอย่างด้วย C ได้ ทำให้รู้สึกดีเสมอ
    วิธีสร้างขึ้นมาจากองค์ประกอบพื้นฐานระดับต่ำสุดมันให้ความรู้สึกเป็นธรรมชาติ
    ในทางกลับกัน บน macOS ทุกอย่างเป็นออบเจกต์ Objective-C ดังนั้นแม้จะเขียนแอปด้วย C ล้วนได้ แต่ก็เหมือนลงไปต่ำกว่าชั้น abstraction ที่ Apple ตั้งใจไว้หนึ่งระดับ ทำให้เยิ่นเย้อขึ้นแทบจะ 1000 เท่า ถ้าจะทำอะไรสักอย่าง แทบจะต้องเชิดลำดับชั้นคลาสของ Objective-C เหมือนหุ่นเชิด ซึ่งรู้สึกไม่สบายใจเอามากๆ
    ไม่เข้าใจว่าทำไมถึงเอา API แบบคลาสของ Objective-C ไปวางซ้อนบน API เชิงกระบวนการพื้นฐานแบบ Win32 อีกทีไม่ได้ ในทางเทคนิค Win32 ก็ “อิงคลาส” อยู่เหมือนกัน แต่เป็นแบบขั้นต่ำ
    เลยยังไม่ค่อยรู้สึกอยากพอร์ตโค้ด C ของผมไป macOS ในเร็วๆ นี้

    • ที่น่าสนใจคือ Windows มี API/ABI เชิงวัตถุ ของตัวเองอย่าง COM และ WinRT ที่สร้างบน COM
      แต่คอมไพเลอร์ MIDL สำหรับอินเทอร์เฟซ COM จะสร้างเฮดเดอร์ที่ทำให้ใช้และ implement อินเทอร์เฟซใน C ได้: https://www.codeproject.com/KB/com/com_in_c1.aspx
      เท่าที่ผมรู้ ทุกวันนี้ยังใช้ได้กับ WinRT อยู่ด้วย เพียงแต่โครงสร้าง C และชื่อฟังก์ชันที่สร้างขึ้นมาต้องใส่ namespace เต็มๆ ทำให้หน้าตาน่าเกลียดมาก: https://stackoverflow.com/a/7437006/111335
    • มันเคยมี API เชิงกระบวนการอยู่ ชื่อว่า Carbon
      แทบจะเป็นตัวแทนแบบ drop-in ของ Macintosh Toolbox API ที่ user32.dll ลอกมาอย่างโจ่งแจ้ง
      แต่ถ้าไม่นับความรู้สึกอบอุ่นในฐานะโปรแกรมเมอร์แล้ว UI ต้องการแนวคิดเชิงวัตถุจริงๆ ทรีของออบเจกต์ต่างชนิดที่แชร์พฤติกรรมร่วมกันบางส่วน อธิบายโค้ด UI ได้แทบจะ 99% อยู่แล้ว
      Toolbox กับ Carbon ขาดความเป็นเชิงวัตถุแบบนั้น เลยฝืนอยู่พอสมควร ความคิดสร้างสรรค์อย่างหนึ่งที่ Windows เพิ่มเข้ามาจริงๆ ก็คือ window class
      ส่วนตัวแล้ว ความรู้สึกแปลกๆ เวลาจัดการคลาส Objective-C โดยตรงจาก C นั้น ผมรู้สึกแบบเดียวกันทุกครั้งที่ต้องกำหนด window class หรือ window procedure ในโค้ด user32.dll[0]
      เช่นเดียวกับที่ UI ต้องการเชิงวัตถุ เชิงวัตถุก็ต้องการฟีเจอร์ภาษาเฉพาะทาง ถึงจะสร้างได้แม้ไม่มี แต่ความใช้งานง่ายจะแย่ลง 2000 เท่า
      [0] หรืออะไรก็ตามที่เกี่ยวกับ GTK/GObject

  • ดูเหมือนกำลังลิงก์กับไลบรารีแบบสแตติกอยู่
    ควร ลิงก์กับ DLL ไม่ใช่ไลบรารีแบบสแตติก แบบนั้นขนาดแอปพลิเคชันจะลดลงมาก

    • ผมมองว่ากลับกันนะ
      ถ้ายังไงก็ต้องแจก DLL ไปพร้อมกับโปรแกรมอยู่แล้ว (เพราะไม่ใช่ส่วนหนึ่งของระบบปฏิบัติการ) ใน DLL ก็มีฟังก์ชันทั้งหมดอยู่ และ DLL แต่ละตัวอาจมี C runtime ของตัวเองด้วย
      ถ้าคอมไพล์ทุกอย่างแบบสแตติกเป็น EXE ไฟล์เดียว ก็มี C runtime แค่ชุดเดียว และตัดฟังก์ชันที่ไม่ได้ใช้ออกได้ง่าย
      DLL จะช่วยลดขนาดได้ก็ต่อเมื่อโค้ดนั้นถูกแชร์ระหว่างหลายโปรแกรมเท่านั้น
    • ไม่ใช่ การลิงก์กับ CRT เวอร์ชันสแตติกเป็นตัวเลือกที่ดี สามารถตัดโค้ดที่ไม่ใช้ออกได้
      ถ้าลิงก์แบบไดนามิกกับ MSVCRxx/VCRUNTIME ผู้ใช้ต้องดาวน์โหลด DLL ตัวนั้นเวอร์ชันที่ตรงเป๊ะจาก Microsoft
      ถ้าลิงก์แบบไดนามิกกับ MSVCRT ก็ไม่มีปัญหานั้น แต่ทำใน Visual Studio ได้ยากมาก
      กรณีที่ไม่ควรลิงก์ CRT แบบสแตติกจริงๆ น่าจะมีแค่เรื่องการปฏิบัติตาม LGPL ประมาณนั้น
 
roxie 2025-05-16

พี่ๆ ลมหายใจอุ่นๆ เหมือนส่งมาถึงตรงนี้เลย...