5 pontos por GN⁺ 2023-11-04 | 1 comentários | Compartilhar no WhatsApp
  • Um desenvolvedor publicou, por ocasião de sua aposentadoria, código-fonte acumulado ao longo de mais de 40 anos, permitindo examinar diretamente sistemas antigos, ferramentas e projetos pessoais
  • O material publicado inclui até sistemas operacionais e kernels, como um kernel multiprocessos/multitarefas para ARM, um sistema operacional para CPU 6809 e um OS inicial da época do Altair 1980
  • Também são oferecidas ferramentas de desenvolvimento de baixo nível, como Micro-C Compiler, cross-assemblers, disassemblers, emulador 8052 e debugger
  • Foi disponibilizada uma ampla variedade de utilitários para trabalho em PC, incluindo DOSBox, utilitários DOS, sincronização de arquivos, manipulação de ZIP, criação de pacotes de instalação e editor de texto
  • Inclui ainda projetos pessoais de hardware, como rádio amador, controle remoto infravermelho por RS-232, Ethernet TTY, controle X10 e um robô para ler 1.500 DVDs, o que lhe dá grande valor de preservação

Objetivo da publicação e documentos de orientação

  • Por ocasião da aposentadoria, foi publicado código-fonte acumulado ao longo de mais de 40 anos correspondente a “coisas que eu escrevi”
  • O objetivo da publicação é permitir que outras pessoas usem esse código de forma útil ou aprendam com partes dele
  • Documentos indicados junto com a página de publicação:

Sistemas operacionais, kernels, máquinas virtuais e simulação

  • ARMOS: kernel multiprocessos/multitarefas para ARM
  • CUBIX: sistema operacional para CPU 6809
  • DMF: OS inicial da época do Altair 1980
  • DVM: Dunfield Virtual Machine
  • SIMSYS: sistemas relacionados a Altair, D6809, H8, Horizon e Mod8
  • MONITORS: monitores para vários processadores embarcados
  • 8051ICE: emulador in-circuit que usa EMILY
  • EMILY52: emulador 8052

Compiladores, assemblers, debuggers e ferramentas auxiliares de desenvolvimento

  • MICRO-C: Micro-C Compiler
  • MCSAMPLE: programas de exemplo do Micro-C
  • XASM: cross-assembler e ferramentas
  • DISASM: cross-disassembler
  • DMS: debugger Dunfield MicroScope
  • DESMO: Debug Scripting Monitor
  • DDSIDE: Dunfield Development Systems IDE
  • BLDTOOL: ferramenta que auxilia tarefas de build
  • PUBSRC: ferramenta de manutenção da seção de código-fonte público
  • HFC: Help File Compiler
  • ESL: Extensible Script Language

Utilitários de DOS, arquivos, disco, edição e empacotamento

  • DBBD: disquete de boot do DosBox
  • DBUTIL: utilitário do DosBox
  • DD_DBSRC: árvore de código-fonte do DosBox
  • DOSUTIL: vários utilitários DOS
  • FDI: Floppy Disk Image
  • IMDSRC: ImageDisk
  • EDT: editor de texto EDT
  • ELF: ferramenta de edição de nomes longos de arquivo
  • FTOOLS: várias ferramentas para operações com arquivos
  • SYNC: sincronização de duas árvores de diretórios
  • ZDIR: listagem de arquivos dentro de ZIP e touch
  • MAR: MicroARchiver, usado para compactar arquivos de instalação
  • MKPKG: criação de instalador de pacote em um único .exe
  • ESP: patch de strings em arquivos executáveis
  • PT: ferramenta PaperTape
  • MICROCAD: programa CAD de desenho muito pequeno

Hardware, comunicação, controle e projetos pessoais

  • DARC: Dunfield Amateur Radio Controller
  • HTX242: controle do transceptor amador RS HTX-242
  • ICOMCIV: código de interface ICOM CI-V para rádio amador
  • IR232: controle remoto infravermelho serial RS-232 com aprendizado
  • ETTY: Ethernet TTY
  • SNIFF: sniffer Ethernet
  • DLM: Data Line Monitor
  • ITS: Interactive Terminal Switch
  • DDLINK: DavesDataLink para transferência de arquivos por COM, LPT e NET
  • SERCNCT: alternância entre vários dispositivos em uma única porta COM
  • DBOX: controlador de VCR Sony
  • DVDROBOT: robô criado para ler 1.500 DVDs
  • EPROM: programador de EPROM
  • 8031DWG: exemplo de projeto baseado em 8031
  • X10CTRL: controle de dispositivos X10 a partir do PC
  • RINGSW: switch de distinctive ring para linha telefônica
  • PC100: emulador de terminal VT-100
  • LABTOOLS: várias ferramentas de laboratório/teste
  • CAM: projeto para crianças com deficiências do desenvolvimento
  • MACMON: monitoramento/log de uso da rede pelas crianças
  • TRANZTCL: ferramenta de desenvolvimento para Verifone TRANZ PointOfSale

1 comentários

 
GN⁺ 2023-11-04
Opiniões do Hacker News
  • Dei uma olhada no DOSUTIL.ZIP e gostei muito dos programas em C, simples e elegantes
    Também é impressionante que muitos deles usem só 1 ou 2 linhas de #include padrão do C, e que haja apenas 24 #if em 20 mil linhas de código C
    A experiência de ler uma base de código assim serviu de inspiração quando comecei a trabalhar na Cosmopolitan Libc

    • Se há apenas um alvo de build, dá para reduzir bastante o uso de macros #if
    • Compiladores C antigos deixavam passar todo tipo de erro que compiladores C modernos capturariam corretamente
    • No lado do Rust, escrevi um listener HTTP simples com uma única rota, e o Cargo trouxe umas 105 dependências para fazer o build
      Ainda assim, para fazer uma comparação equivalente, havia só 2 declarações use
    • Por outro lado, em C também existe uma tabela hash implementada apenas com macros. É bem legal: https://troydhanson.github.io/uthash/
  • Achei estranha a convenção True=7 em STYLE.TXT
    O texto dizia que, por experiência com código de baixo nível e hardware, para “minimizar o que pode dar errado em baixo nível”, às vezes ele usava 7 como verdadeiro em vez de 1, aproveitando o fato de que em C 0==FALSE e !0==TRUE
    É uma escolha habitual de que uma diferença de 3 bits é melhor do que uma diferença de 1 bit, mas, se de fato houvesse esse tipo de erro de hardware de 1 bit, a maior parte do sistema estaria quebrada; o próprio autor admite que era uma bobagem
    Fico curioso se antigamente era comum bit flips aleatórios estragarem condicionais

    • Mesmo que isso acontecesse, não dá para tratar todas as condicionais como se fossem booleanos ternários
      Também seria preciso decidir qual branch pode ser executado com segurança em caso de falha, contar o número de bits de cada condição e considerar verdadeiro quando houver mais 1s do que 0s, e ainda registrar em log ou avisar o operador quando um bit tiver virado sem correção de erro
      Há lugares em que códigos de detecção de erro são úteis, mas simplesmente definir verdadeiro como 7 não basta
    • O próprio autor praticamente reconheceu que era um hábito bobo, e acho que isso até deixa a intenção menos clara
      Mesmo assim, foi divertido ler o documento de estilo, e gostei de ele ter publicado tudo assim. Com certeza deve haver alguma ferramenta ali que é perfeita para alguém
    • Ao verificar se uma linha de dados serial está funcionando, usa-se 0xA5(1010 0101) para enviar uma sequência alternada de bits ligeiramente modificada
      É uma forma de testar o maior número possível de falhas de uma só vez
    • Se a preocupação chega a esse ponto, TRUE=7 não é uma solução de verdade
      Se for uma variável booleana, seria preciso tratar em cada condição if (var == TRUE), else if (var == FALSE) e o que fazer para qualquer outro valor, e o próprio código de tratamento também não poderia falhar
      Além disso, bit flips podem afetar variáveis usadas em switch, condições como if (i > 17), ponteiros, endereços de retorno na stack e até o próprio código
      Na melhor das hipóteses é uma solução muito parcial, e a implementação também não é trivial, então é difícil vê-la como uma convenção padrão
    • Não parece ser um problema comum; está mais para “pode acontecer, então vamos tentar evitar onde for fácil”
      Pessoalmente, acho que eu teria usado -1
  • Sinto muita pena de não ter guardado direito meus códigos antigos
    Considerei tudo trivial e sem valor para arquivamento: meu primeiro programa não trivial, um jogo da cobrinha, meu primeiro utilitário feito em assembly, meu primeiro driver de dispositivo para impressora Centronics, até um calendário perpétuo feito em Pascal em uma hora para uma tarefa da faculdade, estando de ressaca pesada
    No fim, não sobrou nenhum código anterior ao fim dos anos 1990. Desenvolvedores jovens deveriam guardar bem o próprio código

    • As crianças de hoje usam Git e vários hubs de hospedagem, então é raro o código desaparecer; nesse sentido, talvez esse seja um problema só da nossa geração
      Claro que, se esses serviços “gratuitos” saírem do ar, vira um problema, então self-hosting também é útil
    • Tenho bastante código antigo guardado, mas é tão constrangedor que não quero olhar de novo
    • Comigo é parecido. Também fiz um programa de planilhas para DOS, tinha gráficos e fórmulas em modeX, e fiz alguns jogos e alguns vírus também
      Na época, TSRs pareciam mágica. Talvez estejam em algum disquete no porão da casa da minha mãe
  • Também vale a pena ler o relato do autor sobre quando quase morreu em 2019: https://dunfield.themindfactory.com/2019.htm

    • Foi intenso. Lembrei do meu sogro, que teve um infarto em 2015 e ficou com 90% do coração danificado
      Os resultados dos exames eram tão ruins que um médico se recusou a tratá-lo, com medo de que ele morresse a qualquer momento durante a consulta
      Mas ele ainda está vivo, leva uma vida normal e corre na praia todo sábado. Os exames não melhoraram e ele vive sem fôlego, mas parece alguém que simplesmente se recusa a morrer
      É parecido com o que o médico do link disse: “você parece muito melhor do que o que está nos papéis”
    • Fico me perguntando por que os médicos agem assim
      No texto havia um trecho em que até “segurar os filhos no colo, dormir na própria cama, comer e fazer um pouco de trabalho manual” foram negados a ele; quando meu pai não melhorava de leucemia e pneumonia e não conseguia sair do respirador, os médicos também diziam com muita firmeza que ele teria deficiências pelo resto da vida
    • Estranhamente, isso me lembrou The Shadow Out of Time, de H. P. Lovecraft
    • É sombrio, mas no fim parece um final feliz
  • Muito bom. Já pensei várias vezes que um dia gostaria de fazer algo parecido
    É semelhante a receber uma herança dos avós. Joias de verdade e objetos curiosos devem estar misturados no meio de tralhas e lixo, mas o conjunto inteiro mostra a história de pessoas reais que viveram vidas ricas e interessantes
    Apenas alguns destaques não conseguem capturar essa vida adequadamente

    • Por que só fazer isso depois de se aposentar? Não dá para fazer agora mesmo?
    • Eu gostaria de ter guardado algumas das coisas que criei programando ao longo de 40 anos, mas a cada vez que mudava de emprego deixava tudo para trás
      Felizmente, ainda tenho um alocador de memória comercial que fiz no fim dos anos 90. Era single-threaded e só dava suporte ao Metrowerks CodeWarrior e ao antigo MacOS, mas era o alocador mais rápido e sem bugs no Mac
      Com a chegada do MacOS X, ele se tornou inútil, e não sei quem se interessaria por isso hoje
      Como eu disse ontem, perdi o código-fonte do Trapeze (https://en.wikipedia.org/wiki/Trapeze_(spreadsheet_program)). Acho que nunca me ocorreu guardar meu trabalho para compartilhá-lo mais tarde, quando ninguém mais se importasse
  • Muito legal. Comparado ao que meu histórico de código deve parecer no futuro, isso dá a impressão de ser um código bastante puro
    Em 2040, meu código provavelmente vai mostrar vestígios de ter usado um monte de bibliotecas e frameworks que “ninguém mais usa hoje em dia”
    Não é uma questão de bom ou ruim; é apenas um reflexo da época

    • Se você não arquivar essas dependências por conta própria, no futuro talvez ninguém consiga ler ou compilar o código direito
      As práticas de desenvolvimento populares hoje são surpreendentemente temporárias e frágeis. Pouquíssimos projetos atuais aguentariam 10 anos abandonados, quanto mais 40
    • Esses pip install e npm install todos vão se tornar inúteis
  • Acho que o utilitário mais influente é o ImageDisk
    Ele foi usado para preservar disquetes de vários tipos de computadores usando um IBM PC, e muitos softwares antigos no bitsavers.org e no archive.org foram recuperados com essa ferramenta

  • Em A Deepness in the Sky, de Vernor Vinge, aparece uma sociedade humana milhares de anos no futuro, na qual quase todo o software já foi escrito, e o problema é apenas encontrá-lo
    Por isso, programadores-arqueólogos vasculham arquivos e, se necessário, executam código em emuladores dentro de emuladores dentro de emuladores: https://garethrees.org/2013/06/12/archaeology/
    Você também contribuiu para uma pilha de tesouros da qual alguém vai se beneficiar, seja amanhã ou daqui a 5.000 anos

    • Engenheiros que gostam de Vinge apreciam especialmente o trecho em que muita gente supõe que o calendário moderno, isto é, do futuro distante, tenha como referência o primeiro pouso humano na Lua, mas na verdade ele se baseia na Unix Epoch
  • Como piada de última correção de bug antes da aposentadoria, fui olhar o micro-cad e deu 404
    URL: https://dunfield.themindfactory.com/dnld/sc/MICROCAD.ZIP
    O comportamento esperado é conseguir baixar o arquivo .zip

    • Parece que ele está incluído completo no zip MCSAMPLE
    • Também encontrei o mesmo 404. Não existem muitos programas CAD originais por aí, então quero muito ver este
  • Excelente. Fui acumulando algumas “bíblias” pessoais que mantenho sempre por perto ao trabalhar com certas linguagens ou tarefas de automação, e também tenho alguns métodos de organização que aprendi no HN
    Só que nunca pensei em publicá-las, porque parecem muito pessoais e específicas ao meu processo de pensamento
    Mas ver materiais como estes me inspirou. É uma ideia realmente ótima e, se possível, eu também gostaria de apoiar financeiramente o projeto de aposentadoria como forma de agradecimento

    • Fiquei curioso para saber o que exatamente você quer dizer com “bíblias” aqui
      E também gostaria de saber que métodos de organização você aprendeu. Estou sempre interessado em aprender dicas de produtividade ou softwares de outras pessoas
    • Eu também tenho várias bíblias desse tipo
      Se tiver interesse, gostaria de trocar arquivos. Acho que há muito a aprender com o seu material. Meu nome de usuário no Gmail é o mesmo do HN