O KiddieOS é um sistema operacional open-source básico em desenvolvimento pelo curso gratuito D.S.O.S [Desenvolvendo Sistemas Operacionais Simples]. A intenção deste sistema será: Criar, editar ou excluir arquivos, codificar em uma linguagem própria do sistema, criar objetos visuais e automatizados (desenhos) através desta linguagem, utilizar uma interface simples e intuitiva, criar novas interfaces gráficas, como: Janelas, botões, campos, etc... e estimular crianças, jovens e adultos a programar numa linguagem simples dentro do sistema operacional KiddieOS. A intenção do curso D.S.O.S é dá início ao desenvolvimento de sistemas operacionais utilizando a linguagem Assembly e entender a fundo sobre diversos conceitos internos deste tipo de sistema. Aqui neste repositório serão armazenados arquivos de APIs do KiddieOS, a imagem de disco para teste e futuramente - todo o sistema operacional completo. Visite o link abaixo para nos acompanhar no curso do Youtube, se inscreva neste canal para se manter atualizado e siga-me no GitHub. Vejo vocês lá:
MIT License
46
stars
5
forks
source link
KiddieOS_v1.3.6: Processamento de caminhos completos #6
Uma grande adaptação no Shell foi realizada, refatorando todo o código do Editor da CLI, excluindo várias partes desnecessárias e criando novas rotinas:
Rotina Format_Command_Line é uma nova rotina que substitui basicamente 70% das rotinas antigas. Esta rotina é responsável por realizar a formatação de dados digitados da CLI, diferentemente de antes que a formatação era em tempo de digitação, atualmente esta formatação está em tempo de execução, isto é, minimizando o máximo possível de erros durante a escrita.
O Format_Command_Line conta com uma série de rotinas adicionais para possibilitar o seu funcionamento:
SkipSI_To_Arguments: Desloca a leitura até o 1ª byte do 1ª argumento no Buffer de dados digitados na CLI, caso houver, apenas em situações onde é um comando.
Check_Drive_Letter: Verifica se o caractere inicial é a letra de unidade de disco, caso for, então a rotina substitui por uma quantidade específica de dois pontos-barra "..\", a depender da cadeia de diretórios.
ToUpperCase: Também utilizado em outras rotinas como ConvCommandToLower, esta rotina é responsável por converter caracteres minúsculos para maiúsculos, para leitura de entradas FAT.
Store_Restricting_Chars: Como o próprio nome já diz, a rotina armazena, ou ao menos, transfere para outro Buffer os caracteres de um primeiro buffer restringindo alguns caracteres especiais.
Check_Special_Chars: Esta rotina não só verifica caracteres especiais como também os utiliza para criar espaços adicionais em nomes de arquivos/pastas, convertendo para o formato compatível com FAT.
ConvCommandToLower: É uma rotina otimizada para não só converter caracteres de comandos para minúsculo, mas também converter para maiúsculo e respeitar os caracteres de ponto e letra da unidade de disco.
ToLowerCase: Simplesmente realiza a conversão dos caracteres para minúsculo e também é chamada pela rotina anterior.
A rotina Format_Command_Line é chamada em 2 comandos: READ e CD; Também é chamada pela rotina SearchToFileExec, onde nesta última a formatação de dados da CLI é essencial para adaptar toda a cadeia de diretórios para execução de programas. Cada nome de pasta ou arquivo formatado na cadeia, segue o padrão 8.3 e são preenchidos de espaços de forma dinâmica para o reconhecimento das entradas do FAT.
Uma rotina chamada AssignDriveLetter também foi implementada com o objetivo de trabalhar indiretamente com o comando Assign, comando que altera a letra de unidade de disco na CLI. Antes da implementação, o comando Assign só poderia alterar a letra de unidade enquanto o sistema operacional estivesse executando, então após a reinicialização ou desligamento, a letra era resetada. Para possibilitar o armazenamento fixo da alteração da letra de unidade de disco, foi implementado a escrita em disco na rotina do comando Assign. No entanto, na inicialização do KiddieOS, era necessário uma nova funcionalidade que pudesse ler esta letra salva no disco para atribuir a uma variável do Shell, esta função é a AssignDriveLetter, que é processada tanto no OS_Inter_Shell (Interpretação originária de fora do Shell) quanto também na PrintAccess (Durante Inicialização da Interface do Shell).
Foi implementado no comando CD a leitura encadeada de diretórios, possibilitando a leitura de cada pasta (caso houver) no buffer formatado até o encontro do arquivo. As adaptações do comando CD foram:
Leitura de uma primeira pasta/diretório, após a leitura se não houver erros, então executar o procedimento a seguir.
Adição ou Subtração de segmento do carregamento do diretório, e salvamento do nome da pasta para o Buffer de diretórios da CLI ou exclusão do nome de pasta selecionado do mesmo buffer.
Deslocamento de SI e DI, apontando para o próximo nome formatado de diretório no Buffer.
Retorno ao início da leitura encadeada, processando o próximo diretório, N vezes até que SI seja igual a 0.
A leitura de diretórios encadeados não é somente útil para processar caminhos completos pelo comando CD, mas também para processar caminhos completos em diversos comandos e até mesmo, fora da execução de comandos, como uma mera execução de processos. Para esta finalidade foi implementada uma nova rotina explicada a seguir.
A rotina Load_File_Path foi uma ótima maneira de generalizar a mesma execução da leitura de diretórios do comando CD, diversificando para outras rotinas. Segue uma forma mais dinâmica e menos estática, podendo até mesmo carregar um arquivo na memória no final da leitura encadeada de diretórios para o comando READ e pode até ignorar a leitura do arquivo final, quando a chamada de Load_File_Path for originado da rotina de execução de processos SearchFileToExec. O Load_File_Path também pode escolher ignorar o processamento de diretórios e saltar diretamente para o carregamento do arquivo, caso este se encontre disponível ou for chamado em um comando READ.
Em todas as formas de carregamento de arquivos e diretórios na memória, seja por qualquer comando, um processamento de códigos de erros pode ser chamado caso houver algum erro na leitura, o processamento é dado por 2 implementações:
4 códigos de erros específicos para cada erro de leitura de dados: Arquivo não encontrado, Pasta não encontrada, Este arquivo não é um diretório e este diretório não é um arquivo. O código de erro é gerado pelo driver do FAT16 após a tentativa de leitura de arquivos/diretórios, entregando não só o código de erro como também uma flag setada.
Uma rotina genérica que identifica qual é o código de erro afim de imprimir na tela uma mensagem de erro específica, o código de erro fica em AX.
Load_File_Path consegue processar caminhos completos, Retornando ou Avançando em diretórios, acessando cadeias completamente distintas e apresentar mensagens de erro caso houver erros na leitura. Pode ser invocado após a formatação dos comandos e diretórios pela rotina Format_Command_Line.
Exec.SearchToFileExec é a rotina de execução de programas/processos. Atualmente ela pode executar programas KXE e MZ do DOS, onde o KXE tem uma estrutura muito básica no início, no entanto não contém um formato conhecido, apenas uma sessão de memória protegida virtual dada pela diretiva section para organizar os endereços do programa. O MZ ainda está passivo de explorações para a melhor maneira de alocação dos dados, como também a implementação possível do PE e do ELF em 32 bits. Nas implementações atuais, a Rotina SearchToFileExec apenas foi readaptada para as novas atualizações, que é a execução do Format_Command_Line + Load_File_Path, desta forma, foi preciso atualizar o código de SearchToFileExec afim de simplificar sua execução e melhorar sua legibilidade para futuras manutenções.
Os_Inter_Shell que foi adicionado há alguns meses, porém não foi implementado 100%, então desta vez o trabalho foi mais otimizado, focando na execução de comandos e executáveis fora da CLI do Shell. Isto pode ser em um programa do usuário dada a String do comando, ou pode ser até mesmo na inicialização do sistema operacional, onde vários comandos pode ser executados em ordens subsequentes, muito similar ao processamento em lote do Windows ou do ShellScript, como também da maior parte dos sistemas operacionais antigos e modernos. As implementações atuais, por mais que não sejam suficientes, introduzem o conceito inicial de Execução de Scripts em Lote.
A respeito disso, a nova rotina Copy_Buffers foi adicionada para copiar os dados da String que está fora do Shell para um Buffer padrão de comandos e argumentos que está dentro do Shell, ou seja, nós temos uma mesma execução que minimiza os conflitos, por não necessitar utilizar Buffers diferentes. Em relação a isto, nós temos temos 2 Buffers principais de tamanho limitado no Shell:
BufferArgs: Permite armazenar a escrita de dados do teclado do usuário, fixando a sequência de caracteres originais desde o comando até os argumentos separados por espaços, com a finalização em 0.
BufferKeys: Se trata de um Buffer (que logo o nome será alterado) para receber a transferência de caracteres do BufferArgs e ser formatado para os padrões do FAT16 sem que isto afete outros Buffers.
Todo o sistema operacional passou por um processo de Reorganização da memória RAM, onde a memória foi dividida e planejada em várias partes, sendo: MBR, VBR, FAT (Tabela), Entrada Raíz (Diretório), Entradas de Arquivos, Dados de arquivos, Código de processos/programas e kernel em 32 bits. Mesmo que a pilha e o segmento em modo real do Kernel, como melhor organização de endereçamento no carregamento de arquivos e do FAT tenha sido alternados/atualizados, fornecendo um maior controle em cada parte, isso não é o suficiente para o gerenciamento de memória, pois algumas operações de mapeamento de memória e configurações da GDT são necessárias, como também alocações e realocações dinâmicas. No entanto, algumas anotações e organizações já foram feitas para possibilitar este desenvolvendo, incluindo o início da Criação de um driver chamado memx86.drv que será responsável por realizar o gerenciamento e configurações iniciais da memória RAM. Mais detalhes sobre memória será abordado nas próximas atualizações.
O Driver de teclado PS/2 também foi mais trabalhado, efetuando inicialização e configuração do teclado. Uma nova forma de inicialização do kernel também foi atribuída, imprimindo Strings de inicialização de cada Driver e sistema, afim de que o usuário possa acompanhar o que de fato está sendo carregando no sistema operacional, processos também podem ser executados e isso nos possibilitará configurar no futuro um arquivo chamado Autorun.ini onde poderíamos escolher como carregar Drivers, ícones, associações e programas na inicialização.
TODO: Próximas atribuições
[x] Criação do sistema de escrita do FAT16.
[x] Criação do comando WRITE.
[x] Aperfeiçoamento do driver e gerenciamento de memória.
[ ] Adaptação de alocações dinâmicas nos comandos WRITE e READ.
[ ] Adaptação de alocações dinâmicas no carregamento de programas.
[ ] Implementação da construção e leitura de estruturas ELF32 em programas .APP.
FrancisBFTC
commented
1 year ago
Recursos/correções
Uma grande adaptação no Shell foi realizada, refatorando todo o código do Editor da CLI, excluindo várias partes desnecessárias e criando novas rotinas:
Rotina Format_Command_Line é uma nova rotina que substitui basicamente 70% das rotinas antigas. Esta rotina é responsável por realizar a formatação de dados digitados da CLI, diferentemente de antes que a formatação era em tempo de digitação, atualmente esta formatação está em tempo de execução, isto é, minimizando o máximo possível de erros durante a escrita.
O Format_Command_Line conta com uma série de rotinas adicionais para possibilitar o seu funcionamento:
A rotina Format_Command_Line é chamada em 2 comandos: READ e CD; Também é chamada pela rotina SearchToFileExec, onde nesta última a formatação de dados da CLI é essencial para adaptar toda a cadeia de diretórios para execução de programas. Cada nome de pasta ou arquivo formatado na cadeia, segue o padrão 8.3 e são preenchidos de espaços de forma dinâmica para o reconhecimento das entradas do FAT.
Uma rotina chamada AssignDriveLetter também foi implementada com o objetivo de trabalhar indiretamente com o comando Assign, comando que altera a letra de unidade de disco na CLI. Antes da implementação, o comando Assign só poderia alterar a letra de unidade enquanto o sistema operacional estivesse executando, então após a reinicialização ou desligamento, a letra era resetada. Para possibilitar o armazenamento fixo da alteração da letra de unidade de disco, foi implementado a escrita em disco na rotina do comando Assign. No entanto, na inicialização do KiddieOS, era necessário uma nova funcionalidade que pudesse ler esta letra salva no disco para atribuir a uma variável do Shell, esta função é a AssignDriveLetter, que é processada tanto no OS_Inter_Shell (Interpretação originária de fora do Shell) quanto também na PrintAccess (Durante Inicialização da Interface do Shell).
Foi implementado no comando CD a leitura encadeada de diretórios, possibilitando a leitura de cada pasta (caso houver) no buffer formatado até o encontro do arquivo. As adaptações do comando CD foram:
A leitura de diretórios encadeados não é somente útil para processar caminhos completos pelo comando CD, mas também para processar caminhos completos em diversos comandos e até mesmo, fora da execução de comandos, como uma mera execução de processos. Para esta finalidade foi implementada uma nova rotina explicada a seguir.
Em todas as formas de carregamento de arquivos e diretórios na memória, seja por qualquer comando, um processamento de códigos de erros pode ser chamado caso houver algum erro na leitura, o processamento é dado por 2 implementações:
4 códigos de erros específicos para cada erro de leitura de dados: Arquivo não encontrado, Pasta não encontrada, Este arquivo não é um diretório e este diretório não é um arquivo. O código de erro é gerado pelo driver do FAT16 após a tentativa de leitura de arquivos/diretórios, entregando não só o código de erro como também uma flag setada.
Uma rotina genérica que identifica qual é o código de erro afim de imprimir na tela uma mensagem de erro específica, o código de erro fica em AX.
Load_File_Path consegue processar caminhos completos, Retornando ou Avançando em diretórios, acessando cadeias completamente distintas e apresentar mensagens de erro caso houver erros na leitura. Pode ser invocado após a formatação dos comandos e diretórios pela rotina Format_Command_Line.
Exec.SearchToFileExec é a rotina de execução de programas/processos. Atualmente ela pode executar programas KXE e MZ do DOS, onde o KXE tem uma estrutura muito básica no início, no entanto não contém um formato conhecido, apenas uma sessão de memória protegida virtual dada pela diretiva section para organizar os endereços do programa. O MZ ainda está passivo de explorações para a melhor maneira de alocação dos dados, como também a implementação possível do PE e do ELF em 32 bits. Nas implementações atuais, a Rotina SearchToFileExec apenas foi readaptada para as novas atualizações, que é a execução do Format_Command_Line + Load_File_Path, desta forma, foi preciso atualizar o código de SearchToFileExec afim de simplificar sua execução e melhorar sua legibilidade para futuras manutenções.
Os_Inter_Shell que foi adicionado há alguns meses, porém não foi implementado 100%, então desta vez o trabalho foi mais otimizado, focando na execução de comandos e executáveis fora da CLI do Shell. Isto pode ser em um programa do usuário dada a String do comando, ou pode ser até mesmo na inicialização do sistema operacional, onde vários comandos pode ser executados em ordens subsequentes, muito similar ao processamento em lote do Windows ou do ShellScript, como também da maior parte dos sistemas operacionais antigos e modernos. As implementações atuais, por mais que não sejam suficientes, introduzem o conceito inicial de Execução de Scripts em Lote.
A respeito disso, a nova rotina Copy_Buffers foi adicionada para copiar os dados da String que está fora do Shell para um Buffer padrão de comandos e argumentos que está dentro do Shell, ou seja, nós temos uma mesma execução que minimiza os conflitos, por não necessitar utilizar Buffers diferentes. Em relação a isto, nós temos temos 2 Buffers principais de tamanho limitado no Shell:
BufferArgs: Permite armazenar a escrita de dados do teclado do usuário, fixando a sequência de caracteres originais desde o comando até os argumentos separados por espaços, com a finalização em 0.
BufferKeys: Se trata de um Buffer (que logo o nome será alterado) para receber a transferência de caracteres do BufferArgs e ser formatado para os padrões do FAT16 sem que isto afete outros Buffers.
Todo o sistema operacional passou por um processo de Reorganização da memória RAM, onde a memória foi dividida e planejada em várias partes, sendo: MBR, VBR, FAT (Tabela), Entrada Raíz (Diretório), Entradas de Arquivos, Dados de arquivos, Código de processos/programas e kernel em 32 bits. Mesmo que a pilha e o segmento em modo real do Kernel, como melhor organização de endereçamento no carregamento de arquivos e do FAT tenha sido alternados/atualizados, fornecendo um maior controle em cada parte, isso não é o suficiente para o gerenciamento de memória, pois algumas operações de mapeamento de memória e configurações da GDT são necessárias, como também alocações e realocações dinâmicas. No entanto, algumas anotações e organizações já foram feitas para possibilitar este desenvolvendo, incluindo o início da Criação de um driver chamado memx86.drv que será responsável por realizar o gerenciamento e configurações iniciais da memória RAM. Mais detalhes sobre memória será abordado nas próximas atualizações.
O Driver de teclado PS/2 também foi mais trabalhado, efetuando inicialização e configuração do teclado. Uma nova forma de inicialização do kernel também foi atribuída, imprimindo Strings de inicialização de cada Driver e sistema, afim de que o usuário possa acompanhar o que de fato está sendo carregando no sistema operacional, processos também podem ser executados e isso nos possibilitará configurar no futuro um arquivo chamado Autorun.ini onde poderíamos escolher como carregar Drivers, ícones, associações e programas na inicialização.
TODO: Próximas atribuições