If-Koubou

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

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

Biorąc pod uwagę, że DOS był systemem operacyjnym o pojedynczej obsłudze i powiązaniami z wcześniejszymi wersjami systemu Windows, to w jaki sposób wcześniejsze wersje systemu Windows zdołały wykonać wielozadaniowość? 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 - poddziału Stack Exchange, społecznościowego forum 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 ?:

Czytałem, że DOS jest systemem operacyjnym przeznaczonym tylko do jednego zadania. Ale jeśli starsze wersje systemu Windows (w tym Windows 95?) Były tylko opakowaniem dla systemu DOS, to jak mogłyby działać jako wielozadaniowy system operacyjny?

Dobre pytanie! W jaki sposób starsze wersje systemu Windows mogły działać jako systemy wielozadaniowe?

Odpowiedź

Współautorzy SuperUser, Bob i Pete, mają dla nas odpowiedź. Po pierwsze, 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. Zaimplementowano 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-a, i używały tylko kooperatywnego wielozadaniowości - 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

Jeśli chodzi o to, jak wczesne programy systemu Windows mogłyby uzyskać kontrolę:

  • System Windows 3.1 korzysta ze współpracy wielozadaniowej - co oznacza, ż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ę ta aplikacja. Jednak wiele aplikacji systemu Windows 3.1 sprawdzi kolejkę komunikatów tylko nieczęsto lub wcale i zmonopolizuje sterowanie procesorem przez tyle czasu, ile będzie wymagało. Uprzedzający 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), która przejmie kontrolę bez wychodzenia. Teoretycznie, wyprzedzające wielozadaniowość może być ewentualnie zastosowane na wierzchu DOS, tak czy inaczej, z wykorzystaniem 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 dotyczące 386 rozszerzonego trybu systemu Windows 3.x, który ma 32-bitowy format, i obsługuje zapobiegawcze 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 robi wszystkie rzeczy wymienione powyżej.

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 jednostronny.

MS-DOS

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

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

Dokładnie mówiąc, bitność i wielozadaniowość nie są od siebie zależne. Powinno być możliwe zaimplementowanie dowolnego trybu wielozadaniowego w dowolnym bit-ness. Jednak przejście z 16-bitowych procesorów do 32-bitowych procesorów również wprowadziło inną funkcjonalność sprzętową, która ułatwiłaby wdrożenie 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 16-bitowe programy.

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 Windows 95 był tylko opakowaniem dla 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 z DOS.

DOS (Disk Operating System) był, o ile mi wiadomo, 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 DOS został po raz pierwszy stworzony w 1970 roku, tryb chroniony nie istniał w CPU. Dopiero 80286 procesor w połowie 1980 roku 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.