Windows 11 ยังรันไบนารีที่คอมไพล์เมื่อ 30 ปีก่อนได้

 (twitter.com/mikko)
1 คะแนน โดย GN⁺ 2023-08-20 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Windows 11 รุ่นล่าสุดสามารถรันไบนารีที่คอมไพล์เมื่อวันที่ 18 สิงหาคม 1993 ได้ ซึ่งตอกย้ำความโดดเด่นของความเข้ากันได้ย้อนหลังระยะยาวของ Microsoft
  • โปรแกรมดังกล่าวเป็นไบนารีที่สร้างขึ้นเมื่อ 30 ปีก่อน ณ เวลาที่มีการเผยแพร่ และแสดงให้เห็นว่าซอฟต์แวร์ Windows รุ่นเก่ายังสามารถทำงานได้ในสภาพแวดล้อมสมัยใหม่
  • ประเด็นสำคัญของกรณีนี้อยู่ที่ ความเข้ากันได้ย้อนหลัง ที่ทำให้ระบบปฏิบัติการเวอร์ชันใหม่ยังยอมรับไฟล์รันได้จากอดีตโดยตรง
  • จากข้อมูลที่เปิดเผย ยังไม่สามารถยืนยันได้ว่าจำเป็นต้องมีการแปลง คอมไพล์ใหม่ หรือตั้งค่าเพิ่มเติมหรือไม่
  • ความสามารถในการรันไบนารีเก่าเป็นสัญญาณด้านเสถียรภาพที่สำคัญสำหรับทั้งองค์กรและผู้ใช้ทั่วไปเมื่อต้องจัดการซอฟต์แวร์ที่เก็บรักษาระยะยาว

กรณีตัวอย่างการรันไบนารีอายุ 30 ปีบน Windows 11

  • Windows 11 สามารถรันไบนารีที่คอมไพล์เมื่อวันที่ 18 สิงหาคม 1993 ได้
  • กรณีนี้ถูกแชร์พร้อมกับการประเมินว่า ความเข้ากันได้ย้อนหลัง ของ Microsoft แข็งแกร่งอย่างมาก
  • ข้อมูลที่ยืนยันได้จำกัดอยู่ที่การรันได้จริงและวันที่คอมไพล์
    • ไม่มีการระบุชื่อไบนารี ภาษาในการพัฒนา วิธีการรัน หรือว่าต้องมีการตั้งค่าเพิ่มเติมหรือไม่

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

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

 
GN⁺ 2023-08-20
ความคิดเห็นจาก Hacker News

  • อ้างอิง: มีบทความของ Joel Spolsky ด้วย: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    หนึ่งในนักพัฒนา SimCity เล่าว่า มีบั๊กร้ายแรงที่บังเอิญทำงานได้ดีบน DOS แต่พังบน Windows เป็นบั๊กที่นำหน่วยความจำที่ปล่อยไปแล้วกลับมาใช้อีก และทีมทดสอบของ Windows พบว่า SimCity ล่มตลอดระหว่างลองรันแอปยอดนิยมต่าง ๆ นักพัฒนา Windows จึง disassemble SimCity แล้วไล่ตามด้วย debugger จนเจอบั๊ก จากนั้นใส่โค้ดที่ตรวจว่า กำลังรัน SimCity อยู่หรือไม่ และเฉพาะกรณีนั้นเท่านั้นจะให้ memory allocator ทำงานในโหมดพิเศษที่ยังคงอนุญาตให้ใช้หน่วยความจำได้ต่อแม้หลังปล่อยไปแล้ว

    • ตัวอย่างแย้งคือ Soldier of Fortune พังบน Windows รุ่นใหม่เพราะ compatibility hack ถูกนำไปใช้ผิดกรณี ถ้าเปลี่ยนชื่อไฟล์ executable ก็ทำงานได้ไม่มีปัญหา
      การทำ backward compatibility แบบนี้ไม่ค่อยดี เพราะทึบและเป็นการแก้เฉพาะหน้า เครื่องมือทำนองเดียวกันก็เคยถูกใช้เพื่อทำให้แอปของคู่แข่งพังด้วย ปกติสุดท้ายก็กลายเป็นการลองทีละตัวว่าจะให้รันเหมือน Windows เวอร์ชันเก่าเวอร์ชันไหน Linux ก็ไม่ได้ดีกว่าเพราะไม่มี ABI ที่เสถียร ส่วน Mac ก็เป็นส่วนผสมระหว่าง Rosetta ที่ยอดเยี่ยมกับการที่แอปพังแบบไม่มีเหตุผล ชวนสงสัยว่า FreeBSD ทำได้ดีกว่านี้ไหม หรือระบบปฏิบัติการ “สุกงอม” ที่หายไปแล้วอย่าง VMS เคยดีกว่านี้หรือเปล่า
    • ทุกวันนี้ การอัปเดตไดรเวอร์ GPU โดยทั่วไปก็เป็นแบบนี้เหมือนกัน แทนที่นักพัฒนาจะไปแก้เกม Nvidia คำนวณแล้วว่าการแก้บั๊กของเกมในระดับไดรเวอร์ GPU แล้วปล่อยอัปเดตออกไปเป็นประโยชน์กับตัวเองมากกว่า
    • นี่กลับดูเหมือนเป็นเหตุผลชั้นดีว่าควร ทำลาย backward compatibility ด้วยซ้ำ แฮ็กไร้สาระแบบนี้กลายเป็นภาระบำรุงรักษาและดีบักของใครบางคน และถูกวางทับบนระบบปฏิบัติการทั้งระบบเหมือนภาษี ผมว่าร่องรอยของมันโผล่ออกมาให้เห็นไม่น้อยจริง ๆ
    • ถ้าลองหาอ่านบทโบนัสของ “The Old New Thing” ของ Raymond Chen จะพบตัวอย่างมากมายที่มี ทีมเฉพาะกิจสำหรับแฮ็ก Windows เพื่อตรวจแอปยอดนิยมทีละตัวและทำให้มันรันบนระบบปฏิบัติการใหม่ได้
    • อีกด้านหนึ่ง ไดรเวอร์ GPU ของ Asahi Linux จะตรวจว่าตัวอักษรแรกของชื่อโปรเซสเป็น X หรือไม่ และถ้าใช่ก็ปฏิเสธไปเลย
      ประมาณว่า ทำไมยังรัน Xorg อยู่ล่ะ? ควรย้ายไป Wayland ได้แล้วสิ
      https://social.treehouse.systems/@marcan/110904454552941656

  • Raymond Chen ให้มุมมองจากภายในเกี่ยวกับหัวข้อนี้มาหลายสิบปีแล้ว: https://devblogs.microsoft.com/oldnewthing/

  • น่าสนใจที่ความเสถียรโดยรวมของ Windows API ทำให้ Win32/DX กลายเป็น API “อเนกประสงค์” ที่เสถียรและเชื่อถือได้มากบน Linux และระบบปฏิบัติการอื่น ๆ ผ่านงานมหาศาลของ Wine/Proton ผมเห็นเรื่อย ๆ ว่าเกมเลิกออกเวอร์ชัน Linux native แล้วปล่อยมาให้ใช้กับ Proton แทน

    • รุ่นที่รับรู้ Proton มักตั้งค่าง่ายกว่าและรันได้ดีกว่าเวอร์ชัน Linux native
    • ใช่ ปีที่แล้วมีคนเขียนบทความเรื่องนี้ และที่นี่ก็ถกกันพอสมควร
      https://sporks.space/2022/02/27/win32-is-the-stable-linux-us...

  • เรื่องนี้ไม่ใช่เรื่องบ้า แต่เป็นระดับที่เราควรคาดหวังจากเครื่องมืออยู่แล้ว ค้อนของผมยังใช้กับตะปูที่ซื้อมาเมื่อ 30 ปีก่อนได้อย่างสมบูรณ์แบบ
    เราสร้างอะไรบนรากฐานที่สั่นคลอนซึ่งคอยทำลาย backward compatibility ไม่ได้ สุดท้ายเวลาจะหมดไปกับการบำรุงรักษามากกว่าสร้างของ แล้วก็ต้องกลับไปประดิษฐ์ล้อขึ้นใหม่ ทั้งที่ในมุมผู้ใช้ ล้อใหม่มันวาวก็ไม่ได้จำเป็นต้องดีกว่าเสมอ ซอฟต์แวร์ส่วนใหญ่ที่ผมใช้มีอายุเกิน 10 ปีแล้ว บางตัวยังอัปเดตอยู่ แต่บางตัวไม่อัปเดตแล้วหรือย้ายไปคลาวด์ ทำให้ผมถูกทิ้งไว้ข้างหลังอย่างมีความสุข

    • Milwaukee ยังผลิต แบตเตอรี่ NiCAD สำหรับเครื่องมือของตัวเองที่ล้าหลังไปนานแล้วอยู่
    • ในทางกลับกัน คุณก็อาจถูกผูกติดกับ ข้อจำกัดโง่ ๆ แบบนี้ไปตลอดกาลได้: https://news.ycombinator.com/item?id=14286383

  • เมื่อก่อนผมเคยเชื่อแบบนั้น แต่ตอนนี้ไม่แล้ว
    เกม Steam ที่ใช้บริการ Games for Windows – Live และไม่ได้อัปเดตหลังบริการปิดตัวในปี 2014 จะรันไม่ได้ตั้งแต่ Windows 10 เป็นต้นไป เพราะ DLL ของบริการนั้นถูกเอาออกแล้ว ช่วงหนึ่งผู้คนแก้ด้วยการดาวน์โหลด DLL จากเว็บ third-party แต่ตอนนี้วิธีนั้นก็ใช้ไม่ได้แล้ว

    • เกมเก่าที่ไม่มี DRM หรือบริการเครือข่ายก็อาจรันไม่ได้เพราะ ความเข้ากันได้ด้านกราฟิก แต่ cnc-ddraw ช่วยกู้กลับมาได้จำนวนมาก: https://github.com/FunkyFr3sh/cnc-ddraw
    • ถึงอย่างนั้น เวอร์ชันเถื่อนของเกมเหล่านั้นก็น่าจะยังรันได้อยู่ ;)

  • มีตัวอย่างที่ “บ้า” กว่านี้ด้วย
    z/OS (หรือที่เรียกว่า OS360, MVS) รองรับไปถึงโปรแกรมจากยุค 1960 และ DE คนหนึ่งของ IBM เคยบอกว่ายังใช้โปรแกรมที่คอมไพล์ไว้ราวช่วงภารกิจ Apollo 11 อยู่

    • ในโลกเมนเฟรม นี่เป็นเรื่องธรรมดา Unisys (เดิมคือ Univac) ยังมีเมนเฟรม Dorado ที่เข้ากันได้ในระดับไบนารีกับ Univac 1100 ที่ออกมาในปี 1962 อยู่
    • DE คืออะไร? แล้วเขาบอกไหมว่าโปรแกรมนั้นทำอะไร?
      ยังมีระบบอื่น ๆ ที่รันหรือแปลงไบนารีอายุเกิน 30 ปีให้อัตโนมัติได้ด้วย IBM i on POWER (i5/AS400) น่าจะรันโปรแกรมสมัย System/38 (1980) ได้ และ HPE NonStop (หรือที่เรียกว่า Tandem Guardian) on X86-64 ก็รันหรือแปลงไบนารีจากระบบ TNS ดั้งเดิมเฉพาะทางช่วงปลายยุค 1970 และระบบ MIPS ปี 1991 ได้

  • เป็นที่รู้กันว่า Windows ยึดมั่นกับความเข้ากันได้ย้อนหลังอย่างจริงจัง แต่สำหรับ แอป DOS CLI นั้น ระบบย่อย DOS แทบจะหยุดนิ่งไปแล้ว เลยรู้สึกว่าไม่ใช่ความท้าทายใหญ่อะไรนัก อยากรู้ว่าถ้ารันโปรแกรมแบบ DOS ที่มีข้อกำหนดมากกว่านี้ หรือแอป Win16 ยุคแรก ๆ จะเป็นอย่างไร เช่น Zortech C++ ปี 1986 กับ Phar Lap DOS extender หรือ Minesweeper ของ Windows 3.1 จะทำงานได้ไหม?

    • นั่นไม่ใช่แอป DOS แต่เป็น แอปคอนโซล Win32 แอป DOS (ไม่ว่าจะ 16 บิตหรือ 32 บิต) หรือแอป Win16 ไม่ได้รันแบบเนทีฟ
    • Zortech C++ เคยเป็นเครื่องมือที่ผมใช้พักหนึ่ง และมีความทรงจำดี ๆ กับมัน Phar Lap เข้าไปยุ่งลึกเกินไป ผมคิดว่าน่าจะรันบน Windows ปัจจุบันได้ยาก แต่ก็น่าลองทดลองดู อาจเป็นไปได้ว่าฟีเจอร์ที่เกี่ยวกับหน่วยความจำแบบ extended/expanded ส่วนใหญ่ตอนนี้ใช้ไม่ได้แล้ว

  • เรื่องนี้ไม่ควรถูกมองว่ายอดเยี่ยมเลยสักนิด ควรถูกมองว่าเป็นเรื่องปกติในชีวิตประจำวันและเป็นเรื่องที่ควรเป็น ถ้าทำไม่ได้ควรถูกมองว่าเป็นความล้มเหลวที่น่าอับอายมากและยอมรับไม่ได้
    ไม่ได้หมายความว่าไม่ยอดเยี่ยมเมื่อเทียบกับความเละเทะในปี 2023 แต่หมายถึง บรรทัดฐาน ที่เราควรมุ่งไปควรเป็นแบบนั้น

    • เห็นด้วย ไม่มีเหตุผลเลยที่ ไบนารีที่คอมไพล์แบบสแตติก ส่วนใหญ่ควรจะหยุดทำงาน

  • บางคนอาจบอกว่า Linux ก็เป็นแบบนั้นเหมือนกัน และในเชิงเทคนิคก็ถูก แต่ในทางปฏิบัติค่อนข้างยาก
    เคอร์เนล ABI นั้นเสถียร แต่ส่วนที่เหลือแทบจะเป็นความโกลาหลล้วน ๆ ซึ่งเป็นผลมาจากวิธีที่แอปพลิเคชันบน Linux มักถูกแพ็กเกจ ตัวแอปเองอาจโหลดได้ (ถ้าไม่ใช่รูปแบบ a.out) แต่มีโอกาสสูงที่จะล้มเหลวตอนโหลดไลบรารีส่วนใหญ่ สุดท้ายก็ต้องใช้ chroot ของดิสทริบิวชัน Linux ทั้งชุดที่เป็นฐานอ้างอิงหรือรันไทม์อื่น และยังไม่แน่ใจด้วยซ้ำว่าจะหาไฟล์อาร์ไคฟ์ของดิสทริบิวชันอายุ 30 ปีได้ไหม ยิ่งไปกว่านั้นยังต้องสมมติว่าเคอร์เนล ABI ไม่ได้เปลี่ยนแม้แต่บิตเดียวจริง ๆ และอินเทอร์เฟซอื่น ๆ อย่าง /proc หรือ /sys ก็ไม่เปลี่ยนด้วย ดูเหมือนว่า /sys เมื่อ 30 ปีก่อนยังไม่มีด้วยซ้ำ ถ้าเป็นแอป Xorg ผมคงไม่กล้าเดิมพันเงินค่าอาหารกลางวันกับความเข้ากันได้ในระดับโปรโตคอล

    • บน Linux ก็ทำงานแบบเดียวกับ Windows นั่นแหละ ถ้าไม่มี ไลบรารีแบบไดนามิกและการตั้งค่า ที่จำเป็น ก็รันไม่ได้
      ผมเข้าใจยากว่าทำไมเรื่องนี้ถึงเป็นข้อเสียของ Linux แต่ไม่ใช่ของ Windows

  • ผมรู้สึกเสียดายเสมอที่ซอฟต์แวร์ Mac เก่า ๆ รันไม่ได้ง่าย ๆ การที่ Apple ย้ายไปสถาปัตยกรรมใหม่อาจเป็นเรื่องหลีกเลี่ยงไม่ได้ แต่ปัญหาคืออีกไม่กี่ปีต่อมา อีมูเลเตอร์ ก็พัง
    ความทุ่มเทที่ Microsoft แสดงต่อลูกค้าไม่ควรเป็นเรื่องน่าทึ่งขนาดนี้ ทุกบริษัทควรทำแบบนั้น

    • Apple ก็เคยมีช่วงเวลาที่ทำให้ iMac รุ่นแรก (300MHz?) สามารถติดตั้ง Mac OS X รุ่นล่าสุดได้ อาจต้องเพิ่ม RAM ให้เต็มที่ แต่แค่นั้นก็พอ และใช้งานได้ค่อนข้างดีจริง ๆ