كيف كان تعدد المهام ممكن في الإصدارات القديمة من ويندوز؟

بالنظر إلى أن نظام DOS هو نظام تشغيل واحد للمهام وعلاقاته مع الإصدارات المبكرة من Windows ، فكيف تمكنت الإصدارات السابقة من Windows من إنجاز مهام متعددة؟ ينظر اليوم SuperUser Q & A post إلى الإجابات على هذا السؤال.

تأتي جلسة الأسئلة والأجوبة اليوم مقدمة من SuperUser-a subdivision of Stack Exchange ، وهي مجموعة مجتمعية مدفوعة من مواقع Q & A.

لقطة شاشة لنظام Windows 95 من ويكيبيديا.

السؤال

يريد قارئ SuperUser LeNoob معرفة كيفية تشغيل إصدارات Windows القديمة كنظام متعدد المهام ؟:

قرأت أن DOS هو نظام التشغيل واحد المهام. ولكن إذا كانت الإصدارات الأقدم من Windows (بما في ذلك Windows 95؟) عبارة عن أغلفة لـ DOS فقط ، فكيف يمكن تشغيلها كنظام تشغيل متعدد المهام?

سؤال جيد! كيف تمكنت الإصدارات الأقدم من Windows من العمل كنظم متعددة المهام?

الاجابة

مساعدي SuperUser يملك Bob و Pet إجابة لنا. أولاً ، بوب:

كان Windows 95 أكثر بكثير من "مجرد مجمّع" لـ MS-DOS. نقلا عن ريمون تشن:

• خدم MS-DOS غرضين في نظام التشغيل Windows 95: 1.) أنه بمثابة محمل التمهيد. & 2.) أنها بمثابة طبقة برنامج تشغيل الجهاز القديم 16 بت.

Windows 95 بالفعل مدمن مخدرات / overrode فقط حول كافة MS-DOS ، الاحتفاظ بها كطبقة توافق أثناء القيام بكل رفع ثقيل نفسه. كما نفذت تعدد المهام الاستباقية لبرامج 32 بت.

قبل نظام التشغيل Windows 95

كان Windows 3.x والإصدارات الأقدم في الأغلب 16 بت (باستثناء Win32s ، وهو نوع من طبقة التوافق التي تصل إلى 16 و 32 ، ولكننا سنقوم بتجاهلها هنا) ، كانت أكثر اعتمادًا على DOS ، واستخدمت فقط تعدد المهام التعاوني - هذا هو المكان الذي لا يجبروا فيه برنامجًا جارٍ على التبديل ؛ ينتظرون تشغيل البرنامج قيد التشغيل (بشكل أساسي ، قل "انتهيت" من خلال إخبار نظام التشغيل بتشغيل البرنامج التالي الذي ينتظر).

• كان تعدد المهام متعاونًا ، تمامًا كما هو الحال في الإصدارات القديمة من MacOS (على الرغم من أنه مختلف عن DOS 4.x multi-tasking ، الذي كان يتسم بمهام متعددة وقائية). كان على مهمة الاستسلام لنظام التشغيل من أجل جدولة مهمة مختلفة. تم إنشاء العوائد في مكالمات API معينة ، ولا سيما معالجة الرسائل. طالما كانت مهمة معالجة الرسائل في الوقت المناسب ، كل شيء كان رائعا. إذا توقفت إحدى المهام عن معالجة الرسائل وكانت مشغولة بتنفيذ بعض حلقات المعالجة ، فلم يعد هناك تعدد المهام.

ويندوز 3.x العمارة

بالنسبة إلى كيفية قيام برامج Windows المبكرة بالتحكم في:

• يستخدم Windows 3.1 تعدد المهام التعاوني - بمعنى أنه يتم توجيه كل تطبيق قيد التشغيل بشكل دوري للتحقق من قائمة انتظار الرسائل لمعرفة ما إذا كان أي تطبيق آخر يطلب استخدام وحدة المعالجة المركزية (CPU) ، وإذا كان الأمر كذلك ، لإعطاء التحكم إلى هذا التطبيق. ومع ذلك ، العديد من تطبيقات Windows 3.1 من شأنه أن يفحص قائمة انتظار الرسائل بشكل غير متكرر ، أو لا يحدث على الإطلاق ، ويحتكر التحكم في وحدة المعالجة المركزية طوال الوقت المطلوب. سيأخذ نظام متعدد المهام وقائي مثل نظام التشغيل Windows 95 سيطرة وحدة المعالجة المركزية بعيدًا عن تطبيق قيد التشغيل وتوزيعه على أولئك الذين لديهم أولوية أعلى بناءً على احتياجات النظام.

مصدر

سيرى كل DOS هو هذا التطبيق الفردي (Windows أو غيره) قيد التشغيل ، والذي من شأنه أن يسيطر على التحكم دون الخروج. من الناحية النظرية ، يمكن تنفيذ مهام متعددة وقائية على قمة دوس على أي حال مع استخدام المقاطعات في الوقت الحقيقي والمقاطعات لإعطاء السيطرة على المجدول بالقوة. كما تعليق توني ، تم القيام به بالفعل من قبل بعض أنظمة تشغيل تعمل على قمة دوس.

وضع المحسن 386?

ملاحظة: كانت هناك بعض التعليقات على 386 وضع المحسّن لـ Windows 3.x هي 32 بت وتدعم تعدد المهام الاستباقية.

هذا هو حالة مثيرة للاهتمام. لتلخيص منشور المدونة المرتبط ، كان وضع المحسن 386 في الأساس هو hypervisor 32-بت ، والذي قام بتشغيل الأجهزة الظاهرية. داخل أحد هذه الأجهزة الظاهرية تشغيل وضع Windows 3.x القياسي ، الذي يفعل كافة الأشياء المذكورة أعلاه.

كما يمكن تشغيل MS-DOS داخل هذه الأجهزة الظاهرية ، ومن الواضح أنها كانت متعددة المهام بشكل استباقي - لذلك يبدو أن برنامج Hyper mode المحسن 386 سيشارك شرائح وقت المعالج CPU بين الأجهزة الظاهرية (التي يعمل أحدها بشكل طبيعي 3.x و الآخرين التي شغلت MS-DOS) ، وسوف تفعل كل VM شيء خاص بها - 3.x سوف متعددة المهام بشكل تعاوني ، في حين أن MS-DOS سوف تكون مهمة واحدة.

MS-DOS

DOS نفسها كانت مهمة واحدة على الورق ، ولكن لديها دعم لبرامج TSR التي ستبقى في الخلفية حتى يتم تشغيلها من قبل مقاطعة الأجهزة. بعيدًا عن تعدد المهام الحقيقي ، ولكن ليس مهمًا تمامًا.

كل هذا الكلام عن البتة؟ سألت عن تعدد المهام!

حسنا ، بالمعنى الدقيق للكلمة ، لا تعتمد البتة وتعدد المهام على بعضها البعض. يجب أن يكون من الممكن تنفيذ أي وضع تعدد المهام في أي بت. ومع ذلك ، فإن الانتقال من المعالجات ذات 16 بت إلى المعالجات ذات 32 بت قدم أيضًا وظائف الأجهزة الأخرى التي كان من الممكن أن تجعل تنفيذ المهام المتعددة الوقائية أكثر سهولة في التنفيذ.

أيضا ، بما أن برامج 32 بت كانت جديدة ، كان من الأسهل حملها على العمل عندما تم إبعادها بالقوة - والتي ربما تكون قد كسرت بعض البرامج القديمة ذات 16 بت.

بالطبع ، هذا هو كل التكهنات. إذا كنت تريد حقاً معرفة السبب في عدم تنفيذ MS لمهام متعددة وقائية في Windows 3.x (وضع المحسن 386 بالرغم من ذلك) ، يجب عليك أن تسأل شخصًا يعمل هناك.

أيضا ، كنت أرغب في تصحيح افتراضك أن ويندوز 95 كان مجرد غلاف لدوس.

تليها الإجابة من بيت:

في نظام التشغيل الحديث ، يتحكم نظام التشغيل في جميع موارد الأجهزة ، ويتم الاحتفاظ بالتطبيقات قيد التشغيل في صناديق الرمل. لا يُسمح للتطبيق بالوصول إلى الذاكرة التي لم يخصصها نظام التشغيل إلى هذا التطبيق ، ولا يمكنه الوصول إلى الأجهزة بشكل مباشر في الكمبيوتر. إذا كان الوصول إلى الأجهزة مطلوبًا ، فيجب أن يتصل التطبيق من خلال برامج تشغيل الأجهزة.

يمكن لنظام التشغيل فرض عنصر التحكم هذا ، لأنه يفرض على وحدة المعالجة المركزية إدخال الوضع المحمي.

DOS ، من ناحية أخرى ، لا يدخل الوضع المحمي أبداً ، ولكنه يبقى في الوضع الحقيقي (*انظر أدناه). في الوضع الحقيقي ، يمكن للتطبيقات قيد التشغيل تنفيذ أي شيء تريده ، أي الوصول إلى الأجهزة مباشرةً. ولكن يمكن أيضًا للتطبيق الذي يعمل في الوضع الحقيقي إخبار وحدة المعالجة المركزية بإدخال الوضع المحمي.

ويسمح هذا الجزء الأخير للتطبيقات مثل Windows 95 لبدء بيئة متعددة مؤشرات الترابط على الرغم من أنها تم إطلاقها بشكل أساسي من DOS.

كان DOS (نظام تشغيل القرص) ، بقدر ما أعرف ، ليس أكثر بكثير من نظام إدارة الملفات. وقد وفر نظام ملفات ، وآليات للتنقل في نظام الملفات ، وعدد قليل من الأدوات ، وإمكانية تشغيل التطبيقات. كما أنها سمحت لبعض التطبيقات بالبقاء مقيمين ، أي برامج تشغيل الماوس ومحاكاة EMM. لكنه لم يحاول السيطرة على الأجهزة في الكمبيوتر على غرار نظام التشغيل الحديث.

*عندما تم إنشاء DOS لأول مرة في السبعينات ، لم يكن الوضع المحمي موجودًا في وحدة المعالجة المركزية. لم يكن حتى 80286 المعالج في منتصف 1980s أصبح الوضع المحمي جزءا من وحدة المعالجة المركزية.

تأكد من التصفح على الخيط الأصلي وقراءة النقاش النشط حول هذا الموضوع باستخدام الرابط أدناه!

هل لديك شيء تضيفه إلى الشرح؟ الصوت قبالة في التعليقات. هل ترغب في قراءة المزيد من الإجابات من مستخدمي Stack Exchange الآخرين المحترفين بالتكنولوجيا؟ تحقق من موضوع المناقشة الكامل هنا.