ریموند چن، مهندس سابق مایکروسافت و مورخ نیمه‌رسمی ویندوز، در وبلاگ Old New Thing خود به جزئیات جالبی از عملکرد ویندوز ۹۵ اشاره کرده است. به گفته او، این سیستم‌عامل قدیمی برای تشخیص برنامه‌های نصب‌کننده، به‌جای روش‌های پیشرفته، صرفاً نام فایل اجرایی را با فهرستی از کلمات خاص مقایسه می‌کرد.

چگونه ویندوز ۹۵ نصب‌کننده‌ها را «حدس» می‌زد؟

ویندوز ۹۵ برای اینکه متوجه شود یک فایل اجرایی یک نصب‌کننده است یا خیر، نام آن را با شش کلمه از پیش تعریف‌شده مقایسه می‌کرد: setup، install، inst، imposta، ayarla و felrak. سه کلمه آخر به ترتیب معادل‌های ایتالیایی، ترکی و مجارستانی بودند که خود چن آن‌ها را به لیست اضافه کرده بود.

جالب اینکه کلمه «install» عملاً زائد بود، زیرا هر نامی که شامل آن باشد، حتماً حاوی «inst» نیز هست. چن حدس می‌زند که «inst» بعداً برای پوشش نصب‌کننده‌هایی با نام‌هایی مانند blahinst اضافه شده، بدون اینکه ورودی قبلی حذف شود.

اگر نام فایل با هیچ‌کدام تطبیق نداشت، ویندوز ۹۵ بررسی می‌کرد که آیا کلمه «Setup» در مسیر کامل فایل (path) وجود دارد یا خیر. همچنین پس از نصب هر درایور مولتی‌مدیا از طریق یک فایل INF، یک بررسی جداگانه انجام می‌شد، زیرا این درایورها اغلب فایل‌های DLL سیستم را بازنویسی می‌کردند.

مکانیسم بازیابی فایل‌های سیستم

این روش ابتدایی برای فعال‌سازی یک مکانیسم بازیابی حیاتی به کار می‌رفت. در آن دوران، نصب‌کننده‌ها اغلب فایل‌های سیستم را بدون توجه به نسخه، بازنویسی می‌کردند. برای مثال، یک نصب‌کننده که حاوی نسخه‌های DLL مربوط به ویندوز ۳٫۱ بود، نسخه‌های جدیدتر ویندوز ۹۵ را زیر آن دفن می‌کرد و باعث خرابی سایر برنامه‌ها می‌شد.

ویندوز ۹۵ نسخه‌های پشتیبان این فایل‌های آسیب‌پذیر را در دایرکتوری مخفی C:\Windows\SYSBCKUP ذخیره می‌کرد. پس از اتمام هر نصب‌کننده، سیستم کار آن را بررسی کرده و در صورت لزوم، فایل‌های صحیح را بازیابی می‌کرد. این تور ایمنی کاملاً به تشخیص درست نصب‌کننده وابسته بود؛ بنابراین یک برنامه معمولی با نام instant.exe به اشتباه فعال می‌شد، در حالی که یک نصب‌کننده با نام غیرمعمول از آن عبور می‌کرد.

تصویری از دسکتاپ ویندوز ۹۵

تعویق بررسی تا راه‌اندازی مجدد

چن توضیح می‌دهد که بررسی فایل‌ها اغلب تا بوت بعدی به تعویق می‌افتاد. دلیل این کار این بود که برخی نصب‌کننده‌ها نمی‌توانستند فایل‌های در حال استفاده را جایگزین کنند؛ بنابراین به MS-DOS بازمی‌گشتند، یک فایل بچ اجرا کرده و ویندوز را ری‌استارت می‌کردند. در نتیجه، عملیات پاک‌سازی باید تا پس از راه‌اندازی مجدد صبر می‌کرد تا تغییرات اعمال‌شده توسط فایل بچ را شناسایی کند.

تکامل محافظت از فایل در ویندوز

این روش ابتدایی در ویندوز ۲۰۰۰ کنار گذاشته شد. مایکروسافت در آن نسخه Windows File Protection (WFP) را معرفی کرد که از طریق اعلان‌های تغییر فایل (file change notifications) و یک حافظه نهان در %WinDir%\System32\dllcache کار می‌کرد. دیگر خبری از حدس زدن نام فایل یا انتظار برای اتمام نصب نبود.

نمایی از خط فرمان ویندوز با دستور sfc /scannow

پس از آن، ویندوز ME با System File Protection مشابهی عرضه شد و از ویندوز ویستا به بعد، Windows Resource Protection (WRP) با استفاده از لیست‌های کنترل دسترسی (ACL) جایگزین آن شد. دستور sfc /scannow که امروزه نیز در ویندوز ۱۱ برای تعمیر فایل‌های سیستم استفاده می‌شود، ریشه در همین تکامل دارد و جایگزین مکانیسم ساده‌ای شده است که در سال ۱۹۹۵ با جستجوی کلمه «setup» در نام فایل‌ها تصمیم‌گیری می‌کرد.

نتیجه‌گیری

این داستان جذاب نشان می‌دهد که حتی در سیستم‌عامل‌های بزرگ و پرکاربردی مانند ویندوز، گاهی از روش‌های بسیار ساده و ابتدایی برای حل مسائل پیچیده استفاده می‌شود. هرچند این روش‌ها کامل نبودند، اما در زمان خود راه‌حلی مؤثر ارائه می‌دادند و پایه‌گذار سیستم‌های پیشرفته‌تری شدند که امروزه از آن‌ها بهره می‌بریم.