Como é um sistema operacional sem um shell?

Um shell como o bash ou command.com (até Windows ME) ou CMD.EXE (em versões posteriores) fornece uma interface que (entre outras coisas) aceita comandos do usuário. Como é um sistema operacional antes de um shell ser executado? Como os sistemas foram usados ​​antes do primeiro shell ser desenvolvido (por exemplo, UNIX no início dos anos 70)? Se um computador não pode sequer aceitar comandos (não há linha de comando), como um usuário pode interagir com ele? Qual é a interface mais básica? Posso executar essa interface em um emulador de terminal ou não há como ficar atrás de um shell?

Como é um sistema operacional antes de um shell ser executado?

Depende do sistema operacional e de como você o configura. O Linux pode ser configurado para gravar o texto de inicialização em um dispositivo do console, seja um console de modo de texto, um console de buffer de quadros ou uma porta serial. Também pode ser configurado para ficar perfeitamente silencioso. Alguns SOs / sistemas podem gravar informações de diagnóstico em uma memória não volátil que pode ser acessada colocando o sistema no modo de desenvolvedor, depuração ou diagnóstico. Muitos sistemas operacionais suportam a saída de informações de inicialização e diagnóstico para alguma forma de UART, que pode estar disponível de alguma forma na unidade, mesmo que oculta ao usuário (google "Adicionar porta serial ao DD-WRT") para exemplos de onde os fabricantes ocultam portas seriais e como você pode chegar até eles).

Um sistema operacional não precisa ter um monitor externo - é apenas outro dispositivo para o sistema operacional.

Como os sistemas foram usados ​​antes do primeiro shell ser desenvolvido (por exemplo, UNIX no início dos anos 70)?

Essencialmente (e deixando de fora muita coisa, mas isso deve lhe dar a idéia) - Você carregou o programa, alternando interruptores em um painel ou usando um leitor de fita de papel (esses dispositivos gravariam na memória diretamente sem a intervenção da CPU) e, em seguida, iniciavam a CPU com outro switch. A CPU executaria esse programa, geraria sua saída e pararia. Este é o processamento em lote, em oposição ao processamento interativo. Se você queria executar um programa diferente, precisava fazer isso novamente.

Se um computador não pode sequer aceitar comandos (não há linha de comando), como um usuário pode interagir com ele?

Não sou especialista nesta área, mas computadores antigos e antigos, como o Altair, IMSAI e PDP-8, tinham interruptores no painel frontal que controlavam diretamente a CPU e podiam ler e gravar memória diretamente sem intervenção da CPU.

Qual é a interface mais básica?

Acredito que a maioria, senão todas as CPUs modernas, têm uma "porta JTAG" que permite o mesmo tipo de operações diretas. Lembre-se de que, durante muito tempo, espera-se que a maioria dos computadores possua ROM ou firmware que controle o sistema quando ele é ligado antes de ser entregue a um sistema operacional. Aqui, os utilitários de pré-inicialização podem existir ou existe um mecanismo mínimo para carregar esses utilitários. Alguns gerenciadores de inicialização, como o U-Boot, podem ser acessados ​​via porta serial. Os gerenciadores de inicialização não correm "atrás" do sistema operacional, eles carregam o sistema operacional, controlam o controle manualmente e não estão mais em execução.

Posso executar essa interface em um emulador de terminal ou não há como ficar atrás de um shell?

Não, você precisa de uma interface JTAG. Isso está mergulhando no mundo da eletrônica e admito que não sei muito sobre isso, exceto que o meu GuruPlug vem com um e eu posso programar diretamente o chip flash na placa do GuruPlug com ele - ou seja, se algo matar o gerenciador de inicialização no GuruPlug, eu tenho uma maneira "independente da CPU" de voltar a piscar.

Um sistema operacional não precisa fornecer um shell, já que o termo é comumente usado hoje em dia (ou seja, um aplicativo que aceita comandos interativamente do usuário), mas esse sistema operacional não "realmente se parece" com nada para o usuário. do utilizador. Como Oliver Salzburg menciona, provavelmente mostraria apenas uma tela em branco (se houver suporte para saída de exibição), embora não haja motivo para isso. Tomemos, por exemplo, a saída de diagnóstico do kernel Linux durante o processo de inicialização e inicialização do kernel.

O shell, seja um shell gráfico, um interpretador de linha de comando ou qualquer outra coisa, usa os recursos fornecidos pelo sistema operacional para executar comandos como ler comandos, iniciar processos, redirecionar E / S e assim por diante.

No entanto, não há razão para que o aplicativo que usa esses recursos precise ser um shell .

Antigamente, os sistemas operacionais eram simplesmente uma coleção dessas "rotinas úteis" que cada aplicativo teria que reescrever do zero, e os computadores eram essencialmente dispositivos de processamento em lote. Coisas como E / S de arquivos, discos e impressoras foram provavelmente as primeiras a serem coletadas no que hoje é conhecido como sistema operacional, seguido de agendamento de processos (vale a pena notar que o Apollo Guidance Computer do início dos anos 1960 era um computador multitarefa) Os aplicativos poderiam então fazer chamadas para o sistema operacional em vez de usar suas próprias rotinas para fazer essas coisas, o que reduzia a complexidade da programação e provavelmente ajudava a reduzir o tamanho do código ou o tempo de execução (porque esses recursos do sistema poderiam ser fortemente otimizados e depurados uma vez, após o que todos se beneficiariam) . À medida que os computadores se tornaram cada vez mais comuns, os sistemas operacionais adicionaram recursos amplamente centrados no usuário, como uma maneira de o usuário interagir com o computador e dar comandos de maneira interativa; conchas gráficas são simplesmente uma extensão dessa linha de raciocínio.

Além disso, há pouco tempo (pense no final dos anos 80), ainda era bastante comum escrever aplicativos para rodar no hardware de computadores pessoais, sem a assistência de qualquer sistema operacional comum. Isso foi particularmente útil para jogos, pois evitou a sobrecarga de memória e processamento do sistema operacional, mas tenho certeza de que havia outros exemplos também. Nesses casos, até certo ponto, o aplicativo era seu próprio sistema operacional e, consequentemente, a interface do usuário fornecida por esse aplicativo era o shell.

Os computadores antigos não tinham um sistema operacional no sentido em que usamos a palavra hoje. Eles expuseram funções implementadas no hardware diretamente a qualquer programa em execução nele. Havia apenas um programa em execução ao mesmo tempo. O programa em si tinha que controlar todas as tarefas, nada foi feito "em segundo plano" por um sistema operacional.

Mas ainda havia um ponto de entrada para o usuário iniciar um programa. Se você esticar a palavra, poderá chamar isso de "casca". Mas, basicamente, era apenas o hardware aguardando o usuário inserir o primeiro bit do programa a ser executado. Seja na forma de botões pressionados, interruptores, fios conectados em um painel de distribuição, cartões perfurados, filme perfurado ou fita magnética. Talvez eles possam escolher entre várias opções de programa carregadas anteriormente. Porém, mesmo selecionar uma lista exibida como luzes brilhantes pressionando um botão próximo a ela já pode ser considerado um 'shell'.

Portanto, se sua definição de 'shell' é 'uma interface que aceita comandos de um usuário', então não havia tempo para isso, pelo menos para dispositivos que você chamaria vagamente de computador.

Você pode querer dar uma olhada na página da wikipedia sobre a história da computação , embora ela não se concentre muito na perspectiva de entrada / saída.

Provavelmente será uma tela em branco.

O shell provavelmente é chamado de shell porque é um shell em torno do kernel (o kernel é o sistema operacional). Portanto, de certa forma, é a interface do usuário do sistema operacional, qualquer que seja a interface.

Se um sistema operacional tivesse apenas uma única função, que seria desligar o computador, e você criaria um programa que aceita qualquer entrada do teclado e depois chama essa função, esse é o shell. Não é necessário ter uma interface de linha de comando complexa para criar algo que faça interface com o usuário.

Do ponto de vista histórico, eu acho que havia cartões perfurados ( https://en.wikipedia.org/wiki/Punched_card ). Para interagir com um sistema de computador. Mas acho que isso é voltar para a sua pergunta.

O primeiro sistema operacional que usei (1981) após a faculdade foi o PRIMOS em um minicomputador Prime. Este era um sistema operacional de compartilhamento de tempo e suportava vários usuários, cada um usando um terminal conectado ao computador através de um cabo RS232. Você teve que fazer logon no terminal fornecendo um nome de usuário e senha. Sua sessão do terminal foi uma espécie de concha. Você pode editar arquivos, compilar, executar todas as coisas que fazemos hoje em dia. Todos os terminais tiveram acesso ao mesmo sistema de arquivamento. Em grande parte, esses terminais não passavam de máquinas de escrever - não havia editores WYSISWYG, e até mesmo o emacs era um sonho.

O sistema operacional foi estruturado da forma como está agora e pode ser imaginado como uma camada de casca de cebola. A camada mais interna tinha funcionalidade de nível muito baixo - como controle de hardware, acesso à memória. Indo para fora, o sistema de arquivos seria adicionado e as camadas do usuário. No seu programa, você seria capaz de interagir com algumas camadas, mas não com as mais internas (para não mexer no compartilhamento de tempo ou no hardware real - luzes e assim por diante). Um computador sem shell seria como uma dessas camadas internas; ele poderá acessar um disco rígido e um leitor de fita (realmente!), Mas não saberia sobre arquivos ou usuários.

Para inicializar um computador anterior, você precisava carregar um conjunto básico de instruções (isso pode envolver a alternância de comutadores físicos em uma sequência definida no computador). Essa sequência iniciaria um segundo pequeno programa, que poderia permitir que o leitor de fita funcionasse. Em seguida, você carregaria um sistema mais complexo através do leitor de fita, o que poderia colocar a unidade de disco on-line. Você pode imaginar um sistema operacional sem shell como sendo um desses carregadores iniciais.

Atualmente, os computadores têm sequências semelhantes; portanto, quando você inicia a máquina, carrega seu BIOS, que inicia os discos, placas de rede, placa de vídeo etc., o BIOS procura um programa específico no disco rígido e o executa (no Windows finalmente). O Unix faz algo semelhante: configura progressivamente o kernel, começando com módulos muito básicos e construindo neles até chegar ao prompt de login

O sistema operacional como definição é bastante ambíguo. É um próprio kernel? É o kernel e também as ferramentas que o acompanham? Linux é o kernel, mas GNU / Linux é o sistema operacional baseado no kernel do Linux e nas ferramentas de projeto GNU. A Shell é parte integrante de tal sistema operacional.

No entanto, uma vez que o Linux esteja completo e finalizado com a "inicialização", você precisará dizer qual programa executar. A partir de então, tudo estará nas mãos desse programa em particular. Por padrão, é initquem sabe o que fazer a seguir e poderá levá-lo a uma boa tela de login da GUI. Mas não precisa ser assim. Você pode inicializar assim

kernel /boot/vmlinuz-2.6.30 root=/dev/sda1 ro init=/bin/fancy

Em seguida, o programa /bin/fancyimprimirá "Olá, mundo!". Não precisamos de casca para isso. Se você deseja iniciar outro programa, inicie um novo processo com man 2 forke man 2 execve, ou leia no dispositivo terminal e aceite a entrada do usuário. Ainda não há necessidade de concha.

Na minha opinião, o shell do sistema operacional é um programa capaz de ler a entrada do usuário e, em seguida, iniciar outros programas. Se você pensar bem, é bastante óbvio por que alguém gostaria de escrever um programa assim.

Mesmo que você não precise ler a entrada do usuário interativamente, é muito mais conveniente escrever um shell script simples para sua tarefa. Nesse caso, é apenas intérprete de comandos shell armazenados. Você também pode escrever seu programa em intérprete de outro idioma.

Os sistemas operacionais sem shells da linha de comando ou interfaces gráficas possuem muitos outros tipos de "faces".

Os sistemas embarcados realizam seu trabalho sem nenhuma interface do usuário, como o sistema de gerenciamento do motor em seu carro (que você pode acessar de alguma maneira através da interface OBD2 e de um terminal adequado). Ou pode ter teclados digitais, botões ou o que for (pense: forno de microondas, elevador ou o painel de um sistema de som moderno). Se você os considera como uma forma de concha é subjetivo, é claro.

Aqui está uma receita de alto nível de como, como um hobby, você pode criar um computador útil sem uma concha:

• Construa uma placa de circuito para um microcontrolador ou obtenha uma placa genérica.
• Conecte-o para acionar alguns dispositivos úteis, como, por exemplo, um sensor de umidade e uma válvula de água. O microcontrolador possui pinos periféricos para essa finalidade: UARTs, GPIOs e assim por diante.
• Escreva o firmware para monitorar o sensor e regue o solo.
• Carregue o firmware através das ferramentas de desenvolvimento (portanto, não é necessário um shell no computador host para carregar e executar qualquer coisa, e o firmware é armazenado na memória flash do chip). A programação pode envolver o microcontrolador sendo conectado a uma placa de programação especial ou pode haver uma maneira de fazê-lo enquanto está sentado na sua placa atual. A placa faz interface com o seu PC (atualmente via USB, por exemplo) e você usa algumas ferramentas: como um IDE ou ferramentas de linha de comando no host.
• Implante a coisa: agora é essencialmente uma caixa preta eletrônica que de alguma forma monitora a umidade do solo e liga a água, sem outras entradas ou saídas.

Os computadores de uso geral muito antigos, sem casca, tinham alguns meios de entrada, como a leitura de cartões perfurados. Mas é claro que os cartões perfurados precisavam ser distinguidos: um cartão perfurado dá ao computador algum comando especial ou é parte de um programa Fortran? Então, "linguagens de controle de tarefas" tiveram que ser desenvolvidas, que são linhas de comando de fato.

Antes dos cartões perfurados e das linguagens de controle de tarefas, os programadores precisavam alternar os interruptores para alimentar o código binário na máquina. Você pode ter ouvido histórias de veteranos que tiveram que "alternar" a sequência de instruções para iniciar uma inicialização. Isso ainda é feito hoje, de certa forma: ainda existem dispositivos que possuem jumpers ou comutadores DIP, e existem algumas vantagens em comparação com as configurações do firmware.

O primeiro computador em que eu estava preso foi um Siemens 305 em 1977, eu estava aprendendo o FORTRAN IV. Tinha uma máquina de escrever para executar comandos e imprimir mensagens de diagnóstico em papel, um leitor de cartões perfurados, um leitor / gravador de fitas perfuradas e uma impressora. Para não esquecer o disco rígido removível de 40 MB, 16 polegadas ou mais. Portanto, ele já tinha um shell, e a interface era a máquina de escrever.

Lembro-me de executar um depurador e editor de texto (DDT e emacs) como o equivalente a um shell de comando nos anos 70. Portanto, se você executar o emacs no modo de console com qualquer outro programa executado via eshell em um depurador que executa o programa, terá uma experiência próxima.

Observe que o emacs possui um ambiente lisp completo; portanto, além da boa edição do histórico de comandos e de vários terminais virtuais, você possui um recurso de macro e script muito capaz incorporado.