Якщо DOS однозначний, то як було можливо багатозадачність у старій версії Windows?

Я читав, що DOS - це одноосібна ОС.

Але якщо старі версії Windows (включаючи Windows 95?) Були лише обгортками DOS, як Windows могла працювати як багатозадачна ОС?

Windows 95

Windows 95 набагато більше, ніж "просто обгортка" для MS-DOS . Цитуючи Реймонда Чена:

MS-DOS виконував дві цілі в Windows 95.

• Він служив завантажувачем.
• Він виступав як 16-розрядний застарілий драйвер шару пристрою.

Windows 95 насправді підключив / перекрив майже всі MS-DOS, зберігаючи його як шар сумісності, роблячи весь важкий підйом. Він також реалізував переважне багатозадачність для 32-бітних програм.

Попередній Windows 95

Windows 3.x і пізніші версії були здебільшого 16-бітними (за винятком Win32s, своєрідного рівня сумісності, який мостить 16 та 32, але ми це ігноруємо), були більш залежними від DOS і використовували лише спільну багатозадачність - це той, де вони не змушують запущену програму вимикатися; вони чекають, коли запущена програма здасть контроль (в основному, скажіть "Я закінчила", сказавши ОС запустити наступну програму, яка чекає).

Багатозадачність була спільною, як і в старих версіях MacOS (хоча на відміну від Multitasking DOS 4.x, яка підтримувала переважне багатозадачність). Завдання повинно було поступитися ОС, щоб запланувати інше завдання. Вихід був вбудований у певні виклики API, зокрема обробку повідомлень. Поки завдання своєчасно обробляло повідомлення, все було чудово. Якщо завдання припинило обробку повідомлень і було зайнято виконанням певного циклу обробки, багатозадачність більше не було.

Архітектура Windows 3.x

Щодо того, як ранні програми Windows отримають контроль:

У Windows 3.1 використовується багатозадачність спільної роботи - це означає, що кожній програмі, яка знаходиться в процесі запуску, доручено періодично перевіряти чергу повідомлень, щоб з’ясувати, чи будь-яка інша програма просить використовувати ЦП і, якщо це так, щоб отримати контроль над цією програмою . Однак багато програм Windows 3.1 перевірятимуть чергу повідомлень лише рідко, або зовсім не, і монополізують управління процесором стільки часу, скільки потрібно. Переважна багатозадачна система, як-от Windows 95, забере керування процесором від запущеного додатка і поширює його на ті, у кого вищий пріоритет, залежно від потреб системи.

джерело

Все, що DOS бачив, - це один єдиний додаток (Windows чи інший), який працює під управлінням, який передаватиме контроль без виходу. Теоретично попереджувальна багатозадачність може бути реалізована поверх DOS у будь-якому випадку із застосуванням годинника в режимі реального часу та апаратних перерв для примусового контролю планувальника. Як коментує Тоні , це було зроблено деякими ОС, що працюють поверх DOS.

386 вдосконалений режим?

Примітка. Було кілька коментарів щодо розширеного режиму Windows 3.x 386, який є 32-бітним та підтримує попереджувальну багатозадачність.

Це цікавий випадок. Підсумовуючи пов’язану публікацію блогу , 386 вдосконаленого режиму в основному був 32-розрядним гіпервізором, який керував віртуальними машинами. Всередині однієї з цих віртуальних машин працював стандартний режим Windows 3.x, який виконує всі перераховані вище речі.

MS-DOS також працюватиме у цих віртуальних машинах, і, мабуть, вони були превантивно багатозадачними - тому, схоже, гіпервізор 386 вдосконаленого режиму поділить відрізки часу процесора між віртуальними машинами (одна з яких працює нормально 3.x та інші, на яких працює MS -DOS), і кожен VM зробить свою справу - 3.x буде співпрацювати багатозадачно, тоді як MS-DOS буде однозначним.

MS-DOS

Сам DOS на папері був однозначним, але в ньому була підтримка програм TSR , які залишатимуться у фоновому режимі, доки не призведе апаратне переривання. Далеко від справжнього багатозадачності, але теж не повністю одноосібного.

Все це балакання? Я запитав про багатозадачність!

Ну, строго кажучи, що біт і багатозадачність не залежать один від одного. Повинно бути можливим зверху реалізувати будь-який багатозадачний режим у будь-якій біті. Однак перехід від 16-розрядних процесорів до 32-бітних процесорів також ввів інші функціональні можливості апаратури, які могли б полегшити реалізацію багатозадачності.

Крім того, оскільки 32-бітні програми були новими, легше було змусити їх працювати, коли вони були насильно вимкнені - що, можливо, порушило деякі застарілі 16-бітні програми.

Звичайно, це все міркування. Якщо ви дійсно хочете знати, чому MS не впроваджує попереджувальну багатозадачність у Windows 3.x (не зважаючи на 386 покращеного режиму), вам доведеться запитати когось, хто там працював.

Крім того, я хотів виправити ваше припущення, що Windows 95 був jsut обгорткою для DOS;)

Він безперервно запускав одну програму, ту, яку називали windows. Цей розподіляє час процесора (та інші ресурси) між різними програмами.

Розглянемо цю аналогію:

У вас є офіс, який одночасно може мати лише одна людина (Ця людина називається господарем або місісом DOS). Ця людина працює над однією справою в той час. Наприклад, він телефонує на одну людину і починає спілкуватися з нею 24/7.

Тепер ви замінюєте цю особу на пана секретаря. (вікна). Він телефонуватиме комусь і весь час з ним розмовлятиме (все ще одне завдання). Потім через деякий час інша людина скаже: "Я вже досить розмовляв. Ідіть, поговоріть з кимось іншим і передзвоніть мені трохи".

Пан секретар зателефонує іншій особі. Спілкуйтеся з цим, поки ця людина не скаже те саме. Потім він зателефонує наступній особі, поки вона не буде в кінці списку людей, з якими потрібно поговорити. В цей час воно почнеться знову вгорі.

• У технічному плані це називається кооперативним багатозадачністю. Інша людина вимагає сказати, що у нього було достатньо часу для процесора. Якщо цього не робити, то все розпадається.
• Сучасні системи набагато розумніші. Включаючи переважне багатозадачність. Подумайте, як секретар встановить будильник і відрізає іншу людину через 5 хвилин. "Це приємна Джейн. Але я повинен зараз поговорити з Джо. Я передзвоню тобі трохи. - Клацніть".

Якщо додати кілька процесорів, це стає ще складніше. :)

У сучасній операційній системі операційна система контролює всі апаратні ресурси, а запущені програми зберігаються в пісочницях. Додаток не має доступу до пам'яті, яку ОС не виділив цій програмі, і він не може безпосередньо отримати доступ до апаратних пристроїв на комп'ютері. Якщо потрібен апаратний доступ, програма повинна спілкуватися через драйвери пристроїв.

ОС може застосувати цей контроль, оскільки він змушує процесор перейти в захищений режим .

DOS, з іншого боку, ніколи не переходить у захищений режим, а залишається в реальному режимі *. У реальному режимі запущені програми можуть виконувати все, що хочеться, наприклад, безпосередньо отримувати доступ до обладнання. Але програма, що працює в реальному режимі, також може сказати процесору перейти в захищений режим.

І ця остання частина дозволяє таким програмам, як Windows 95, запускати багатопотокове середовище, навіть якщо вони були запущені з DOS.

DOS (дискова операційна система) була, afaik, не набагато більше, ніж система управління файлами. Він надав файлову систему, механізми навігації по файловій системі, кілька інструментів та можливість запуску програм. Це також дозволило деяким програмам залишатися резидентами, наприклад, драйвери миші та емулятори EMM. Але він не намагався керувати обладнанням у комп’ютері так, як це робить сучасна ОС.

* Коли DOS вперше був створений у 70-х, захищений режим не існував у процесорі. Лише процесор 80286 в середині 80-х захищений режим став частиною процесора.

До Windows 3.x, яка була першою версією багатозадачних додатків DOS, існували такі програми, як DesqView, які могли робити те саме. Якби наприклад було запущено три сесії DOS одночасно, DesqView створив би чотири віртуальні машини. Кожні три сесії DOS вважають, що вони "володіють" цілою машиною, за винятком того, що жодна з них насправді не виконує введення / виведення файлів. Натомість версія DOS, що працює в кожному сеансі, буде виправлена, щоб вона пересилала будь-які запити на введення / виведення файлів на спеціальний сеанс, який був призначений для цієї мети. Оскільки апаратне забезпечення в текстовому режимі ПК постійно відображатиме вміст області пам'яті як символи; DesqView може дозволити кожному сеансу мати власний віртуальний екран, зіставляючи діапазон 0xB8000-0xB9FFF кожного сеансу до власної області ОЗУ, і періодично копіювати область поточної програми у фізичний буфер екрану. Графічна підтримка виявилася набагато складніше, тому що 256K оперативної пам’яті на дошці дисплея контролювались за допомогою 64К адресного простору, деяких регістрів вводу / виводу, а також деякого «цікавого» обладнання, яке вимагало прочитати та записати речі у певних певних послідовностях. У текстовому режимі, коли програма записувала щось до текстового буфера, DesqView може встановити прапор із зазначенням, що його слід скопіювати на дисплей наступного галочки таймера; тільки перше записування в текстовий буфер у вказаний момент часу вимагатиме втручання DesqView; всі інші будуть консолідовані до наступної галочки таймера. оскільки 256K оперативної пам’яті на дошці дисплея контролювались за допомогою 64K адресного простору, деяких регістрів вводу-виводу та деякого «цікавого» обладнання, яке вимагало, щоб речі були прочитані та записані у певних певних послідовностях. У текстовому режимі, коли програма записувала щось до текстового буфера, DesqView може встановити прапор із зазначенням, що його слід скопіювати на дисплей наступного галочки таймера; тільки перше записування в текстовий буфер у вказаний момент часу вимагатиме втручання DesqView; всі інші будуть консолідовані до наступної галочки таймера. оскільки 256K оперативної пам’яті на дошці дисплея контролювались за допомогою 64K адресного простору, деяких регістрів вводу-виводу та деякого «цікавого» обладнання, яке вимагало, щоб речі були прочитані та записані у певних певних послідовностях. У текстовому режимі, коли програма записувала щось до текстового буфера, DesqView може встановити прапор із зазначенням, що його слід скопіювати на дисплей наступного галочки таймера; тільки перше записування в текстовий буфер у вказаний момент часу вимагатиме втручання DesqView; всі інші будуть консолідовані до наступної галочки таймера. DesqView може встановити прапор із зазначенням, що його слід скопіювати на дисплей наступного галочки таймера; тільки перше записування в текстовий буфер у вказаний момент часу вимагатиме втручання DesqView; всі інші будуть консолідовані до наступної галочки таймера. DesqView може встановити прапор із зазначенням, що його слід скопіювати на дисплей наступного галочки таймера; тільки перше записування в текстовий буфер у вказаний момент часу вимагатиме втручання DesqView; всі інші будуть консолідовані до наступної галочки таймера.

Навпаки, віртуалізація графічного режиму вимагатиме від DeskView, щоб утримувати кожну окрему запис для відображення пам'яті або регістрів вводу / виводу. Зважаючи на те, що це сповільнить запис пам'яті на коефіцієнт приблизно 100, а графічні програми повинні були записати набагато більше даних, ніж текстові програми, віртуалізація більшості графічних програм в реальному часі не була практичною. Натомість графікою обробляється будь-яка програма, яка не виходить на передній план, яка намагалася робити графіку паузами, поки вона не стала додатком переднього плану, а потім надала їй повний контроль над екраном. Коли управління переключилося на інший додаток, DesqView спробує зробити копію стану всіх графічних регістрів, а потім переключитися. Після повернення до графічного додатку DesqView відновить збережений стан.

Певним чином, багатозадачні не графічні програми DOS були простішими, ніж багатозадачні програми Windows, оскільки спільних ресурсів було дуже мало, і додатки не повинні взаємодіяти один з одним. У Windows, навпаки, потрібно мати справу з такими речами, як буфер обміну, або ймовірність того, що вікна однієї програми можуть рухатися таким чином, щоб затемнювати інші. Windows 95 була першою версією Windows, яка могла подолати такі обмеження, включивши такі речі, як віконна система, яка могла б забезпечити недоступність області екрана, в той час як код намагався залучити до цього (з тим, що малюнок маскується ).

Багатозадачність - це не що інше, як ілюзія одночасного запуску програм. Це сприймається як одночасне виконання на вашому кінці, але насправді процеси A, B і C ділять час процесора в такому порядку: A, B, C, A, B, C, A, B ... вони просто включаються і дуже швидко. Жоден процес не працює одночасно.

Отже, цілком можливо зробити багатозадачність MS-DOS, зробивши призупинення одного процесу, запустити наступний на короткий проміжок часу, призупинити цей, перейти назад до першого тощо.

Багатозадачність - це лише розумна функція, розроблена, коли процесори почали бути досить швидкими, щоб продовжувати обертатись через ці процеси і робити це здається одночасним для кінцевого користувача.

Для тих, хто пам’ятає, ігри все ще проводили на DOS4GW, оскільки Windows був занадто повільним.

Незважаючи на те, що він може зосередитись лише на одному завданні, те, що вона зробить, - це простий крок швидкого переходу від однієї до іншої. Таким чином виявилося, що це багатозадачність, але насправді його просто зосередження на 1, потім на іншому, потім на іншому тощо.

Одне, що я не бачив тут, що було цікавим:

Windows 3.0 не була переважаючою багатозадачною системою, вона була спільною, як і всі версії MacOS, до тих пір, поки OS X - Один додаток не повинен був повернутися з виклику, перш ніж будь-який інший додаток міг вжити будь-яких дій.

Як нагадав мені коментатор, додатки DOS були багатозадачними. Це тому, що вони не були написані на багатозадачне завдання "Співпраця" (Це завжди має бути вбудовано в системи, які його використовують).

У той час існували програми під назвою TSR (Terminate-Stay Resident), які займали місце сьогоднішніх драйверів пристроїв. Ці драйвери працюватимуть незалежно - як правило, за власним потоком, вставляючи себе в один із обробників подій ОС. Windows взагалі про них не знала, вони працювали на нижчому рівні.

Це насправді не були програми для Windows, але вони проходили як все потоки дій перед Windows 3.1, такі як драйвери принтера, драйвери ком і т.д.

Хоча Windows 3.1 був багатозадачним, DOS не був, але Windows 3.1 просто відсунув дос із шляху і перейняв його, коли він запускався (тоді ви часто запускали вікна з підказки DOS).

Гарне питання. У MS-DOS ядро ​​було монолітним, це означає, що він обробляв лише одне завдання за один раз порівняно з новим сучасним ядром, реалізованим у Windows 9x та поточній версії. Дізнатися більше можна тут .