Biorąc pod uwagę, że DOS był systemem jednozadaniowym i powiązania, które miał z wczesnymi wersjami systemu Windows, w jaki sposób wcześniejsze wersje systemu Windows radziły sobie z wielozadaniowością? Dzisiejszy post z pytaniami i odpowiedziami dla SuperUser zawiera odpowiedzi na to pytanie.
Dzisiejsza sesja pytań i odpowiedzi przychodzi do nas dzięki uprzejmości SuperUser — pododdziału Stack Exchange, społecznościowej grupy witryn internetowych z pytaniami i odpowiedziami.
Zrzut ekranu systemu Windows 95 dzięki uprzejmości Wikipedia.
Pytanie
Czytnik SuperUser LeNoob chce wiedzieć, jak starsze wersje systemu Windows mogły działać jako systemy wielozadaniowe?:
Czytałem, że DOS jest systemem jednozadaniowym. Ale jeśli starsze wersje systemu Windows (w tym również Windows 95?) były tylko wrapperami dla DOS, jak mogły działać jako wielozadaniowy system operacyjny?
Dobre pytanie! Jak starsze wersje systemu Windows zdołały działać jako systemy wielozadaniowe?
Odpowiedź
Współtwórcy SuperUser Bob i Pete mają dla nas odpowiedź. Po pierwsze, Bob:
Okna 95 był czymś znacznie więcej niż „tylko opakowaniem” dla MS-DOS. Cytując Raymonda Chena:
- MS-DOS służył dwóm celom w Windows 95: 1.) Służył jako program ładujący. & 2.) Działał jako 16-bitowa warstwa sterownika starszego urządzenia.
Windows 95 faktycznie zahaczył/zmienił prawie cały system MS-DOS, zachowując go jako warstwę kompatybilności, jednocześnie wykonując wszystkie ciężkie prace. Zaimplementowano także wielozadaniowość z wywłaszczaniem dla programów 32-bitowych.
Przed Windows 95
Windows 3.x i starsze były w większości 16-bitowe (z wyjątkiem Win32, rodzaj warstwy kompatybilności, która łączy 16 i 32, ale tutaj to zignorujemy), były bardziej zależne od DOS-u i używały tylko kooperacyjnego wielozadaniowości – czyli taki, w którym nie wymuszają wyłączenia uruchomionego programu; czekają, aż uruchomiony program przejmie kontrolę (zasadniczo powiedz „Skończyłem”, mówiąc systemowi operacyjnemu, aby uruchomił następny oczekujący program).
- Wielozadaniowość była kooperacyjna, podobnie jak w starych wersjach MacOS (choć w przeciwieństwie do Multitasking DOS 4.x, który posiadał wielozadaniowość z wywłaszczaniem). Zadanie musiało ustąpić systemowi operacyjnemu, aby zaplanować inne zadanie. Wyniki zostały wbudowane w niektóre wywołania API, w szczególności przetwarzanie komunikatów. Dopóki zadanie przetwarzało wiadomości w odpowiednim czasie, wszystko było świetnie. Jeśli zadanie przestało przetwarzać wiadomości i było zajęte wykonywaniem jakiejś pętli przetwarzania, wielozadaniowość przestała istnieć.
Architektura systemu Windows 3.x
Jeśli chodzi o to, jak wczesne programy Windows dawałyby kontrolę:
- Windows 3.1 wykorzystuje kooperacyjną wielozadaniowość – co oznacza, że każda aplikacja, która jest w trakcie działania, jest instruowana, aby okresowo sprawdzała kolejkę komunikatów, aby dowiedzieć się, czy jakakolwiek inna aplikacja prosi o użycie procesora, a jeśli tak, przekazywać kontrolę tej aplikacji. Jednak wiele aplikacji Windows 3.1 sprawdzałoby kolejkę komunikatów rzadko lub wcale i monopolizowało kontrolę nad procesorem na tyle czasu, ile było to potrzebne. Wielozadaniowy system z wywłaszczaniem, taki jak Windows 95, odbierze kontrolę nad procesorem od działającej aplikacji i przekaże ją tym, które mają wyższy priorytet, w oparciu o potrzeby systemu.
Wszystko, co widzi DOS, to ta pojedyncza aplikacja (Windows lub inna) działająca, która przekaże kontrolę bez wychodzenia. Teoretycznie wielozadaniowość z wywłaszczaniem może być prawdopodobnie zaimplementowana na wierzchu systemu DOS z wykorzystaniem zegara czasu rzeczywistego i przerwań sprzętowych, aby wymusić kontrolę nad harmonogramem. NS Komentarze Tonny, zostało to faktycznie zrobione przez niektóre systemy operacyjne działające na DOS-ie.
386 Tryb rozszerzony?
Uwaga: pojawiło się kilka komentarzy 386 tryb rozszerzony Windows 3.x jest 32-bitowy i obsługuje wielozadaniowość z wywłaszczaniem.
To ciekawy przypadek. Podsumowując linkowane post na blogu, tryb rozszerzony 386 był w zasadzie 32-bitowym hiperwizorem, który uruchamiał maszyny wirtualne. Wewnątrz jednej z tych maszyn wirtualnych działał standardowy tryb Windows 3.x, który wykonuje wszystkie wymienione powyżej rzeczy.
MS-DOS również działałby wewnątrz tych maszyn wirtualnych i najwyraźniej były one prewencyjnie wielozadaniowe – więc wydaje się, że hiperwizor 386 w trybie rozszerzonym będzie dzielił wycinki czasu procesora między maszyny wirtualne (z których jedna działała normalnie 3.x i inne, które działały pod MS-DOS), a każda maszyna wirtualna zrobi swoje – 3.x będzie współpracował wielozadaniowo, podczas gdy MS-DOS będzie jednozadaniowy.
MS-DOS
Sam DOS był jednozadaniowy na papierze, ale miał wsparcie dla TSR programy, które pozostaną w tle, dopóki nie zostaną wyzwolone przez przerwanie sprzętowe. Daleko od prawdziwej wielozadaniowości, ale też nie w pełni jednozadaniowej.
Cała ta rozmowa o bitowości? Pytałem o wielozadaniowość!
Cóż, ściśle mówiąc, bitowość i wielozadaniowość nie są od siebie zależne. Powinno być możliwe zaimplementowanie dowolnego trybu wielozadaniowości w dowolnej bitowości. Jednak przejście z procesorów 16-bitowych na procesory 32-bitowe wprowadziło również inne funkcje sprzętowe, które mogły ułatwić wdrożenie wielozadaniowości z wywłaszczaniem.
Ponadto, ponieważ programy 32-bitowe były nowe, łatwiej było je uruchomić, gdy zostały przymusowo wyłączone – co mogło spowodować uszkodzenie niektórych starszych programów 16-bitowych.
Oczywiście to wszystko spekulacje. Jeśli naprawdę chcesz wiedzieć, dlaczego MS nie zaimplementował wielozadaniowości z wywłaszczaniem w systemie Windows 3.x (niezależnie od trybu rozszerzonego 386), będziesz musiał zapytać kogoś, kto tam pracował.
Chciałem również poprawić twoje założenie, że Windows 95 był tylko opakowaniem dla DOS-a.
Następnie odpowiedź od Pete’a:
W nowoczesnym systemie operacyjnym system operacyjny kontroluje wszystkie zasoby sprzętowe, a uruchomione aplikacje są trzymane w piaskownicach. Aplikacja nie może uzyskiwać dostępu do pamięci, której system operacyjny nie przydzielił tej aplikacji, i nie może uzyskać bezpośredniego dostępu do urządzeń sprzętowych w komputerze. Jeśli wymagany jest dostęp do sprzętu, aplikacja musi komunikować się za pośrednictwem sterowników urządzeń.
System operacyjny może wymusić tę kontrolę, ponieważ zmusza procesor do wejścia tryb obronny.
Z drugiej strony DOS nigdy nie wchodzi w tryb chroniony, ale pozostaje w tryb rzeczywisty (*patrz poniżej). W trybie rzeczywistym uruchomione aplikacje mogą wykonywać wszystko, czego chcą, tj. uzyskiwać bezpośredni dostęp do sprzętu. Ale aplikacja działająca w trybie rzeczywistym może również nakazać procesorowi przejście w tryb chroniony.
A ta ostatnia część pozwala aplikacjom takim jak Windows 95 na uruchomienie wielowątkowego środowiska, nawet jeśli zostały one w zasadzie uruchomione z DOS-a.
DOS (Disk Operating System) był, o ile mi wiadomo, niewiele więcej niż systemem zarządzania plikami. Zapewniał system plików, mechanizmy poruszania się po systemie plików, kilka narzędzi oraz możliwość uruchamiania aplikacji. Pozwoliło to również na zachowanie rezydencji niektórych aplikacji, tj. sterowników myszy i emulatorów EMM. Ale nie próbował kontrolować sprzętu w komputerze, tak jak robi to nowoczesny system operacyjny.
*Kiedy DOS został po raz pierwszy stworzony w latach 70., tryb chroniony nie istniał w procesorze. Dopiero procesor 80286 w połowie lat 80. sprawił, że tryb chroniony stał się częścią procesora.
Koniecznie przejdź do oryginalnego wątku i przeczytaj ożywioną dyskusję na ten temat, korzystając z poniższego linku!
Masz coś do dodania do wyjaśnienia? Dźwięk w komentarzach. Chcesz przeczytać więcej odpowiedzi od innych doświadczonych technologicznie użytkowników Stack Exchange? Sprawdź pełny wątek dyskusji tutaj.