Como foi possível o Multi-Tasking em versões mais antigas do Windows?

Considerando que o DOS era um sistema operacional com uma única tarefa e os laços que ele tinha com as primeiras versões do Windows, como as versões anteriores do Windows conseguiam realizar multitarefas? A postagem de perguntas e respostas do SuperUser de hoje aborda as respostas a essa pergunta.

A sessão de perguntas e respostas de hoje nos é oferecida por cortesia do SuperUser - uma subdivisão do Stack Exchange, um agrupamento de sites de perguntas e respostas conduzido pela comunidade..

Imagem de tela do Windows 95, cortesia da Wikipedia.

A questão

Leitor SuperUser O LeNoob quer saber como versões mais antigas do Windows podem ser executadas como sistemas multitarefa ?:

Eu li que o DOS é um sistema operacional único. Mas se versões mais antigas do Windows (incluindo também o Windows 95?) Eram apenas invólucros para o DOS, como elas poderiam ser executadas como um sistema operacional multitarefa??

Boa pergunta! Como as versões mais antigas do Windows conseguiram rodar como sistemas multitarefas??

A resposta

Os colaboradores do SuperUser Bob e Pete têm a resposta para nós. Primeiro, Bob:

O Windows 95 era muito mais do que “apenas um invólucro” para o MS-DOS. Citando Raymond Chen:

• O MS-DOS servia a dois propósitos no Windows 95: 1.) Servia como o carregador de boot. & 2.) Ele atuou como a camada de driver de dispositivo legado de 16 bits.

O Windows 95, na verdade, 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 preventiva 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 multitarefa cooperativa - essa é aquela em que eles não forçam um programa em execução a sair; 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).

• A multitarefa era cooperativa, assim como nas versões antigas do MacOS (embora, ao contrário do Multi-tasking DOS 4.x, que oferecia uma multitarefa preventiva). Uma tarefa tinha que ceder ao sistema operacional para agendar uma tarefa diferente. Os rendimentos foram incorporados em determinadas chamadas de API, principalmente no processamento de mensagens. Contanto que uma tarefa processasse as mensagens em tempo hábil, tudo estava ótimo. Se uma tarefa parasse de processar mensagens e estivesse ocupada executando algum loop de processamento, a multitarefa não era mais.

Arquitetura do Windows 3.x

Quanto aos primeiros programas do Windows gerariam controle:

• O Windows 3.1 usa multitarefa cooperativa - o que significa que cada aplicativo que está em execução é instruído a verificar periodicamente uma fila de mensagens para descobrir se algum outro aplicativo está solicitando o uso da CPU e, em caso afirmativo, para gerar controle para essa aplicação. No entanto, muitos aplicativos do Windows 3.1 verificariam a fila de mensagens com pouca frequência, ou não, e monopolizariam o controle da CPU pelo tempo que eles exigissem. Um sistema multitarefa preemptiva como o Windows 95 retirará o controle da CPU de um aplicativo em execução e o distribuirá para aqueles que tiverem uma prioridade mais alta com base nas necessidades do sistema.

Fonte

Todos os DOS veriam se esta aplicação única (Windows ou outra) rodando, que passaria o controle sem sair. Em teoria, a multitarefa preventiva pode ser implementada no topo do DOS com o uso de um relógio em tempo real e interrupções de hardware para forçar o controle do planejador. Como Tonny comenta, isso foi realmente feito por alguns sistemas operacionais rodando em cima do DOS.

386 Modo Avançado?

Nota: houve alguns comentários no modo 386 avançado do Windows 3.x sendo de 32 bits e suportando multitarefa preventiva.

Este é um caso interessante. Para resumir a postagem do blog vinculada, o modo 386 avançado era basicamente um hipervisor de 32 bits, 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 preventivamente multitarefas - portanto, parece que o hipervisor de modo avançado 386 compartilhará intervalos de tempo de CPU entre as máquinas virtuais (uma das quais executou normal 3.xe outros que executavam o MS-DOS), e cada VM faria sua própria tarefa - 3.x cooperaria em várias tarefas, enquanto o MS-DOS seria com uma única tarefa.

MS-DOS

O próprio DOS estava com tarefas únicas no papel, mas tinha suporte para programas TSR que ficavam em segundo plano até serem acionados por uma interrupção de hardware. Longe de verdadeiras multitarefas, mas 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 são dependentes um do outro. Deve ser possível implementar qualquer modo multi-tarefa em qualquer bit-ness. 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 preventiva para implementação.

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 preventiva 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 apenas um wrapper para DOS.

Seguido pela resposta do Pete:

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 para 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 SO 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 (*ver abaixo). No modo real, os aplicativos em execução podem executar qualquer coisa que desejarem, ou seja, acessar o 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-thread, mesmo que eles tenham sido lançados do DOS.

O DOS (Disk Operating System) era, até onde eu sei, não muito mais do 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. Ele também permitiu que alguns aplicativos permanecessem residentes, ou seja, drivers de mouse e emuladores de 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 na década de 1970, o modo protegido não existia na CPU. Não foi até o processador 80286 em meados da década de 1980 que o modo protegido se tornou parte da CPU.

Certifique-se de navegar até o tópico original e ler a discussão animada sobre esse tópico usando o link abaixo!

Tem algo a acrescentar à explicação? Som desligado nos comentários. Quer ler mais respostas de outros usuários do Stack Exchange com experiência em tecnologia? Confira o tópico de discussão completo aqui.