7 คะแนน โดย GN⁺ 2025-06-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระบบปฏิบัติการสไตล์ DOS แบบ 64 บิต ที่พัฒนาด้วย Rust โดยมีการใช้ x86 แอสเซมบลีบางส่วนสำหรับการโหลดเคอร์เนล
  • รองรับโหมดข้อความ VGA (80x25), ระบบไฟล์ FAT12 และสแตกเครือข่าย IPv4 ผ่าน SLIP (ICMP/UDP/TCP/HTTP)
  • รันและพัฒนาบนเครื่องเสมือนที่ใช้ QEMU และรองรับฟลอปปีดิสก์จริงบางส่วน
  • มี โปรแกรมแก้ไขข้อความแบบเรียบง่าย, การเติมชื่อไฟล์/ไดเรกทอรีอัตโนมัติด้วย TAB, เกม Snake และยูทิลิตีพื้นฐานอื่น ๆ มาให้

สถาปัตยกรรมและบูตโหลดเดอร์

  • CPU เป้าหมายคือ x86_64 และมีแผนจะรองรับสถาปัตยกรรม ARM (aarch) ในอนาคต
  • เวอร์ชันแรกใช้ บูตโหลดเดอร์ที่เขียนขึ้นเอง เพื่อโหลดเคอร์เนลขึ้นหน่วยความจำและเริ่มทำงาน
  • ในเคอร์เนลแบบ 64 บิต ใช้ GRUB2 บูตโหลดเดอร์ เพื่อจัดการการเข้า Long Mode และการสลับไปยัง Protected Mode
  • stage2 บูตโหลดเดอร์ ทำหน้าที่ตั้งค่า GDT, IDT, เพจจิง และจัดสรรตัวชี้ Multiboot2 เป็นต้น
  • เคอร์เนลประกอบด้วย ตัวประมวลผลคำสั่งเชลล์และคอมโพเนนต์แบบกำหนดเองหลากหลายส่วน

การจำลองและอิมเมจบน QEMU

  • พัฒนาและทดสอบในสภาพแวดล้อมเครื่องเสมือนผ่าน QEMU
  • การสร้างอิมเมจ ISO: ใช้ grub2-mkrescue และ xorriso
  • รองรับ การสร้างและเมานต์อิมเมจฟลอปปี FAT12 และสามารถใช้งานกับอุปกรณ์จริงหรือผ่านแฟลก QEMU (-fda fat.img) ได้

ขั้นตอนการเริ่มต้นระบบ

  • เมื่อเข้าเคอร์เนล จะตรวจสอบ Long Mode, แท็ก Multiboot2, ระบบไฟล์ FAT12 และสถานะ VGA
  • หลังแสดงโลโก้ ASCII art แล้ว จะ ส่งการควบคุมต่อไปยังลูปของเชลล์

ระบบไฟล์

  • รองรับ ระบบไฟล์ FAT12: อ่าน/เขียน/ค้นหา/ลบไฟล์ รวมถึงสร้าง/ลบไดเรกทอรี
  • รองรับการสร้างและเขียนทับไฟล์ข้อความ รวมถึงไดเรกทอรีย่อย
  • มีความสามารถตรวจสอบความสอดคล้องของระบบไฟล์ด้วย เครื่องมือ fsck
  • มีแผนจะรองรับ FAT32 ในอนาคต

สแตกเครือข่าย

  • รับส่งแพ็กเก็ต IPv4 บนพื้นฐาน โปรโตคอล SLIP
  • รองรับการจัดการ Ethernet frame (ยังทดสอบไม่สมบูรณ์)
  • รองรับ ICMP Echo (Request/Reply), UDP, TCP (state machine ของ SYN/SYNACK) เป็นต้น
  • มี HTTP เซิร์ฟเวอร์ แบบง่ายสำหรับให้บริการหน้า HTML แบบคงที่

เกม Snake

  • มี เกม Snake ในตัว และมีแผนทำเวอร์ชัน เล่นหลายคน (P2P TCP) ในอนาคต
  • ข้อมูลเกม (เลเวล, คะแนน) สามารถบันทึกและโหลดผ่านไฟล์ข้อความได้
  • ออกจากเกมด้วย ESC และบันทึก High Score ตามคะแนน

คุณค่าและจุดเด่นในการนำไปใช้ของโปรเจกต์

  • เป็นตัวอย่างของ ระบบปฏิบัติการที่เขียนด้วย Rust ทำให้เห็นประโยชน์ด้านความปลอดภัยและประสิทธิภาพการพัฒนาของซอฟต์แวร์ระดับล่างได้ชัดเจน
  • ด้วยการทดสอบ SLIP/ICMP, การแจกจ่ายที่สะดวก และการรองรับอุปกรณ์จริง จึงเหมาะกับการทดลอง OS และการเรียนรู้การทำอิมพลีเมนต์แบบคัสตอม
  • เปิดโอกาสให้สัมผัสโครงสร้างระบบสไตล์ DOS ที่ผสาน Rust และ x86 แอสเซมบลีได้โดยตรง

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

 
GN⁺ 2025-06-24
ความเห็นจาก Hacker News
  • ใช้ภาษาที่รับประกันความปลอดภัยของหน่วยความจำ, ทำงานบน x86_64 และมีแผนรองรับ Arm, มีสแตกเครือข่ายของตัวเอง, บูตได้จาก CD และ multiboot, โปรเจกต์งานอดิเรกของฉันมอบประสบการณ์ที่เหนือกว่า DOS
    • ถ้าจะมาแข่งกับ DOS ก็ต้องรองรับการรัน Doom และ BASIC ด้วย เพราะนี่แทบจะเป็นเส้นฐานอย่างเป็นทางการของความเป็นสไตล์ DOS
    • เป็นการผสม Rust กับ x86 assembly เลยทำให้นึกว่า ถ้าจะมุ่งเรื่อง memory safety จริง ๆ มันมีคุณค่าเชิงปฏิบัติมากแค่ไหน, ทุกวันนี้ Rust ให้ความรู้สึกเหมือนถูกทำการตลาดเกินจริงแบบที่ 3D printing เคยเป็น, ระหว่างทางสู่การใช้งานแพร่หลายประโยชน์ที่จับต้องได้อาจมีจำกัด, และแม้โปรเจกต์แบบนี้จะดีถ้าเข้ากันได้กับซอฟต์แวร์เก่า แต่ถ้าไม่ก็ยังดูใกล้เคียงโปรเจกต์เพื่อการเรียนรู้หรือสำหรับสายฮอบบี้มากกว่า, รู้สึกว่ายังอีกไกลกว่าจะถึงระดับใช้งานจริง
  • ชอบมากที่ในสแตกเครือข่ายใช้ SLIP กับ slattach(1), ตอนที่เคยทำสแตก TCP/IP แบบง่าย ๆ เองก็เคยเชื่อม SLIP ผ่าน pty บน Linux เพื่อผูกกับเคอร์เนลเหมือนกัน, เมื่อก่อน macOS ก็เคยมี slattach(1) แต่ดูเหมือนตอนนี้ถูกถอดออกไปแล้ว, เลยสงสัยว่ามีใครเคยใช้ SLIP บน macOS เพื่อทำ networking API แบบข้ามแพลตฟอร์มหรือไม่, ทางเลือกอื่นคือบน Linux ใช้ tun/tap และบน macOS ใช้ utun, แต่ SLIP นั้นง่ายกว่ามาก
  • สงสัยว่าทำไมถึงเลือก x86, เพราะมีทรัพยากรให้เยอะหรือเปล่า, เพราะรูปแบบคำสั่งที่มีเอกลักษณ์, เพราะความซับซ้อนของลำดับการบูต, หรือเป็นกลยุทธ์ที่จะตามรอย DOS ตรง ๆ, เห็นบอกว่าจะรองรับสถาปัตยกรรม ARM เร็ว ๆ นี้ด้วย ทั้งที่ DOS เองก็ผูกกับฮาร์ดแวร์และซอฟต์แวร์อย่างแน่นแฟ้น เลยอยากรู้ว่าจะรองรับหลายสถาปัตยกรรมในลักษณะไหน
    • ยังไม่ได้ดูโปรเจกต์นี้โดยตรง แต่เดาว่าแพลตฟอร์ม x86 ในเชิงประวัติศาสตร์มีอินเทอร์เฟซในตัวหลากหลายมากเพราะความเข้ากันได้ย้อนหลัง จึงทำให้สร้าง “OS แบบ DOS” ที่บางและเรียบง่ายได้ง่ายมาก, ไม่ต้องมีการ parse device tree, ตั้งค่า MMU, หรือจัดการบัสซับซ้อนอย่าง PCI(e) ก็เริ่มต้นแบบง่าย ๆ ได้, ส่วน ARM นั้นแค่ bootstrap ก็ยากแล้ว ถ้าจะรักษาความเรียบง่ายก็ต้องยอมรับข้อจำกัดมากขึ้น, สิ่งที่ทำได้โดยไม่มี MMU ก็มีจำกัด และไม่มี BIOS interface ด้วย เลยทำอะไรตรงไปตรงมาแบบอ่านเซกเตอร์หรือรอคีย์อินพุตเหมือนบน x86 ได้ยาก
    • เหตุผลที่เลือก x86 ก็เพราะระบบนี้สืบทอดมาจากเวอร์ชันแรกที่สร้างบน Turbo C โดยอาศัย BIOS interrupt และ inline assembly, ไม่ได้ตั้งใจจะลอก MS-DOS อย่างเดียว แต่ได้รับแรงบันดาลใจจากมันมาก, การรองรับหลายสถาปัตยกรรมก็ดูมีความเป็นไปได้เพราะ Rust compiler มีความสามารถในการระบุ target architecture, แค่กำหนด target ก่อน build ก็สะท้อนเข้าไปในกระบวนการ build ได้ทันที
  • รู้สึกว่าในยุค UEFI ปัจจุบันและโลกที่ไม่มีเชลล์แบบเดิม โซลูชันแนว DOS 64 บิตแบบ FLOSS อย่างนี้น่าจะดีกว่า, น่าจะเหมาะมากสำหรับ boot manager แนว retro หรือเครื่องมือวินิจฉัยระบบ, สงสัยว่าจะรันจาก EFI system partition ได้ไหม, เห็นว่ารองรับ fat12 แต่ไม่แน่ใจว่า gpt เป็นอย่างไร, แล้วการแสดงผลเป็นแบบควบคุมฮาร์ดแวร์วิดีโอโดยตรงหรือเป็นเอาต์พุตลักษณะเทอร์มินัล
    • ตอนนี้ยังไม่ได้ทดสอบการบูตจาก EFI system partition, ตอนนี้รองรับอย่างเป็นทางการแค่ระบบไฟล์ FAT12 (แม้จะมีฟีเจอร์ memory disk แต่ตอนนี้ยังไม่ทำงาน), ตอนนี้ยังไม่รองรับ gpt, และกำลังพิจารณาให้ FAT32 เป็นลำดับความสำคัญก่อน (เพราะแฟลชดิสก์ทั่วไปมักใช้ FAT32), สำหรับคำถามสุดท้าย OS เขียนลง VGA memory buffer โดยตรง และ GRUB จัดเตรียมความละเอียด 80x25 มาให้
  • คิดว่าโปรเจกต์นี้เจ๋งดี, เสียดายที่พลาดประโยคอมตะ “มันก็แค่งานอดิเรก คงไม่ใหญ่และเป็นมืออาชีพแบบ Linux หรอก”
  • สงสัยว่ามีแผนรองรับเครื่องหมายกำกับการออกเสียงในภาษาเช็กหรือไม่
    • เวอร์ชันนี้มีแผนรองรับแค่อังกฤษ, ส่วนเวอร์ชันแรกเดิมทีทำเป็นภาษาเช็ก
  • สงสัยว่าใช้ไดรเวอร์ VGA ที่เขียนใหม่ทั้งหมดด้วย Rust หรือไม่
  • ถามว่าแม้จะเป็นสไตล์ DOS แต่จริง ๆ แล้วไม่ได้เข้ากันได้กับ DOS ใช่ไหม
    • เป็นการวิเคราะห์ที่ถูกต้อง, เวอร์ชันแรกเป็น 16 บิตและออกแบบให้แทบเข้ากันได้กับ MS-DOS, และถ้าจัดการได้แค่ disk I/O แบบง่าย ๆ ก็น่าจะนับรวมอยู่ในกลุ่มระบบ DOS ได้ในความหมายกว้าง ๆ
    • กล่าวคือหมายถึงระดับที่เข้ากันได้กับ MS-DOS, รองรับการรัน Alley Cat หรือ Dune 2 และ Doom
  • มีความเห็นว่าควรมี event queue เพื่อรองรับ async runtime
    • อยากฟังความเห็นว่าถ้าจะทำ event loop ที่สมบูรณ์จะเป็นอย่างไร
  • คำถามขำ ๆ ว่ารัน Crysis ได้ไหม