Я читал, что DOS - это однозадачная ОС.
Но если старые версии Windows (включая Windows 95?) были просто оболочками DOS, как Windows могла работать как многозадачная ОС?
Я читал, что DOS - это однозадачная ОС.
Но если старые версии Windows (включая Windows 95?) были просто оболочками DOS, как Windows могла работать как многозадачная ОС?
Windows 95 была гораздо больше, чем просто оболочка для MS-DOS. Цитируя Рэймонда Чена:
MS-DOS служил двум целям в Windows 95.
- Он служил загрузчиком.
- Он действовал как 16-битный уровень драйвера устройства.
Windows 95 фактически зацепила / перегрузила практически все MS-DOS, сохранив ее как слой совместимости, одновременно выполняя всю тяжелую работу. Также реализована вытесняющая многозадачность для 32-битных программ.
Windows 3.x и более ранние были в основном 16-разрядными (за исключением Win32s, своего рода уровня совместимости, который соединяет 16 и 32, но здесь мы проигнорируем), в большей степени зависели от DOS и использовали только совместную многозадачность - это та, где они не заставляют работающую программу отключаться; они ждут, пока запущенная программа выдаст контроль (в основном, скажите «Я сделал», сказав ОС запустить следующую программу, которая ожидает).
Многозадачность была кооперативной, как и в старых версиях MacOS (хотя в отличие от многозадачной DOS 4.x, в которой использовалась вытесняющая многозадачность). Задача должна была уступить ОС, чтобы запланировать другую задачу. Урожайность была встроена в определенные вызовы API, особенно в обработку сообщений. Пока задание обрабатывало сообщения своевременно, все было замечательно. Если задача перестала обрабатывать сообщения и была занята выполнением некоторого цикла обработки, многозадачности больше не было.
Что касается того, как ранние программы Windows могли дать контроль:
В Windows 3.1 используется совместная многозадачность. Это означает, что каждому приложению, которое находится в процессе выполнения, предписывается периодически проверять очередь сообщений, чтобы выяснить, запрашивает ли какое-либо другое приложение использование ЦП, и, если да, передать управление этому приложению. , Тем не менее, многие приложения Windows 3.1 будут проверять очередь сообщений лишь редко или не проверять ее и монополизировать управление процессором столько времени, сколько им требуется. Превентивная многозадачная система, такая как Windows 95, отнимает управление процессором у запущенного приложения и распределяет его среди тех, которые имеют более высокий приоритет в зависимости от потребностей системы.
Все, что увидит DOS, - это запущенное приложение (Windows или другое), которое будет передавать управление без выхода. Теоретически, вытесняющая многозадачность может быть реализована поверх DOS в любом случае с использованием часов реального времени и аппаратных прерываний, чтобы принудительно передать управление планировщику. Как комментирует Тонни, на самом деле это делали некоторые операционные системы, работающие поверх DOS.
Примечание: были некоторые комментарии по поводу 386 расширенного режима Windows 3.x, являющегося 32-разрядным и поддерживающим вытесняющую многозадачность.
Это интересный случай. Подводя итог , связанный сообщение в блоге, 386 расширенный режим был в основном 32-разрядный гипервизор, который бежал виртуальных машин. Внутри одной из этих виртуальных машин работал стандартный режим Windows 3.x, который выполняет все перечисленное выше.
MS-DOS также будет работать внутри этих виртуальных машин, и, очевидно, они были преимущественно многозадачными, поэтому кажется, что гипервизор с расширенным режимом 386 будет распределять временные интервалы ЦП между виртуальными машинами (одна из которых работала нормально 3.x, а другая - MS). -DOS), и каждая виртуальная машина будет делать свое дело - 3.x будет работать совместно в многозадачном режиме, в то время как MS-DOS будет однозадачной.
Сама DOS была однозадачной на бумаге, но она поддерживала программы TSR , которые оставались бы в фоновом режиме, пока не были вызваны аппаратным прерыванием. Далеко от истинной многозадачности, но не полностью однозадачной.
Ну, строго говоря, битность и многозадачность не зависят друг от друга. Должна быть возможность реализовать любой многозадачный режим в любой битности. Однако переход от 16-разрядных процессоров к 32-разрядным процессорам также представил другие аппаратные функции, которые могли бы упростить реализацию упреждающей многозадачности.
Кроме того, поскольку 32-разрядные программы были новыми, было проще заставить их работать, когда они принудительно отключены - что могло привести к поломке некоторых устаревших 16-разрядных программ.
Конечно, это все домыслы. Если вы действительно хотите знать, почему MS не реализовала вытесняющую многозадачность в Windows 3.x (несмотря на расширенный режим 386), вам нужно будет спросить кого-то, кто там работал.
Кроме того, я хотел бы исправить ваше предположение, что Windows 95 была просто оболочкой для DOS;)
Он постоянно запускал одну программу, называемую windows. Тот распределял время процессора (и другие ресурсы) между различными программами.
Рассмотрим эту аналогию:
У вас есть офис, в котором может быть только один человек (этот человек называется мистер или миссис DOS). Этот человек работает над одной вещью в то время. Например, он звонит одному человеку и начинает общаться с ним 24 часа в сутки.
Теперь замените этого человека мистером секретарем. (окна). Он будет звонить кому-то и все время с ним разговаривать (все еще одна задача). Затем через некоторое время другой человек скажет: «Я уже достаточно поговорил. Иди поговори с кем-нибудь и перезвони мне чуть-чуть ".
Мистер секретарь позвонит другому человеку. Общайтесь с этим, пока этот человек не скажет то же самое. Затем он позвонит следующему человеку, пока не окажется в конце списка людей, с которыми можно поговорить. В это время это начнется снова на вершине.
Если вы добавите несколько процессоров, это станет еще сложнее. :)
В современной операционной системе операционная система контролирует все аппаратные ресурсы, а запущенные приложения хранятся в песочницах. Приложению не разрешен доступ к памяти, которую ОС не выделяла этому приложению, и оно не может напрямую обращаться к аппаратным устройствам на компьютере. Если требуется аппаратный доступ, приложение должно взаимодействовать через драйверы устройств.
ОС может применить этот контроль, потому что он заставляет ЦП перейти в защищенный режим.
DOS, с другой стороны, никогда не входит в защищенный режим, а остается в реальном режиме *. В реальном режиме работающие приложения могут выполнять все, что хотят, например, напрямую обращаться к оборудованию. Но приложение, работающее в реальном режиме, также может указать ЦП перейти в защищенный режим.
И эта последняя часть позволяет приложениям, таким как Windows 95, запускать многопоточную среду, даже если они были в основном запущены из DOS.
На самом деле DOS (Disk Operating System) была не чем иным, как системой управления файлами. Он предоставил файловую систему, механизмы навигации по файловой системе, несколько инструментов и возможность запуска приложений. Это также позволило некоторым приложениям оставаться резидентными, например, драйверы мыши и эмуляторы EMM. Но он не пытался контролировать аппаратное обеспечение компьютера, как это делает современная ОС.
* Когда DOS был впервые создан в 70-х годах, защищенный режим не существовал в CPU. Только в середине 80-х годов процессор 80286 защищенного режима стал частью процессора.
До Windows 3.x, которая была первой версией для многозадачных приложений DOS, были такие программы, как DesqView, которые могли бы делать то же самое. Например, если один запускает три сеанса DOS одновременно, то DesqView создаст четыре виртуальные машины. Каждый из трех сеансов DOS будет думать, что они "владеют" всей машиной, за исключением того, что ни один из них на самом деле не выполняет файловый ввод-вывод. Вместо этого версия DOS, работающая в каждом сеансе, будет исправлена так, что она будет пересылать любые запросы для файлового ввода-вывода специальному сеансу, который был выделен для этой цели. Поскольку аппаратное обеспечение текстового режима ПК будет непрерывно отображать содержимое области памяти в виде символов; DesqView может позволить каждому сеансу иметь свой собственный виртуальный экран, сопоставляя диапазон 0xB8000-0xB9FFF каждого сеанса с собственной областью ОЗУ и периодически копируя область текущего приложения в буфер физического экрана. Графическая поддержка была намного сложнее, потому что 256 КБ ОЗУ на плате дисплея контролировалось с использованием 64 КБ адресного пространства, некоторых регистров ввода-вывода и некоторого "интересного" оборудования, которое требовало чтения и записи в определенных специфических последовательностях. В текстовом режиме, когда приложение записывало что-то в текстовый буфер, был записан, 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 с пути и заняла место при запуске (тогда вы часто запускали Windows из командной строки DOS).
Хороший вопрос. В MS-DOS ядро было монолитным, то есть оно обрабатывало только одну задачу за раз по сравнению с новым современным ядром, которое было реализовано в Windows 9x и текущей версии. Вы можете проверить больше здесь.