w64devkit năm qua có gì mới: Ký số bản phát hành, multilib và nhiều công cụ mới
Bộ công cụ phát triển C/C++ cho Windows w64devkit vừa trải qua một năm nhiều thay đổi: bản phát hành được ký số và bất biến, toolchain x64 chuyển sang multilib, bổ sung CMake, Ninja, Ccache, NSIS và nhiều tiện ích khác. Dự án cũng đang thử nghiệm runtime FatLTO với sự hỗ trợ của AI để sửa lỗi trình biên dịch.
w64devkit năm qua có gì mới: Ký số bản phát hành, multilib và nhiều công cụ mới
w64devkit — bộ công cụ phát triển C/C++ gọn nhẹ cho Windows — vừa có một năm đầy biến động với hàng loạt cải tiến quan trọng. Đáng chú ý nhất là việc toàn bộ bản phát hành giờ đây được ký số và khóa bất biến, toolchain x64 chuyển sang chế độ multilib, cùng sự xuất hiện của nhiều công cụ mới như CMake, Ninja, Ccache và NSIS.
Bảo mật bản phát hành được nâng lên tầm mới
Từ tháng 4, quá trình đóng gói bản phát hành của w64devkit đã được ký số. Hiện tại, mọi file EXE và DLL trong w64devkit đều được ký bằng khóa cá nhân của tác giả, giúp người dùng giảm đáng kể các vấn đề phiền toái với phần mềm bảo mật.
Điểm thú vị là khóa ký này đã xây dựng được uy tín tốt nhờ hàng nghìn chữ ký duy nhất được quan sát trên khoảng 100.000 máy chủ khác nhau — một "tác dụng phụ" dễ chịu từ việc đưa khoảng 300 file nhị phân vào mỗi bản phát hành.
Bản phát hành giờ đây được tự động hóa hoàn toàn qua GitHub Actions, chỉ kích hoạt khi tác giả đẩy thẻ phiên bản mới. Mọi bước trong quy trình đều minh bạch và bắt nguồn trực tiếp từ mã nguồn trong kho lưu trữ.
Đặc biệt, tác giả đã bật tính năng bất biến bản phát hành (release immutability): sau khi xuất bản, các sản phẩm phát hành bị khóa lại và không ai — kể cả chính tác giả — có thể sửa đổi. Điều này loại bỏ hoàn toàn nguy cơ ai đó âm thầm chèn mã độc vào các bản phát hành cũ.
Toolchain chuyển sang multilib
Phiên bản x64 của w64devkit giờ đây là một toolchain multilib, tức có thể biên dịch chương trình cho Windows 32-bit — giống như một phiên bản mở rộng của bản x86. Mục đích duy nhất của bản x86 hiện tại là để chạy w64devkit trên phần cứng hoặc hệ điều hành cũ hơn.
Để nhắm mục tiêu x86, bạn có thể truyền cờ -m32 khi biên dịch và liên kết, hoặc tốt hơn là dùng các công cụ có tiền tố kiến trúc i686-w64-mingw32:
$ x86_64-w64-mingw32-gcc -o hello64.exe hello.c
$ i686-w64-mingw32-gcc -o hello32.exe hello.c
Một thay đổi đáng chú ý khác: trước đây bạn cần đưa thư mục bin/ của w64devkit vào $PATH để GCC tìm được các công cụ khác. Giờ đây điều đó không còn cần thiết — bạn có thể gọi trực tiếp đường dẫn tới gcc.exe từ script mà không cần chỉnh sửa biến môi trường.
Xử lý giới hạn section của định dạng COFF
Định dạng đối tượng COFF tiêu chuẩn chỉ hỗ trợ tối đa 65.535 section. Con số này nghe có vẻ lớn, nhưng các chương trình C++ hiện đại — đặc biệt là bản debug sử dụng nhiều hàm lambda — có thể dễ dàng vượt qua giới hạn này.
Trước đây, tác giả từng phải vá Binutils để mặc định tạo ra định dạng bigobj, nhưng cách này lại gây xung đột với các trình liên kết đơn giản như Go toolchain (gc). Nhờ đóng góp của Peter0x44 — người đồng bảo trì dự án — Binutils giờ đây tự động nâng cấp lên bigobj khi cần thiết, giúp cgo hoạt động trở lại bình thường.
Ưu tiên tính năng hơn kích thước
Năm qua, dự án quyết định giảm bớt ưu tiên cho việc tối giản kích thước và sẵn sàng tăng dung lượng cài đặt để đổi lấy các tính năng xứng đáng. Cụ thể, cờ tối ưu hóa được chuyển từ -Os sang -O2 cho các runtime tĩnh và công cụ tính toán nặng. Kết quả là mọi thứ lớn hơn một chút nhưng nhanh hơn một chút.
Hàng loạt công cụ mới
Bộ công cụ năm nay chào đón nhiều thành viên mới:
- CMake, Ninja và trình gỡ lỗi CMake đồ họa — yêu cầu tối thiểu Windows 7. CMake được vá để mặc định dùng Ninja thay vì tìm kiếm Visual Studio.
- ccmake — giao diện TUI để xem và chỉnh sửa cấu hình CMake, do Peter0x44 đề xuất.
- Ccache — với các bản vá đặc biệt cải thiện hỗ trợ Windows, giúp tăng tốc quá trình build lại khi thường xuyên chuyển nhánh.
- widl và uuidgen — công cụ mã nguồn mở thay thế Microsoft MIDL, hỗ trợ lập trình COM.
- make2compdb — trích xuất file
compile_commands.jsontừ các bản build Make. - recycle — gửi file và thư mục vào thùng rác Windows, thường nhanh hơn
rm -rfvới thư mục lớn. - quilt — công cụ quản lý bản vá cổ điển, được viết lại hoàn toàn bằng C++ để hỗ trợ Windows.
- NSIS — công cụ tạo trình cài đặt, ở cấu hình multilib có thể tạo cả installer 32-bit lẫn 64-bit.
- Zstandard (zstd/unzstd) — định dạng nén hiện đại, được khuyến nghị dùng thay cho gzip.
Runtime: C11 threads và thay đổi trong C++
Một điểm độc đáo của w64devkit là C11 threads giờ đây là một phần của runtime Mingw-w64 — một triển khai mới, độc lập với winpthreads, nhỏ gọn hơn và không cần cờ biên dịch hay liên kết đặc biệt.
Tuy nhiên, triển khai này yêu cầu Windows 7 trở lên vì được xây dựng trên SRW locks. Tác giả cũng thẳng thắn nhận xét rằng C11 threads có đặc tả kém và thiết kế tồi, dẫn chứng là sự tồn tại của recursive locks — một tính năng lẽ ra không nên có trong tiêu chuẩn.
Về phía C++, std::terminate giờ đây thực sự kết thúc chương trình (trap) thay vì gọi exit, cho phép dừng lại trong GDB để kiểm tra. Điều này cũng giúp giảm khoảng 100KB dung lượng chết khỏi hầu hết chương trình C++ nhờ loại bỏ việc in stack trace nửa vời.
Tương lai: FatLTO và sự trợ giúp của AI
Nhiều năm trước, tác giả đã vô hiệu hóa Link-Time Optimization (LTO) do các lỗi trong GCC và Binutils. Giờ đây, ông đang cân nhắc không chỉ bật lại LTO mà còn phân phối runtime "FatLTO" — nơi các file đối tượng runtime chứa cả mã native lẫn bytecode LTO.
Nếu bạn không yêu cầu LTO, bạn nhận được mã native biên dịch sẵn như hiện nay. Nếu bật LTO, runtime về cơ bản được xây dựng lại tại thời điểm liên kết, cho phép kiểm soát hoàn toàn — thậm chí có thể ép về -Os hoặc -Oz nếu muốn.
Điều thú vị là tác giả cho biết việc sửa lỗi LTO giờ đây rất dễ dàng nhờ AI:
"Gắn một AI tiên tiến vào một harness lập trình tốt, chỉ cho nó thấy cái gì hỏng, đưa cho nó toàn bộ mã nguồn, và khoảng 15 phút sau tôi đã có một bản vá. Chúng ta đang sống trong một thế giới khoa học viễn tưởng."
Mặc dù các bản vá này bị GCC từ chối thẳng thừng ở thượng nguồn, điều đó đồng nghĩa w64devkit sẽ có lợi thế độc nhất trong lĩnh vực này.
Vẫn giữ hỗ trợ Windows XP
Bất chấp các tính năng mới yêu cầu Windows 7, tác giả vẫn cam kết duy trì Windows XP làm nền tảng tối thiểu cho bản phát hành x86. Ông vẫn giữ một chiếc laptop XP cũ để kiểm thử và sử dụng w64devkit — bạn chỉ cần chấp nhận một số công cụ cũ hơn, nhưng đó vốn là điều bạn đã làm từ trước.
Đối với lập trình viên Việt Nam làm việc với C/C++ trên Windows — đặc biệt trong các dự án nhúng, game hoặc ứng dụng desktop — w64devkit là một lựa chọn đáng cân nhắc nhờ tính gọn nhẹ, không cần cài đặt phức tạp và giờ đây có thêm bảo mật bản phát hành cùng hệ sinh thái công cụ ngày càng phong phú.
Bài viết liên quan

Công nghệ
Mô hình AI hàng đầu giỏi Vật lý đến đâu? Nghiên cứu mới chỉ ra các bài kiểm tra hiện hành đang đánh giá sai
16 tháng 9, 2026

Công nghệ
Nộp đơn xin việc lẽ ra nên khó hơn. Thật đấy
25 tháng 8, 2026

Công nghệ
DAPO: Hệ thống học tăng cường mã nguồn mở của ByteDance Seed và Tsinghua AIR đạt đỉnh cao mới trên AIME 2024
20 tháng 9, 2026