ข่าวใหญ่ของวงการระบบปฏิบัติการในรอบเดือนที่ผ่านมาคือ การเปิดตัว Windows 11 ซึ่งเป็น Windows เวอร์ชันใหม่ของไมโครซอฟท์ในรอบ 6 ปี (Windows 10 เปิดตัวปี 2015)
ของใหม่ใน Windows 11 แบ่งออกได้เป็น 3 กลุ่มใหญ่ๆ คือ UI ที่เปลี่ยนไปจากเดิมพอสมควร, ฟีเจอร์ด้านเล่นเกมที่ดึงมาจาก Xbox และ Microsoft Store ตัวใหม่ที่เปิดรับแอพหลายประเภท ที่ฮือฮาคือรองรับ Android ผ่าน Amazon Appstore
การที่ Windows 11 เปิดกว้างรับแอพหลากหลายกว่าเดิมอาจเป็นสิ่งที่น่าตื่นเต้น แต่จริงๆ แล้วไอเดียนี้เกิดขึ้นมาตั้งแต่ปี 2015 แล้วล้มเหลวมายาวนาน ก่อนจะมาสำเร็จสักทีในปี 2021
ไมโครซอฟท์เคยประกาศวิสัยทัศน์นี้ไว้ในงาน Microsoft Build 2015 ซึ่งเป็นปีที่เปิดตัว Windows 10 ว่าจะแก้ปัญหา "แอพน้อย" ของแพลตฟอร์ม Windows ด้วยโครงการชื่อ Universal Windows Platform Bridges (UWPB) ที่ประกอบด้วย 4 โครงการย่อยคือ
น่าเสียดายว่า ผลลัพธ์สุดท้ายของโครงการทั้ง 4 ตัวคือ ล้มเหลวทั้งหมด
เหตุผลหลักที่โครงการ UWPB ล่มสลายลงในเวลาไม่นาน ก็มาจากชื่อและแนวคิดของมันคือ ต้องการนำแอพจากแพลตฟอร์มอื่นๆ แปลงมาเป็น Universal Windows Platform (UWP) ที่ไมโครซอฟท์ตั้งเป้าให้เป็นแพลตฟอร์มร่วมของ Windows 10 (พีซี) และ Windows 10 Mobile (มือถือ) เพื่อแก้ปัญหาแพลตฟอร์ไม่มีแอพใช้งานเท่ากับคู่แข่ง
แต่ตัว UWP เองประสบปัญหาทางเทคนิคมากมาย (ตัว API ไม่พร้อม) และไมโครซอฟท์ก็ยอมตัดใจจากตลาดมือถือในปี 2017 (Windows 10 Mobile เวอร์ชันใหญ่ตัวสุดท้ายคือ v1709) ในขณะที่ฝั่งพีซีที่สามารถรันแอพ Win32 แบบเดิมได้อยู่ ทำให้ไม่ค่อยมีนักพัฒนาสนใจทำแอพแบบ UWP สักเท่าไรนัก ความจำเป็นของโครงการ UWPB จึงไม่มีอีกต่อไป
อย่างไรก็ตาม ไอเดียของโครงการเหล่านี้ยังคงอยู่ในใจของไมโครซอฟท์เสมอ ทำให้เราได้เห็นการนำ Android, .NET/Win32 และเว็บแอพ มารันบน Windows 11 อย่างจริงจังอีกครั้ง (ด้วยวิธีที่ต่างจากเดิมในอีก 6 ปีให้หลัง) มีเพียงแค่ไอเดียของแอพ iOS เท่านั้นที่หายไปเลย
บทความนี้จะพาย้อนดูรายละเอียดของโครงการต่างๆ ว่าเกิดอะไรขึ้นระหว่างทาง และมันกลายร่างมาเป็นอะไรใน Windows 11
ชะตากรรม: ถูกยกเลิก แล้วกลับมาเกิดใหม่ Windows Subsystem for Android
Project Astoria คือการนำแอพ Android มารันบน UWP (หลักๆ คือบนมือถือ) แนวทางของไมโครซอฟท์จะคล้ายกับ Amazon Fire OS (หรือ Huawei HMS ในยุคถัดมา) คือออกไลบรารีกลางมาใช้ทดแทน Google Mobile Services
อย่างไรก็ตาม Project Astoria เป็นโครงการแรกที่ถูกไมโครซอฟท์ฆ่าทิ้งในปี 2016 ด้วยเหตุผลว่า โครงการคล้ายกับ Project Islandwood (iOS) เกินไป แอพบน iOS/Android ก็ตัวเดียวกัน
ดังนั้นไมโครซอฟท์จึงเลือกพอร์ตโค้ดจากฝั่ง iOS (เนทีฟ) มารันบน Windows Mobile (เนทีฟ) เพียงตัวเดียวพอ ถ้าเปิดทางเลือกให้พอร์ตโค้ดจาก Android (รันบน VM คือ Dalvik/ART) นักพัฒนาย่อมสับสนว่าควรพอร์ตจากไหนดี (แต่สุดท้ายก็ไม่ต้องพอร์ตจากอะไรเลยเพราะ Windows 10 Mobile เจ๊งไปก่อน ?)
ไอเดียของ Project Astoria กลับมาอีกครั้งในปี 2021 ด้วยวิธีที่ต่างออกไป นั่นคือ เปลี่ยนมารันแบบเนทีฟด้วย Windows Subsystem for Android ซึ่งเป็นผลมาจากการลงทุนพัฒนา Windows Subsystem for Linux (WSL) มาตั้งแต่ปี 2016 และใช้เวลาบ่มเพาะมายาวนานกว่าจะใช้งานได้จริง
ชะตากรรม: กลายเป็นโครงการโอเพนซอร์ส WinObjC ที่สุดท้ายหยุดพัฒนาไป
หาก Project Astoria ถูกไมโครซอฟท์ฆ่าทิ้ง ในทางกลับกัน Project Islandwood ก็เดินหน้าต่อและผลิดอกออกผล โครงการถูกพัฒนาต่อเนื่องมาอีก 2-3 ปีจนกลายมาเป็นชื่ออย่างเป็นทางการ Windows Bridge for iOS Project (ชื่อสั้นๆ คือ WinObjC ซึ่งเปิดเป็นโอเพนซอร์สบน GitHub ด้วย)
เป้าหมายของ Islandwood คือการนำแอพ (เน้นที่เกม) จาก iOS มารันบนแพลตฟอร์ม UWP โดยแปลงการเรียก API ของ iOS มาเป็น API ของ Windows แทน
โครงการไปได้สวยในระดับหนึ่ง มีชุมชนนักพัฒนาบน Github จริงจัง มีการวางแผน Roadmap ชัดเจน น่าเสียดายว่าโครงการแม่คือ Windows 10 Mobile ล่มสลายไปก่อน ทำให้ WinObjC หยุดพัฒนาไปด้วย (commit ครั้งสุดท้ายบน GitHub คือเดือนมกราคม 2020)
ไอเดียของ Project Islandwood ไม่ถูกนำกลับมาใน Windows 11 ด้วยเหตุผลแบบเดียวกับ Astoria แต่กลับด้านกัน คือไมโครซอฟท์มี Windows Subsystem for Android ในการนำแอพมือถือมารันบน Windows 11 อยู่แล้ว จึงไม่ต้องหาวิธีย้ายแอพมือถือจาก iOS มาอีกให้ซ้ำซ้อน
ชะตากรรม: กลายร่างมาเป็น Project Reunion
กรณีของ Astoria/Islandwood คือการนำแอพมือถือจากค่ายคู่แข่ง Android/iOS มารันบน Windows 10 Mobile
แต่กรณีของ Centennial นั้นต่างไป มันคือการนำแอพในจักรวาลไมโครซอฟท์เดิม (.NET/Win32) มาอยู่ในร่างใหม่ที่ทันสมัยขึ้น (UWP ณ เวลานั้น) เพื่อมารันบน Windows 10 ผ่าน Store (ชื่ออย่างเป็นทางการของมันคือ Desktop Bridge)
โครงการ Centennial ไม่ได้ตายจากเราไป 100% แต่ก็ไม่มีคนใช้เยอะนัก (ด้วยข้อจำกัดของแพลตฟอร์ม UWP เอง) สุดท้ายไมโครซอฟท์ก็วิวัฒนาการมันไปเป็น Project Reunion ที่เปิดตัวในปี 2020 ที่คิดไปไกลกว่าการนำ .NET/Win32 มาเป็น UWP เพราะเปลี่ยนวิธีคิดมาเป็นการรวม API ของทั้งสองฝั่งเข้าด้วยกันแทน
ปัจจุบัน Project Reunion ได้ชื่ออย่างเป็นทางการว่า Windows App SDK และเป็นแกนกลางสำคัญของการพัฒนาแอพมาลง Windows 11 ด้วย
ชะตากรรม: มาก่อนกาล เบราว์เซอร์ไม่พร้อม กลับมาใหม่อีกครั้งตามกระแส PWA
แนวคิดของ Project Westminster ค่อนข้างตรงไปตรงมา ดูแล้วทำได้ง่ายในทางทฤษฎี มันคือการนำเว็บแอพมาจัดแพ็กเกจแล้วส่งขึ้น Store โดยอาจเชื่อมกับ API บางอย่างของ Windows (เช่น notification) ให้หรูหราขึ้น
แต่ในทางปฏิบัติแล้วมันไม่ง่ายนัก จากหลายปัจจัยประกอบกัน เช่น
กระแส Progressive Web App (PWA) ในตอนนั้นยังเพิ่งเริ่มต้น ตอนนั้นไมโครซอฟท์ยังเรียกว่า Hosted Web App อยู่เลยด้วยซ้ำ
เอนจินเรนเดอร์เว็บของ Windows 10 ในปี 2015 คือ EdgeHTML ของ Microsoft Edge ตัวเดิม (Spartan) ที่พัฒนามาจากเอนจิน Trident ของ IE อีกต่อหนึ่ง
เอาเข้าจริง นักพัฒนาสายเว็บก็ไม่ได้แคร์ Windows Store มากนัก เข้าเว็บตรงๆ ก็ได้นี่นา
ผลคือ Project Westminster ไม่ค่อยมีใครใช้งาน ที่ไมโครซอฟท์นำมาโชว์ในปี 2016 มีเพียง Yahoo Mail และ Shazam
ทำให้ไมโครซอฟท์เจอความจริงว่า นักพัฒนาเว็บส่วนใหญ่ไม่สนใจปรับเว็บ (ไม่ต้องถึงขั้นเว็บแอพเลยด้วยซ้ำ) ของตัวเองให้ทำงานได้ 100% บน Edge หรือ EdgeHTML มากนัก เพราะส่วนแบ่งตลาดน้อยจนไม่สำคัญ
จนสุดท้าย ในปี 2019 ไมโครซอฟท์ถึงตัดสินใจช็อคโลก เปลี่ยนเอนจินมาเป็น Chromium แทน ทำให้ข้อจำกัดนี้หมดไป นักพัฒนาเว็บแอพไม่ต้องทำอะไรเลยก็ใช้งานกับ Edge ตัวใหม่ได้ทันที
การเปลี่ยนผ่านเอนจินแสดงผลต้องใช้เวลาพอสมควร ไมโครซอฟท์เพิ่งเปิดตัว WebView2 ที่เป็น Chromium ในปี 2020 และมันจะถูกผนวกเข้ากับ Windows 11 เป็นรุ่นแรกด้วย (WebView2 สามารถบันเดิลไปกับแอพได้ถ้าต้องการ ย้อนไปใช้ได้ถึง Windows 7 แต่ถ้าจะเอาแบบดีฟอลต์ การันตีว่าเปิดได้ทันที ต้องรออัพเกรดเป็น Windows 11)
ส่วนการส่งเว็บแอพขึ้น Store ไมโครซอฟท์เพิ่งเปิดตัวเครื่องมือ PWA Builder เวอร์ชันใหม่พร้อม Windows 11 นี้เอง และยังมีเว็บแอพเพียงไม่กี่ตัวที่ใช้กระบวนการนี้ทำแอพขึ้น Store เช่น Twitter/Facebook ซึ่งก็ต้องค่อยๆ รอความนิยมเพิ่มขึ้นตามระยะเวลากันต่อไป
จะเห็นว่าวิสัยทัศน์ของ Universal Windows Platform Bridge (UWPB) ที่ต้องการนำแอพจากแพลตฟอร์มต่างๆ มาสู่ Windows เป็นสิ่งที่ยังคงเป็นจริงอยู่ในระยะยาว แต่จังหวะเวลาในตอนแรกผิดไป และไมโครซอฟท์ต้องใช้เวลานานถึง 6 ปีกว่าจะทำให้วิสัยทัศน์เหล่านี้เป็นจริง
เหตุผลข้อแรกเป็นเรื่องของขอบเขต (scope) อย่างที่เขียนไปข้างต้นแล้วว่าไอเดียของ UWPB เกิดขึ้นมาบนกรอบคิด Universal Windows Platform (UWP) เขียนแอพครั้งเดียวใช้ได้ทั้งบนพีซีและมือถือ ซึ่งอยู่บนสมมติฐานว่าการผสาน 2 แพลตฟอร์ม ช่วยให้ได้เปรียบกว่าคู่แข่ง
เมื่อเวลาผ่านไป ไมโครซอฟท์พ่ายแพ้ในตลาดมือถืออย่างหมดรูป ต้องถอนตัวออกมาอย่างเจ็บปวด แต่ตลาดพีซียังแข็งแกร่ง ไมโครซอฟท์จึงกลับมาจัดทัพใหม่ให้ศูนย์กลางอยู่ที่พีซี กลับมาผลักดันคนรักเก่าอย่าง Win32 ที่อยู่ยืนยง แล้วปรับวิธีนำเสนอให้ทันสมัยขึ้นผ่าน Microsoft Store ตัวใหม่และ Project Reunion
ทั้งหมดนี้เป็นการลดเป้าหมายของ UWP เดิมลงมาเหลือเพียงแพลตฟอร์มเดียว เป้าเล็กลง ทะเยอทะยานน้อยลง แต่ชัดขึ้น และเป็นจริงได้มากกว่า
เหตุผลข้อที่สองเป็นเรื่องของกรอบเวลา (timing) แผนการ UWPB ของไมโครซอฟท์ตอนแรกอาจคิดน้อยไปหน่อย เมื่อเวลาผ่านมา 6 ปี เราจะเห็นว่ากว่าความฝันแต่ละอย่างจะเป็นจริงได้ ต้องผ่านการลงทุนเชิงโครงสร้างที่ใช้เวลาและทรัพยากรมหาศาล
จะเห็นว่าทั้ง 3 ข้อถือเป็น "งานช้าง" ที่ใช้เวลาหลายปีกว่าจะสำเร็จเป็นรูปเป็นร่าง ดังนั้นฝันเดิมในปี 2015 จะมาช้าไปหน่อย มองย้อนกลับไปแล้วคงไม่น่าแปลกใจนัก
ที่เหลือคงอยู่ที่ว่า ไมโครซอฟท์กลับไปทำการบ้านมาครั้งใหญ่ ปูทางมาให้ขนาดนี้แล้ว นักพัฒนาจะยอมทำแอพมาลง Windows 11 ตามแนวทางเหล่านี้หรือไม่ ก็คงต้องพิสูจน์กันหลัง Windows 11 ออกตัวจริงไปสักพัก
อีกประเด็นที่น่าสนใจคือ การหลอมรวมแอพจากหลายแพลตฟอร์มเป็นสิ่งที่คู่แข่งของไมโครซอฟท์ก็ทำเหมือนกัน ดังที่เราเห็นได้จากการนำแอพ iOS มารันบน macOS
หรือถ้าเทียบให้ตรงกว่าคือ Chrome OS ที่เริ่มต้นมาจากเว็บแอพ ตอนนี้รองรับแอพจากลินุกซ์ แอนดรอยด์ และล่าสุดคือ วินโดวส์ (ผ่าน virtualization)
นั่นเท่ากับว่าในปี 2021 เรามีระบบปฏิบัติการสองตัว (Windows 11 และ Chrome OS) ที่มาจาก 2 สุดปลาย แต่สุดท้ายรันแอพจาก 4 แพลตฟอร์มคือ เว็บ ลินุกซ์ แอนดรอยด์ Windows ได้พอๆ กัน (แม้วิธีการคนละอย่าง)
สงครามชิงความเป็นเจ้าเดสก์ท็อปที่เงียบไปนานนับสิบปี กำลังจะกลับมาดุเดือดใหม่อีกครั้ง