Jeśli DOS jest jednozadaniowy, w jaki sposób możliwa była wielozadaniowość w starej wersji systemu Windows?

Czytam, że DOS jest systemem jednozadaniowym.

Ale jeśli stare wersje systemu Windows (w tym także Windows 95?) Były tylko opakowaniami systemu DOS, w jaki sposób system Windows mógłby działać jako system wielozadaniowy?

Windows 95

Windows 95 był czymś więcej niż „tylko opakowaniem” dla MS-DOS . Cytując Raymonda Chena:

MS-DOS służył dwóm celom w Windows 95.

• Służył jako moduł ładujący.
• Działał on jako 16-bitowa, starsza warstwa sterowników urządzeń.

Windows 95 tak naprawdę zaczepił / zastąpił prawie cały MS-DOS, utrzymując go jako warstwę kompatybilności podczas wykonywania samego ciężkiego podnoszenia. Zaimplementowano także zapobiegawcze wielozadaniowość dla programów 32-bitowych.

Przed Windows 95

Windows 3.xi starsze były w większości 16-bitowe (z wyjątkiem Win32s, niejako warstwy kompatybilności łączącej 16 i 32, ale tutaj to zignorujemy), były bardziej zależne od DOS i używały tylko wielozadaniowości kooperacyjnej - to jest ten, w którym nie zmuszają działającego programu do wyłączenia; czekają, aż uruchomiony program przejdzie kontrolę (w zasadzie powiedz „skończyłem”, mówiąc systemowi operacyjnemu, aby uruchomił następny program, który czeka).

Wielozadaniowość była kooperatywna, podobnie jak w starych wersjach MacOS (choć w przeciwieństwie do Multitasking DOS 4.x, w którym zastosowano zapobiegawczą wielozadaniowość). Zadanie musiało ustąpić systemowi operacyjnemu, aby zaplanować inne zadanie. Wydajności zostały wbudowane w niektóre wywołania API, w szczególności przetwarzanie wiadomości. Tak długo, jak 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ść już nie istniała.

Architektura systemu Windows 3.x.

Jeśli chodzi o to, jak wczesne programy systemu Windows dają kontrolę:

System Windows 3.1 korzysta z wielozadaniowości kooperacyjnej - co oznacza, że ​​każda aplikacja, która jest w trakcie działania, otrzymuje polecenie okresowego sprawdzania kolejki komunikatów, aby dowiedzieć się, czy jakakolwiek inna aplikacja prosi o użycie procesora, a jeśli tak, aby przejąć kontrolę nad tą aplikacją . Jednak wiele aplikacji systemu Windows 3.1 rzadko lub wcale nie sprawdza kolejki komunikatów i monopolizuje kontrolę nad procesorem przez tyle czasu, ile potrzeba. Prewencyjny system wielozadaniowy, taki jak Windows 95, odbierze kontrolę procesora od działającej aplikacji i rozdzieli ją na te, które mają wyższy priorytet w zależności od potrzeb systemu.

źródło

Jedyne, co DOS zobaczyłby, to działająca jedna aplikacja (Windows lub inna), która przekazywała kontrolę bez wychodzenia. Teoretycznie zapobiegawcza wielozadaniowość może być zaimplementowana na DOS-ie za pomocą zegara czasu rzeczywistego i przerwań sprzętowych, aby wymusić kontrolę nad harmonogramem. Jak komentuje Tonny , tak naprawdę zrobiły to niektóre systemy operacyjne działające na DOS-ie.

Tryb ulepszony 386?

Uwaga: pojawiły się komentarze na temat ulepszonego trybu 386 systemu Windows 3.x w wersji 32-bitowej i obsługującego zapobiegawczą wielozadaniowość.

To ciekawy przypadek. Podsumowując połączony post na blogu , tryb ulepszony 386 był w zasadzie 32-bitowym hiperwizorem, który obsługiwał maszyny wirtualne. Wewnątrz jednej z tych maszyn wirtualnych działał tryb standardowy Windows 3.x, który wykonuje wszystkie powyższe czynności.

MS-DOS również działałby wewnątrz tych maszyn wirtualnych i najwyraźniej były one zapobiegawczo wielozadaniowe - wydaje się więc, że hiperwizor w trybie rozszerzonym 386 będzie dzielić przedziały czasu procesora między maszynami wirtualnymi (jedna z nich działała normalnie w wersji 3.x i inne z MS -DOS), a każda maszyna wirtualna zrobi to samo - 3.x współpracowałby wielozadaniowo, podczas gdy MS-DOS byłby jednozadaniowy.

MS-DOS

Sam DOS był jednozadaniowy na papierze, ale miał wsparcie dla programów TSR , które pozostawały w tle, dopóki nie zostaną wywołane przez przerwanie sprzętowe. Dalekie od prawdziwej wielozadaniowości, ale nie w pełni jednozadaniowe.

Cała ta gadanina o bitości? Zapytałem o wielozadaniowość!

Cóż, ściśle mówiąc, bitowość i wielozadaniowość nie są od siebie zależne. Powinno być możliwe najlepsze wdrożenie dowolnego trybu wielozadaniowości w dowolnej bitowości. Jednak przejście z procesorów 16-bitowych na procesory 32-bitowe wprowadziło także inne funkcje sprzętowe, które mogłyby ułatwić wdrożenie zapobiegawczej wielozadaniowości.

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

Oczywiście to wszystko spekulacje. Jeśli naprawdę chcesz wiedzieć, dlaczego MS nie wdrożyło zapobiegawczego wielozadaniowości w systemie Windows 3.x (pomimo trybu rozszerzonego 386), musisz zapytać kogoś, kto tam pracował.

Chciałem również poprawić twoje założenie, że Windows 95 był tylko opakowaniem dla DOS;)

Ciągle działał jeden program o nazwie windows. Ten rozkłada czas procesora (i inne zasoby) między różne programy.

Rozważ tę analogię:

Masz biuro, w którym może znajdować się tylko jedna osoba naraz (ta osoba nazywa się DOS). Ta osoba pracuje jednocześnie nad jedną rzeczą. Np. Dzwoni do jednej osoby i zaczyna z nią rozmawiać 24/7.

Teraz zastępujesz tę osobę sekretarzem pana. (Windows). Telefonuje do kogoś i cały czas z nim rozmawia (wciąż jedno zadanie). Potem po pewnym czasie druga osoba powie „Na razie wystarczająco dużo rozmawiałam. Idź porozmawiaj z kimś innym i oddzwoń za chwilę”.

Sekretarz zadzwoni do drugiej osoby. Rozmawiaj z nim, dopóki ta osoba nie powie tego samego. Następnie zadzwoni do następnej osoby, dopóki nie znajdzie się na końcu listy osób do rozmowy. W tym momencie zacznie się ponownie u góry.

• Pod względem technicznym nazywa się to współpracującym wielozadaniowością. Wymaga od drugiej osoby stwierdzenia, że ​​ma wystarczająco dużo czasu procesora. Jeśli tego nie zrobimy, wszystko się rozpadnie.
• Nowoczesne systemy są znacznie inteligentniejsze. W tym wyprzedzająca wielozadaniowość. Pomyśl o tym, jak sekretarka ustawia budzik i odcina drugą osobę po 5 minutach. „To miła Jane. Ale muszę teraz porozmawiać z Joe. Oddzwonię za chwilę. - Kliknij.”

Jeśli dodasz wiele procesorów, stanie się to jeszcze bardziej skomplikowane. :)

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 przydzielił tej aplikacji, i nie ma bezpośredniego dostępu do urządzeń w komputerze. Jeśli wymagany jest dostęp sprzętowy, aplikacja musi komunikować się poprzez sterowniki urządzeń.

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

Z drugiej strony DOS nigdy nie przechodzi w tryb chroniony, ale pozostaje w trybie rzeczywistym *. W trybie rzeczywistym działające aplikacje mogą wykonywać dowolne czynności, np. Uzyskiwać bezpośredni dostęp do sprzętu. Ale aplikacja działająca w trybie rzeczywistym może również nakazać procesorowi przejście do trybu chronionego.

Ta ostatnia część pozwala aplikacjom takim jak Windows 95 na uruchomienie środowiska wielowątkowego, nawet jeśli zostały one zasadniczo uruchomione z DOS.

DOS (Disk Operating System) był, afaik, niewiele więcej niż systemem zarządzania plikami. Zapewniał system plików, mechanizmy nawigacji po systemie plików, kilka narzędzi oraz możliwość uruchamiania aplikacji. Umożliwiło to również pozostanie niektórym aplikacjom, np. Sterownikom myszy i emulatorom EMM. Ale nie próbował kontrolować sprzętu w komputerze tak, jak robi to współczesny system operacyjny.

* Kiedy DOS został stworzony w latach 70-tych, tryb chroniony nie istniał w CPU. Tryb chroniony stał się częścią procesora dopiero w 80286 w połowie lat 80-tych.

Przed Windows 3.x, który był pierwszą wersją wielozadaniowych aplikacji DOS, istniały programy takie jak DesqView, które mogły działać podobnie. Gdyby jedna np. Uruchomiła trzy sesje DOS jednocześnie, DesqView stworzyłby cztery maszyny wirtualne. Każda z trzech sesji DOS pomyślałaby, że „jest właścicielem” całego komputera, z wyjątkiem tego, że żadna z nich nie wykonałaby operacji we / wy pliku. Zamiast tego wersja DOS działająca w każdej sesji zostałaby załatana, aby przekazywał wszelkie żądania we / wy pliku do specjalnej sesji, która była przeznaczona do tego celu. Ponieważ tryb tekstowy komputera PC stale wyświetlałby zawartość obszaru pamięci jako znaki; DesqView może pozwolić każdej sesji mieć własny ekran wirtualny, mapując zakres 0xB8000-0xB9FFF każdej sesji do własnego obszaru pamięci RAM, oraz okresowe kopiowanie obszaru bieżącej aplikacji do fizycznego bufora ekranu. Obsługa graficzna była znacznie trudniejsza, ponieważ 256 K pamięci RAM na płycie kontrolowanej było kontrolowane przy użyciu 64 K przestrzeni adresowej, niektórych rejestrów I / O i pewnego „interesującego” sprzętu, który wymagał odczytu i zapisu w określonych sekwencjach. W trybie tekstowym, gdy aplikacja zapisuje coś do bufora tekstowego, DesqView może ustawić flagę wskazującą, że należy ją skopiować na wyświetlacz przy następnym tyknięciu zegara; tylko pierwszy zapis do bufora tekstowego w danym tyknięciu czasu wymagałby interwencji DesqView; wszystkie pozostałe zostaną skonsolidowane do następnego tyknięcia timera. ponieważ 256K pamięci RAM na płycie wyświetlacza było kontrolowane przy użyciu 64K przestrzeni adresowej, niektórych rejestrów I / O i jakiegoś „interesującego” sprzętu, który wymagał odczytu i zapisu w określonych sekwencjach. W trybie tekstowym, gdy aplikacja zapisuje coś do bufora tekstowego, DesqView może ustawić flagę wskazującą, że należy ją skopiować na wyświetlacz przy następnym tyknięciu zegara; tylko pierwszy zapis do bufora tekstowego w danym tyknięciu czasu wymagałby interwencji DesqView; wszystkie pozostałe zostaną skonsolidowane do następnego tyknięcia timera. ponieważ 256K pamięci RAM na płycie wyświetlacza było kontrolowane przy użyciu 64K przestrzeni adresowej, niektórych rejestrów I / O i jakiegoś „interesującego” sprzętu, który wymagał odczytu i zapisu w określonych sekwencjach. W trybie tekstowym, gdy aplikacja zapisuje coś do bufora tekstowego, DesqView może ustawić flagę wskazującą, że należy ją skopiować na wyświetlacz przy następnym tyknięciu zegara; tylko pierwszy zapis do bufora tekstowego w danym tyknięciu czasu wymagałby interwencji DesqView; wszystkie pozostałe zostaną skonsolidowane do następnego tyknięcia timera. DesqView może ustawić flagę wskazującą, że należy ją skopiować na wyświetlacz przy następnym takcie timera; tylko pierwszy zapis do bufora tekstowego w danym tyknięciu czasu wymagałby interwencji DesqView; wszystkie pozostałe zostaną skonsolidowane do następnego tyknięcia timera. DesqView może ustawić flagę wskazującą, że należy ją skopiować na wyświetlacz przy następnym takcie timera; tylko pierwszy zapis do bufora tekstowego w danym tyknięciu czasu wymagałby interwencji DesqView; wszystkie pozostałe zostaną skonsolidowane do następnego tyknięcia timera.

Natomiast wirtualizacja trybu graficznego wymagałaby DeskView do przechwytywania każdego pojedynczego zapisu do pamięci wyświetlacza lub rejestrów I / O. Biorąc pod uwagę, że spowolniłoby to zapisywanie pamięci około 100 razy, a programy graficzne musiały zapisywać znacznie więcej danych niż programy tekstowe, wirtualizacja większości programów graficznych w czasie rzeczywistym nie była praktyczna. Zamiast tego grafika była obsługiwana przez dowolną aplikację nieprzykładową, która próbowała wstrzymać grafikę, aż stała się aplikacją pierwszego planu, a następnie dała jej pełną kontrolę nad ekranem. Gdy sterowanie zostanie przełączone na inną aplikację, DesqView będzie próbował wykonać kopię stanu wszystkich rejestrów graficznych, a następnie przełączy się. Po przełączeniu z powrotem do aplikacji graficznej DesqView przywróci zapisany stan.

W pewnym sensie wielozadaniowe, nie graficzne aplikacje DOS były łatwiejsze niż wielozadaniowe aplikacje Windows, ponieważ było bardzo niewiele zasobów współdzielonych, a aplikacje nie musiały ze sobą współdziałać. Natomiast w systemie Windows konieczne jest radzenie sobie z takimi rzeczami, jak schowek lub możliwość, że okna jednego programu mogą poruszać się w taki sposób, że zasłaniają okna innego. Windows 95 był pierwszą wersją systemu Windows, która mogła przezwyciężyć takie ograniczenia, włączając takie elementy, jak system okienkowy, który mógł pomieścić, gdy obszar ekranu stał się niedostępny, gdy kod próbował do niego narysować (z efektem maskowania rysunku ).

Wielozadaniowość to nic innego jak iluzja uruchamiania aplikacji jednocześnie. Jest to postrzegane jako jednoczesne wykonanie po twojej stronie, ale w rzeczywistości procesy A, B i C współużytkują czas procesora w następującej kolejności: A, B, C, A, B, C, A, B ... po prostu się włączają i bardzo szybko. W rzeczywistości nie działają dwa procesy jednocześnie.

Jest więc możliwe, aby wykonać wielozadaniowość MS-DOS, zmuszając go do wstrzymania jednego procesu, uruchomienia następnego na krótki czas, zatrzymania tego, powrotu do pierwszego i tak dalej.

Wielozadaniowość to po prostu sprytna funkcja opracowana, gdy procesory zaczęły być wystarczająco szybkie, aby obracać się między tymi procesami i sprawiać, że użytkownik końcowy wydaje się jednocześnie.

Dla tych, którzy pamiętają, gry były nadal uruchamiane na DOS4GW, ponieważ Windows był po prostu zbyt wolny.

Mimo że może skupić się tylko na jednym zadaniu, wystarczy, że szybko przejdzie od jednego do drugiego. W ten sposób wydawało się, że to wielozadaniowość, ale tak naprawdę koncentruje się na 1, potem na innym, potem na innym itd.

Jedna rzecz, o której tu nie wspominałem, jest dość interesująca:

Windows 3.0 nie był wyprzedzającym systemem wielozadaniowym, współpracował jak wszystkie wersje MacOS aż do OS X - Jedna aplikacja musiała wrócić z połączenia, zanim jakakolwiek inna aplikacja mogła podjąć jakiekolwiek działanie.

Jednak jak przypomniał mi komentator, aplikacje DOS były wielozadaniowe. Wynika to z faktu, że nie zostały napisane do wielozadaniowości „Cooperative” (zawsze musi to być wbudowane w systemy, które z niej korzystają).

W tym czasie istniały programy zwane TSR (Terminate-Stay Resident), które zastąpiły dzisiejsze sterowniki urządzeń. Te sterowniki działałyby niezależnie - generalnie w swoim własnym wątku, wstawiając się do jednej z procedur obsługi zdarzeń systemu operacyjnego. Windows ogólnie o nich nie wiedział, działały na niższym poziomie.

Nie były to tak naprawdę aplikacje dla systemu Windows, ale były to wszystkie działania związane z wątkami przed Windows 3.1, takie jak sterowniki drukarek, sterowniki komputerów itp.

Chociaż system Windows 3.1 był wielozadaniowy, system DOS nie, ale system Windows 3.1 po prostu odepchnął dos i przeszkodził, gdy się uruchomił (wtedy często uruchamiałeś system Windows z monitu DOS).

Dobre pytanie. W MS-DOS jądro było monolityczne, co oznacza, że ​​obsługiwało tylko jedno zadanie na raz, w porównaniu z nowym, nowoczesnym jądrem, które zostało zaimplementowane w systemie Windows 9x i bieżącej wersji. Możesz sprawdzić więcej tutaj .