Como é um sistema operacional sem um shell?

Question

Um shell como o bash ou o command.com (até o Windows ME) ou o 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 desenvolvimento do primeiro shell (por exemplo, UNIX no início dos anos 70)? Se um computador não puder aceitar comandos (não há linha de comando), como um usuário pode interagir com ele? O que é essa interface mais básica? Posso executar essa interface em um emulador de terminal ou não há como ir atrás de um shell?

    

Answer 1

What does an operating system look like before a shell is run?

Depende do sistema operacional e de como você o configura. O Linux pode ser configurado para gravar texto de inicialização em um dispositivo de console, seja um console de modo de texto, console de buffer de quadro ou uma porta serial. Também pode ser configurado para ser 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 de alguma forma estar disponível na unidade mesmo se ocultado do 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.

How were systems used before the first shell was developed (e.g. UNIX in the early 1970s)?

Essencialmente (e deixando de fora muito, mas isso deve lhe dar a idéia) - Você carregou seu programa, tanto ligando interruptores em um painel ou usando um leitor de fita de papel (esses dispositivos gravariam diretamente na memória sem intervenção da CPU) e então inicie a CPU com outro switch. A CPU executaria este programa, geraria sua saída e pararia. Este é o processamento em lote, em oposição ao processamento interativo. Se você quisesse executar um programa diferente, teria que fazer isso.

If a computer cannot even accept commands (there is no command line), how can a user interact with it?

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

What is this most basic interface?

Eu acredito que a maioria das CPUs modernas, se não todas, tem uma "porta JTAG" que permite o mesmo tipo de operações diretas. Lembre-se de que, durante muito tempo, esperava-se que a maioria dos computadores possuísse ROM ou firmware que assumisse o controle do sistema quando ele fosse ligado antes de ser transferido para um sistema operacional. Aqui, os utilitários de pré-inicialização podem existir ou existe um mecanismo mínimo para carregar tais utilitários. Alguns gerenciadores de inicialização, como o U-Boot, podem ser acessados pela porta serial. Os gerenciadores de inicialização não executam "por trás" do sistema operacional, carregam o sistema operacional, controlam a mão e, em seguida, não estão mais em execução.

Can I run this interface in a terminal emulator or is there no way going behind a shell?

Não, você precisa de uma interface JTAG. Isso é mergulhar no reino da eletrônica e eu 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 - o que significa que se algo mata o gerenciador de inicialização no GuruPlug, eu tenho uma maneira "independente da CPU" de exibi-lo de volta.

    

Answer 2

Um sistema operacional não precisa fornecer um shell como o termo é comumente usado hoje (ou seja, um aplicativo que aceitará comandos interativamente do usuário), mas esse sistema operacional não será "parecido" com nada tudo para o usuário. Como Oliver Salzburg menciona, ele provavelmente mostraria apenas uma tela em branco (se tiver suporte de saída de vídeo), embora haja Não há razão 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 fazer coisas como ler comandos, iniciar processos, redirecionar E / S e assim por diante.

No entanto, não há motivo para que o aplicativo que usa esses recursos tenha um shell .

Antigamente, os sistemas operacionais eram simplesmente uma coleção dessas "rotinas úteis" que cada aplicativo precisaria reescrever do zero, e os computadores eram essencialmente dispositivos de processamento em lote. Coisas como E / S de arquivo, disco e impressora provavelmente foram as primeiras a serem coletadas no que hoje é conhecido como sistema operacional, seguido por programação de processo (vale a pena notar que o início dos anos 60 Apollo Guidance Computer era um computador multitarefa . Os aplicativos poderiam 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 essas instalações do sistema poderiam ser altamente otimizadas e depuradas uma vez e todas seriam beneficiadas) . À medida que os computadores se tornaram cada vez mais comuns, os sistemas operacionais acrescentaram recursos que eram 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, não faz muito tempo (acho que até o final dos anos 80), ainda era bastante comum escrever aplicativos para serem executados no hardware do computador pessoal, 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, por consequência, a interface do usuário fornecida por esse aplicativo era o shell.

    

Answer 3

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

Mas ainda havia um ponto de entrada para o usuário iniciar um programa. Se você esticar a palavra, você poderia chamar isso de "shell". 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 acionados, fios conectados em um painel de controle, cartões perfurados, filme perfurado ou fita magnética. Talvez eles pudessem escolher entre várias opções de programas carregadas anteriormente. Mas mesmo selecionando de uma lista exibida como luzes brilhantes, pressionando um botão ao lado dele já pode ser considerado um 'shell'.

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

Você pode querer verificar a boa página da Wikipédia sobre o histórico da computação , embora não se concentre muito na perspectiva de entrada / saída.

    

Answer 4

Provavelmente será uma tela em branco.

O shell é provavelmente chamado de shell porque é um shell em torno do kernel (o kernel é o sistema operacional). Então, em certo sentido, é a interface do usuário para o 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 de teclado e invoca essa função, esse é o Concha. Não há necessidade de ter uma interface de linha de comando complexa para construir algo que interaja com o usuário.

    

Answer 5

De um ponto de vista histórico, eu diria que havia cartões perfurados ( link ). Para interagir com um sistema de computador. Mas eu acho que isso é muito para trás para sua pergunta.

    

Answer 6

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

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

Para inicializar um computador antigo, é necessário 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 programa pequeno, que poderia permitir que o leitor de fita funcionasse. Então você carregaria um sistema mais complexo através do leitor de fita, o que poderia colocar a unidade de disco on-line. Você poderia imaginar um sistema operacional sem shell como sendo um desses carregadores iniciais.

Hoje em dia os computadores têm sequências similares, então quando você inicia a máquina, ele carrega seu BIOS, que inicia os discos, placas de rede, placa de vídeo e assim por diante, então o BIOS procura por um programa específico no disco rígido e roda esse (no Windows, pelo menos). O Unix faz algo semelhante, ele configura progressivamente o kernel, iniciando com módulos muito básicos e construindo sobre eles até chegar ao prompt de login

    

Answer 7

O sistema operacional como definição é bastante ambíguo. É um kernel em si? É o kernel e também ferramentas de acompanhamento? O Linux é o kernel, mas o GNU / Linux é o sistema operacional baseado no kernel Linux e nas ferramentas de projeto GNU. O shell é parte integrante desse sistema operacional.

No entanto, uma vez que o Linux esteja ativo e finalizado com "boot", você precisa dizer qual programa executar. A partir de então, tudo está em mãos desse programa em particular. Por padrão, é init que sabe o que fazer a seguir e pode, eventualmente, levar você 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/fancy imprimirá "Hello world!". Nós não precisamos de shell para isso. Se você quiser iniciar algum outro programa, basta gerar um novo processo em man 2 fork e man 2 execve ou ler o dispositivo terminal e aceitar a entrada do usuário. Ainda não há necessidade de shell.

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 nisso, é bastante óbvio por que alguém gostaria de escrever um programa desse tipo.

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

    

Answer 8

Sistemas operacionais sem shells de linha de comando ou interfaces gráficas têm muitos outros tipos de "faces".

Os sistemas embarcados apenas fazem seu trabalho sem qualquer interface de usuário, como o sistema de gerenciamento do motor do seu carro (que você pode obter de alguma forma através da interface OBD2 e de um terminal adequado). Ou pode ter teclados digitais, botões ou qualquer coisa (pense: forno de microondas, elevador ou a placa frontal de um sistema de som moderno). Se você considera isso como uma forma de concha, é claro, é claro.

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

• Construa uma placa de circuito para um microcontrolador ou obtenha uma placa genérica.
• Conecte-o para acionar alguns dispositivos úteis, como, digamos, um sensor de umidade e uma válvula de água. O microcontrolador tem pinos periféricos para essa finalidade: UARTs, GPIOs e assim por diante.
• Escreva o firmware para monitorar o sensor e regar o solo.
• Carregue o firmware por meio das ferramentas de desenvolvimento (portanto, nenhum shell é necessário no computador host para carregar e executar qualquer coisa, e o firmware é armazenado na memória flash no 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 estiver na sua placa real. A placa faz interface com 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.

Computadores de uso geral muito precoces sem shells tinham algum meio de entrada, como ler cartões perfurados. Mas é claro, cartões perfurados tinham que ser distinguidos: um cartão perfurado dá ao computador algum comando especial, ou é um pedaço 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 switches para alimentar código binário na máquina. Você pode ter ouvido histórias de veteranos que tiveram que "alternar" a seqüência de instruções para iniciar um bootstrap. Isso ainda é feito hoje, de certa forma: ainda existem dispositivos que possuem jumpers ou chaves DIP, e há algumas vantagens em relação aos ajustes no firmware.

    

Answer 9

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

    

Answer 10

Lembro-me de executar um depurador e um 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 para um depurador que executa o programa, você terá uma experiência próxima.

Note que o emacs tem um ambiente lisp completo, então, além da boa edição do histórico de comandos e de vários terminais virtuais, você tem um recurso de macros e scripts muito capaz.