ویندوز XP برای اجرای نرم‌افزارهای قدیمی به آن‌ها دروغ می‌گفت!

یکی از ویژگی‌های طلایی ویندوز XP که در نسخه‌های جدید تقریباً وجود ندارد، سازگاری با برنامه‌های قدیمی بود. حالا می‌دانیم فرمول موفق مایکروسافت آن چیزی نبوده که بسیاری تصور می‌کردند. این شرکت فهرستی از برنامه‌های مشکل‌ساز تهیه کرده بود و می‌توانست رفتار ویندوز را هنگام اجرای هرکدام از آن‌ها تغییر دهد. گاهی ویندوز خودش را یک نسخه قدیمی‌تر از XP جا می‌زد و در مواردی حتی برخی اجزای ویندوز ۹۵ را به‌کار می‌گرفت.

این جزئیات را ریموند چن، مهندس باسابقه مایکروسافت که بیش از ۳۰ سال روی ویندوز کار کرده، اخیراً توضیح داده است. این راهکارها کمک می‌کردند نرم‌افزارهایی که برای نسخه‌های قدیمی‌تر ویندوز نوشته شده بودند، بدون نیاز به اصلاح توسط سازندگانشان روی ویندوز XP اجرا شوند.

ویندوز XP چطور برنامه‌های ناسازگار را شناسایی می‌کرد؟

مایکروسافت برای مدیریت این سازگاری‌ها از سازوکاری به نام Application Compatibility Database استفاده می‌کرد. این پایگاه داده در قالب فایل‌های باینری با پسوند SDB نگهداری می‌شد و در ویندوز XP فایلی با نام Sysmain.sdb بود. طبق توضیحات مایکروسافت هنگام عرضه ویندوز XP فایل مزبور حاوی لیست حدود ۲۰۰ برنامه بود.

ویندوز برای شناسایی برنامه‌های ناسازگار موجود در این لیست صرفاً نام فایل اجرایی را بررسی نمی‌کرد. اندازه فایل، چک‌سام، شماره نسخه و تاریخ آن نیز می‌توانستند در تشخیص نرم‌افزار نقش داشته باشند. حتی امکان بررسی فایل‌های دیگر موجود در پوشه برنامه وجود داشت تا اصلاحات فقط روی نسخه‌ای اعمال شوند که مشکل داشت و نسخه‌های جدیدتر و سازگارتر را تحت تأثیر قرار ندهند.

پس از شناسایی برنامه‌های تعریف شده در بانک اطلاعاتی، ویندوز از راهکارهایی به نام Shim استفاده می‌کرد. این لایه‌های کوچک نرم‌افزاری بین برنامه و رابط‌های برنامه‌نویسی ویندوز قرار می‌گرفتند و می‌توانستند ورودی‌های برنامه را تغییر دهند، پاسخ متفاوتی به آن بدهند یا پیش از اجرای تابع اصلی ویندوز، کدهای دیگری را اجرا کنند.

برای مثال بعضی نرم‌افزارهای قدیمی فقط زمانی اجرا می‌شدند که نسخه مشخصی از ویندوز را تشخیص می‌دادند. مایکروسافت برای حل این مشکل از راهکاری به نام VersionLie استفاده می‌کرد که نسخه ویندوز را به شکل دلخواه برنامه گزارش می‌داد. به این ترتیب ممکن بود نرم‌افزار تصور کند روی ویندوز ۹۸ اجرا شده است، در حالی که سیستم‌عامل واقعی ویندوز XP بود.

مایکروسافت گاهی رفتار ویندوز ۹۵ را هم بازسازی می‌کرد

جعل شماره نسخه فقط بخشی از ماجرا بود. یکی از نمونه‌های جالبی که چن توضیح داده، راهکاری به نام EmulateHeap است. این سازوکار می‌توانست مدیر حافظه Heap ویندوز را برای یک برنامه با نسخه‌ای دقیقاً مشابه مدیر حافظه ویندوز ۹۵ جایگزین کند.

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

این رویکرد حتی پیش از ویندوز XP نیز وجود داشت. جوئل اسپالسکی، برنامه‌نویس سابق مایکروسافت، پیش‌تر توضیح داده بود که بازی SimCity از حافظه‌ای استفاده می‌کرد که پیش‌تر آزاد شده بود. ویندوز ۹۵ برای جلوگیری از بروز مشکل، کدی داشت که این بازی را شناسایی می‌کرد و مدیریت حافظه را به شکلی ویژه تغییر می‌داد تا حافظه آزادشده بلافاصله دوباره در اختیار بخش‌های دیگر قرار نگیرد.

چن از این شیوه با عنوان «سازگاری باگ‌به‌باگ» یاد کرده است. ایده اصلی این بود که اگر یک برنامه قدیمی به رفتار اشتباه یا مستند نشده‌ای از ویندوز وابسته شده باشد، تغییر آن رفتار در نسخه جدید می‌تواند نرم‌افزار را از کار بیندازد. در چنین شرایطی مایکروسافت گاهی ترجیح می‌داد همان رفتار قدیمی را برای آن برنامه حفظ کند و اصلاً مهم نبود که یک باگ باشد.

این سازگاری چه هزینه‌ای برای امنیت داشت؟

تغییر رفتار ویندوز برای اجرای نرم‌افزارهای قدیمی همیشه بدون هزینه نبود. چن در نوشته‌ای دیگر توضیح داده است که برخی حالت‌های سازگاری می‌توانند رفتارهای امنیتی نسخه‌های قدیمی‌تر ویندوز را حفظ کنند. برای نمونه حالت سازگاری ویندوز ۲۰۰۰ ممکن است باعث شود یک برنامه کتابخانه‌های DLL را مطابق قواعد همان سیستم‌عامل بارگذاری کند که با الزامات امنیتی جدید ویندوز هم‌خوانی ندارد.

با این حال راهکارهای موسوم به Shim محدودیت‌هایی هم داشتند. این اصلاحات در محدوده فرایند خود برنامه عمل می‌کردند و قرار نبود مرزهای امنیتی میان برنامه و سایر بخش‌های سیستم را تغییر دهند. علاه بر این چنین روش‌هایی نمی‌توانستند مشکل درایورهای ناسازگار در سطح هسته سیستم‌عامل را به همین شکل برطرف کنند.

مایکروسافت نیز نمی‌توانست تمام مشکلات نرم‌افزارهای قدیمی را با این روش حل کند. با این حال حفظ سازگاری برنامه‌ها آن‌قدر اهمیت داشت که این شرکت سال‌ها پس از عرضه ویندوز XP نیز اصلاحات جدیدی به پایگاه داده سازگاری آن اضافه می‌کرد. برای نمونه به‌روزرسانی آوریل ۲۰۱۱ این پایگاه داده را در ویندوز XP سرویس پک ۳ به‌روز و جایگزین کرد.

چرا مایکروسافت حاضر بود چنین زحمتی بکشد؟

دلیل اصلی این کار، جلوگیری از شکست ارتقای ویندوز در شرکت‌ها و سازمان‌ها بود. چن در نوشته‌ای مربوط به سال ۲۰۰۳ توضیح داده بود که هر برنامه ناسازگار می‌تواند بهانه‌ای برای کاربران باشد تا به نسخه جدید ویندوز مهاجرت نکنند. کافی بود یک نرم‌افزار حیاتی در یک اداره یا شرکت اجرا نشود تا کل فرایند ارتقای سیستم‌عامل زیر سؤال برود.

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

چن همچنین به بررسی داخلی مایکروسافت اشاره کرده بود که نشان می‌داد شرکت‌ها معمولاً دست‌کم یک برنامه حیاتی دارند که ناسازگاری آن می‌تواند مانع ارتقای سیستم‌عامل شود. در برخی موارد این نرم‌افزارها برنامه‌های داخلی نوشته‌شده با Visual Basic بودند که توسعه‌دهنده آن‌ها دیگر در شرکت حضور نداشت.

مایکروسافت برای مدیریت این اصلاحات بسیاری از راهکارهای سازگاری را در فایل‌های DLL موجود در پوشه AppPatch قرار داد تا مجبور نباشد فایل‌های اصلی سیستم‌عامل را برای هر اصلاح تغییر دهد. این شرکت همچنین سال‌ها به افزودن راهکارهای تازه ادامه داد.

در نهایت باید گفت بخشی از شهرت ویندوز XP در اجرای نرم‌افزارهای قدیمی نه فقط به کیفیت کدنویسی آن، بلکه به تلاش گسترده مایکروسافت برای سازگار نگه‌داشتن برنامه‌ها مربوط بود. پشت تجربه ساده‌ای که کاربر با دوبار کلیک روی یک بازی یا نرم‌افزار قدیمی داشت، گاهی سازوکاری قرار گرفته بود که ویندوز را برای همان برنامه تغییر می‌داد.