مسیری از پروژه آستوریا به WSL 1.0
اجرای مستقیم فایلهای اجرایی باینری لینوکس روی ویندوز، سالها یکی از چالشهای اصلی توسعهدهندگان بود تا اینکه مایکروسافت زنجیرهٔ زیرسیستم ویندوز برای لینوکس را با دو رویکرد معماری کاملاً متفاوت ارائه داد. رویکرد نخست یعنی WSL 1، تلاش کرد فراخوانهای سیستمی لینوکس را در لحظه به دستورات هستهٔ NT تبدیل کند. رویکرد دوم اما گامی رادیکال برداشت و یک هستهٔ اصیل لینوکس را درون یک ماشین مجازی سبک و غیرقابلمشاهده جای داد. درک نحوهٔ کار این معماریها و دلیل کنار گذاشتن اولی برای دومی، شکاف عمیق بین هستهٔ لینوکس و ویندوز NT را به شکل عینی نشان میدهد.
ریشههای این فناوری به سال 2010 و پروژهٔ آستوریا بازمیگردد. این تلاش که برای اجرای برنامههای اندروید روی ویندوز فون طراحی شده بود، هرگز به مرحلهٔ تولید نرسید اما نمونهٔ اولیهٔ آن پایهٔ ترجمهٔ بلادرنگ فراخوانهای سیستمی لینوکس به NT را فراهم کرد. این فناوری در سال 2016 به شکل پروژهٔ Bash on Windows ظاهر شد. شرکت کانونیکال در توسعهٔ اولیه نقش کلیدی داشت و توسعهدهندگان مایکروسافت با تطبیق ابزارهای تحقیقاتی این شرکت، لایهٔ سازگاری WSL 1.0 را خلق کردند. این نسخه به کاربران اجازه داد توزیعهایی مانند اوبونتو، openSUSE و فدورا را از طریق مکانیزم پروسههای پیکو اجرا کنند.
معماری ترجمه در WSL 1
طراحی WSL 1 از نظر مفهومی بسیار ظریف است. به جای شبیهسازی کامل سختافزار یا اجرای مجازیسازی سنگین، این معماری فایلهای اجرایی لینوکس را مستقیماً روی سیستمعامل میزبان مینشاند، درخواستهای آنها را رهگیری کرده و آنها را به معادلهای قابلدرک هستهٔ NT تبدیل میکند.
سرویس LXSS و مدیریت نمونهها
در سلسلهمراتب این معماری، سرویس LXSS Manager بهعنوان واسط اصلی عمل میکند. هنگامی که یک فرآیند ویندوزی مانند bash.exe درخواست اجرای یک فایل لینوکسی را ارسال میکند، درخواست ابتدا از مسیر این سرویس عبور میکند. LXSS Manager وضعیت کاربر را ردیابی کرده و از اجرای همزمان عملیات نصب یا حذف اطمینان حاصل میکند. تمام فرآیندهای لینوکسی راهاندازیشده توسط یک کاربر خاص، در یک ساختار داده به نام LX Instance گروهبندی میشوند. این نمونه از لحظهٔ اجرای اول فایل لینوکسی زنده میشود و بهمحض بستهشدن آخرین کلاینت ویندوزی، بهطور کامل از حافظه تخلیه میشود. این خالیشدن حافظه شامل تمام خدمات پسزمینهٔ فعال در آن محیط نیز میشود.
ترجمهٔ فراخوانهای سیستمی: پیادهسازی Clean-Room
قلب معماری WSL 1، مدیریت فراخوانهای سیستمی است. هم لینوکس و هم ویندوز NT صدها تابع برای ارتباط حالت کاربر با هسته ارائه میدهند اما معنای آنها به کلی متفاوت است. لینوکس از توابعی مانند fork، open و kill استفاده میکند در حالی که NT در سطح پایینتر از NtCreateProcess و NtOpenFile بهره میبرد. این شکاف توسط دو درایور حالت هسته به نامهای lxss.sys و lxcore.sys پر میشود که هیچکدام حاوی کد اصلی هستهٔ لینوکس نیستند.
این درایورها یک پیادهسازی ایزوله و مبتنی بر اصول Clean-Room از رابطهای سازگار با لینوکس ارائه میدهند. وقتی یک فایل اجرایی لینوکسی یک فراخوان سیستمی صادر میکند، هستهٔ ویندوز NT درخواست را به lxcore.sys ارجاع میدهد. در مواردی که نگاشت منطقی وجود دارد، درایور دستوری لینوکس را به قابلیت معادل NT تبدیل میکند، اما در مواردی که معادلی وجود ندارد، lxcore.sys مسئول بهتنهایی مدیریت و پردازش درخواست است. چالش فراخوان fork بهترین نمونهٔ این پیچیدگی است. دستور fork که وظیفهٔ ساخت کپی از فرآیند فعال را دارد، در مستندات ویندوز معادل مستقیمی برای آن وجود ندارد. هنگام دریافت این درخواست، lxcore.sys کارهای آمادهسازی اولیه را انجام داده و سپس مکانیزمی شبیهسازیشدهٔ fork را در فضای حافظهٔ ویندوز پیادهسازی میکند تا وضعیت جدید به شکلی سازگار بازسازی شود. این رویکرد سازگاری بالا را فراهم میکرد اما محدودیتهای عملکردی و عدمِ پشتیبانی از برخی توابع سطح پایین POSIX را نیز برجسته ساخت.
دوراهی معماری و تولد WSL 2
تجربهٔ عملی WSL 1 نشان داد که ترجمهٔ بلادرنگ فراخوانهای سیستمی میتواند در کارهایی که نیاز به پردازش فایل سنگین، عملیات شبکهٔ پیچیده یا استفاده از تمامی توابع هستهای دارند، دچار افت عملکرد شود. مایکروسافت برای غلبه بر این محدودیتها و جذب نهایی جامعهٔ توسعهدهندگان متنباز، مسیر جدیدی را در پیش گرفت. طبق مستندات رسمی WSL، تیم توسعهٔ ویندوز تصمیم گرفت لایهٔ ترجمه را کنار بگذارد و بهجای آن یک هستهٔ لینوکس واقعی را مستقیماً در فضای هستهٔ ویندوز بارگذاری کند. این تغییر پارادایم، WSL 2 را به وجود آورد که با بهرهگیری از فناوری مجازیسازی سبک Hyper-V، هستهٔ لینوکس را بهصورت یک فرآیند ایزوله اما بسیار سبک مدیریت میکند.
این معماری جدید همگامسازی کامل POSIX، عملکرد فایلسیستم سریعتر با استفاده از یک فایلسیستم اختصاصی ext4، و قابلیت اجرای دمونها و توابع شبکهای سنگین را بدون افت راندمان ترجمه ارمغان آورد. ادغام هستهٔ لینوکس در ویندوز دیگر یک لایهٔ ترجمهٔ کاربردی نبود، بلکه به یک زیرساخت بومی تبدیل شد که مرزهای دو اکوسیستم را تقریباً بهطور کامل از بین برد.
آیندهٔ مشترک ویندوز و لینوکس
سیر تکامل معماری WSL نشان میدهد که مایکروسافت از رویکرد دفاعی لایههای سازگاری کاملاً عبور کرده و به سمت یکپارچگی زیرساختی حرکت کرده است. با بهبود مستمر عملکرد فایلسیستم، پشتیبانی از رابط گرافیکی X11 و Wayland، و یکپارچهسازی عمیقتر با ابزارهای CI/CD، این معماری دیگر یک ویژگی آزمایشی محسوب نمیشود. انتظار میرود نسلهای آیندهٔ این زیرسیستم بر تمرکز بیشتر به امنیت، ایزولهسازی، بهینهسازی مصرف حافظه در محیطهای سازمانی، و ادغام ناظرانهتر با کانتینرها پیش برود. ترکیب پایداری هستهٔ NT با انعطافپذیری اکوسیستم لینوکس، استاندارد جدیدی برای محیطهای توسعهٔ مدرن تعریف کرده که راه را برای ابزارهای توسعهٔ چندسکویی هموارتر خواهد کرد.
