Jak wielozadaniowość była możliwa w starszych wersjach systemu Windows?

Biorąc pod uwagę, że DOS był systemem operacyjnym o pojedynczej obsłudze i powiązaniami z wczesnymi wersjami systemu Windows, to w jaki sposób wcześniejsze wersje systemu Windows zdołały wykonać wielozadaniowość? Dzisiejszy post z pytaniami i odpowiedziami SuperUser zawiera odpowiedzi na to pytanie.

Dzisiejsza sesja pytań i odpowiedzi przychodzi do nas dzięki uprzejmości SuperUser - poddziału Stack Exchange, opartego na społecznościach grupowania witryn z pytaniami i odpowiedziami.

Windows 95 screenshot dzięki uprzejmości Wikipedii.

Pytanie

Czytnik SuperUser LeNoob chce wiedzieć, w jaki sposób starsze wersje systemu Windows mogły działać jako systemy wielozadaniowe ?:

Czytam, że DOS jest systemem operacyjnym przeznaczonym tylko do jednego zadania. Ale czy starsze wersje systemu Windows (w tym Windows 95?) Były tylko opakowaniem dla systemu DOS, jak mogły działać jako wielozadaniowe systemy operacyjne?

Dobre pytanie! Jak starsze wersje systemu Windows działały jako systemy wielozadaniowe?

Odpowiedź

Współautorzy SuperUser, Bob i Pete, mają dla nas odpowiedź. Najpierw Bob:

Windows 95 był czymś znacznie więcej niż "tylko opakowaniem" dla MS-DOS. Quoting Raymond Chen:

• MS-DOS spełniał dwa cele w Windows 95: 1.) Służył jako boot loader. & 2.) Działał jako 16-bitowa starsza warstwa sterownika urządzenia.

Windows 95 faktycznie zahaczył / przesłonił prawie wszystkie MS-DOS, zachowując go jako warstwę kompatybilności, wykonując jednocześnie wszystkie ciężkie operacje podnoszenia. Zaimplementował również zapobiegawcze wielozadaniowość dla programów 32-bitowych.

Pre-Windows 95

Windows 3.x i starsze były w większości 16-bitowe (z wyjątkiem Win32s, rodzaj warstwy kompatybilności, która łączy 16 i 32, ale zignorujemy to tutaj), były bardziej zależne od DOS i korzystały tylko ze współpracy wielozadaniowej - to jest ten, w którym nie wymuszają przejścia uruchomionego programu; czekają, aż uruchomiony program przejmie kontrolę (w zasadzie powiedz "Zrobiłem", informując system operacyjny, aby uruchomił następny program, który czeka).

• Wielozadaniowość była wspólna, podobnie jak w starszych wersjach systemu MacOS (choć w przeciwieństwie do wielozadaniowego systemu DOS 4.x, w którym zastosowano zapobiegawcze wielozadaniowość). Zadanie musiało ustąpić systemowi operacyjnemu, aby zaplanować inne zadanie. Plony zostały wbudowane w niektóre wywołania API, w szczególności przetwarzanie wiadomości. Dopóki zadanie przetwarzało wiadomości w odpowiednim czasie, wszystko było świetnie. Jeśli zadanie zatrzymało przetwarzanie komunikatów i było zajęte wykonywaniem pętli przetwarzania, nie było już zadań wielozadaniowych.

Architektura Windows 3.x.

Co do tego, jak wczesne programy systemu Windows mogłyby uzyskać kontrolę:

• System Windows 3.1 korzysta ze współpracy wielozadaniowej - oznacza to, że każda aplikacja, która jest w trakcie uruchamiania, jest polecana do okresowego sprawdzania kolejki komunikatów, aby dowiedzieć się, czy jakakolwiek inna aplikacja żąda użycia procesora, a jeśli tak, to uzyskać kontrolę nad ta aplikacja. Jednak wiele aplikacji systemu Windows 3.1 sprawdzałoby kolejkę komunikatów rzadko lub wcale i monopolizowało sterowanie procesorem przez tyle czasu, ile było to konieczne. Prewencyjny system wielozadaniowy, taki jak Windows 95, przejmuje kontrolę nad procesorem od działającej aplikacji i dystrybuuje ją do tych, które mają wyższy priorytet w zależności od potrzeb systemu.

Źródło

Wszystko, co zobaczy DOS, to ta pojedyncza aplikacja (Windows lub inna) działająca, która przejmie kontrolę bez wychodzenia. Teoretycznie, wyprzedzające wielozadaniowość można ewentualnie zaimplementować nad DOS i tak za pomocą zegara czasu rzeczywistego i przerwań sprzętowych, aby wymusić kontrolę nad harmonogramem. Jak komentuje Tonny, zostało to faktycznie zrobione przez niektóre systemy operacyjne działające na systemie DOS.

386 Tryb ulepszony?

Uwaga: pojawiły się komentarze na temat 386 rozszerzonego trybu systemu Windows 3.x, który jest 32-bitowy i wspiera wyprzedzające wielozadaniowość.

To interesujący przypadek. Aby podsumować połączony wpis 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ł tryb standardowy Windows 3.x, który wykonuje wszystkie wymienione powyżej czynności.

MS-DOS działałby również wewnątrz tych maszyn wirtualnych i najwyraźniej były one z wyprzedzeniem wielozadaniowe - więc wygląda na to, że hiperwizor trybu 386 w trybie rozszerzonym będzie współdzielić przedziały czasu procesora między maszynami wirtualnymi (z których jedna działa normalnie 3.x i inne, które uruchamiały MS-DOS), a każda VM wykona swoją własną rzecz - 3.x będzie współpracować wielozadaniowo, podczas gdy MS-DOS będzie jednostronnie.

MS-DOS

Sam DOS był jednorazowy na papierze, ale miał wsparcie dla programów TSR, które pozostałyby w tle, dopóki nie zostanie uruchomione przez przerwanie sprzętowe. Daleki od prawdziwego wielozadaniowości, ale nie w pełni jednemu zadaniu.

Cała ta rozmowa o bitości? Pytałem o wielozadaniowość!

Cóż, ściśle mówiąc, bitność i wielozadaniowość nie są od siebie zależne. Powinno być możliwe zaimplementowanie dowolnego trybu wielozadaniowego w dowolnym bit-ności. Jednak przejście z 16-bitowych procesorów do 32-bitowych procesorów wprowadziło także inną funkcjonalność sprzętową, która ułatwiłaby realizację wyprzedzającego wielozadaniowości..

Ponadto, ponieważ programy 32-bitowe były nowe, łatwiej było je uruchomić, gdy zostały przymusowo wyłączone - co mogło zepsuć niektóre starsze programy 16-bitowe.

Oczywiście, to wszystko spekulacja. Jeśli naprawdę chcesz wiedzieć, dlaczego MS nie wdrożyło zapobiegawczej wielozadaniowości w Windows 3.x (niezależnie od trybu ulepszonego 386), będziesz musiał zapytać kogoś, kto tam pracował.

Ponadto chciałem poprawić założenie, że system Windows 95 był tylko opakowaniem dla systemu DOS.

Później odpowiedź Pete'a:

W nowoczesnym systemie operacyjnym system operacyjny kontroluje wszystkie zasoby sprzętowe, a uruchomione aplikacje są przechowywane w piaskownicach. Aplikacja nie ma dostępu do pamięci, której system operacyjny nie przypisał do 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 pomocą sterowników urządzeń.

System operacyjny może wymusić tę kontrolę, ponieważ zmusza procesor do wejścia w tryb chroniony.

Z kolei DOS nigdy nie wchodzi w tryb chroniony, ale pozostaje w trybie rzeczywistym (*patrz poniżej). W trybie rzeczywistym uruchomione aplikacje mogą wykonywać dowolne czynności, tj. Bezpośrednio uzyskiwać dostęp do sprzętu. Ale aplikacja działająca w trybie rzeczywistym może również nakazać procesorowi wejście w tryb chroniony.

Ta ostatnia część umożliwia aplikacjom takim jak Windows 95 uruchomienie środowiska wielowątkowego, mimo że zostały one uruchomione w DOS.

DOS (Disk Operating System) był, o ile wiem, niewiele większy od systemu zarządzania plikami. Dostarczył system plików, mechanizmy do poruszania się w systemie plików, kilka narzędzi i możliwość uruchamiania aplikacji. Pozwoliło to również niektórym aplikacjom pozostać rezydentami, tj. Sterownikami myszy i emulatorami EMM. Ale nie próbował kontrolować sprzętu w komputerze tak, jak robi to nowoczesny system operacyjny.

*Kiedy system DOS został po raz pierwszy stworzony w 1970 roku, tryb chroniony nie istniał w procesorze. Dopiero 80286 procesor w połowie 1980 roku, ż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!

Czy masz coś do dodania do wyjaśnienia? Dźwięk w komentarzach. Chcesz przeczytać więcej odpowiedzi od innych użytkowników Stack Exchange, którzy znają się na technologii? Sprawdź cały wątek dyskusji tutaj.