Hệ thống con Windows 9x dành cho Linux

 (social.hails.org)
12 điểm bởi GN⁺ 2026-04-23 | 2 bình luận | Chia sẻ qua WhatsApp
  • Một dự án thử nghiệm cho phép chạy nhân Linux mới nhất (6.19) theo kiểu hợp tác bên trong nhân Windows 9x, giúp tận dụng đồng thời toàn bộ tính năng của cả hai hệ điều hành
  • Khác với WSL, dự án không dùng ảo hóa phần cứng nên có thể chạy cả trên 486
  • Có thể sử dụng các tính năng OS hiện đại như phân trang, bảo vệ bộ nhớ, lập lịch ưu tiên ngắt trong môi trường Windows 9x, đồng thời hỗ trợ chạy ứng dụng song song mà không cần khởi động lại
  • Gồm ba thành phần: nhân Linux đã vá, driver VxD và ứng dụng khách wsl.com, với User-Mode Linux được chỉnh sửa để gọi API nhân Win9x
  • Các system call được điều phối qua trình xử lý lỗi bảo vệ chung (GPF) thay vì int 0x80, do giới hạn bảng mô tả ngắt ngắn của Win9x
  • "Tự hào được viết mà không dùng AI (Proudly written without AI)", giấy phép GPL-3

WSL9x - codeberg.org/hails/wsl9x

Tổng quan

  • WSL9x là hệ thống con Linux cho Windows 9x chạy nhân Linux mới nhất (tại thời điểm viết là 6.19) theo kiểu hợp tác bên trong nhân Windows 9x
  • Có thể tận dụng đồng thời toàn bộ tính năng của cả hai hệ điều hành như phân trang, bảo vệ bộ nhớ, lập lịch ưu tiên ngắt
  • Có thể chạy ứng dụng của cả hai OS song song mà không cần khởi động lại
  • Được viết thủ công, không dùng AI

Cấu trúc kỹ thuật

  • WSL9x gồm ba thành phần
    • Nhân Linux đã vá (win9x-um-6.19 branch)
    • Driver VxD
    • Chương trình khách wsl.com

Driver VxD

  • Phụ trách khởi tạo WSL9x, với điểm vào là vxd/wsl9x.asm
  • Thiết lập ánh xạ ban đầu cho mã nhân và tải vmlinux.elf từ đĩa thông qua ngắt DOS (vxd/loader.c, vxd/fs.asm)
  • Nhân được biên dịch với địa chỉ nền cố định 0xd0000000
  • Khởi tạo một luồng mới trong System VM và cấp phát stack 16 KiB để dùng cho việc vào Linux
  • Sau đó đi vào nhân, phân phối IRQ, quay lại user space và vào vòng lặp sự kiện xử lý trạng thái idle (vxd/entry.c)

Xử lý system call và page fault

  • Driver xử lý page fault và system call, là các sự kiện từ user space cần được điều phối tới nhân
  • System call được xử lý qua trình xử lý lỗi bảo vệ chung (GPF)
    • Win9x có bảng mô tả ngắt không đủ dài để cài một trình xử lý đúng nghĩa cho int 0x80, là ngắt system call Linux i386
    • Trình xử lý GPF kiểm tra lệnh gây lỗi, nếu là int 0x80 thì sẽ tăng con trỏ lệnh như thể ngắt đã thành công rồi điều phối sang system call Linux (vxd/fault.c)

Chỉnh sửa nhân Linux

  • Dựa trên User-mode Linux, nhưng được sửa để gọi API nhân Windows 9x thay vì POSIX API
  • Chạy ở ring 0 (supervisor/kernel mode) chứ không phải user mode (ring 3)
  • Phần lớn việc tích hợp với nhân Win9x, bao gồm chuyển ngữ cảnh, nằm ở phía nhân Linux
    • Vị trí mã chính: linux/arch/um/os-Win95
    • Điểm vào: _start trong main.c, các tệp chính gồm process.c, mmu.c

Ứng dụng khách wsl.com

  • Là chương trình DOS 16-bit được triển khai trong wsl/wsl.asm
  • Cho phép tận dụng dấu nhắc MS-DOS làm cửa sổ TTY mà không cần triển khai TTY riêng
  • Khi chạy, chương trình gọi WSL9x V86 API (vxd/v86_api.asm) để xin cấp một console chưa dùng và yêu cầu đầu ra của console đó được điều phối về cho nó
  • Sau đó đi vào vòng lặp sự kiện chờ IRQ và thử đọc bàn phím khi có ngắt xảy ra
  • Cũng đóng vai trò điểm đồng bộ hóa của driver console (vxd/console.c)
    • Khi đầu ra Linux sẵn sàng, nó lên lịch một sự kiện và thực thi int 0x29 trong ngữ cảnh MS-DOS VM để in ký tự ra cửa sổ DOS
    • Ngắt này cũng là nơi các driver ANSI cho DOS như NNANSI chặn đầu ra terminal để triển khai mã thoát ANSI

Yêu cầu build và chạy

  • Cần cross toolchain cho đích i386-linux-musl (khuyến nghị dùng musl-cross-make)
  • Cần Open Watcom v2 toolchain để build các thành phần Windows
  • Cần build nhân Linux đã vá từ branch win9x-um-6.19
  • Thiết lập đúng các biến môi trường WATCOM và LINUX (xem ví dụ trong .envrc.example)
  • Cần ảnh đĩa cứng hdd.base.img với Windows 9x đã được cài sẵn
  • Chạy make sẽ tạo hdd.img đã chuẩn bị sẵn WSL9x
  • Chạy wsl từ dấu nhắc MS-DOS để mở pty; nếu dùng màu ANSI thì nên nạp trước driver như nnansi.com

Giấy phép

  • GPL-3

Bài viết liên quan

2 bình luận

 
GN⁺ 2026-04-23
Ý kiến trên Hacker News
  • Trước WSL, những cách tiêu biểu để chạy các binary Linux chưa chỉnh sửa bên trong Windows là CoLinux và flinux
    http://www.colinux.org/
    https://github.com/wishstudio/flinux
    flinux trên thực tế khá gần với kiến trúc WSL1, còn CoLinux thì mang cảm giác giống WSL2 ở chỗ chở kernel Linux chạy bên cạnh
    Về mặt kỹ thuật, tôi thấy Cygwin mới là con đường chính thống hơn. Thay vì cố nhét đường ống Linux từ bên ngoài vào, nó tiếp cận theo hướng chạy các binary POSIX native trên Windows, và tôi cũng thích điểm chỉ cần liên kết DLL nhẹ nhàng, không động tới ring 0
    Dù vậy, hồi đó sự tiện lợi của các trình quản lý gói CLI còn thiếu, và khi thực sự làm việc trên Windows thì tôi đã dùng CoLinux khá nhiều
    • Tôi nhớ là Cygwin có từ rất lâu trước CoLinux. CoLinux là năm 2004, còn Cygwin được công bố từ năm 1995
      Vấn đề cốt lõi mà tôi nhớ là DLL hell. Ví dụ, nếu bản port OpenSSH cho Windows mang theo cygwin1.dll riêng của nó thì rất hay xảy ra xung đột phiên bản
      Dù vậy, vào thời RAM ít và swap rất nặng, việc có ít overhead vẫn là một lợi thế đáng kể
      Thời đó ứng dụng native mới là trung tâm chứ chưa phải Web 2.0 hay NodeJS, còn Java cũng không được đánh giá cao
      Cuối cùng thì đúng như mọi khi, nó giống một dòng chảy kiểu tiến hai bước rồi lùi một bước
    • Nói Cygwin là chính thống có thể đúng theo một số tiêu chí, nhưng với tôi thì đó là một cách tiếp cận khá kỳ quặc
      Trái với hàm ý rằng nó không chậm, trên thực tế nó vẫn chậm, tương thích kém hơn các cách khác, cần biên dịch lại, và trong phần lớn vòng đời của mình cũng không phải công cụ được yêu thích rộng rãi
      Bên trong cygwin1.dll có rất nhiều ảo thuật tương thích, và rốt cuộc vẫn là kéo đường ống Linux từ bên ngoài vào trong tiến trình. Nhất là khi nghĩ tới cách nó hiện thực fork() mà không có hỗ trợ từ hệ thống thì lại càng như vậy
      Cygwin hoàn toàn không chạy được trong vùng cô lập Windows AppContainer. MSYS2 đến giờ vẫn dùng nền tảng này, nên binary MSYS2 cũng không thể chạy trong AppContainer
      Vì vậy khi sandboxing Claude Code, tôi đã phải đi theo một con đường hoàn toàn khác. Claude Code muốn dùng Git for Windows, mà Git for Windows lại phân phối bash.exe v.v. được build bằng MSYS2
      Trong khi đó, các bản build Windows native thực sự không có những kiểu hack lạ mà cygwin1.dll yêu cầu, nên các bản build non-MSYS2 mà tôi tìm được đều chạy tốt trong AppContainer
    • Dạo này MSYS2 về bản chất vẫn phụ thuộc vào cygwin bên trong nhưng có cung cấp trình quản lý gói
      Có thể dùng pacman của Arch Linux, nên việc xử lý các binary POSIX native trên Windows đã trở nên khá thân thiện ngay cả khi không có Linux VM
    • Trong trải nghiệm phát triển thực tế, làm việc trên Cygwin thực sự rất đau khổ
      Nếu thư viện C mà bạn muốn dùng không có sẵn bản Cygwin được build trước, bạn phải tự chạy configure, make cho cả cây phụ thuộc
      Thêm nữa, theo trí nhớ của tôi thì cỡ hai phần ba trường hợp là phải tự sửa gì đó, vì POSIX không hoàn toàn khớp một cách hoàn hảo
    • Về cơ bản, Cygwin hiện thực POSIX API trên Win32 và trộn thêm một số lời gọi Nt để tăng tương thích
      Nhưng để đạt đúng ngữ nghĩa thì phải dùng đủ loại đường vòng và hack, ví dụ fork không phải copy-on-write
      Tôi đã dùng Cygwin từ khoảng năm 1999 đến 2022, cũng thử WSL2 một chút và bây giờ trên laptop tôi vẫn dùng nó
      Còn desktop thì từ năm ngoái tôi đã chuyển hẳn sang Linux
  • Tôi khá mừng vì nó giống như một phiên bản Windows trước NT của colinux
    Hồi còn dùng Windows thời XP, tôi từng chạy Colinux, và đó thực sự là một công cụ kỳ diệu
    Việc dựng stack LAMP ở phía Linux dễ hơn nhiều, và bạn có thể biên tập bằng editor Windows trong khi vẫn tạo được một môi trường phát triển cục bộ khá ổn
    Thậm chí còn có thể thử gắn X11 server cho Windows để dựng desktop Linux lên trên
    Cứ nhìn bản thân dần dần chồng thêm môi trường giống Unix lên trên Windows như vậy, cuối cùng tôi đã chuyển hẳn sang macOS
    Ngoài giá trị hack thuần túy, nếu nghĩ tới công dụng thực tế thì tôi cũng thấy có lẽ máy cấp 486 sẽ nhanh chóng chạm giới hạn bộ nhớ
    http://colinux.org/
    • Tôi cho rằng Colinux thực sự là một thành tựu kỹ thuật
      Chỉ là không nhiều người nhận ra điều đó mà thôi
  • Người làm ra thứ này gần như khiến tôi thấy họ là một phù thủy
    Trong mắt tôi đây gần như là công việc bất khả thi
    Nhưng tôi cũng tò mò không biết trong mắt những người hiểu cấu trúc hệ thống thì nó trông như thế nào
    Thế là tôi nhớ tới câu đùa về hai nhà toán học bảo rằng một định lý là chuyện tầm thường, rồi phải giải thích hai tiếng sau mới thực sự thừa nhận là nó tầm thường
    • Tôi cũng từng có lần ở năm nhất CS, trong giờ học lý thuyết tập hợp, đứng trước bảng chứng minh rồi gặp đoạn mãi không nhìn ra được nên cứ thế lướt qua bằng cách gọi nó là tầm thường
      Thế là giáo sư cũng bảo đúng rồi và chuyển luôn sang phần tiếp theo
    • Tôi thường là người hiểu được cấu trúc, nhưng cái này không khiến tôi thấy như phép màu
      Thứ làm tôi thực sự khâm phục là tác giả đã lần lượt mò ra cả một danh sách chi tiết dài như sách khải huyền cần có để biến nó thành hiện thực
    • Tôi hiểu vai trò cốt lõi của hệ điều hành hiện đại là cho nhiều chương trình chạy đồng thời mà không thể can thiệp lẫn nhau
      Vì thế mỗi chương trình chỉ có thể đọc một phần bộ nhớ của riêng nó, và CPU cũng chỉ được dùng trong một khoảng thời gian giới hạn trước khi nhường cho chương trình khác
      Windows bắt đầu dùng những cơ chế đó một cách nghiêm túc từ Windows NT, và XP cũng thuộc cùng dòng đó
      Trong khi đó, cho tới Windows 98 thì chương trình gần như có thể làm bất cứ điều gì, và các tính năng bảo vệ phần cứng kiểu đó hầu như bị bỏ không
      Windows thời ấy, theo cảm nhận của tôi, gần với một gói thư viện chức năng để dựng UI và giao tiếp với thiết bị ngoại vi hơn là một hệ điều hành đúng nghĩa
      CPU có phần cứng đặc biệt để giới hạn truy cập bộ nhớ và thời gian xử lý, nhưng Windows 9x đã không tận dụng đầy đủ
      Vì vậy mới xuất hiện khoảng trống để một hệ thống con Linux cho Windows 9x tự đóng vai hệ điều hành, lấy các cơ chế phần cứng đó và chạy một hệ điều hành hiện đại bên trong
    • Nhìn trang dự án thì tôi thấy phần giải thích khá tốt
      Theo tôi, phần khó nhất trong kiểu công việc này là lần ra API driver của Microsoft
      Tài liệu thời 9x vừa không đủ chi tiết vừa không dễ tiếp cận, và đến giờ đây vẫn không phải lĩnh vực dễ chịu gì
    • Kernel win9x vốn nổi tiếng là không làm quá nhiều việc
      Vì vậy có vẻ như lại có khá nhiều chỗ để cấy một phần chức năng mức thấp của Linux vào
  • Tôi vui vì những bài như thế này lại lên trang chủ cùng ngày
    Một bên là câu chuyện Show HN tăng gấp ba và đầy những ứng dụng mang cảm giác vibe coding na ná nhau, còn bên kia là có người đã đào sâu suốt 6 năm vào bên trong Win9x để chạy một kernel Linux hiện đại trong đó
    So với những luồng thảo luận đầy app làm ra bằng prompt 20 phút, kiểu bài đăng này thực sự khiến tôi thấy vui
    • Tôi thấy trong README của dự án có dòng Proudly written without AI
      Thấy những câu như vậy thật sự khá thích
    • Thậm chí tôi còn thấy có khả năng chính prompt cũng do AI tạo ra
      Bây giờ chuyện thường gặp là thay vì bảo create me an owl app thì người ta lại yêu cầu tạo một prompt tổng hợp để làm owl app, rồi dán nó vào một phiên AI khác
  • Cụm > Proudly written with zero AI trong README khiến tôi thấy hơi mơ hồ
    Vì thực ra có một sản phẩm tên là Zero AI, nên cũng có thể hiểu theo nghĩa đó
    • Có vẻ giờ nó đã được sửa rõ ràng hơn thành > Proudly written without AI
      Cách diễn đạt cũng rõ hơn nhiều, và bản thân dự án thật sự rất đáng kinh ngạc
    • Theo tôi ở đây khác biệt chữ hoa chữ thường là quan trọng
  • Để lại liên kết trực tiếp không qua mạng xã hội
    https://codeberg.org/hails/wsl9x
  • Tôi tò mò không biết có tài liệu hay nào giải thích tốt cấu trúc của Windows 3.x và 9x không
    Tôi có biết vài mảnh thông tin như chuyện có VM Monitor và loại hỗ trợ kiểu này tồn tại, nhưng phần giải thích chi tiết thì cảm giác bị rải rác khắp nơi
    Nhiều người tóm gọn Windows như chỉ chạy trên DOS, nhưng tôi thấy rõ ràng cách nói đó không chính xác
    Tất nhiên nó không phải máy ảo theo nghĩa ngày nay, nhưng bên trong có khá nhiều cấu trúc kỹ thuật thú vị, trong khi đa số tài liệu dường như chỉ chạm rất nông vào phần đó
    Tôi cũng tò mò dự án này giống BSD on Windows đến mức nào
    Và tôi cũng biết Architecture of Windows 9x, nhưng theo gu của tôi thì nó chưa đủ sâu
  • Nếu theo kiểu đặt tên của Microsoft thì thứ này đáng ra không phải Windows Subsystem for Linux mà phải là Linux Subsystem for Windows mới đúng chứ
    • Tôi không nghĩ nhất thiết là vậy
      Vì WSL nghĩa là Linux on Windows, nên cái này có lẽ được đọc là W9xSL theo nghĩa Linux trên Windows 9x
    • Tôi cũng từ lâu đã thấy cái tên này không trực quan
    • Tôi cũng đồng ý
      Giờ thì tôi chưa thể nêu bằng chứng ngay, nhưng tôi nhớ từng đọc đâu đó rằng chuyện này có liên quan tới vấn đề thương hiệu
      Đại ý là họ vốn muốn gọi là Linux Subsystem for Windows, nhưng phía Linux foundation không cho phép một dự án không được ủy quyền dùng tên bắt đầu bằng Linux
  • Tôi đoán chuyện này chắc dễ hơn so với https://github.com/haileys/doslinux
    • Dù vậy tôi vẫn muốn nói là để đi được tới bước tiếp theo đó cũng đã mất 6 năm
  • Tôi hiểu rằng kernel NT từ NT 3.1 qua 2000, XP rồi sau này tới cả WSL trên Windows 10/11 đều có một phần huyết thống nối tiếp, và ngay từ năm 1993 nó đã được thiết kế với hệ thống con POSIX trong đầu
    Triết lý cốt lõi là có nhiều personality khác nhau, rồi dịch các system call của từng môi trường sang lời gọi kernel NT
    Vì vậy WSL1 năm 2016, về cơ bản, chỉ là trò ảo thuật đó được triển khai lại cho Linux
    Ngược lại, Windows 9x thuộc họ DOS, nên để chạy Linux trong đó hẳn phải cần kiểu hack bẩn hơn nhiều và khác biệt ở mức căn bản
    Có lẽ đó cũng là lý do ngày xưa chẳng ai làm
    Vì vậy, chỉ riêng việc nó thực sự chạy được cũng đã cho thấy kiến trúc NT đi trước thời đại tới mức nào
    Nếu nghĩ tới ứng dụng thực tế thì tôi liên tưởng tới các môi trường bị trói vào Windows 98 như phần mềm y tế hay công nghiệp cũ
    Tuy vậy, nếu vào năm 2026 mà bạn đang cầm một con 486 trên tay, thì rất có thể chạy Linux native sẽ hữu ích hơn nhiều so với việc nhét Linux vào trong một nhánh DOS 30 năm tuổi
 
plumpmath 2026-04-24

Ha, coLinux haha -_- cái tên thật đáng mừng. Haha. Nhưng giờ dù có WSL mình cũng không dùng, còn kiểu win95+linux này thì lại thấy cuốn đấy.