در اعماق کدهای منبع ویندوز 95، یکی از پراستفادهترین نرمافزارهای تاریخ، قطعه کد کوچکی وجود دارد که تنها یک وظیفه بر عهده دارد: پرسیدن یک سؤال عجیب و بسیار خاص. این کد، استراتژی سازگاری ویندوز با گذشته را به بهترین شکل به تصویر میکشد و نشان میدهد که چگونه یک تصمیم هوشمندانه میتواند به سلطه یک شرکت در بازار فناوری منجر شود. سؤال این بود: آیا کاربر در حال اجرای بازی سیمسیتی (SimCity) است؟
اگر پاسخ مثبت بود، ویندوز 95 بیسروصدا رفتار خود را تغییر میداد و مدیریت حافظه خود را به یک حالت ویژه منتقل میکرد. این کار تنها به یک دلیل انجام میشد: کنار آمدن با یک باگ! این باگ نه در خود ویندوز، بلکه یک باگ در بازی سیمسیتی بود که سالها قبل به طور تصادفی توسط برنامهنویس خود بازی در آن جا مانده بود.
این یکی از عجیبترین و در عین حال آموزندهترین تصمیمها در تاریخ رایانههای شخصی است و نکته مهمی را درباره دلیل سلطه ویندوز بر جهان توضیح میدهد. با ما در دیجی رو همراه باشید.
باگی که قرار نبود مهم باشد
این داستان از زبان جوئل اسپولسکی (Joel Spolsky)، برنامهنویس سابق مایکروسافت، یکی از بنیانگذاران استک اورفلو (Stack Overflow) و از نویسندگان معتبر در حوزه نرمافزار، نقل شده است. او این ماجرا را مستقیماً از شخصی شنیده بود که مسئول این اتفاق بود.
جان راس (Jon Ross) نسخه اصلی بازی محبوب و بسیار موفق شهرسازی، یعنی سیمسیتی را برای ویندوز نوشته بود. راس در حین نوشتن کد، مرتکب اشتباه کوچکی شد. کد او در یک نقطه، بخشی از حافظه کامپیوتر را آزاد میکرد (یعنی آن را به سیستم عامل بازمیگرداند و اعلام میکرد که دیگر به آن نیازی ندارد) و لحظهای بعد، دوباره از همان بخش از حافظه برای خواندن اطلاعات استفاده میکرد.
این یک خطای برنامهنویسی کاملاً آشنا است و نام مشخصی هم دارد: باگ «استفاده پس از آزادسازی». شما نباید از حافظهای که قبلاً آن را پس دادهاید، دوباره استفاده کنید. این کار در دنیای نرمافزار مانند این است که از یک اتاق هتل تسویه حساب کنید و خارج شوید، اما چند دقیقه بعد دوباره به اتاق برگردید تا از حمام آن استفاده کنید!
اما نکته اینجا بود: در ویندوز 3.x (سیستم عاملی که سیمسیتی برای آن ساخته شده بود) این باگ هیچ اهمیتی نداشت. وقتی سیمسیتی آن حافظه را آزاد میکرد، ویندوز 3.x به سادگی آن را دستنخورده رها میکرد. بنابراین، هنگامی که سیمسیتی به اشتباه دوباره آن را میخواند، دادهها هنوز دقیقاً مانند قبل در آنجا وجود داشتند. باگ کاملاً وجود داشت، اما رفتار سیستم عامل به طور اتفاقی آن را بیضرر کرده بود. بازی سیمسیتی منتشر شد، بیش از پنج میلیون نسخه فروخت و هیچکس هرگز از این موضوع خبردار نشد.
این باگ برای سالها در سکوت کامل، درون یکی از محبوبترین بازیهای جهان، کاملاً نامرئی باقی ماند.
تا اینکه مایکروسافت یک سیستم عامل جدید ساخت.
وقتی سیمسیتی از کار افتاد؛ چالشی برای سازگاری ویندوز با گذشته
ویندوز 95 یک جهش بزرگ رو به جلو بود. این سیستم عامل دنیای MS-DOS و ویندوز را با هم ادغام کرد، از نرمافزارهای 16 بیتی به 32 بیتی مهاجرت کرد و مقادیر عظیمی از نحوه کار سیستم در پشت صحنه را (از جمله نحوه مدیریت حافظه) کاملاً بازسازی کرد.
در طول آزمایش نسخه بتای ویندوز 95 در سالهای 1994 و 1995، مهندسان مایکروسافت با یک مشکل بزرگ مواجه شدند. سیمسیتی که یکی از پرفروشترین و محبوبترین بازیهای کامپیوتری آن زمان بود، روی ویندوز 95 کار نمیکرد. بازی به سادگی از کار میافتاد و کِرَش میکرد.
وقتی مهندسان علت را ردیابی کردند، به همان باگ قدیمی «استفاده پس از آزادسازی» که توسط جان راس ایجاد شده بود، رسیدند. ویندوز 95 حافظه آزاد شده را متفاوت از ویندوز 3.x مدیریت میکرد. هنگامی که سیمسیتی آن بخش از حافظه را آزاد میکرد، ویندوز 95 بلافاصله آن را بازپس میگرفت و برای کار دیگری استفاده میکرد. بنابراین، وقتی سیمسیتی دوباره تلاش میکرد از آن حافظه بخواند، دادهها یا از بین رفته بودند یا به هم ریخته بودند و در نتیجه، بازی از کار میافتاد.
این اتفاق، مایکروسافت را در برابر یک تصمیم سرنوشتساز قرار داد و تصمیمی که آنها گرفتند، بخش جالب ماجراست.
چرا مایکروسافت باگ شخص دیگری را اصلاح کرد؟
حرکت واضح و منطقی این بود که تلفن را بردارند، با استودیوی مکسیس (Maxis)، سازنده سیمسیتی، تماس بگیرند و به آنها بگویند که باگ خود را برطرف کرده و یک بهروزرسانی برای بازی منتشر کنند.
اما مایکروسافت این کار را نکرد. در عوض، مهندسان این شرکت کدی را مستقیماً به ویندوز 95 اضافه کردند؛ کدی که به طور خاص تشخیص میداد چه زمانی سیمسیتی در حال اجراست. هنگامی که ویندوز این بازی را شناسایی میکرد، تخصیص دهنده حافظه خود را به یک حالت ویژه تغییر میداد که حافظه آزاد شده را فوراً بازپس نمیگرفت. در واقع، ویندوز 95 عمداً رفتار قدیمی و اشتباه ویندوز 3.x را بازسازی میکرد، اما فقط برای سیمسیتی و فقط به این دلیل که سیمسیتی به آن نیاز داشت.
به عبارت دیگر، مایکروسافت تصمیم گرفت سیستم عامل کاملاً جدید خود را حول یک اشتباه چند ساله در محصول شخص دیگری، انعطافپذیر کند. آنها سیستم عامل را مجبور کردند تا با آن باگ کنار بیاید. این یک نمونه درخشان از تعهد به سازگاری ویندوز با گذشته بود.
چرا؟ به دلیل یک منطق تجاری بیرحمانه که اسپولسکی آن را به وضوح بیان میکند:
وقتی یک شخص سیستم عامل جدیدی میخرد و نرمافزار مورد علاقهاش دیگر کار نمیکند، او نرمافزار را سرزنش نمیکند؛ او سیستم عامل را مقصر میداند! مشتری فکر نمیکند که «سیمسیتی باگ دارد». مشتری فکر میکند «ویندوز 95 بازی من را خراب کرد» و به دوستانش میگوید که سیستم عامل خود را ارتقا ندهند.
برای مایکروسافت، هر برنامه محبوبی که روی ویندوز 95 خراب میشد، دلیلی بود برای میلیونها نفر که ویندوز 95 را نخرند. سیمسیتی بیش از 5 میلیون نسخه فروخته بود. این یعنی 5 میلیون مشتری بالقوه که اولین تجربه آنها از سیستم عامل جدید میتوانست کرش کردن بازی مورد علاقهشان باشد. هزینه نوشتن یک بلوک کد کوچک برای این مورد خاص تقریباً هیچ بود، اما هزینه کار نکردن سیمسیتی میتوانست بسیار هنگفت باشد.
بنابراین، مایکروسافت کار غیر معقول اما کم هزینهتر را انجام داد. آنها کاری کردند که بازی به هر قیمتی کار کند.
موزه پنهان در دل ویندوز؛ اوج سازگاری ویندوز با گذشته
این چیزی است که اکثر مردم متوجه آن نمیشوند. راهحل سیمسیتی یک مورد منحصربهفرد نیست. این تنها یک نمونه از کاری است که ویندوز دهههاست در سکوت انجام میدهد.
در اعماق ویندوز، صدها مورد از این موارد خاص پنهان شده است؛ بلوکهای کوچکی از کد که برنامهها و بازیهای قدیمی خاصی را شناسایی کرده و بیسروصدا رفتار سیستم را برای ادامه کار آنها تنظیم میکنند! مهندسان این کدها را «شیم» (Shim) مینامند.
شیم (Shim) چیست؟
در مهندسی نرمافزار، «شیم» یک لایه کد کوچک است که به عنوان واسطه عمل میکند. وظیفه آن رهگیری فراخوانیهای API (رابط برنامهنویسی نرمافزار)، مدیریت پارامترها یا انجام عملیات اضافی است تا یک نرمافزار قدیمی بتواند روی یک سیستم عامل جدیدتر به درستی کار کند. در واقع، شیم مانند یک مترجم یا آداپتور عمل میکند که زبان قدیمی برنامه را به زبان جدید سیستم عامل تبدیل میکند تا از بروز خطا جلوگیری شود.
بازیهای دیگری نیز به همین شکل شناسایی و پشتیبانی شدهاند. به برخی از آنها گفته میشود که روی نسخه قدیمیتری از ویندوز در حال اجرا هستند، زیرا در غیر این صورت دچار مشکل میشوند. به برخی دیگر اطلاعات کمی نادرست داده میشود یا ویژگیهای خاصی در ارتباط با آنها غیرفعال میشود، صرفاً برای اینکه به کار خود ادامه دهند.
ویندوز، به معنای واقعی کلمه، یک موزه پنهان از سازگاری را در خود جای داده است؛ یک لایه وسیع و عمدتاً نامرئی از کد که تمام وظیفهاش زنده نگه داشتن نرمافزارهای قدیمی بر روی کامپیوترهای امروزی است. این استراتژی سازگاری ویندوز با گذشته در عمل است.
به همین دلیل است که برنامهای که در دهه 1990 نوشته شده، اغلب هنوز هم روی یک کامپیوتر مدرن ویندوزی اجرا میشود. این اتفاقی نیست. این نتیجه انباشته شدن دههها تلاش مهندسان مایکروسافت است که دقیقاً همان تصمیمی را گرفتند که برای سیمسیتی گرفته بودند: نرمافزارهای قدیمی را، حتی با وجود اشتباهاتشان، در آغوش بگیرید، به جای آنکه آنها را در هم بشکنید.
چرا این داستان به ظاهر کوچک اینقدر اهمیت دارد؟
شاید این داستان در نگاه اول فقط یک نکته جالب و سرگرم کننده به نظر برسد، اما چیزی فراتر از آن است.
ماجرای سیمسیتی، مهمترین و در عین حال نامرئیترین دلیلی را که باعث شد ویندوز به چنین سلطهای دست یابد، به تصویر میکشد. این موفقیت هرگز فقط به خاطر ویژگیها یا بازاریابی نبود. بلکه به خاطر یک تعهد تقریباً وسواسگونه و عمیقاً غیرجذاب به «سازگاری با نسخههای قدیمی» بود؛ قولی که در طول دههها حفظ شد: چیزهایی که قبلاً خریدهاید، به کار خود ادامه خواهند داد.
جان راس در اوایل دهه 1990 مرتکب اشتباه کوچکی شد. به لطف تصمیم مهندسان مایکروسافت، آن اشتباه هرگز باعث خرابی چیزی برای کسی نشد. آن باگ به سادگی و در سکوت، توسط خود سیستم عامل حل شد و نسخهای از همان وسواس فکری برای حفظ سازگاری ویندوز با گذشته، هنوز هم در ویندوز امروزی در حال کار است.
آن باگ هنوز وجود دارد. کدی که آن را برطرف میکند نیز همینطور. این داستان به ما یادآوری میکند که گاهی اوقات، بهترین راه برای ساختن آینده، احترام گذاشتن و حمایت از گذشته است؛ حتی اگر آن گذشته، کمی باگ داشته باشد.
