Conhecendo o sistema (projeto interessante)

Valeu! 😅 Se tiver alguma dúvida ou encontrar bugs no projeto, pode perguntar por aqui. 🙂

Okay, muito bom saber o seu interesse! Primeiro eu gostaria de saber sobre o quanto você conhece de Assembly x86 Intel sintaxe NASM e FASM. E de que forma você gostaria de colaborar ou ajudar.

Bom dia! Pois é, vou explicar algumas coisas. O Assembly x86 arquitetura CISC facilmente você encontra PDFs e materiais no Google, mas eu também já disponibilizo alguns desses materiais nos links dos meus vídeos. Então a primeira coisa que indico é: Assistir e praticar o máximo das minhas vídeos-aulas do curso D.S.O.S. Este sistema operacional nasceu desse curso, no curso eu trato em mínimos detalhes de desenvolvimento desde o início deste sistema, não digo até o estado atual porque o canal deu uma paradinha temporária devido a umas questões pessoais que eu tive, porém até um estado bacana do sistema você encontra como vídeo-aulas no canal, que já pode ser suficiente pra você ter uma experiência mais prática no Assembly.

O Assembly não é difícil, ele é só prática e você saber minerar o que é essencial para seus programas e sistemas. Se você sabe o essencial e tem domínio nisso, você vai longe! Não precisa conhecer todas as instruções da Intel e de todas as tecnologias de processadores, mas é bom sim ter uma base teórica, conhecer o básico de hardware, como as coisas acontecem lá dentro até pra você não ter tanta dificuldade assim em entender o próprio Assembly pois ele é quase que "inteiramente" baseado em Hardware, o Assembly ta um pouquinho acima da camada ISA (Instruction Set Architecture ou Arquitetura do Conjunto de Instruções) que ta bem próximo da microarquitetura de circuitos lógicos, então é bem próximo do hardware, é a linguagem de programação (ou melhor, montagem) mais próxima do hardware que existe (Exceto aquelas relacionadas a VHDL que já é específica pra Hardware). O Assembly é sua ponte de compreensão do software e do hardware juntos.

Assista as aulas, coloque mão na massa e isso já vai te ajudar a conhecer o KiddieOS por dentro e já elaborar ideias pra integrar seus próprios códigos e correções de bugs, mas no próximo comentário vou especificar melhor sobre os tipos de colaboração que você já pode fazer sem precisar de muitos conhecimentos.

Sobre a similaridade do meu sistema com outros, o meu sistema é DOS-Like, ao invés de UNIX-Like, isso significa que é baseado em DOS, pois contém uma partição comum MBR, com sistema de arquivos padrão FAT16, divisão de bootloaders em MBR, VBR e finalmente Kernel. Linha de comandos similar ao MS-DOS da época, que hoje conhecemos como "Prompt de Comando", interrupções 21h que é dos próprios serviços DOS pra diversas operações e um kernel & shell de 16-bit, assim como o MS-DOS na época. Mas tem um porém... Ele não é "somente" baseado no DOS e tão pouco foi escrito "reutilizando" código pronto do DOS ou algo parecido, não é bem isso, a inspiração do KiddieOS só foi se "basear" mesmo, ou seja, eu sabia que certos conceitos existia, eu simplesmente reescrevi esses conceitos do zero no meu próprio sistema usando o que eu já conhecia de Assembly x86, foi exatamente isso. Mesclando com estudos de sistemas operacionais no Wiki.osdev.org (Outra fonte perfeita pra você). E quando eu disse que não é "somente" baseado no DOS, eu quis dizer que ele também tem características UNIX-Like, e lá vai uma delas: Interrupções de Software via IDT em 32-bit.

Pode-se perceber que a maioria dos sistemas similares ao UNIX feito por hobbystas mundo a fora, utilizam como chamada de sistemas interrupções de software gerenciados por uma estrutura chamado IDT (Interrupt Descriptor Table) em Kernel modo protegido 32 bits e é uma forma mais "dinâmica" de se chamar rotinas encapsuladas do Kernel por aplicações de software no sistema operacional e o Linux faz isso (um dos motivos por ser Unix-like), que no caso o Linux usa a interrupção 80h pra diversas operações de software. Okay, O KiddieOS segue esse conceito também. Outro exemplo é o formato de alguns comandos do Shell que eu não seguir "literalmente" vindo do DOS ou Windows, mas algo mais próximo do Linux, como o comando CHMOD (Comando pra permissões de arquivos) e comando LF (LF significa List Files que se assemelha ao comando LS do Linux), dentre outros. E outros comandos mais similar ao Windows e outros próprios do KiddieOS, ou seja, eu não tenho um "padrão único" amarrado no KiddieOS, o sistema KiddieOS foi feito pra ser único porém compartilhar características comuns entre o MS-DOS, Windows e Linux (Exceto MacOS). Quais os sistemas que inspirou o KiddieOS nascer e que também auxiliou alguns "layouts" digamos assim na parte de programação e na parte visual? Pois bem, MikeOS é um deles, pela sua simplicidade, por ser feito em Assembly e por ser em 16-bit. MenuetOS é outro, que é um sistema bem avançado, com interface gráfica e tudo mais, 32-bit, inteiramente feito em Assembly. GramadoOS, foi a partir do Gramado que introduzi o FAT16, depois eu só otimizei ele adicionando minhas próprias rotinas e o deixando mais completo e personalizável, também em Assembly. Esses são os sistemas que tirei de base pra me auxiliar em alguns partes, mas 95% do KiddieOS foi tudo idealizado por mim.

Tamo junto amigo, já já vou te enviar sobre as metas de colaboração e sobre a sua ideia de colaboração que também faz parte das metas... aguarde um pouco.

outra forma de colaboração, penso eu na divulgação enquanto estudo esse código fonte.

Essa forma de colaboração é muito boa, na verdade é perfeita e faz parte das metas, até pra conseguirmos atrair um público-alvo maior. Vou falar mais sobre ela. O que vou te explicar aqui é um arcabouço de colaborações que expliquei também para um outro amigo que também quer colaborar, mas tudo isso ainda vai se transformar em uma documentação acessível para todos, quando a comunidade tiver maior.

O KiddieOS eu dividi ele em duas fases de desenvolvimento: Fase de Construção e Fase de Otimização. A fase de construção é o que estou agora, em desenvolver a base e deixar pronta, um sistema utilizável, no qual já estou há um pouco mais de 3 anos nesta fase. A fase de otimização já é coordenada pelos usuários e colaboradores do sistema, que é responsável por otimizar, escalar, personalizar, acrescentar e corrigir o sistema. Ou seja, melhorar o sistema como um todo, desde a parte do usuário como a parte do Kernel. Porém, pra esta fase de otimização existir, toda a base na fase de construção deve estar pronta, no qual eu quero estar inteiramente responsável por ela. Até porque o sistema KiddieOS ainda está "instável" para uso ou até para otimizações ou compreensão por parte dos colaboradores, portanto, quando a fase de construção acabar, ele vai entrar nessa nova fase, que vai me exigir criar Documentações mais completas e rígidas de todo o código, de cada funcionalidade, rotina, conceito, formas de uso, ou seja, um tutorial completo e homogêneo de como usar e programar o KiddieOS, do núcleo até a parte mais alta (aplicações).

A documentação será separada em algumas partes:

Comentários em códigos-fontes: Vai descrever todas as operações direto no código e deixar tudo dividido e demarcado.
Documento técnico escrito: Um documento README, WORD e PDF explicando as funcionalidades do KiddieOS, com suas funções existentes, e lógica de funcionamento, incluindo fluxogramas, diagramas, textos e imagens exemplo.
Documento não-técnico: Um documento focado pra usuários, sendo um tutorial de utilização, como: Usar comandos, criar aplicações, onde encontrar pastas e arquivos, como fazer configurações no sistema, etc.

A partir do momento que toda essa documentação de toda a fase de construção já tiver pronta, é aí que se inicia a fase de otimização, onde vou disponibilizar essa documentação para todos em redes sociais, youtube, github, páginas, grupos e demais canais de comunicação. Junto a documentação, terá uma lista de regras para colaboradores e os seus tipos de colaboração. Não vou introduzir a estas regras agora, mas vou especificar os tipos de colaboração possíveis neste momento atual e nos momentos futuros:

Colaboração pro momento atual

Divulgação: Como você mencionou, essa será um dos primeiros tipos, não tendo uma ordem específica de execução, mas que tem igual relevância. A divulgação será pra atrair mais colaboradores, interessados e usuários. Também vai servir pra aumentar nossa comunidade, que já é existente no Discord e no Youtube (KiddieOS.Community, posso te passar o link mais tarde se não tiver lá). Você como divulgador, poderá até mesmo aumentar seu "Networking" e círculo de amizades de novos colaboradores, criar uma teia, uma rede de pessoas que te sigam e que até mesmo te "ajudem" a colaborar. É como se você fosse um professor alternativo do KiddieOS, que ajuda disseminar o conceito do KiddieOS nas redes sociais e grupos de programação.
Identificação de falhas: Você pode ser um explorador de falhas no KiddieOS apenas em "tentar" utilizá-lo, e uma forma legal de se fazer isto é assistir o máximo de vídeos de "Demonstração" do KiddieOS no canal, que são vídeos que geralmente coloco "KiddieOS:" ou "KiddieOS - " no início do título, ou apenas um título SEM a tag #dsos, que é uma tag só relacionado para as "Video-aulas". Os vídeos de demonstração eu demonstro testes e novas funcionalidades desenvolvidas no KiddieOS, normalmente são vídeos mais curtos e sem voz (Com música de fundo). Assistindo estes vídeos, você aprende a como utilizar o KiddieOS existente e efetuar seus primeiros usos e testes, procurando bugs e reportando aqui em formato de Issues no Github, eu irei checar, corrigir em um tempo adequado e te dar um feedback didático do que ocasionou o bug e o que eu fiz pra corrigir, prezando também no seu próprio aprendizado sobre o sistema e sobre os desafios de programação (Detalhe: Não é necessário conhecer de programação pra explorar esses bugs, apenas usar e tentar fazer algo). Para criar Issues aqui, teria algumas regrinhas, mas nada tão exigente assim, apenas que detalhe bem nas descrições, crie um título do erro, e descreva o erro o melhor possível que você conseguir, pra me conseguir entender exatamente o que você estava tentando fazer e o que você esperava como resultado do seu teste, e assim saberei como corrigir ou terei uma forma melhor de procurar e corrigir o erro.
Sugestões de novos sistemas: As sugestões são importantes, até pra filtrarmos os interesses e necessidades, e é algo frequentemente visto no meu canal, no entanto, uma sugestão jogada no ar na internet sem domínio técnico é apenas uma "Sugestão", correto? Algo que encontramos direto por aí. Okay, não é bem dessa forma que eu menciono esse tipo de sugestão que eu espero em uma dessas colaborações, vou explicar: Se você pede algo como - "Eu tenho uma sugestão: Crie um gerenciador de tarefas exatamente igual o do Windows" ou "Crie um driver de placa de vídeo avançada que rode qualquer jogo 3D do Windows", concorda que eu posso levar anos pra concluir estas coisas? E que são sugestões genéricas que todos pedem? Então, tente fugir desse tipo de sugestão. Eu gostaria de algo mais técnico, simples, objetivo e específico, quanto mais específico melhor e quanto mais enquadrado ao que já "existe" no sistema, melhor ainda. Por exemplo: Digamos que eu criei um novo comando pra checar "Detalhes" de arquivos, e aí nos seus testes, você identificou que seria bom ter um novo parâmetro para checar um detalhe específico de um tipo de arquivo.. e aí eu analisei a sua sugestão, estudei o caso e vi que realmente seria bom, então isso sim seria "Sugestão perfeita" digna de "Colaboração do KiddieOS". Isto significa que deve ser algo criteriosamente avaliado, validado e enquadrado nas necessidades atuais do sistema, medidas pelos seus estudos do KiddieOS e o que ele poderia ter "a mais" pra melhorar, algo que pode ser mais rápido de implementar mas que faria toda a diferença pra quem tivesse a mesma necessidade que você. Viu que não é algo apenas jogado no ar? Pode ser algo muito simples, um simples parâmetro de um comando, um simples ícone de uma janela, ou... um novo comando, talvez, uma nova rotina Assembly que complemente outra, existem milhares de sugestões boas que você poderá fazer.

Colaboração pro momento futuro

Integração de Código: Isso será feito utilizando a ferramenta de Pull Request do Github, no qual terá um documento escrito por mim citando as regras de utilização e envio (Todo repo mais completo tem algo assim). Integrar código seria você realizar o Fork do KiddieOS para seu próprio repo e máquina, e após o conhecimento avançado de toda a arquitetura estrutural e funcional do KiddieOS, você implementar seus próprios algoritmos para por exemplo: Novas Syscalls, novas interrupções de software, novas libraries, novas funções em libraries existentes, ou novos comandos do Shell, ou seja, você já tem uma base, já conhece Assembly e viu uma oportunidade de criar um código que funcione e testado por você. Você simplesmente enviaria uma solicitação de Pull (Pull Request) com suas novas modificações, juntamente com Imagens ScreenShots de Testes, descrições ricas de cada alteração, sua motivação em atribuir essa funcionalidade, etc... eu baixaria na minha máquina, testaria e se tivesse dentro dos padrões, sem afetar nenhuma outra funcionalidade e tendo um valor legal no sistema, eu concordaria com sua nova contribuição e realizaria o Merge da sua alteração com o Repo principal (Main) e sua nova funcionalidade estaria no KiddieOS. Essas novas funcionalidades poderiam ser desde simples/básicas até mais avançadas/maiores, no entanto, para esse tipo de Integração inicialmente, será preferencialmente recomendável pequenas alterações por motivos de segurança também, ou seja, funcionalidades menores. Isto é, preferível criar muitas funcionalidades menores uma de cada vez (pra cada Pull Request) como partes integrantes de um problema maior, do que todo o problema maior resolvido de uma vez só, na integração de código por Pull Request.
Otimização/Personalização: Otimizar e personalizar pode sim ser criar algo novo, mas muito frequentemente ta ligado a mexer com algo que já ta pronto, por isso há uma alta taxa de riscos e uma grande probabilidade de reprovação no Pull Request, então exige maiores conhecimentos do que no tipo de colaboração anterior. Otimizar seria pegar um código que por natureza ta lento e aumentar sua eficiência, sua velocidade, trocando instruções, invertendo algoritmos ou refazendo partes do algoritmo sem afetar nenhuma outra funcionalidade pré-existente, deixando o algoritmo mais rápido, mais eficaz. Personalizar já é deixar algum sistema/algoritmo com características mais avançadas. Por exemplo: Se eu tenho uma janela gráfica do KiddieOS, que o padrão dela construída por mim foi: botão minimizar, maximizar, fechar, título da barra e só. Então você decide adicionar nas syscalls e interrupções de software uma nova personalização - adicionar menus com as mesmas funções dos botões no canto superior esquerdo da janela após um click de mouse, Opa, isso se trata de uma "personalização", é algo que foi acrescentado em outro existente pra tornar mais avançado e melhor a experiência do usuário. Mudar a cor da barra por exemplo seria considerado "Personalização"? Depende... se o KiddieOS já tiver uma função pra mudar a cor automaticamente da barra, neste caso não seria personalização, pois qualquer um poderia mudar, mas se ele não tiver essa função e você "Implementar" essa função pra alteração de cor dinâmica da barra por qualquer usuário, aí sim, é uma personalização. Mas apenas mudar a cor de X para Y não seria considerado personalização. E otimização? Okay, digamos que um algoritmo pra procurar a pasta X dentro de 50 pastas leve em torno de 1,3s (1 segundo e 300 milisegundos) na média ali segundo seus cálculos de eficiência e você encontrou uma forma algorítmica bem simples de alterar aquele algoritmo e que fez ele buscar a mesma pasta X nas 50 pastas por um tempo 50% inferior ao tempo original, como 650ms (650 milisegundos), isso é uma otimização. Poderia ser apenas 5% inferior, ou apenas 300 ms a menos de diferença, ainda é uma otimização, porque melhorou o algoritmo. No entanto, se essa diferença for insignificante demais, como apenas 5 ms, 10.. 50.. sei lá... algo que não faz diferença, já não seria uma otimização tão relevante. A otimização também pode ser enquadrada na correção de bugs, porque um sistema pode ter falhas, erros e defeitos, são 3 características diferentes... e você pode tanto que otimizar ou corrigir, tudo será uma otimização. Se você encontrar uma falha, mesmo que mínima, mas que pode acarretar lá na frente e souber corrigir, você ainda estará otimizando o sistema, então está valendo. Muitas vezes um defeito não é tão perceptível assim, erros e falhas é até mais fácil, mas deficiências, defeitos, é algo que só se descobre com o tempo de uso, como a velocidade de operação por exemplo e isso só pode ser corrigido via otimização.

Então, isso é só uma pré-introdução do que seria uma pequena parte da documentação pra colaboradores e usuários. Eu indicaria você começar pelas colaborações pro momento atual, uma das que eu mencionei (ou todas se quiser, você que escolhe) porque ela é a que está disponível por enquanto na fase de construção.

OBSERVAÇÕES: A fase de otimização não é uma substituta da fase de construção, na verdade ela vai complementar em cima. Ou seja, todos aqueles tipos de colaboração que eu mencionei vai coexistir junto. Por enquanto, eu que faço isso tudo sozinho, mas no futuro quero uma comunidade inteira, com várias pessoas fazendo cada parte dessa.

Qualquer dúvida que você tiver, será bem-vinda! :)

Obrigado! Sua ajuda é extremamente valiosa e significante pra mim.

É uma ideia boa, mas nunca criei por ainda não entender exatamente o intuito dessas organizações aqui no Github, ainda tem coisa aqui que quero explorar mais.

Até fiz um teste uma vez criando uma organização pro Curso D.S.O.S, onde o meu intuito era ter uma sala de aula no Github pra quem acompanhasse o curso, podendo criar seus repositórios de prática, e também exercícios e desafios seriam postados ao decorrer das aulas: https://github.com/CursoDSOS

Mas o pessoal não se juntou lá e eu também não busquei saber mais sobre estas organizações, aí ficou lá parado, deixei apenas o repositório. Mas quem sabe eu possa retornar com essa ideia.

Este sistema especificamente não pretendo deixar em algum nicho de mercado, não este, mas outro que vem a nascer a partir dele. Eu tenho outra ideia de projeto que já existe há um tempo, mas pra ele existir é preciso do KiddieOS pronto, portanto, o KiddieOS será a base e o núcleo do próximo sistema, que este sim, terá um nicho de mercado.

O KiddieOS é um sistema open-source e livre pra distribuir e modificar, sem fins lucrativos, similar ao Linux. É um sistema didático mais focado no público estudante, em especial dos que estudam sistemas operacionais, Assembly e C. Atualmente ele ainda não tem a linguagem C como desenvolvimento, mas terá no âmbito de aplicações e outros tipos de drivers alternativos no formato ELF que os programadores/colaboradores venha a criar, após eu dar o suporte ao formato ELF.

O KiddieOS será um sistema comum de utilização como qualquer outro, não tendo tantos recursos inicialmente como Linux ou Windows, nem suporte a nuvem ou mobile, mas um sistema minimalista com recursos essenciais pra tarefas tradicionais e especializado em ensinar sobre a parte interna dos sistemas. Então ele terá uma base otimizável e escalável, onde os usuários poderá configurar o sistema a ter outros comportamentos e cada usuário poderá ter seu próprio KiddieOS personalizado. Toda essa personalização poderá ser conhecida e estudada através do código-fonte disponível pelo GitHub e por arquivos de configuração também.

O próximo sistema que vai nascer dele é por âmbito comercial focado em novas plataformas diferentes do Desktop e do Mobile, mas por enquanto não posso revelar ainda porque é apenas uma ideia escrita. O KiddieOS será o núcleo base desse sistema. Este próximo sistema, depois de um protótipo pronto, usarei como trabalho de pesquisa inicialmente para mestrado em computação, mas após isto, ele será comercializado com a aplicação do protótipo. Já o próprio KiddieOS ele será distribuível e livre pra comunidade aprender e aplicar seus conhecimentos de sistemas operacionais. Farei apenas a base e os usuários farão o resto pra fazer ele crescer sozinho.

KiddieOS_Memory_Architecture

Acima contém uma imagem do modelo de arquitetura de memória do KiddieOS. Alguns destes tópicos estão feitos, outros ainda estão em andamento e outros ainda faltam desenvolver, mas pelo menos a parte inicial ali do Shell em 16-bit, seus comandos, o kernel, já ta desenvolvido e estava recentemente em período de otimização e manutenção. Alguns desses drivers também já foram construídos, o gerenciador de janelas também mas ainda falta corrigir erros do gerenciador e outras falhas que deixei em aberto aqui numa outra Issue. Toda essa arquitetura é a versão base do KiddieOS que eu mencionei pra você, a fase de construção. Após esta arquitetura pronta, é que eu vou abrir a colaboração completa (Fase de otimização).

Conhece sobre os sistemas open-sources existentes? TempleOS, MenuetOS, BareMetalOS, etc... pode ser visto neste link centenas destes projetos https://wiki.osdev.org/Projects. Meu foco no KiddieOS é seguir nessa linha primeiro, como alguns destes projetos que você pode estar vendo neste link. São sistemas hobbystas, feitos por entusiastas, alguns deles acredito que já morreram (Como o Terris Davis), outros ainda estão com os sistemas ativos recebendo suporte, e outros abandonados, mas contém centenas deles. Então, O KiddieOS é nesta linha, pra depois o próximo sistema usufruir disso pra incorpora-lo e criar outro sistema, para aí sim ser comercializado.

FrancisBFTC / KiddieOS_Development

Conhecendo o sistema (projeto interessante) #18

Colaboração pro momento atual

Colaboração pro momento futuro