DOS가 단일 작업 인 경우 이전 버전의 Windows에서 멀티 태스킹이 어떻게 가능 했습니까?

DOS는 단일 작업 OS라는 것을 읽었습니다.

그러나 이전 버전의 Windows (Windows 95 포함)가 DOS의 래퍼 인 경우 Windows는 어떻게 멀티 태스킹 OS로 실행될 수 있습니까?

윈도우 95

Windows 95 는 MS-DOS의 "단지 래퍼"이상이었습니다 . 인용 레이몬드 첸 :

MS-DOS는 Windows 95에서 두 가지 목적으로 사용되었습니다.

• 부트 로더로 사용되었습니다.
• 16 비트 레거시 장치 드라이버 계층 역할을했습니다.

Windows 95는 실제로 거의 모든 MS-DOS를 연결 / 오버로드하여 모든 무거운 작업 자체를 수행하면서 호환성 계층으로 유지합니다. 또한 32 비트 프로그램에 대한 선점 형 멀티 태스킹을 구현했습니다.

Windows 95 이전

Windows 3.x 및 이전 버전은 대부분 16 비트 (16과 32를 연결하는 일종의 호환성 계층 인 Win32 제외)이며 DOS에 더 의존하고 협력적인 멀티 태스킹 만 사용했습니다. 실행중인 프로그램을 강제로 끄지 않는 곳; 실행중인 프로그램이 제어를 수행 할 때까지 기다립니다 (기본적으로 OS에서 대기중인 다음 프로그램을 실행하도록 지시하여 "완료되었습니다"라고 말함).

멀티 태스킹은 이전 버전의 MacOS와 마찬가지로 협력 적이었습니다 (선점 형 멀티 태스킹을 사용한 멀티 태스킹 DOS 4.x와는 달리). 다른 작업을 예약하려면 작업이 OS에 양보되어야했습니다. 수율은 특정 API 호출, 특히 메시지 처리에 내장되었습니다. 작업이 메시지를 적시에 처리하는 한 모든 것이 훌륭했습니다. 작업이 메시지 처리를 중단하고 일부 처리 루프를 실행하는 중이면 멀티 태스킹이 더 이상 없었습니다.

Windows 3.x 아키텍처

초기 Windows 프로그램이 제어권을 얻는 방법은 다음과 같습니다.

Windows 3.1은 협력적인 멀티 태스킹을 사용합니다. 즉, 실행중인 각 응용 프로그램은 주기적으로 메시지 큐를 확인하여 다른 응용 프로그램이 CPU 사용을 요청하는지 확인하고 해당되는 경우 해당 응용 프로그램에 대한 제어를 수행하도록 지시받습니다. . 그러나 많은 Windows 3.1 응용 프로그램은 메시지 대기열을 자주 또는 전혀 확인하지 않고 필요한만큼 CPU 제어를 독점합니다. Windows 95와 같은 선점 형 멀티 태스킹 시스템은 실행중인 응용 프로그램에서 CPU를 제어하여 시스템 요구에 따라 우선 순위가 높은 시스템으로 분산시킵니다.

출처

모든 DOS는이 단일 응용 프로그램 (Windows 또는 기타)이 실행 중이며 종료하지 않고 제어를 전달합니다. 이론적으로, 선점 형 멀티 태스킹은 실시간 클록과 스케줄러를 강제로 제어하기위한 하드웨어 인터럽트를 사용하여 DOS 위에서 구현 될 수 있습니다. Tonny가 언급 했듯이 실제로 이것은 DOS에서 실행되는 일부 OS에서 수행되었습니다.

386 확장 모드?

참고 : Windows 3.x의 386 고급 모드 에 대해서는 32 비트이며 선점 형 멀티 태스킹을 지원하는 의견이 있습니다 .

흥미로운 사례입니다. 링크 된 블로그 게시물 을 요약하면 386 확장 모드는 기본적으로 가상 머신을 실행하는 32 비트 하이퍼 바이저였습니다. 이러한 가상 머신 중 하나에서 Windows 3.x 표준 모드를 ​​실행하여 위에 나열된 모든 작업을 수행합니다.

MS-DOS는 이러한 가상 머신 내에서도 실행되며 선점 적으로 멀티 태스킹 된 것 같습니다. 따라서 386 확장 모드 하이퍼 바이저는 가상 머신 (일반적인 3.x를 실행 한 시스템과 MS를 실행 한 시스템 사이)에서 CPU 시간 조각을 공유하는 것으로 보입니다. -DOS), 각 VM은 자체 작업을 수행합니다. 3.x는 협력 적으로 멀티 태스킹하고 MS-DOS는 단일 작업입니다.

MS-DOS

DOS 자체는 종이에 대한 단일 작업이지만 하드웨어 인터럽트에 의해 트리거 될 때까지 백그라운드에서 유지되는 TSR 프로그램 을 지원했습니다 . 진정한 멀티 태스킹과는 거리가 멀지 만 완전히 단일 작업은 아닙니다.

이 모든 비트 비트 이야기? 멀티 태스킹에 대해 물었습니다!

비트 니스와 멀티 태스킹은 엄밀히 말하면 서로 의존하지 않습니다. 비트 단위로 멀티 태스킹 모드를 구현할 수 있어야합니다. 그러나 16 비트 프로세서에서 32 비트 프로세서로 이동함에 따라 선점 형 멀티 태스킹을보다 쉽게 ​​구현할 수있는 다른 하드웨어 기능이 도입되었습니다.

또한 32 비트 프로그램이 새로워 졌기 때문에 강제로 전환 할 때 기존 16 비트 프로그램이 손상되었을 수 있습니다.

물론 이것은 모든 추측입니다. MS가 왜 Windows 3.x에서 선점 형 멀티 태스킹을 구현하지 않았는지 (386 확장 모드에도 불구하고) 왜 실제로 알고 싶다면 거기에서 일한 사람에게 문의해야합니다.

또한 Windows 95가 DOS의 래퍼라는 가정을 수정하고 싶었습니다.)

Windows라는 단일 프로그램을 지속적으로 실행했습니다. 그 하나는 다른 프로그램간에 CPU 시간 (및 기타 리소스)을 분산시킵니다.

이 비유를 고려하십시오.

한 번에 한 사람 만 가질 수있는 사무실이 있습니다 (이 사람을 mister 또는 missus DOS라고합니다). 그 사람은 한 번에 한 가지 일을합니다. 예를 들어, 한 사람에게 전화를 걸어 24 시간 연중 무휴 채팅을 시작합니다.

이제 그 사람을 미스터 비서로 교체하십시오. (창문). 누군가에게 전화를 걸고 항상 대화를 나눕니다 (아직 단일 작업). 그런 다음 얼마 후에 다른 사람은 "지금은 충분히 이야기했습니다. 다른 사람과 이야기를 나누고 조금만 다시 전화하십시오"라고 말합니다.

비서관이 상대방에게 연락 할 것입니다. 그 사람이 같은 것을 말할 때까지 그 사람과 대화하십시오. 그런 다음 대화 할 사람 목록이 끝날 때까지 다음 사람을 호출합니다. 그때 상단에서 다시 시작됩니다.

• 기술적 인 용어로 이것을 협동 멀티 태스킹이라고합니다. 다른 사람이 충분한 CPU 시간을 가지고 있다고 말해야합니다. 그렇게하지 않으면 모든 것이 무너집니다.
• 현대 시스템은 훨씬 더 똑똑합니다. 선제 멀티 태스킹 포함. 비서가 알람 시계를 설정하고 5 분 후에 상대방을 차단한다고 생각하십시오. "좋은 Jane이다. 그러나 나는 지금 Joe와 이야기해야한다. 나는 조금 후에 다시 전화 할 것이다.-누르십시오."

여러 개의 프로세서를 추가하면 훨씬 더 복잡해집니다. :)

최신 운영 체제에서 운영 체제는 모든 하드웨어 리소스를 제어하며 실행중인 응용 프로그램은 샌드 박스에 보관됩니다. 응용 프로그램은 OS가 해당 응용 프로그램에 할당하지 않은 메모리에 액세스 할 수 없으며 컴퓨터의 하드웨어 장치에 직접 액세스 할 수 없습니다. 하드웨어 액세스가 필요한 경우 응용 프로그램은 장치 드라이버를 통해 통신해야합니다.

OS는 강제로 CPU가 보호 모드 로 들어가기 때문에이 제어를 시행 할 수 있습니다 .

반면 DOS는 보호 모드로 들어 가지 않지만 실제 모드 *로 유지됩니다 . 실제 모드에서 실행중인 응용 프로그램은 하드웨어에 직접 액세스하는 등 원하는 모든 작업을 수행 할 수 있습니다. 그러나 실제 모드에서 실행되는 응용 프로그램은 CPU에게 보호 모드로 들어가도록 지시 할 수도 있습니다.

그리고 마지막 부분은 Windows 95와 같은 응용 프로그램이 기본적으로 DOS에서 시작되었지만 멀티 스레드 환경을 시작할 수 있도록합니다.

DOS (디스크 운영 체제)는 파일 관리 시스템에 그치지 않았습니다. 파일 시스템, 파일 시스템 탐색 메커니즘, 몇 가지 도구 및 응용 프로그램 실행 가능성을 제공했습니다. 또한 일부 응용 프로그램 (예 : 마우스 드라이버 및 EMM 에뮬레이터)을 상주 상태로 유지할 수있었습니다. 그러나 최신 OS와 같은 방식으로 컴퓨터의 하드웨어를 제어하려고 시도하지 않았습니다.

* 70 년대에 DOS가 처음 만들어 졌을 때, CPU에는 보호 모드가 없었습니다. 80 년대 중반 80286 프로세서가 보호 모드가 CPU의 일부가되기 전까지는 아니었다.

멀티 태스킹 DOS 응용 프로그램의 첫 번째 버전 인 Windows 3.x 이전에는 DesqView와 같은 프로그램도있었습니다. 예를 들어 한 번에 세 개의 DOS 세션을 실행하는 경우 DesqView는 네 개의 가상 머신을 생성합니다. 세 개의 DOS 세션은 각각 파일 I / O를 수행하지 않는 것을 제외하고는 전체 시스템을 "소유"했다고 생각합니다. 대신, 각 세션에서 실행중인 DOS 버전이 패치되어 파일 I / O 요청이 특수 목적 세션으로 전달됩니다. PC의 텍스트 모드 하드웨어는 메모리 영역의 내용을 문자로 지속적으로 표시하기 때문에; DesqView는 각 세션의 0xB8000-0xB9FFF 범위를 자체 RAM 영역에 매핑하여 각 세션마다 자체 가상 화면을 갖도록 할 수 있습니다. 및 현재 애플리케이션의 영역을 물리적 스크린 버퍼에 주기적으로 복사하는 단계를 포함한다. 디스플레이 보드의 256K RAM은 64K의 주소 공간, 일부 I / O 레지스터 및 특정 특정 순서로 읽고 쓰는 것이 필요한 일부 "흥미로운"하드웨어를 사용하여 제어되기 때문에 그래픽 지원이 훨씬 어려워졌습니다. 텍스트 모드에서 응용 프로그램이 텍스트 버퍼에 무언가를 썼을 때 DesqView는 다음 타이머 틱의 디스플레이에 복사되어야한다는 것을 나타내는 플래그를 설정할 수있었습니다. 주어진 시간에 텍스트 버퍼에 첫 번째 쓰기 만 DesqView의 개입이 필요합니다. 다른 모든 타이머는 다음 타이머 틱에 통합됩니다. 디스플레이 보드의 256K RAM은 64K의 주소 공간, 일부 I / O 레지스터 및 특정 특정 순서로 읽고 쓰는 것이 필요한 일부 "흥미로운"하드웨어를 사용하여 제어 되었기 때문입니다. 텍스트 모드에서 응용 프로그램이 텍스트 버퍼에 무언가를 썼을 때 DesqView는 다음 타이머 틱의 디스플레이에 복사되어야한다는 것을 나타내는 플래그를 설정할 수있었습니다. 주어진 시간에 텍스트 버퍼에 첫 번째 쓰기 만 DesqView의 개입이 필요합니다. 다른 모든 타이머는 다음 타이머 틱에 통합됩니다. 디스플레이 보드의 256K RAM은 64K의 주소 공간, 일부 I / O 레지스터 및 특정 특정 순서로 읽고 쓰는 것이 필요한 일부 "흥미로운"하드웨어를 사용하여 제어 되었기 때문입니다. 텍스트 모드에서 응용 프로그램이 텍스트 버퍼에 무언가를 썼을 때 DesqView는 다음 타이머 틱의 디스플레이에 복사되어야한다는 것을 나타내는 플래그를 설정할 수있었습니다. 주어진 시간에 텍스트 버퍼에 첫 번째 쓰기 만 DesqView의 개입이 필요합니다. 다른 모든 타이머는 다음 타이머 틱에 통합됩니다. DesqView는 다음 타이머 틱의 디스플레이에 복사되어야 함을 나타내는 플래그를 설정할 수 있습니다. 주어진 시간에 텍스트 버퍼에 첫 번째 쓰기 만 DesqView의 개입이 필요합니다. 다른 모든 타이머는 다음 타이머 틱에 통합됩니다. DesqView는 다음 타이머 틱의 디스플레이에 복사되어야 함을 나타내는 플래그를 설정할 수 있습니다. 주어진 시간에 텍스트 버퍼에 첫 번째 쓰기 만 DesqView의 개입이 필요합니다. 다른 모든 타이머는 다음 타이머 틱에 통합됩니다.

반대로 그래픽 모드를 가상화하려면 DeskView에서 모든 개별 쓰기를 트랩하여 메모리 또는 I / O 레지스터를 표시해야합니다. 이로 인해 메모리 쓰기 속도가 약 100 배 줄어들고 그래픽 프로그램은 텍스트 프로그램보다 훨씬 더 많은 데이터를 작성해야하므로 대부분의 그래픽 소프트웨어의 실시간 가상화는 실용적이지 못했습니다. 대신, 포 그라운드 응용 프로그램이 될 때까지 그래픽 일시 중지를 시도한 비포 그라운드 응용 프로그램을 사용하여 화면을 완전히 제어하여 그래픽을 처리했습니다. 컨트롤이 다른 응용 프로그램으로 전환되면 DesqView는 모든 그래픽 레지스터의 상태를 복사 한 다음 전환하려고 시도합니다. 그래픽 응용 프로그램으로 다시 전환하면 DesqView는 저장된 상태를 복원합니다.

어떤 방식으로, 공유 리소스가 거의없고 응용 프로그램이 서로 상호 작용할 필요가 없었기 때문에 멀티 태스킹 비 그래픽 DOS 응용 프로그램은 멀티 태스킹 Windows 응용 프로그램보다 쉽습니다. 반대로 Windows에서는 클립 보드와 같은 것을 처리하거나 한 프로그램의 창을 다른 창을 가리는 방식으로 이동할 수 있어야합니다. Windows 95는 코드가 화면에 그려지려고 할 때 화면 영역을 사용할 수 없게하는 창 시스템과 같은 기능을 포함하여 이러한 제한을 극복 할 수있는 최초의 Windows 버전입니다 (도면이 마스크되는 효과가 있음) ).

멀티 태스킹은 응용 프로그램을 동시에 실행한다는 환상에 지나지 않습니다. 결국에는 동시 실행으로 인식되지만 실제로 프로세스 A, B 및 C는 A, B, C, A, B, C, A, B의 순서로 CPU 시간을 공유합니다. 아주 빨리. 실제로 두 프로세스가 동시에 실행되고 있지 않습니다.

따라서 MS-DOS 멀티 태스킹을 한 프로세스 일시 중지, 다음 프로세스를 짧은 시간 동안 실행, 일시 중지, 첫 번째 프로세스로 건너 뛰는 등의 방법으로 완벽하게 수행 할 수 있습니다.

멀티 태스킹은 CPU가 이러한 프로세스를 계속 회전하고 최종 사용자에게 동시에 보이도록 충분히 빠르기 시작했을 때 개발 된 영리한 기능입니다.

기억하는 사람들은 Windows가 너무 느리기 때문에 여전히 DOS4GW에서 게임을 실행하고있었습니다.

한 작업에만 초점을 맞출 수는 있지만 한 작업에서 다른 작업으로 빠르게 이동하는 간단한 단계입니다. 이런 식으로 멀티 태스킹 인 것처럼 보였지만 실제로는 1, 다음에 중점을 두었습니다.

내가 여기에 언급하지 않은 한 가지는 흥미 롭습니다.

Windows 3.0은 선점 형 멀티 태스킹 시스템이 아니 었으며 OS X까지 다른 MacOS 버전과 마찬가지로 협력 적이었습니다. 다른 앱이 조치를 취하기 전에 한 앱이 호출에서 돌아와야했습니다.

댓글 작성자가 나에게 상기시켜 주었 듯이, DOS 앱은 많은 작업을 수행했다. "협업 적으로"멀티 태스킹으로 작성되지 않았기 때문입니다 (이것은 항상이를 사용하는 시스템에 내장되어야합니다).

당시에는 오늘날의 장치 드라이버를 대신 한 TSR (Terminate-Stay Resident)이라는 프로그램이있었습니다. 이러한 드라이버는 OS 이벤트 핸들러 중 하나에 자신을 삽입하여 독립적으로 (일반적으로 자체 스레드에서) 실행됩니다. Windows는 일반적으로 그들에 대해 알지 못했으며 낮은 수준에서 실행되었습니다.

이들은 실제로 Windows 응용 프로그램은 아니지만 프린터 드라이버, COM 드라이버 등과 같은 Windows 3.1 이전의 모든 스레딩 활동이 수행 된 방식이었습니다.

Windows 3.1은 멀티 태스킹 이었지만 DOS는 그렇지 않았지만 Windows 3.1은 작업을 중단하고 시작했을 때 대신했습니다 (이전에는 DOS 프롬프트에서 종종 Windows를 시작했습니다).

좋은 질문. MS-DOS에서 커널은 단일체 (monolithic)로 Windows 9x 및 현재 버전에서 구현 된 새로운 최신 커널에 비해 한 번에 하나의 작업 만 처리했습니다. 자세한 내용은 여기 를 참조 하십시오 .