Hogyan volt lehetséges a többfeladatos feladat a Windows régebbi verzióiban?

Figyelembe véve, hogy a DOS egyfeladatos operációs rendszer volt és a Windows korai verzióival kötött kapcsolatok, hogy a Windows korábbi verziói hogyan tudtak több feladatot végrehajtani? A mai SuperUser Q&A hozzászólás a kérdésre adott válaszokat vizsgálja.

A mai Kérdések és válaszok munkamenet a Jóvagyon - a Stack Exchange alosztályának, a közösség által vezérelt Q&A webhelyek csoportjának köszönhetően..

Windows 95 képernyőkép a Wikipedia jóvoltából.

A kérdés

A SuperUser olvasó LeNoob azt szeretné tudni, hogy a Windows régebbi verziói többfunkciós rendszerként működhettek ?:

Elolvastam, hogy a DOS egyfeladatos operációs rendszer. De ha a Windows régebbi verziói (beleértve a Windows 95-t is) csak a DOS csomagolói voltak, hogyan működhettek a többfeladatos operációs rendszer?

Jó kérdés! Hogyan sikerült a Windows régebbi verziói többfunkciós rendszerként futtatni?

A válasz

A SuperUser közreműködők Bob és Pete válaszolnak számunkra. Először fel, Bob:

A Windows 95 sokkal több volt, mint az „csak egy csomagolás” az MS-DOS számára. Idézve Raymond Chen-t:

• Az MS-DOS két célt szolgáltatott a Windows 95: 1-ben:). & 2.) 16-bites örökölt eszközmeghajtó rétegként működött.

A Windows 95 valójában csak az összes MS-DOS-t összekapcsolta / felülbírálta, így kompatibilitási rétegként tartotta magát, miközben minden nehéz emelést végez. A 32 bites programokra is elővigyázatos több feladatot hajtott végre.

Előzetes Windows 95

A Windows 3.x és az idősebbek többnyire 16 bitesek voltak (a Win32-ek kivételével, egyfajta kompatibilitási réteg, amelyet a 16-as és 32-es hidak, de itt figyelmen kívül hagyunk), jobban függtek a DOS-tól, és csak együttműködő több feladatot használtak - ez az, ahol nem kényszeríti a futó programot, hogy kilépjen; várják, hogy a futó program vezérlést eredményezzen (alapvetően azt mondja, hogy „kész vagyok”, ha azt mondja az operációs rendszernek, hogy futtassa a következő várakozó programot).

• A többfeladatosság együttműködő volt, csakúgy, mint a MacOS régi verzióiban (bár ellentétben a többfeladatos DOS 4.x-vel, amely előfeltételes több feladatot végzett). A feladatnak egy másik feladat ütemezéséhez kellett hozzáadnia az operációs rendszert. A hozamokat bizonyos API hívásokba építették be, nevezetesen az üzenetek feldolgozásába. Mindaddig, amíg egy feladat feldolgozta az üzeneteket, minden jó volt. Ha egy feladat leállította az üzenetek feldolgozását, és elfoglalt volt néhány feldolgozási ciklus végrehajtása, a többfeladatos feladat nem volt több.

Windows 3.x architektúra

Ami a Windows programok korai ellenőrzését biztosítja:

• A Windows 3.1 együttműködő, többfeladatos feladatot használ - ez azt jelenti, hogy minden olyan futó alkalmazás, amelyik folyamatban van, utasítást kap, hogy rendszeresen ellenőrizze az üzenetsort, hogy megtudja, hogy bármely más alkalmazás kéri-e a CPU használatát, és ha igen, a vezérlést alkalmazást. Sok Windows 3.1 alkalmazás azonban csak ritkán vagy egyáltalán nem ellenőrzi az üzenetsort, és monopolizálja a CPU vezérlését annyi ideig, amennyi szükséges. A Windows 95-höz hasonló, előremutató, többfeladatos rendszer a CPU-vezérlést távol tartja a futó alkalmazástól, és továbbítja azokat azoknak, akik nagyobb prioritást élveznek a rendszer igényei alapján.

Forrás

Minden DOS látná, hogy ez az egyetlen alkalmazás (Windows vagy más) fut-e, ami az irányítás nélkül elhagyna. Elméletileg előzetes többfeladatos feladatot valósíthatunk meg a DOS tetején egy valós idejű óra- és hardveres megszakításokkal, hogy erőteljesen irányítsák az ütemezőt. Mint Tonny megjegyzéseit, ezt néhány operációs rendszer végzi a DOS tetején.

386 Továbbfejlesztett mód?

Megjegyzés: a Windows 3.x 386-os továbbfejlesztett módjáról néhány 32-bites észrevétel történt, és támogatja a megelőző többfeladatos feladatot.

Ez egy érdekes eset. Összefoglalva a kapcsolódó blogbejegyzést, a 386 továbbfejlesztett mód alapvetően egy 32 bites hipervizor volt, amely virtuális gépeket futtatott. Az egyik ilyen virtuális gépen Windows 3.x szabványos módot futtattak, amely az összes fent felsorolt ​​cuccot tartalmazza.

Az MS-DOS ezen virtuális gépeken belül is futna, és látszólag előzőleg többfeladatos feladat volt - úgy tűnik, hogy a 386 továbbfejlesztett módú hypervisor megosztja a CPU időszeleteket a virtuális gépek között (amelyek közül az egyik normális 3.x és mások, amelyek MS-DOS-t futtattak), és mindegyik VM saját dolgot fog tenni - 3.x együttműködik több feladattal, míg az MS-DOS egyszeri feladattal.

MS-DOS

A DOS maga is papíron volt egyszeri feladat, de támogatta a TSR programokat, amelyek a háttérben maradnak, amíg a hardver megszakítása nem indult. Távol az igazi többfeladatos feladattól, de nem teljesen egyfelől a feladatra sem.

Ez a beszélgetés kicsit? Megkérdeztem a több feladatot!

Nos, szigorúan figyelembe véve, hogy a bitesség és a többfeladatos feladat nem függ egymástól. Lehetővé kell tenni, hogy bármilyen többfeladatos módot végrehajtson bármilyen bitben. A 16 bites processzorokról a 32 bites processzorokra való áttérés azonban más hardver funkciókat is bevezetett, amelyek könnyebben megvalósíthatták a többfunkciós feladatokat..

Továbbá, mivel a 32 bites programok újdonságok voltak, könnyebben tudták őket dolgozni, amikor erőszakkal ki lettek kapcsolva - ami esetleg megsemmisített néhány örökölt 16 bites programot.

Természetesen ez minden spekuláció. Ha valóban szeretné tudni, hogy miért nem hajtotta végre az MS-t a Windows 3.x rendszerben az elsőbbségi többfunkciós feladatok végrehajtásában (386 továbbfejlesztett mód), akkor meg kell kérdeznie valakit, aki ott dolgozik.

Azt is ki akartam igazítani, hogy a Windows 95 csak egy csomagolás volt a DOS számára.

A Pete válaszát követi:

Egy modern operációs rendszerben az operációs rendszer ellenőrzi az összes hardver erőforrást, és az alkalmazások futtatása homokozóban történik. Az alkalmazás nem férhet hozzá olyan memóriához, amelyet az operációs rendszer nem adott hozzá az alkalmazáshoz, és nem férhet hozzá közvetlenül a számítógép hardvereszközeihez. Ha hardveres hozzáférés szükséges, az alkalmazásnak kommunikálnia kell az eszközillesztőkön.

Az operációs rendszer képes végrehajtani ezt az irányítást, mert arra kényszeríti a CPU-t, hogy belépjen védett módba.

Ezzel szemben a DOS soha nem lép be védett módba, de valós módban marad (*lásd lentebb). Valós módban a futó alkalmazások bármit is végrehajthatnak, azaz közvetlenül a hardverhez. Azonban egy valós módban futó alkalmazás megmondhatja a CPU-nak, hogy védett módba lépjen.

Ez az utolsó rész lehetővé teszi az olyan alkalmazások, mint a Windows 95, hogy többszálas környezetet indítsanak el, bár alapvetően a DOS-ból indultak.

A DOS (Disk Operating System) a tudásom szerint nem sokkal több, mint egy fájlkezelő rendszer. Adott egy fájlrendszert, a fájlrendszer navigálására szolgáló mechanizmusokat, néhány eszközt és az alkalmazások elindításának lehetőségét. Lehetővé tette továbbá, hogy egyes alkalmazások tartózkodjanak, azaz egérvezetők és EMM emulátorok. De nem próbálta vezérelni a számítógép hardverét a modern operációs rendszer működésének módjában.

*Amikor a DOS-t először az 1970-es években hozták létre, a védett mód nem létezett a CPU-ban. Az 1980-as évek közepén a 80286-as processzortól kezdve a védett mód a CPU részévé vált.

Győződjön meg róla, hogy az alábbi témakörön keresztül böngészhet az eredeti szálra, és olvassa el a témával kapcsolatos élénk vitát!

Van valami, amit hozzá kell adni a magyarázathoz? Kikapcsolja a megjegyzéseket. Szeretne további válaszokat olvasni más tech-savvy Stack Exchange felhasználóktól? Nézze meg a teljes beszélgetés szálát itt.