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.10: Resolução de bug gráfico e programa DOS que carrega o sistema de imagens. #15
Endereço 0xC000 foi atualizado para 0x30000 na definição GUI_VARS do winmng32.kxe (Gerenciador gráfico em modo protegido) para ler corretamente, no início do arquivo VESA incluído em winmng.osf, os parâmetros do modo gráfico.
Na rotina CheckBufferLoaded do arquivo fat16.osf, o registrador AX foi alterado pra EAX na leitura do POINTER_FILE, ponteiro este que normalmente é alterado pela função SEEK de arquivos (Função de deslocamento de ponteiro) e naturalmente é alterado pela função de leitura READ. A função de leitura estava atualizando apenas os 16 bits mais baixos de AX, desconsiderando os mais altos, desta forma, um arquivo que ultrapassasse 65535 bytes teria seu deslocamento de ponteiro incorretamente.
Alteração de modo de vídeo após o retorno do WINMNG no kernel.asm e variáveis de Cursor sendo zeradas, assim evitamos outros tipos de erros.
Novos endereços de saltos no kernel.asm para SYSCMNG (Gerenciador de SYSCALLs, o responsável por executar programas de 32 bits), WINMNG (com o deslocamento de +3, para chamar uma rotina de alternância de modo gráfico no VESA) e SHELL16 (Também com o deslocamento de +3, para executar o interpretador de comandos fora do Shell, que será útil pra atribuir permissões).
Mudança das operações antigas no winmng.osf correlacionado às atualizações antigas para uma nova forma de operação de arquivos: Usando rotinas do DOS. Como estas rotinas estão mais completas e personalizáveis, foi possível abrir, ler e fechar arquivos adequadamente carregando arquivos no endereço 0x5000 (Endereço de programas em modo protegido) e 0x6A00 (Endereço de arquivos BMP).
Mudança de endereço pra carregamento de programas DOS devido a um conflito que ocorreu entre o programa em modo protegido e este programa DOS em modo real. A partir de agora, programas DOS serão carregados no endereço 0x4000:0 tendo 65535 bytes de limite de tamanho e programas em modo protegido serão carregados no endereço 0x5000:0 até o endereço 0x6800:0 (Buffer de carregamento temporário de dados dos arquivos). Este buffer temporário vai até 0x6A00 e daqui pra frente podemos carregar "grandes" arquivos de imagens BMP, já que consomem bastante memória, no entanto, ainda contém limitações de imagens BMP acima de 320x200x24bpp.
Novo programa DOS implementado correspondente ao sistema intermediário winmng.osf, com o nome winsetup.exe. Este programa faz a mesma coisa, com a diferença de que o usuário poderá passar como parâmetro o nome de uma imagem em um dado diretório e o gerenciador gráfico será inicializado com a nova imagem na área de trabalho. Caso o usuário decida não passar nada como parâmetro, o programa DOS considera um diretório de imagem padrão.
A forma de impressão de Strings no VESA.lib foi modificado pois estas mesmas funções de impressão serão utilizadas no Shell16 que considera limitações específicas de tela, logo a função padrão Print_String não satisfaria as necessidades do ecrã do shell, apenas a função PrintData, a que foi usada no VESA.lib. Também ao invés de imprimirmos valores hexadecimais dos parâmetros de modo de vídeo, agora é imprimido valores decimais, usando a rotina Print_Dec_Value32 que já está há algum tempo no sistema. Apenas o endereço imprimido da memória de vídeo que está em hexadecimal.
No OS_Intern_Shell, chamado por outros sistemas pelo nome SHELL16+3, o código inicial deduzia que todo sistema que o chamaria estaria no mesmo segmento, o que não era uma verdade pois qualquer programa carregado em outros endereços, como: 0x4000:0, 0x5000:0, etc. Poderia querer chamar estas operações do OS_Intern_Shell, um exemplo é quando o usuário quer executar um comando via String só que fora da interface do Shell, dentro de algum arquivo ASM, como o famoso system("comando aqui...") que conhecemos em C. Então pra eliminar esta limitação de "apenas mesmos segmentos podem chamar", foi usado bruscamente o registrador ES com o endereço 0x3000 (Endereço do kernel) bem no início do código OS_Intern_Shell, mantendo também o endereço original de DS e removi a parte que jogava DS para ES, no entanto, DS e ES são salvos na pilha, e após isto ES recebe DS após a cópia do buffer, ou seja, após esta cópia não precisamos mais nos preocupar com o código que está sendo chamado estar em outro segmento ou não, pois a partir daí tudo é feito no endereço 0x3000:0.
Foi removido todas as inclusões de libs desnecessárias em winmng.osf, libs estas que não estão mais sendo usadas neste momento. Está sendo usado apenas VESA.lib e User16.inc.
Outro detalhe pequeno mas importante é que o retorno de valor de um programa DOS após executado é armazenado em AL, pois AH estará com 0x4C, função da INT 21h pra sair do programa. Normalmente, AL = 0, porém criei uma nova condição no shell pra quando AL = 2, o Shell não voltar pra Cursor_Commands (Apenas imprimir o diretório da linha de comando) mas sim pra Os_Shell_Setup que iria redesenhar toda a interface do Shell do zero. Isto foi necessário porque dava certos problemas quando se tratava deste programa DOS específico pois ele migra pra outro sistema distante que é o modo protegido em endereço alto no modo gráfico, e na volta pro modo real do Shell tudo precisaria estar salvo, todos os estados, inclusive os Pixels da tela do Shell, já que a tela gráfica no modo texto é apagada. Então pra não perder tanto tempo fazendo tudo isso para "apenas voltar ao estado original" decidi fazer pelo procedimento mais simples que é apenas mudar um valor de retorno, apenas isso. Então se criar um programa comum no DOS que não executa o modo gráfico, apenas use AX = 0x4C00 na INT 21h para sair do programa, agora se o seu programa saltar para o modo gráfico, que iria redesenhar a tela, use AX = 0x4C02h pra sair e tudo estará okay.
Uma tecla de retorno foi adicionada no gerenciador gráfico, antes do desenho das janelas, pois ainda há alguns problemas na formação das janelas que não consegui identificar ainda, mas será depurado com mais calma. Então o sistema só imprime a imagem BMP e espera que o usuário pressione F1 pra retornar ao Shell ou ao menu inicial do Kernel.
Para saber com mais detalhes como todas essas mudanças foram feitas, é só checar cada arquivo commitado no próprio Pull Request na aba commits ou clicando aqui https://github.com/FrancisBFTC/KiddieOS_Development/pull/15/commits/13b0e8acd4c6c3a3bb4f2bb97afd7ba051318b74 e encontrará as linhas que foram modificadas. Vários arquivos foram modificados ao longo do tempo, mas para esse bug em questão apenas estes aqui: kernel.asm, winmng.asm, winmng32.asm, fat16.asm, shell16.asm, user16.inc e winsetup.asm.
Formas de executar as novas modificações
Para executar o gerenciador gráfico pelo menu, basta selecionar com o teclado a opção "Graphical Mode (winmng.osf)" no menu inicial do kernel e pressionar ENTER para passar das informações básicas do modo gráfico. E assim uma imagem padrão inserida no winmng.osf será imprimida. O sistema espera que o usuário pressione a tecla F1, após isto, o sistema irá retornar ao menu inicial.
Para executar o gerenciador gráfico pela linha de comando do Shell, basta digitar kiddieos\users\winsetup.exe se você estiver no diretório raiz K:\ ou winsetup.exe se você estiver no diretório K:\kiddieos\users\. A extensão ".exe" pode ser omitida na digitação se quiser. Digitando o nome do programa (sem argumentos) como foi mostrado, o programa DOS vai imprimir as informações do modo gráfico (assim como a primeira forma) e esperar uma tecla qualquer, pressionando-a irá para o gerenciador gráfico com a imagem BMP imprimida, no entanto, esta é uma outra imagem padrão diferente daquela que está em winmng.osf. Para testar outra imagem como Área de trabalho, basta digitar winsetup K:\imagem.bmp considerando que "imagem.bmp" está no diretório raiz, mas se por exemplo estiver no diretório "Kiddieos\images\" basta digitar winsetup K:\kiddieos\images\imagem.bmp e tudo dará certo. Se caso a imagem não existir, ocorrerá um erro de abertura e se caso a imagem tiver uma resolução maior que 320x200x24bpp, ocorrerá um erro de "Arquivo não suportado". Um detalhe importante: Na primeira vez você pode até digitar algo como winsetup bftc\images\flower1.bmp e ainda dá certo, caso estiver no diretório "Kiddieos\users\", mas na segunda vez já não dá mais e ocorre um bug, então não está 100% perfeito. Por isso, considere por enquanto usar o diretório completo, começando da letra de unidade raiz como "K:\kiddieos.....".
OBS.: Não é possível carregar arquivos maiores que a resolução 320x200 justamente por que ainda não temos o Driver ATA, e são arquivos muito grandes pra ser carregados na memória baixa que só é abaixo de 1 MB. Após a construção do Driver ATA e adaptação do FAT16 pro modo protegido, aí sim, podemos carregar resoluções altíssimas como outros sistemas operacionais modernos.
New features & Bugs fixed
Para saber com mais detalhes como todas essas mudanças foram feitas, é só checar cada arquivo commitado no próprio Pull Request na aba commits ou clicando aqui https://github.com/FrancisBFTC/KiddieOS_Development/pull/15/commits/13b0e8acd4c6c3a3bb4f2bb97afd7ba051318b74 e encontrará as linhas que foram modificadas. Vários arquivos foram modificados ao longo do tempo, mas para esse bug em questão apenas estes aqui: kernel.asm, winmng.asm, winmng32.asm, fat16.asm, shell16.asm, user16.inc e winsetup.asm.
Formas de executar as novas modificações
kiddieos\users\winsetup.exese você estiver no diretório raizK:\ouwinsetup.exese você estiver no diretórioK:\kiddieos\users\. A extensão ".exe" pode ser omitida na digitação se quiser. Digitando o nome do programa (sem argumentos) como foi mostrado, o programa DOS vai imprimir as informações do modo gráfico (assim como a primeira forma) e esperar uma tecla qualquer, pressionando-a irá para o gerenciador gráfico com a imagem BMP imprimida, no entanto, esta é uma outra imagem padrão diferente daquela que está em winmng.osf. Para testar outra imagem como Área de trabalho, basta digitarwinsetup K:\imagem.bmpconsiderando que "imagem.bmp" está no diretório raiz, mas se por exemplo estiver no diretório "Kiddieos\images\" basta digitarwinsetup K:\kiddieos\images\imagem.bmpe tudo dará certo. Se caso a imagem não existir, ocorrerá um erro de abertura e se caso a imagem tiver uma resolução maior que 320x200x24bpp, ocorrerá um erro de "Arquivo não suportado". Um detalhe importante: Na primeira vez você pode até digitar algo comowinsetup bftc\images\flower1.bmpe ainda dá certo, caso estiver no diretório "Kiddieos\users\", mas na segunda vez já não dá mais e ocorre um bug, então não está 100% perfeito. Por isso, considere por enquanto usar o diretório completo, começando da letra de unidade raiz como "K:\kiddieos.....".OBS.: Não é possível carregar arquivos maiores que a resolução 320x200 justamente por que ainda não temos o Driver ATA, e são arquivos muito grandes pra ser carregados na memória baixa que só é abaixo de 1 MB. Após a construção do Driver ATA e adaptação do FAT16 pro modo protegido, aí sim, podemos carregar resoluções altíssimas como outros sistemas operacionais modernos.