تکامل معکوس: از میراث داس به معماری مدرن

پایان دوران ویندوز 9x در سال 2001 با عرضه‌ی ویندوز XP، نقطه‌ی عطفی بود که مسیر سیستم‌عامل‌های شخصی را برای همیشه تغییر داد. این خانواده‌ی سیستم‌عامل شامل ویندوز 95، 98 و مِه، صرفاً نسخه‌های قدیمی‌تری از ویندوزهای امروزی نبود. آن‌ها بر پایه‌ی فلسفه‌ای کاملاً متفاوت در طراحی کرنل بنا شده بودند. برای درک عمق این شکاف معماری، باید به ریشه‌ها، ساختار داخلی و نحوه‌ی بارگذاری این سیستم‌عامل‌ها نگاهی دقیق انداخت.

دو خط تولید، دو بنیان مستقل

سلسله‌ی ویندوز 9x که از سال 1995 تا 2000 عرضه شد، مستقیماً از کرنل ویندوز 95 به‌عنوان هسته‌ی اصلی خود بهره می‌برد. این کرنل از نوع یکپارچه بود و کد پایه‌ی آن تا حد زیادی شبیه به هسته‌ی مایکروسافت داس عمل می‌کرد. این ویژگی تصادفی نبود. خط 9x دقیقاً برای پر کردن شکاف میان سیستم‌های مبتنی بر داس و معماری پیشرفته‌ی ویندوز NT طراحی شده بود. در مقابل، ویندوز NT که از نسخه 3.1 آغاز شد، از اولین روز با هدف پیاده‌سازی حافظه‌ی محافظت‌شده و جداسازی رسمی میان لایه‌ی خدمات سیستم و برنامه‌های کاربردی، از بنیان متفاوتی پدید آمده بود. در حالی که 9x از داس تکامل یافت، NT از ته‌خطی کاملاً مستقل ساخته شد.

ایزولاسیون ضعیف در برابر حفاظت سفت‌وسخت

مشهورترین تفاوت معماری میان این دو، استفاده‌ی ویندوز 9x از کرنل یکپارچه در تقابل با مدل سلسله‌مراتبی NT است. اما مسئله فراتر از یک برچسب تخصصی رفت:

  • مرزهای نفوذپذیر در 9x: این سیستم‌عامل بر معماری‌ای تکیه داشت که در آن جداسازی سخت‌گیرانه‌ی حالتِ کاربر و حالتِ کرنل، یک اصل نبود. مؤلفه‌های سیستم‌عامل و برنامه‌های کاربردی اغلب در فضای حافظه‌ای مشترک یا با محدودیت‌های کمتر اجرا می‌شدند.
  • حفاظت حافظه در NT: معماری ویندوز NT مرزهای سفت‌وسختی میان سرویس‌های سیستم و کاربردی‌ها ایجاد کرد. حافظه‌ی محافظت‌شده در اینجا یک ویژگی الحاقی نبود، بلکه ستونِ فقراتِ طراحیِ سیستم بود.
  • تأثیر مستقیم بر APIها: این شکاف درونی بلافاصله در رابط‌های برنامه‌نویسی که هر پلتفرم ارائه می‌داد، خود را نشان داد. بنیان سیستم‌عامل به‌طور مستقیم نحوه‌ی تعامل توسعه‌دهندگان و نرم‌افزارها را دیکته می‌کرد.
مقایسه ساختار حافظه در ویندوز 9x و NT

این تفاوت در فلسفۀ مدیریت حافظه و ایزولاسیون، بسیاری از چالش‌های عملی آن دوره را توجیه می‌کند. ویندوز مِه، که در سپتامبر 2000 به‌عنوان آخرین نسخه‌ی این خط منتشر شد، به‌خاطر ناپایداری نسبت به نسخه‌های پیش‌تر مورد انتقاد بود. این نام‌نودی با معماری‌ای کاملاً همخوانی دارد که در آن گاردهای دفاعی میان بخش‌های مختلف کمتر بود. جالب این‌که تیم مایکروسافت برای جبران این شکنندگی داخلی، قابلیت System Restore را به ویندوز مِه اضافه کرد. این ابزار که به کاربران اجازه می‌داد سیستم را به نقطه‌ای امن در گذشته بازگردانند، اعترافی شفاف به باگ‌های ذاتی معماری قدیمی و پلی بود به سوی ویژگی‌هایی که بعدها استاندارد سیستم‌عامل‌های پیشرفته شدند.

هیبرید ۱۶ و ۳۲ بیتی؛ زنجیری به داس

بارزترین ویژگی معماری ویندوز 9x، ماهیت هیبریدی آن بود که برای اجرای صحیح کاملاً به پشتیبانی از مایکروسافت داس وابسته ماند. این وابستگی در کل ساختار فایل‌های سیستم دیده می‌شود. فایل KRNL386.EXE از جنس ۱۶ بیتی در کنار KERNEL32.DLL با ۳۲ بیتی اجرا می‌شد تا رابط برنامه‌نویسی را برای منابعِ سیستم تأمین کند. جفت‌های GDI.EXE و GDI32.DLL به‌علاوه‌ی USER.EXE و USER32.DLL نیز وظیفه‌ی مدیریت رابط گرافیکی و رابط کاربری را بر عهده داشتند. مجموعه‌ای از درایورهای ۱۶ بیتی شامل SYSTEM.DRV، MMSOUND.DRV و VGA.DRV همچنان در میان فایل‌های بحرانی که برای بوت‌شدن سیستم حیاتی بودند، حضور داشتند. درایور دستگاهی HIMEM.SYS نیز امکان استفاده از حافظه‌ی توسعه‌یافته را برای برنامه‌های قدیمی فراهم می‌کرد.

حتی تحویل مسئولیت کرنل در لحظه‌ی روشن‌شدن دستگاه، متفاوت بود. فایل IO.SYS تمامی عملکردهای پایه را تا زمان بارگذاری کامل توسط VMM32.VXD مدیریت می‌کرد. این فایل مجازی‌ساز، در واقع مدیر ماشین مجازی محسوب می‌شد که مهم‌ترین درایورها و هسته‌ی اصلی ویندوز درون آن جای گرفت. چنین رویکرد مرحله‌ای و وابسته‌ی داس در دنیای NT هرگز دیده نشد و نشان می‌داد که چگونه میراث گذشته می‌تواند محدودیتی سخت در مسیر معماری‌بندی محسوب شود.

فرآیند بوت و میراث معماری

فرآیند راه‌اندازی شش‌مرحله‌ای ویندوز 9x نشانگر میزان عمق این وابستگی تاریخی است. از لحظه‌ای که کد ROM BIOS آدرس حقیقی 000FFFF0h را تحریک می‌کند، فرآیند Power-On Self-Test آغاز می‌شود. پس از آن، MBR در آدرس 7C00h بارگذاری شده و سکتور بوت، فایل IO.SYS را به حافظه منتقل می‌کند. در این مرحله، کرنل داسی اولیه جدول تخصیص فایل FAT را مقداردهی کرده و فایل‌های پیکربندی را پردازش می‌نماید. ویندوز Me با هدف بهبود پایداری، مرحله‌ی بارگذاری درایورهای حالتِ حقیقیِ داس را حذف کرد تا از اجرای نرم‌افزارهای قدیمی نوع TSR جلوگیری شود.

ساختار فایل‌های هسته ویندوز 9x

پایان عصر ویندوزهای مبتنی بر داس، پایان یک آزمایش بزرگ مهندسی بود که نشان داد چگونه می‌توان عملکرد را با افزودن لایه‌های حافظه‌ی مجازی به یک هسته‌ی قدیمی ارتقا داد. اما هزینه‌ی این سازگاری، فدا کردن ایزولاسیون و پایداری ذاتی بود. ویندوز NT با حذف داس و تکیه بر حافظه‌ی محافظت‌شده، مسیری هموارتر برای آینده‌ی رایانش شخصی هموار کرد. امروز نسل‌های بعدی ویندوز نشان می‌دهند که جداسازی دقیق لایه‌ها، به‌ویژه در محیط‌های چندوظیفه‌ای و شبکه‌ای، تنها یک انتخاب مهندسی نبود، بلکه پاسخی ضروری به نیازهای امنیتی و پایداری است که در دهه‌ی گذشته شکل گرفت و آینده‌ی سیستم‌عامل‌ها را تعریف می‌کند.