افتح نافذة الأوامر في أي جهاز يعمل بنظام Windows 11 واكتب الأمر ver، وسوف تجد أن النظام يعرف نفسه برقم يبدأ بـ 10.0، ثم افتح مدير المهام Task Manager وابحث عن العملية التي اسمها System، وإذا تتبعت ملفها فسوف تصل إلى C:\Windows\System32\ntoskrnl.exe. والحرفان NT في اسم هذا الملف ليسا صدفة، فهما بقايا مشروع بدأ في نهاية 1988 بسبعة أشخاص فقط، ستة منهم جاؤوا من شركة أخرى بعد أن ألغت مشروعهم، وكان يقودهم مهندس لم يلمس حاسباً واحداً حتى تخرج من الجامعة. هذا المهندس هو ديف كتلر Dave Cutler، والمشروع هو Windows NT، والنواة Kernel التي كتبها فريقه هي نفسها التي تشغل اليوم جهازك المحمول وسيرفرات Windows Server وأجزاء من منصة Azure.
وقد تتساءل: لماذا يهمني كمطور أو مدير أنظمة أن أعرف من كتب نواة Windows؟ والإجابة أن كثيراً مما تراه في Windows اليوم، من رسالة الشاشة الزرقاء التي تذكر IRQL_NOT_LESS_OR_EQUAL، إلى صلاحيات الملفات في NTFS، إلى قدرة النظام على تشغيل برامج Linux في WSL، هو نتيجة قرارات اتخذها هذا الفريق قبل أكثر من خمس وثلاثين سنة، وفهم تلك القرارات يفسر لك لماذا يعمل النظام بهذا الشكل. وفي قصة Unix وLinux التي تعرفها جيداً قصة موازية تماماً لنظام صمم في شركة تجارية بميزانية ضخمة وفريق صارم، وكلا الطريقين وصل إلى مليارات الأجهزة.
وكل ما في هذا المقال مأخوذ من مصادر منشورة يمكنك الرجوع إليها: سيرة كتلر في متحف تاريخ الحاسب Computer History Museum الذي اختاره زميلاً Fellow في 2016، ومقال Microsoft الطويل عنه «The engineer's engineer» الذي جمع شهادات من عملوا معه، ومحاضرة Mark Lucovsky في مؤتمر USENIX وهو أحد السبعة الأوائل في الفريق، وتقرير صحيفة Seattle Times في مايو 1993 قبل صدور النظام بأسابيع، ووثائق Microsoft Learn الحالية عن معمارية النواة. ومن يريد القصة كاملة بتفاصيلها اليومية فقد كتبها الصحفي G. Pascal Zachary في كتاب Show Stopper! الصادر في 1994، وهو الكتاب الذي تابع الفريق خمس سنوات من الداخل.
وسوف نناقش في هذا المقال ما يلي:
- البدايات: من DuPont إلى شركة DEC، ونظاما RSX-11M وVMS اللذان صنعا اسم كتلر.
- إلغاء مشروع Prism وMica في 1988، ولماذا انتقل كتلر وفريقه إلى Microsoft.
- كيف بدأ NT: مواصفات مكتوبة قبل الكود، ومعالج لم يصل في موعده، وتحول من OS/2 إلى Windows في منتصف الطريق.
- الأفكار التصميمية التي وضعها كتلر في النواة: الأهداف المرتبة، وطبقة HAL، ومدير الكائنات، والأنظمة الفرعية.
- ثقافة الجودة وثمنها على الفريق، وصدور NT 3.1 في يوليو 1993.
- ما فعله كتلر بعد NT، وما الذي بقي من تصميمه داخل Windows 11، وماذا نتعلم من القصة.
والصورة التالية تجمع المحطات التي سوف نمر عليها:
من DuPont إلى DEC: مبرمج بدأ متأخراً
ولد David Neil Cutler في 1942 في مدينة Lansing بولاية Michigan الأمريكية، ونشأ في بيئة ريفية بسيطة، فوالده كان يعمل عامل نظافة في مبنى ووالدته في وظائف حكومية، كما ذكرت Seattle Times في تقريرها عنه. وكان رياضياً في المدرسة أكثر منه طالب علوم، ودخل كلية Olivet الصغيرة بمنحة، وتخرج فيها في 1965 بتخصص الرياضيات والفيزياء، ولاحظ هنا أنه، كما يقول ملخص مقابلته الطويلة في متحف تاريخ الحاسب، لم يلمس حاسباً واحداً طوال سنوات الدراسة.
بعد التخرج عمل في شركة الكيماويات DuPont، وهناك بدأ يكتب برامج التحكم في العمليات الصناعية Process Control التي تعمل في الزمن الحقيقي Real-Time، أي برامج يجب أن ترد على حدث في المصنع خلال وقت محدد وإلا فسد المنتج أو توقف خط الإنتاج. وهذا النوع من البرمجة يعلمك شيئاً لا تعلمه برامج المكاتب: أن البرنامج الذي يعمل «في أغلب الأوقات» برنامج فاشل، لأن المصنع لا ينتظر إعادة التشغيل. وسوف ترى هذه الفكرة تتكرر في كل ما بناه كتلر لاحقاً.
وفي 1971 انتقل إلى شركة Digital Equipment Corporation واختصاراً DEC، وهي في ذلك الوقت من أكبر شركات الحواسيب الصغيرة Minicomputers في العالم، وكانت حواسيبها من سلسلة PDP-11 منتشرة في الجامعات والمصانع والمختبرات. وعلى PDP-11 كتب نظام التشغيل RSX-11M، وهو نظام للزمن الحقيقي يشغل عدة برامج معاً على جهاز ذاكرته صغيرة جداً بمقاييس اليوم. ويذكر مقال Microsoft أنه كان قد قضى أربع سنوات في DEC يبني أنظمة الزمن الحقيقي لـ PDP-11 عندما جاءته المهمة التي صنعت اسمه.
VMS والحاسب VAX: نظام التشغيل Operating System الذي صنع اسمه
في منتصف السبعينيات كانت DEC تعمل على جيل جديد من حواسيبها بمعالج 32 بت ومساحة عناوين أكبر بكثير من PDP-11، وهو الجيل الذي سمته VAX. وطلب Gordon Bell، نائب رئيس الهندسة في الشركة وأحد أشهر مصممي الحواسيب في تلك الفترة، من كتلر وعمره 33 سنة أن يقود تطوير نظام التشغيل لهذا الجهاز، وكان كتلر المبرمج الأول في فريق من خمسة مهندسين كبار. وكان كتلر أيضاً واحداً من فريق من ستة أشخاص صمموا معمارية VAX نفسها، كما تذكر سيرته في متحف تاريخ الحاسب، أي أنه شارك في تصميم العتاد والنظام الذي يعمل عليه معاً، وهذا نادر حتى اليوم.
والنتيجة كانت الحاسب VAX-11/780 الذي يؤرخه سجل متحف تاريخ الحاسب بسنة 1977، ومعه نظام التشغيل VAX/VMS، واختصار VMS هو Virtual Memory System، أي أن النظام بني من البداية حول الذاكرة الافتراضية Virtual Memory التي شرحناها في مقال الذاكرة الافتراضية وجداول الصفحات، بحيث يرى كل برنامج مساحة عناوين خاصة به ولا يستطيع أن يكتب في ذاكرة غيره. ونجح VAX مع VMS نجاحاً كبيراً في الجامعات والبنوك والمؤسسات الحكومية خلال الثمانينيات، وقال Gordon Bell لاحقاً إن كتلر هو «أفضل كاتب أنظمة تشغيل في العالم».
ولم يكن VMS نظاماً عابراً، فقد انتقل من VAX إلى معالجات Alpha ثم Itanium، وما زال حياً حتى اليوم باسم OpenVMS، حيث نقلته شركة VMS Software إلى معالجات x86-64 وأصدرت النسخة V9.2 للإنتاج في 2022 كما نشرت The Register، ما يعني أن نظاماً بدأ كتلر تصميمه في السبعينيات ما زال يشغل أنظمة في البنوك والمصانع بعد قرابة خمسين سنة. وهذا أول درس في القصة: قرارات التصميم الأولى في نظام التشغيل تعيش أطول بكثير مما يتوقع من اتخذها.
وفي DEC قاد كتلر أيضاً فريقاً كتب مترجمات Compilers للغتي PL/I وC، ويذكر مقال Microsoft أنه كتب الجزء الخلفي Backend من مترجم PL/I، أي الجزء الذي يحول البرنامج إلى تعليمات الجهاز، وهذا يفسر لماذا كان يفكر دائماً في النظام كله، من التعليمة التي ينفذها المعالج إلى الواجهة التي يراها المبرمج.
DECwest ثم Prism ثم Mica: مشروع ألغي بعد سنوات
في بداية الثمانينيات ضاق كتلر بالبيروقراطية في المقر الرئيسي لشركة DEC في ولاية Massachusetts، وأعلن أنه يريد ترك الشركة. ولكن Gordon Bell قدم له عرضاً مختلفاً: أن يؤسس معملاً هندسياً خاصاً بعيداً عن المقر. وهكذا ولد معمل DECwest في Bellevue بولاية Washington، على بعد أكثر من 3,000 ميل من المقر، كما يروي مقال Microsoft، بينما تؤرخ سيرة المتحف تأسيس المعمل بسنة 1981. وفي هذا المعمل صمم الفريق الحاسب MicroVAX I، وكتب كتلر بنفسه الشيفرة الدقيقة Microcode الخاصة به.
ثم جاء المشروع الكبير: معمارية جديدة اسمها Prism مبنية على فكرة المعالجات ذات التعليمات المختصرة RISC التي كانت تنتشر في تلك الفترة، ومعها نظام تشغيل جديد اسمه Mica يفترض أن يكون خليفة VMS. وعمل فريق كتلر على هذا المشروع ثلاث سنوات تقريباً، ثم ألغته إدارة DEC في 1988، وفضلت الاعتماد على معالجات MIPS في محطات العمل. وتنقل Seattle Times أن كتلر أعطى فريقه في Bellevue، وكانوا قرابة 200 شخص، إجازة شهر بعد الإلغاء دون موافقة ظاهرة من المقر.
تخيل أنك قضيت ثلاث سنوات تبني نظاماً تؤمن به، ثم يلغيه قرار إداري في مكان بعيد عنك. هذا الموقف يتكرر في الشركات أكثر مما نحب أن نعترف، والفرق في قصة كتلر أن ما تعلمه الفريق في Mica لم يضع، وإنما انتقل مع الأشخاص أنفسهم إلى شركة أخرى. وقد قال كتلر في حديث مع مجلة UnixWorld نقلته الصحيفة: «إذا كان هناك شيء واحد أريد أن أفعله فهو أن أهزم DEC».
Microsoft في 1988: فريق صغير وورقة بيضاء
في تلك الفترة كانت Microsoft شركة نظام MS-DOS، وكانت تعمل مع IBM على نظام OS/2 الذي كان يفترض أن يكون مستقبل الحواسيب الشخصية، ولكن OS/2 في نسخته الأولى كان نظاماً 16 بت يعمل على معالجات Intel فقط. وكان Bill Gates يريد نظاماً حديثاً مختلفاً يمكن أن يعمل على أكثر من معالج وأن يصلح للسيرفرات ومحطات العمل، فتفاوض مع كتلر، وبدأ كتلر العمل في Microsoft في 31 أكتوبر 1988.
ولم يأت وحده، فقد تبعه Rob Short وعدد من مهندسي DECwest، منهم خمسة متخصصون في البرمجيات وستة في العتاد. ويروي Darryl Havens، أحدهم، في مقال Microsoft أنهم قدموا استقالاتهم لشركة DEC يوم جمعة وبدأوا العمل في Microsoft يوم الاثنين التالي. والموظف الوحيد من Microsoft نفسها في الفريق الأول كان Steve Wood. وتلخص شريحة من محاضرة Mark Lucovsky البداية في أسطر قليلة: تشكل الفريق في نوفمبر 1988، ستة من DEC وواحد من Microsoft، والهدف نظام تشغيل متقدم للحواسيب الشخصية يصلح للمكتب والسيرفر، آمن ويعمل على عدة معالجات Symmetric Multiprocessing واختصاراً SMP، وكل الكود جديد. وفي نفس الشريحة جملة يحبها كل من عمل في مشروع برمجي كبير: «الجدول الزمني 18 شهراً، ولم نتأخر عنه إلا ثلاث سنوات».
المواصفات Specifications قبل الكود
أول ما فعله الفريق لم يكن كتابة الكود، فقد قضوا قرابة ستة أشهر في كتابة المواصفات، وبدأت كتابة الكود في أوائل 1989، حيث يؤرخها مقال Microsoft بشهر أبريل وتؤرخها شرائح Lucovsky بشهر فبراير. وكانت هذه المواصفات تجمع في ملف عرف باسم NT OS/2 Design Workbook، ويصفه Lucovsky في شريحة خاصة بأنه وثيقة كتبها المهندسون للمهندسين، وأن كل واجهة وظيفية في الجزء التنفيذي من النظام عرفت فيه وروجعت قبل أن تكتب.
وقد يبدو لك هذا بطيئاً، ولكن انظر إلى النتيجة: يقول Darryl Havens إنه كتب نظام الإدخال والإخراج I/O System كاملاً في ثلاثة أسابيع، لأن المواصفة كانت كاملة لدرجة أنه كان «يطبعها» فقط. ولاحظ أن Lucovsky نفسه يضيف تحذيراً مهماً في نفس الشريحة: هذه الطريقة تعمل بكفاءة في الفرق الصغيرة، ولكن جعلها تعمل مع فريق كبير شبه مستحيل، لأن كبار المطورين يغرقون في مراجعة المواصفات وتفقد ملاحظاتهم قيمتها، فيجب توزيع المراجعة على الجميع، ويجب أن يشترك الجميع في نفس الثقافة.
معالج i860 والمحاكي Simulator: لماذا بدأوا بعيداً عن Intel x86؟
القرار الذي يفاجئ أغلب من يسمع القصة أن الفريق لم يبدأ على معالج Intel x86 الذي تعمل عليه كل الحواسيب الشخصية، وإنما على معالج Intel آخر من نوع RISC اسمه i860 واسمه الداخلي N10. وتذكر شريحة Lucovsky عن تاريخ NT أن اسم NT نفسه كان تلاعباً بين N-Ten والتقنية الجديدة New Technology. والمشكلة أن المعالج لم يكن متوفراً بعد، فكان أغلب التطوير يجري على محاكي Simulator لمعالج i860 يعمل فوق OS/2 1.2، وكل تشغيل للنظام على المحاكي يأخذ قرابة 30 دقيقة. ثم صنعت Microsoft لوحة حاسب خاصة بمعالج i860 اسمها Dazzle، وشغل الفريق عليها النواة وإدارة الذاكرة كاملة، وكان المترجم من شركة Metaware، تصل تحديثاته أسبوعياً، وكتب الفريق بنفسه رابطاً Linker لصيغة PE/COFF ومنقح أخطاء Debugger رسومياً.
ولماذا كل هذا العناء؟ الإجابة في شريحة الأهداف: «بدأنا نقل النظام إلى i386 متأخراً جداً عن قصد، حتى لا نقع في التصميم المعتاد في Microsoft الذي يتمحور حول x86». أي أن العمل على معالج آخر كان وسيلة لإجبار الفريق على كتابة كود لا يفترض شكل معالج معين. ثم انتقل الفريق لاحقاً من i860 إلى معالج MIPS، وكان NT 3.1 عند صدوره يعمل على x86 وMIPS، ثم أضيف معالج Alpha الخاص بشركة DEC نفسها، والذي أعلنت DEC في 1993 أنها سوف تشغل NT عليه، كما ذكرت Seattle Times. وهي مفارقة واضحة: الشركة التي ألغت مشروع كتلر صارت تبيع أجهزتها بنظامه الجديد.
الأهداف قبل الكود: قابلية النقل Portability والموثوقية Reliability
أول عمل قام به الفريق بعد تشكله، كما يقول Lucovsky، كان كتابة الأهداف العليا للنظام، ثم ترتيبها. وكانت خمسة أهداف بالترتيب التالي:
- قابلية النقل Portability: أن يعمل النظام على أكثر من نوع من المعالجات، وأن يتجنب لغة التجميع Assembly قدر الإمكان، وأن يعزل كل ما يخص الجهاز في مكان واحد.
- الموثوقية Reliability: «لا شيء يجب أن يستطيع إيقاع النظام، وأي شيء يوقعه هو خطأ برمجي Bug». ويعلق Lucovsky بأن هذا كان تفكيراً جذرياً داخل Microsoft، لأن Windows في ذلك الوقت (Win16) كان يشغل كل البرامج في مساحة عناوين واحدة بتعدد مهام تعاوني Cooperative Multitasking، أي أن أي برنامج سيئ يستطيع أن يوقف الجهاز كله.
- قابلية التوسع Extensibility: أن يمكن إضافة قدرات للنظام مع الوقت دون إعادة كتابته.
- التوافق Compatibility: مع برامج DOS وOS/2 وPOSIX وأي بيئة تشغيل شائعة أخرى. ويقول Lucovsky إن هذا الهدف هو الذي سمح لهم «باختراع Windows» بعد سنتين من بداية تطوير NT OS/2، وسوف نعود إلى هذه الجملة بعد قليل.
- الأداء Performance: «كل ما سبق أهم من السرعة الخام».
ولاحظ أن ترتيب الأهداف هنا هو القرار الحقيقي، وليس الأهداف نفسها، فكل فريق يريد نظاماً سريعاً وموثوقاً وقابلاً للنقل، ولكن عندما يتعارض هدفان، وهما يتعارضان كل يوم، يجب أن يعرف كل مهندس في الفريق أيهما يقدم دون أن يسأل مديره. فإذا كان تحسين سرعة دالة يتطلب افتراض شكل معالج معين، فالإجابة معروفة مسبقاً: قابلية النقل أولاً. ويقول Lucovsky في شريحة ثقافة NT إن كل قرار في الفريق كان يتخذ في سياق هذه الأهداف. وقد شرحنا في مقال ما هو نظام التشغيل أن نظام التشغيل يقف بين البرامج والعتاد، وهنا ترى كيف تتحول هذه الوظيفة إلى قرارات يومية.
كيف صمم Cutler النواة Kernel؟
كتب Bill Gates في خطاب ترشيح كتلر لوسام التقنية الأمريكي، الذي نقله مقال Microsoft، أن كتلر «كان المصمم الرئيسي لبنية الطبقات Layering في النظام». والصورة التالية تبين هذه الطبقات كما تشرحها اليوم وثيقة Overview of Windows Components في Microsoft Learn:
وفيما يلي أهم الأفكار في هذا التصميم، وكلها ما زالت موجودة:
طبقة تجريد العتاد HAL
هدف قابلية النقل يحتاج مكاناً واحداً يعزل فيه كل ما يختلف بين جهاز وآخر: طريقة التعامل مع المقاطعات Interrupts، والمؤقتات، وتفاصيل اللوحة الأم. وهذا المكان هو طبقة تجريد العتاد Hardware Abstraction Layer واختصاراً HAL، وهي ما زالت موثقة اليوم في Windows Kernel-Mode HAL Library. والفكرة أن النواة وبرامج التشغيل Drivers لا تكلم العتاد مباشرة في هذه النقاط، وإنما تطلب من HAL، فإذا انتقلت إلى جهاز مختلف فأنت تكتب HAL جديدة ولا تعيد كتابة النظام. وهذا هو ما سمح لنفس النظام أن يعمل على x86 وMIPS وAlpha وPowerPC في التسعينيات، ثم على x64 وARM64 اليوم.
ومن نفس الفكرة جاءت مستويات أولوية المقاطعات IRQL، وهي أرقام تحدد في أي مستوى يعمل الكود الآن، وما الذي يسمح له بفعله. فالكود الذي يعمل في مستوى DISPATCH_LEVEL مثلاً لا يجوز له أن ينتظر أو أن يلمس ذاكرة يمكن أن تكون مخزنة على القرص، كما تشرح وثيقة Managing Hardware Priorities. وإذا رأيت يوماً شاشة زرقاء مكتوباً فيها IRQL_NOT_LESS_OR_EQUAL فهذا برنامج تشغيل خالف هذه القاعدة، والقاعدة نفسها عمرها من عمر NT.
مدير الكائنات Object Manager والأمان Security
في NT كل شيء تقريباً يديره النظام هو كائن Object: الملف، والعملية Process، والخيط Thread، ومفتاح الريجستري Registry، والحدث Event الذي تنتظره البرامج. ويعطى البرنامج مقبضاً Handle للكائن، ويمر كل طلب لفتح كائن عبر مدير الكائنات Object Manager، والذي يسأل بدوره مراقب الأمان Security Reference Monitor: هل يسمح لهذا المستخدم بهذا النوع من الوصول؟ والإجابة تأتي من قائمة صلاحيات Access Control List مرتبطة بالكائن.
والفائدة من هذا التوحيد أن الأمان لا يكتب مرة لكل نوع من الموارد، وإنما في مكان واحد يمر عليه الجميع، وهي نفس فكرة «كل شيء ملف» في Unix ولكن بشكل مختلف: هناك الواجهة الموحدة هي الملف، وهنا الواجهة الموحدة هي الكائن مع قائمة صلاحيات. ويذكر مقال Microsoft أن الأمان كان هدفاً من البداية، حيث أريد للنظام أن يكون آمناً بما يكفي لشهادة الأمان الحكومية الأمريكية من مستوى C2، وهذا شيء لم يكن في MS-DOS ولا في Windows 3.x إطلاقاً.
ونظام الإدخال والإخراج بني بنفس الروح، فكل عملية قراءة أو كتابة تتحول إلى حزمة طلب اسمها I/O Request Packet واختصاراً IRP، تمر عبر سلسلة من برامج التشغيل فوق بعضها، فبرنامج تشغيل نظام الملفات يمرر الطلب إلى برنامج تشغيل القرص، ويمكن أن يدخل بينهما برنامج آخر مثل برنامج مكافحة الفيروسات أو التشفير. وهذا هو النظام الذي يقول Havens إنه كتبه في ثلاثة أسابيع من المواصفة.
الأنظمة الفرعية Environment Subsystems: من OS/2 إلى Win32
هدف التوافق قاد إلى فكرة ذكية: النواة لا تقدم واجهة نظام تشغيل معين، وإنما تقدم خدمات عامة، وفوقها في وضع المستخدم User Mode تعمل أنظمة فرعية Environment Subsystems، كل منها يقدم للبرامج «شخصية» نظام تشغيل مختلف. ويقول Bill Gates في خطابه إن NT صمم في 1989 ليكون متوافقاً مع OS/2 ومع POSIX، ويؤكد فريق WSL في Microsoft أن نواة NT دعمت عند صدورها الأول ثلاثة أنظمة فرعية: POSIX وOS/2 وWin32.
وهنا تأتي اللحظة الحاسمة في القصة. فالمشروع بدأ باسم NT OS/2، أي أن الواجهة الأساسية كانت OS/2، ولكن Windows 3.0 الذي صدر في 1990 نجح نجاحاً كبيراً، ومعه بدأت العلاقة بين Microsoft وIBM تسوء، فقررت Microsoft أن تكون الواجهة الأساسية للنظام الجديد هي واجهة Windows بنسخة 32 بت، والتي صارت تعرف باسم Win32. وهذا التحول بعد سنتين من بداية المشروع هو ما يقصده Lucovsky بجملة «اختراع Windows»، وهو لم يكن ممكناً لو كانت النواة مربوطة بواجهة OS/2، ولكن لأن الواجهة كانت طبقة فوق النواة، أمكن تغيير الطبقة دون هدم النظام. ويذكر مقال Microsoft أن الفريق انتقل بالفعل من واجهة OS/2 الموسعة إلى Win32 بسبب شعبية Windows.
والطريف أن هذه الفكرة عادت بعد أكثر من 25 سنة، فعندما أرادت Microsoft في 2016 تشغيل برامج Linux كما هي على Windows، بنت الإصدار الأول من Windows Subsystem for Linux على ما يسمى Pico Processes، وهي عمليات تمرر استدعاءات النظام System Calls فيها إلى برنامج تشغيل يترجمها إلى استدعاءات NT. ويقول الفريق في مقاله صراحة إن نواة NT صممت لتسمح بأنظمة فرعية جديدة، وإنهم استفادوا من ذلك الاستثمار القديم. وقد شرحنا استدعاءات النظام وحدود النواة في مقال فضاء النواة وفضاء المستخدم.
وعلى أي حال، لم تكن كل أهداف التوافق قصة نجاح، فنظام POSIX الفرعي في NT كان محدوداً، وتقول Microsoft في نفس المقال إن الأنظمة الفرعية الأولى «تقاعدت» مع الوقت، وإن نسخة لاحقة لـ POSIX واجهت صعوبة في مطابقة سلوك استدعاءات مثل fork() لأنها بنيت في وضع المستخدم. والدرس أن المعمارية المرنة تعطيك الخيار، ولكنها لا تضمن أن كل خيار سوف يستحق الاستثمار.
الجودة Quality عند Cutler: اختبار الضغط Stress Testing كل ليلة
إذا سألت من عمل مع كتلر عن صفة واحدة، فسوف يقولون لك: الجودة. وهو يقولها بنفسه في مقال Microsoft: «الجودة هي القيد الأول عندي، دائماً»، ويضيف جملة تستحق أن تعلق فوق مكتب كل مبرمج: «إذا لم تضع الأخطاء في الكود، فلن تحتاج إلى إخراجها». ويصف طريقته في الكتابة بأنه ينفذ الكود في رأسه أثناء كتابته ليجد الأخطاء قبل التشغيل، وأنه يفضل البناء التدريجي، حيث يتحقق من كل جزء قبل أن ينتقل إلى الجزء التالي.
ولكن الجودة في نظام بهذا الحجم لا تأتي من انضباط شخص واحد، فقد اختار الفريق طريقة غير معتادة في الاختبار. فبدلاً من مجموعة اختبارات Test Suite شاملة تغطي كل دالة، بنوا نظام ضغط ديناميكي Dynamic Stress System يضع النظام كله تحت ضغط عال من برامج كثيرة في نفس الوقت، ويشغلونه كل ليلة على مئات الأجهزة، وفي الصباح يجتمع الفريق ليراجع كل عطل ظهر. ويصف Rob Short هذه الطريقة بأنها «علم ذكي جداً مع القوة الغاشمة Brute Force، وعدم الخوف من الأرقام الكبيرة».
ويعطي Lucovsky في شريحة إدارة العمل في NT 3.1 تفاصيل اليوم الواحد: فترة يومية آمنة لمزامنة الكود، ثم يبني معمل البناء Build Lab النظام كاملاً، وكان البناء الكامل يأخذ خمس ساعات على أجهزة 486 بسرعة 50 ميجاهرتز، ثم اختبار إقلاع بسيط، ثم يبدأ اختبار الضغط على قرابة 100 جهاز. وكان من الطبيعي أن يفشل البناء مرة أو مرتين في اليوم، فيصلح يدوياً أثناء البناء. وفي شريحة الثقافة قاعدة أخرى: الكود ملك الجميع، فإذا تعطل شيء فمن حق أي شخص في الفريق، بل من واجبه، أن يصلحه.
وهنا تلاحظ شيئاً مهماً: هذه الفكرة، أن تشغل النظام كاملاً تحت ضغط Load حقيقي كل يوم بدل أن تكتفي باختبار كل جزء وحده، هي نفس الفكرة التي تراها اليوم في اختبارات الضغط Load Testing وفي هندسة الفوضى Chaos Engineering، وقد شرحنا جانباً منها في مقال اختبار الضغط Load Testing. والفرق أن فريق NT كان يفعلها في نهاية الثمانينيات بأجهزة حقيقية مكدسة في الممرات.
الثمن: ثقافة قاسية Culture وفريق مرهق
ولكن القصة لها وجه آخر لا يجب أن نخفيه. فكتلر كان معروفاً بأنه صعب ومتطلب، ويقول Rob Short، الذي عمل معه منذ DEC، إنه «يمكن أن يكون فظاً ومتطلباً في بعض الأحيان»، ثم يضيف في نفس الجملة أنه «جيد جداً في تحفيز الناس». وتنقل Seattle Times أنه ضرب جداراً بقبضته في 1992 بعد أن علم بخلل في NT، وأن زملاءه أهدوه لاحقاً قطعة من الجدار في إطار في عيد ميلاده كمزحة، وأن الفريق عمل ساعات طويلة تشمل عطلات نهاية الأسبوع لأكثر من سنتين. ومن كلماته لمجلة UnixWorld التي نقلتها الصحيفة: «من لا يقوم بعمله يدهس»، و«عندما أقبل مهمة فإني أنهيها، ولا شيء يقف في الطريق إلا إلغاء المشروع كاملاً».
وأوضح وصف لهذا الجانب جاء من داخل الفريق نفسه. ففي شريحة ثقافة NT يكتب Lucovsky، وهو من السبعة الأوائل، أن عدم التسامح مع الإهمال Sloppiness فكرة رائعة، ولكن من الصعب جداً رعايتها عندما يكبر الفريق، وأن «الإساءة والترهيب يخرجان عن السيطرة، ولا يمكنك أن تستمر في وصف الناس بالأغبياء ثم تتوقع أن يستمعوا إليك»، ثم يختم بأن الثقافة الناجحة يجب أن تقبل أن الأخطاء سوف تحدث. ويذكر ملخص Publishers Weekly لكتاب Show Stopper! أن الكتاب يتابع الفريق خلال الإخفاقات التقنية وآلاف الأخطاء والصراعات الداخلية والضغط الشخصي، وهي الصورة التي جعلت الكتاب مرجعاً لكل من يكتب عن إدارة المشاريع البرمجية الكبيرة.
وهنا درس لا يخص Microsoft وحدها، فقد ناقشنا في قصة لينوس تورفالدز كيف اعتذر هو أيضاً في 2018 عن لغته القاسية على القوائم البريدية. فالمعايير العالية شيء، والقسوة على الأشخاص شيء آخر، والفرق الناجحة على المدى الطويل تحتفظ بالأول وتتخلص من الثاني، لأن الفريق الذي يخاف من الخطأ يخفيه بدل أن يبلغ عنه.
والشريحة التالية من محاضرة Lucovsky تبين لماذا أصبحت الثقافة مشكلة بالأرقام، حيث تقارن بين فريق NT 3.1 وفريق Windows 2000 بعد سبع سنوات:
ففي NT 3.1، كما يقول Lucovsky في شريحة الفريق، بدأ الفريق بستة أشخاص ونما ببطء إلى قرابة 200، وكانت ثقافة NT مفهومة للجميع، أما في Windows 2000 فقد ضم فريق NT فرقاً أخرى كثيرة، فصار عدد المطورين 1,400، والكود 29 مليون سطر مقابل 6 ملايين في NT 3.1 حسب شريحة نظام إدارة الكود، وصار عطل واحد يدخل الفرع الرئيسي يوقف 1,400 مطور ضمن فريق من 5,000 شخص. وهذه الأرقام تشرح بشكل عملي ما ناقشناه في مقال هل يسلم الفريق الأكبر أسرع؟ قانون Brooks.
يوليو 1993: صدور Windows NT 3.1
في مايو 1993 أعلنت Microsoft النظام رسمياً، وكتبت Seattle Times أن المشروع شارك فيه قرابة 300 شخص منهم 100 مطور على مدى خمس سنوات، بتكلفة قدرت بحوالي 400 مليون دولار، وأن Microsoft باعت 65,000 نسخة من حزمة المطورين قبل الصدور، وأن النظام تأخر أكثر من سنة عن موعده الأصلي. أما مقال Microsoft فيذكر أن الفريق كان قرابة 20 مهندساً في بداية المشروع وقرابة 150 عند الصدور الأول، والفرق بين الرقمين يأتي من طريقة العد، فرقم الصحيفة يشمل كل من شارك في المشروع.
وصدر Windows NT 3.1 في 27 يوليو 1993. ورقم 3.1 لم يأت لأن هناك NT 1 أو NT 2، وإنما ليطابق رقم Windows 3.1 المنتشر في ذلك الوقت، فالنظام الجديد كان يقدم نفس واجهة المستخدم ولكن فوق نواة مختلفة تماماً. ولم ينتشر NT 3.1 بين المستخدمين المنزليين، فقد كان يحتاج أجهزة أقوى مما يملكه أغلب الناس، وتذكر الصحيفة نفسها أن Microsoft خففت توقعاتها وصارت تستهدف أصحاب الأجهزة الكبيرة أولاً. وقال المحلل Paul Cubbage للصحيفة إن NT «يريد أن يستبدل كل شيء»، وهو وصف كان أدق مما ظن صاحبه.
من NT 4.0 إلى Windows XP: كيف أصبحت NT هي Windows؟
بعد NT 3.1 صدرت NT 3.5 في سبتمبر 1994، ثم NT 3.51 في مايو 1995، ثم NT 4.0 في يوليو 1996 بواجهة Windows 95، ثم NT 5.0 الذي سمي Windows 2000 في ديسمبر 1999، وهذه التواريخ من شريحة الخط الزمني عند Lucovsky. وطوال هذه السنوات كانت Microsoft تبيع خطين منفصلين: خط Windows 95 و98 وMe المبني على MS-DOS للمستخدمين المنزليين، وخط NT للشركات والسيرفرات.
ثم جاء Windows XP في 2001 ليجمع الخطين، ويكتب Bill Gates في خطاب الترشيح الذي نقله مقال Microsoft أن NT «أصبح منذ Windows XP في 2001 أساس كل أنظمة تشغيل Microsoft للحواسيب الشخصية». ومنذ ذلك اليوم كل نسخة Windows، من Vista و7 و10 إلى 11، وكل نسخة Windows Server، هي NT في الداخل. وهذا هو السبب أن الأمر ver في أول المقال يطبع رقماً يبدأ بـ 10.0، فهو رقم إصدار نواة NT وليس رقماً تسويقياً.
أما كتلر نفسه فقد توقف عن إدارة مشروع NT كاملاً في 1996، واستمر يقود تطوير النواة حتى 2006 حسب مقال Microsoft. وفي هذه الفترة حدثت قصة صغيرة تدل على شخصيته، فهو لم يتحول إلى مدير يكتفي بالاجتماعات، وإنما بقي يكتب الكود الحساس بنفسه، وهي ملاحظة ذكرتها Seattle Times منذ 1993.
بعد NT: معمارية x64 ثم Azure ثم Xbox One
ما يجعل قصة كتلر مختلفة عن أغلب قصص المؤسسين أنه لم يتوقف بعد المشروع الكبير. ففي منتصف العقد الأول من الألفية عمل مع شركة AMD على معمارية AMD64، أي معالجات 64 بت المتوافقة مع x86، وقاد إصدار أول نسختين من Windows لهذه المعمارية، واحدة لمحطات العمل وأخرى للسيرفرات، كما يذكر مقال Microsoft. وهنا ظهرت قيمة هدف قابلية النقل مرة أخرى بعد خمس عشرة سنة: النظام الذي صمم ليعمل على أكثر من معالج انتقل إلى معالج جديد دون إعادة كتابة.
ثم جنده Amitabh Srivastava في 2006 لمشروع سري اسمه Red Dog، وهو نظام تشغيل للسحابة، وكان دور كتلر تطوير الـ Hypervisor الذي يشغل الأجهزة الافتراضية فيه. وعرضت Microsoft هذا المشروع لأول مرة في مؤتمر PDC في 27 أكتوبر 2008 باسم Windows Azure، والذي صار اليوم Microsoft Azure. ويقول Srivastava عنه: «ديف لا يختصر الطريق». ثم في 2011، قبل أشهر من بلوغه السبعين، جنده Boyd Multerer وHoi Vo لفريق Xbox One، ويقول Multerer إن كتلر صمم وكتب الـ Hypervisor الخاص بالجهاز و«كل الجزء السفلي من النظام»، وصدر الجهاز في أمريكا الشمالية في 22 نوفمبر 2013.
وحصل كتلر على وسام التقنية والابتكار الوطني الأمريكي، وهو عضو في الأكاديمية الوطنية للهندسة National Academy of Engineering، واختاره متحف تاريخ الحاسب زميلاً في 2016 «لمساهماته الأساسية في معمارية الحاسب والمترجمات وأنظمة التشغيل وهندسة البرمجيات» كما في إعلان المتحف. وقال عنه Steve Ballmer، المدير التنفيذي السابق لشركة Microsoft: «لما وجدت Microsoft اليوم لولا ديف»، وهي جملة قد تبدو مبالغة حتى تتذكر أن كل نسخة Windows منذ 2001 تعمل على نواته.
ماذا بقي من NT داخل Windows 11؟
قد تظن أن نظاماً صدر في 1993 لم يبق منه شيء بعد ثلاثين سنة من التطوير وآلاف المهندسين، ولكن إذا قرأت وثائق Microsoft Learn الحالية لمطوري برامج التشغيل فسوف تجد أفكار NT الأولى في كل صفحة تقريباً:
- الملف
ntoskrnl.exe: ما زال اسم النواة يحمل الحرفين NT، ويضم الجزء التنفيذي والنواة معاً. - طبقة HAL ومستويات IRQL: موثقتان كما هما في مكتبة HAL وإدارة أولويات العتاد، وكل برنامج تشغيل تكتبه اليوم يجب أن يحترمهما.
- الكائنات والمقابض والصلاحيات: كل ملف ومفتاح ريجستري وعملية يمر عبر مدير الكائنات ومراقب الأمان، وقائمة الصلاحيات التي تعدلها في خصائص أي ملف هي ACL بنفس التصميم.
- حزم IRP: ما زالت طريقة مرور طلبات الإدخال والإخراج عبر طبقات برامج التشغيل.
- الفصل بين وضع المستخدم ووضع النواة: موثق في User mode and kernel mode، وهو تحقيق هدف الموثوقية الذي كتبه الفريق في 1988: البرنامج الذي يتعطل في وضع المستخدم لا يوقع النظام.
- نظام الملفات NTFS الذي جاء مع NT، وما زال نظام الملفات الأساسي في Windows، بصلاحياته وسجله Journal.
- Unicode في Windows API: بنيت NT على Unicode منذ البداية، ولهذا تجد لكل دالة في Win32 نسختين تنتهي إحداهما بحرف W، وهي النسخة الأصلية في النظام. وهذا القرار هو ما جعل النصوص العربية تعمل في Windows بشكل أفضل بكثير من الأنظمة التي سبقته.
ومن يريد أن يتعمق في هذه الأجزاء فالمرجع المعروف هو سلسلة كتب Windows Internals الصادرة عن Microsoft Press، والتي تشرح كل جزء من الأجزاء السابقة في النسخ الحالية من Windows.
ماذا نتعلم من قصة Cutler مع NT؟
قصص الأشخاص الكبار تغري بالتقليد الأعمى، ولكن الأفضل أن نأخذ منها ما يصلح لفرقنا ونترك ما لا يصلح. وفيما يلي ما نراه يستحق النقل:
- اكتب أهدافك ورتبها قبل أن تكتب الكود: الأهداف وحدها لا تكفي، لأن الجميع يريد كل شيء. الترتيب هو الذي يجيب عن سؤال «ماذا نفعل عندما يتعارض هدفان؟»، وفريق NT وضع الأداء في آخر القائمة عن قصد، وهذا القرار حمى النظام ثلاثين سنة.
- المواصفة الجيدة توفر وقتاً أكثر مما تأخذ: ستة أشهر من المواصفات سمحت لمهندس أن يكتب نظام الإدخال والإخراج في ثلاثة أسابيع. ولكن انتبه لتحذير Lucovsky: هذه الطريقة تعمل في الفريق الصغير، وتحتاج تعديلاً عندما يكبر.
- اجعل البيئة تجبرك على المبدأ: البدء على معالج غير x86 كان أقوى من أي وثيقة تطلب كتابة كود قابل للنقل. فإذا أردت أن يكون نظامك مستقلاً عن مزود سحابي معين، فشغله من اليوم الأول على اثنين.
- اختبر النظام كاملاً تحت الضغط كل يوم: اختبارات الوحدة Unit Tests مهمة، ولكن أخطاء أنظمة التشغيل والأنظمة الموزعة تظهر عندما تعمل الأجزاء معاً تحت ضغط حقيقي، وفريق NT جعل هذا طقساً يومياً.
- افصل الواجهة عن النواة: قرار الأنظمة الفرعية هو الذي أنقذ المشروع عندما تغيرت الواجهة من OS/2 إلى Win32، وهو نفسه الذي سمح بـ WSL بعد ربع قرن. وفي أنظمتك أنت، الطبقة التي تفصل منطق العمل عن واجهة API معينة هي ما يسمح لك بتغيير الواجهة دون هدم كل شيء.
- الإلغاء ليس نهاية الخبرة: ألغت DEC مشروع Mica، ولكن ما تعلمه الفريق انتقل معه وصار NT. فإذا ألغي مشروعك، فالخبرة التي بنيتها ما زالت لك.
- المعايير العالية لا تحتاج القسوة: حتى من داخل الفريق قال Lucovsky إن الترهيب لا يعمل عندما يكبر الفريق، والفريق الذي يخاف يخفي الأخطاء.
- المهندس يمكن أن يبقى مهندساً: كتلر لم يتحول إلى مدير اجتماعات، وكتب Hypervisor لجهاز Xbox وهو قريب من السبعين. وفي شركاتنا يظن كثير من المبرمجين أن الطريق الوحيد للتقدم هو الإدارة، وقصة كتلر، ومعها مسار المهندس الخبير Technical Fellow في Microsoft، تقول إن هناك طريقاً آخر.
الخلاصة
- ديف كتلر بدأ البرمجة بعد الجامعة في DuPont، ثم كتب RSX-11M وقاد تطوير VMS في DEC، وما زال VMS يعمل حتى اليوم باسم OpenVMS على x86-64.
- بعد إلغاء مشروع Prism وMica في 1988 انضم إلى Microsoft في 31 أكتوبر 1988 مع مجموعة من مهندسي DECwest، وبدأ فريق من سبعة أشخاص مشروع NT OS/2.
- كتب الفريق المواصفات قبل الكود، وبدأ على معالج i860 ثم MIPS ليجبر نفسه على قابلية النقل، ورتب الأهداف بحيث يأتي الأداء أخيراً.
- التصميم الطبقي مع HAL ومدير الكائنات والأنظمة الفرعية سمح بتحويل الواجهة الأساسية من OS/2 إلى Win32 بعد نجاح Windows 3.0.
- صدر Windows NT 3.1 في 27 يوليو 1993، وأصبح NT أساس كل نسخ Windows منذ XP في 2001، بما فيها Windows 11.
- بعد NT عمل كتلر على x64 وعلى Hypervisor منصة Azure وجهاز Xbox One، ونال وسام التقنية الأمريكي وزمالة متحف تاريخ الحاسب.
- الثقافة الصارمة صنعت نظاماً موثوقاً، ولكنها كلفت الفريق كثيراً، ولم تصمد عندما كبر الفريق إلى آلاف الأشخاص.
وإذا أعجبتك هذه القصة فاقرأ معها قصة لينوس تورفالدز صانع Linux وGit لترى الطريق الآخر لبناء نواة تعمل على مليارات الأجهزة، وقصة Java من Sun إلى Oracle، وقصص لغات البرمجة ومن صنعها، وقصة James Hamilton الذي عمل هو أيضاً في Microsoft قبل أن ينتقل إلى AWS. وإذا أردت أن تفهم الأجزاء التقنية التي مررنا عليها فابدأ بمقالات العمليات وجدولة المعالج والذاكرة الافتراضية ونظام الملفات من الداخل.
سجل التحديثات
- أكتوبر 2026: كتابة القصة من مصادرها المنشورة: سيرة متحف تاريخ الحاسب ومقابلته مع كتلر، ومقال Microsoft عنه في 2016، ومحاضرة Mark Lucovsky في USENIX سنة 2000، وتقرير Seattle Times في مايو 1993، ووثائق Microsoft Learn الحالية.
