Se o DOS é de tarefa única, como a multitarefa era possível na versão antiga do Windows?

Question

Eu li que o DOS é um SO de tarefa única.

Mas se versões antigas do Windows (incluindo também o Windows 95?) eram apenas invólucros do DOS, como o Windows poderia funcionar como um sistema operacional multitarefa?

    

Answer 1

Windows 95

O Windows 95 era muito mais do que "apenas um wrapper" para o MS-DOS . Citando Raymond Chen:

MS-DOS served two purposes in Windows 95.

• It served as the boot loader.
• It acted as the 16-bit legacy device driver layer.

O Windows 95 realmente conectou / anulou praticamente todo o MS-DOS, mantendo-o como uma camada de compatibilidade enquanto fazia todo o trabalho pesado propriamente dito. Também implementou multitarefa preemptiva para programas de 32 bits.

Pré-Windows 95

O Windows 3.xe mais antigo eram em sua maioria de 16 bits (com exceção do Win32s, um tipo de camada de compatibilidade que liga 16 e 32, mas vamos ignorar isso aqui), eram mais dependentes do DOS e usavam apenas cooperativas multitarefa - é aquela em que eles não forçam a execução de um programa em execução; eles esperam que o programa em execução gere controle (basicamente, diga "Estou pronto" dizendo ao SO para executar o próximo programa que está aguardando).

Multitasking was cooperative, just like in old versions of MacOS (though unlike Multitasking DOS 4.x, which sported preemptive multitasking). A task had to yield to the OS in order to schedule a different task. The yields were built into certain API calls, notably message processing. As long as a task processed messages in a timely manner, everything was great. If a task stopped processing messages and was busy executing some processing loop, multitasking was no more.

Arquitetura do Windows 3.x

Quanto aos primeiros programas do Windows gerariam controle:

Windows 3.1 uses cooperative multitasking - meaning that each application that is in the process of running is instructed to periodically check a message queue to find out if any other application is asking for use of the CPU and, if so, to yield control to that application. However, many Windows 3.1 applications would check the message queue only infrequently, or not at all, and monopolize control of the CPU for as much time as they required. A preemptive multitasking system like Windows 95 will take CPU control away from a running application and distribute it to those that have a higher priority based on the system's needs.

fonte

Tudo o que o DOS veria é este único aplicativo (Windows ou outro) em execução, que passaria o controle sem sair. Em teoria, a multitarefa preemptiva pode possivelmente ser implementada na parte superior do DOS com o uso de um relógio em tempo real e interrupções de hardware para forçar o controle do agendador. Como Tonny comments , isso foi realmente feito por alguns sistemas operacionais rodando em cima do DOS.

386 modo avançado?

Observação: houve alguns comentários sobre o 386 modo avançado do Windows 3.x sendo de 32 bits e suportando multitarefa preemptiva.

Este é um caso interessante. Para resumir a postagem de blog vinculada, o modo 386 avançado foi basicamente um -bit hypervisor, que executava máquinas virtuais. Dentro de uma dessas máquinas virtuais executava o modo padrão do Windows 3.x, que faz todas as coisas listadas acima.

O MS-DOS também rodaria dentro dessas máquinas virtuais e, aparentemente, elas eram multitarefas preventivamente - assim, parece que o hipervisor de modo avançado 386 compartilhará intervalos de tempo da CPU entre as máquinas virtuais (uma das quais executou normal 3.xe outros que executava o MS-DOS), e cada VM faria sua própria tarefa - 3.x cooperaria de forma multitarefa, enquanto o MS-DOS teria uma única tarefa.

MS-DOS

O próprio DOS era único no papel, mas tinha suporte para os programas TSR , que permaneceriam no fundo até ser acionado por uma interrupção de hardware. Longe da verdadeira multitarefa, mas também não é totalmente com uma única tarefa.

Toda essa conversa de bit-ness? Eu perguntei sobre multitarefa!

Bem, falando estritamente, o bit e o multitarefa não dependem um do outro. Deve ser possível implementar qualquer modo de multitarefa em qualquer bit. No entanto, a mudança de processadores de 16 bits para processadores de 32 bits também introduziu outra funcionalidade de hardware que poderia ter facilitado a multitarefa preemptiva.

Além disso, como os programas de 32 bits eram novos, era mais fácil fazê-los funcionar quando eram forçados a sair - o que poderia ter quebrado alguns programas legados de 16 bits.

Claro, isso é tudo especulação. Se você realmente quer saber por que o MS não implementou multitarefa preemptiva no Windows 3.x (apesar do modo 386 avançado), você terá que perguntar a alguém que trabalhou lá.

Além disso, eu queria corrigir sua suposição de que o Windows 95 era um invólucro para o DOS;)

    

Answer 2

Ele executou continuamente um único programa, o chamado windows. Aquele espalha o tempo da CPU (e outros recursos) entre diferentes programas.

Considere esta analogia:

Você tem um escritório que só pode ter uma pessoa no momento (Essa pessoa é chamada de senhor ou patroa DOS). Essa pessoa trabalha em uma coisa no momento. Por exemplo. ele telefona para uma única pessoa e começa a conversar 24/7 com ele / ela.

Agora você substitui essa pessoa pelo Sr. secretário. (janelas). Ele vai telefonar para alguém e conversar o tempo todo com ele (ainda uma única tarefa). Então, depois de algum tempo, a outra pessoa dirá: "Já falei o suficiente por enquanto. Vá falar com outra pessoa e me ligue de volta daqui a pouco".

Sr. secretária vai ligar para a outra pessoa. Converse com esse até que a pessoa diga a mesma coisa. Em seguida, ele ligará para a próxima pessoa até que esteja no final da lista de pessoas com quem falar. Naquela época, começará novamente no topo.

• Em termos técnicos, isso é chamado de multitarefa cooperativa. Isso requer que a outra pessoa diga que ele / ela teve tempo de CPU suficiente. Se alguém não faz isso, então tudo desmorona.
• Os sistemas modernos são muito mais inteligentes. Incluindo multitarefa preventiva. Pense na secretária ajustando um despertador e desligando a outra pessoa após 5 minutos. "Isso é legal, Jane. Mas eu tenho que falar com Joe agora. Vou te ligar de volta daqui a pouco. - Clique."

Se você adicionar vários processadores, isso será ainda mais complicado. :)

    

Answer 3

Em um sistema operacional moderno, o sistema operacional controla todos os recursos de hardware e os aplicativos em execução são mantidos em sandboxes. Um aplicativo não tem permissão para acessar a memória que o sistema operacional não alocou a esse aplicativo e não pode acessar diretamente os dispositivos de hardware no computador. Se o acesso ao hardware for necessário, o aplicativo deve se comunicar por meio de drivers de dispositivo.

O sistema operacional pode impor esse controle, porque força a CPU a entrar no modo protegido .

O DOS, por outro lado, nunca entra no modo protegido, mas permanece no modo real *. No modo real, os aplicativos em execução podem executar qualquer coisa que desejarem, por ex. acessar hardware diretamente. Mas um aplicativo em execução no modo real também pode informar a CPU para entrar no modo protegido.

E esta última parte permite que aplicativos como o Windows 95 iniciem um ambiente multi-encadeado mesmo que eles tenham sido basicamente lançados do DOS.

O DOS (Disk Operating System) não era, afaik, muito mais que um sistema de gerenciamento de arquivos. Ele forneceu um sistema de arquivos, mecanismos para navegar pelo sistema de arquivos, algumas ferramentas e a possibilidade de iniciar aplicativos. Também permitiu que algumas aplicações permanecessem residentes, por ex. drivers de mouse e emuladores EMM. Mas ele não tentou controlar o hardware no computador como um sistema operacional moderno faz.

* Quando o DOS foi criado pela primeira vez nos anos 70, o modo protegido não existia na CPU. Não foi até o processador 80286 em meados dos anos 80 que o modo protegido se tornou parte da CPU.

    

Answer 4

Antes do Windows 3.x, que era a primeira versão para multitarefa de aplicativos do DOS, havia programas como o DesqView, que poderiam fazer o mesmo. Se um foi, e. executando três sessões do DOS de uma vez, então o DesqView criaria quatro máquinas virtuais. Cada uma das três sessões do DOS pensaria que elas "possuíam" a máquina inteira, exceto que nenhuma delas executaria a E / S de arquivo. Em vez disso, a versão do DOS em execução em cada sessão seria corrigida para que enviasse quaisquer solicitações de E / S de arquivo para uma sessão especial, que era dedicada a essa finalidade. Já que o hardware do modo de texto do PC exibia continuamente o conteúdo de uma área da memória como caracteres; O DesqView pode permitir que cada sessão tenha sua própria tela virtual, mapeando o intervalo 0xB8000-0xB9FFF de cada sessão para sua própria área de RAM e copiando periodicamente a área do aplicativo atual para o buffer de tela física. O suporte gráfico era muito mais difícil, porque 256K de RAM na placa de exibição eram controlados usando 64K de espaço de endereço, alguns registradores de E / S e algum hardware "interessante" que exigia que as coisas fossem lidas e escritas em certas seqüências específicas. No modo de texto, quando um aplicativo gravou algo no buffer de texto foi gravado, o DesqView poderia definir um sinalizador indicando que ele deveria ser copiado para a exibição no próximo tick do timer; somente a primeira gravação no buffer de texto em um determinado tempo exigiria a intervenção do DesqView; todos os outros seriam consolidados para o próximo tick timer.

Por outro lado, a virtualização do modo gráfico exigiria que o DeskView interceptasse cada gravação individual para exibir registros de memória ou de E / S. Como isso desaceleraria as gravações de memória por um fator de cerca de 100, e os programas gráficos precisavam escrever muito mais dados do que os programas de texto, a virtualização em tempo real da maioria dos softwares gráficos não era prática. Em vez disso, os gráficos eram manipulados ao se ter qualquer aplicativo não-em primeiro plano que tentasse fazer uma pausa nos gráficos até se tornar o aplicativo em primeiro plano e, em seguida, dar-lhe controle total sobre a tela. Quando o controle mudava para um aplicativo diferente, o DesqView tentava fazer uma cópia do estado de todos os registradores gráficos e depois alternar. Ao voltar para o aplicativo gráfico, o DesqView restauraria o estado salvo.

De certa forma, os aplicativos DOS multi-tasking não-gráficos eram mais fáceis do que os aplicativos multi-tarefas do Windows porque havia muito poucos recursos compartilhados, e os aplicativos não precisavam interagir uns com os outros. No Windows, pelo contrário, é necessário lidar com coisas como a área de transferência, ou a possibilidade de que as janelas de um programa possam se mover de maneira a obscurecer as de outro. Windows 95 era a primeira versão do Windows que poderia superar tais limitações, incluindo coisas como um sistema de janelas que poderia acomodar uma área da tela ficar indisponível enquanto o código estava tentando desenhar para ele (com o efeito de que o desenho seria mascarado ).

    

Answer 5

A multitarefa nada mais é do que uma ilusão de executar aplicativos simultaneamente. É percebido como execução simultânea do seu lado, mas na verdade os processos A, B e C estão compartilhando o tempo de CPU nesta ordem: A, B, C, A, B, C, A, B ... eles simplesmente ligam e muito rapidamente. Não há dois processos sendo executados ao mesmo tempo.

Assim, é perfeitamente possível fazer multitarefa do MS-DOS fazendo-a pausar um processo, executar o próximo por um curto período de tempo, pausar esse, voltar para o primeiro e assim por diante.

A multitarefa é apenas uma característica inteligente desenvolvida quando os processadores começaram a ser rápidos o suficiente para manter a rotação através desses processos e fazê-lo parecer simultâneo ao usuário final.

Para quem se lembra, os jogos ainda estavam sendo executados no DOS4GW porque o Windows estava muito lento.

    

Answer 6

Apesar de poder focar somente em uma tarefa, o que ela faria seria um simples passo de ir rapidamente de uma para outra. Dessa forma, parecia que era multitarefa, mas na verdade apenas se concentra em 1, depois em outro, depois em outro, etc.

    

Answer 7

Uma coisa que eu não vi mencionada aqui é interessante:

O Windows 3.0 não era um sistema multitarefa preventivo; era cooperativo, como todas as versões do MacOS, até que o aplicativo OS X-One precisasse retornar de uma chamada antes que qualquer outro aplicativo pudesse realizar qualquer ação.

Como um comentarista me lembrou, no entanto, os aplicativos DOS eram multitarefas. Isto é porque eles não foram escritos para "Cooperativamente" multi-tarefa (Isso deve sempre ser construído em sistemas que o utilizam).

Na época, havia programas chamados TSRs (Terminate-Stay Resident) que ocupavam o lugar dos drivers de dispositivos atuais. Esses drivers seriam executados independentemente - geralmente em seu próprio segmento, inserindo-se em um dos manipuladores de eventos do sistema operacional. O Windows geralmente não sabia sobre eles, eles corriam em um nível mais baixo.

Estes não eram realmente aplicativos do Windows, mas eram como todas as atividades de threading ocorriam antes do Windows 3.1, como drivers de impressora, drivers de computador, etc.

Embora o windows 3.1 fosse multitarefa, o DOS não era, mas o Windows 3.1 apenas empurrava o DOS para fora do caminho e assumia quando ele era iniciado (então você frequentemente iniciava o Windows a partir de um prompt do DOS).

    

Answer 8

Boa pergunta. No MS-DOS, o kernel era monolítico, o que significa que ele lidava apenas com uma tarefa de cada vez, versus o novo e moderno kernel que foi implementado no Windows 9x e na versão atual. Você pode conferir mais aqui .