March 2003
I took the decision to start the development of an operating environment, written in the Forth language. I've been thinking about it for a long time, and written a bunch of documents and doodles, but so far nothing real.
Récupération d'un BootSector parmi tous ceux disponibles. Celui-ci gère les disquettes FAT de tous formats, et lance un .com standard (org 0100h). La fat (FatFileSystem) est préférée au système de blocs (RawBlockFileSystem), ainsi qu'au 4kFs que j'avais ébauché, pour le moment du moins.
Ce BootSector est modifié pour lancer un binaire en org 0000h, les 256 octets manquant aux .com générés par tcom sont écrits en assembleur (nasm) dans un BinaryHeader.
Un embryon de gestionnaire mémoire (MemoryManager) est écrit : allocation d'un nombre de pages contigües pour un pid, désallocation des pages d'un processus.
De même qu'un module d'écriture directe en RAM vidéo.
Avril 2003
Moins de temps libre (nouveau contrat client). J'avance peu. Par contre, j'envisage de passer le développement sous Debian (Woody), éventuellement en changeant de compilateur forth.
Eté 2003
Les événements m'ont un peu accaparé, mais le PC a été basculé en dual boot XP/Woody.
Problème : la partition XP est en lecture seule depuis linux, et la partition Linux n'est pas lisible directement depuis XP.
Solution (après plusieurs itérations): repartitionnements du disque. XP, 2 partitions de boot linux (une courante + une de tests), données Linux (home, backup, etc), swap (pratiquement jamais utilisé vu que le PC a 512 Mo de RAM), Commun (Fat)
Hiver 2003/2004
Je commande puis installe la Debian Sarge, configure DosEmu pour utiliser tcom, positionne CVS, etc.
J'ai installé trop de parasites. Entre temps, d'autres changements personnels mettent le projet en panne, bien que je récupère énormément de docs sur internet (merci l'ADSL).
Hiver 2004/2005
De nouveaux évènements, pas dans le bon sens, m'ont empêché de m'y mettre sérieusement.
J'ai juste écrit une base de routines pour les test unitaires, utilisée dans la TestSuite du BootSector (contrôle des valeurs des registres au lancement du loader).
Pas de bug de fonctionnement détecté, mais les valeurs obtenues ne correspondent pas aux valeurs attendues. ==> Il faudra étudier les registres dont les valeurs sont déterminables en fonction du code du BootSector.
L'utilisation massive de tests unitaires (UnitTesting) si possibles automatisés (TestDrivenDevelopment) est adoptée à l'unanimité (forcément ;-) ).
Avril 2005
Comme le temps passe...
Réinstallation totale de Sarges, DosEmu (avec FreeDos), cvs (récupération de l'ancien repository), kde et gnome (j'ai tenté d'utiliser gnome, mais je préfère le look and feel de Kde adapté à ma sauce), vim.
Sous DosEmu installation de TCOM, et divers outils type make.
Voilà pour la base. Comme d'habitude j'ai installé pas mal d'/inutilitaires/. Je dois désinstaller les jeux, pour éviter la tentation de m'en servir.
La Woody ne sera plus utilisée sur mon poste de dev . Uniquement sur un vieux bouzin pour tester DHCP, nécessaire pour utiliser la FreeBox en Ethernet (note du 2005/06/10: DHCP client a été installé sans aucun problème sur Sarge, et la connection Linux <-> FreeBox -> Internet s'est opérée sans aucune opération supplémentaire).
Le BootSector (récupéré d'un tutorial) a été étudié un peu plus sérieusement. Certains registres ont des valeurs déterminables (eg: registres de segments), et seront donc testés. Les autres (BX, SI, ...) ne seront pas testés pour le moment.
Pb: le test du BootSector n'est pas automatisable pour le moment. Il faut d'abord décider de l'émulateur PC à utiliser, et voir si il propose un moyen de récupérer une sortie texte quelconque (Bochs et Qemu proposent un port E/S pour la sortie de caractères sur stdout), et un moyen de stopper la session d'émulation.
Création d'un document expliquant le fonctionnement de la génération des binaires et images disques.
Pour le moment ce n'est pas vraiment du TDD (TestDrivenDevelopment), vu que les tests sont écrits après le code à tester, mais il faut bien un début.
2005/04/18
Ca y est!
Non, TCOS n'est pas terminé, mais j'ai simplement mis en place l'embryon du process de construction :
- écriture des sources avec vim sous linux
- lancement du make sous Linux.
Le makefile ne construit rien pour le moment (juste un touch bidon.txt sous DosEmu)
'make' sous linux lance l'usine.
Le chemin de construction est le suivant :
shell -> make linux -> DosEmu -> make sous freedos, le tout en mode tty.
Le code de retour du make sous freedos est récupéré (via une petite astuce) par le make sous linux.
Les principales cibles de make sont :
Reste à ajouter la sauvegarde du log dans un fichier (via Tee, lancé depuis Linux).
2005/04/20
Problème, problème.
J'ai inclus au makefile sous DosEmu la génération des binaires.
Le make plante pendant l'exécution de DosEmu, le ventilo du PC tourne à plein, et la cpu est à 100%.
Ca sent la bouble infinie ou le bug DosEmu ou FreeDos. Pourtant en lançant DosEmu en mode interactif, et en lançant chaque make séparément, ce plantage ne se produit pas. Vivement que j'aie une connexion internet permanante chez moi, que je puisse mettre la Sarge à jour (Note du 2005/06/10 : C'est maintenant chose faite)
.
En attendant, je dois trouver une bidouille pour éviter de lancer chaque compilation par tcom ou nasm sous DosEmu. DosEmu est suffisemment rapide, mais à chaque démarrage le FreeDos propose les options de débogage (F5, F8), avec une attente de quelques secondes. Dans l'exemple d'un lot de 200 compilations, avec 4 secondes d'attente au démarrage de FreeDos, ça fait 800 secondes (14 minutes) utilisées à tort, même si rien n'est compilé.
Si chaque compilation par tcom doit être lancée dans une nouvelle session de DosEmu, le makefile Unix devra être granularisé pour lancer lui-même la construction des binaires par tcom, un par un.
Voir l'utilisation de ifdef/ifndef dans le makefile.
Le mieux est encore de faire fonctionner ce foutu make sous DosEmu, et de s'assurer qu'il soit suffisemment standard pour accepter un makefile de type unix, en utilisant les ifdef/endif si nécessaire.
Afin de démarrer sur de bonnes bases, simplifier le makefile pour ne créer qu'une seule cible bidon (touch nom_de_fichier), puis enrichir avec bootsct.bin (nasm), header.bin (nasm), puis regdmp.com (tcom), loader.sys (cat), etc.
2005/04/25
Le make semble fonctionner. Il s'agit d'un make non standard dans ses argument et son comportement par défaut, mais acceptant tout de même la syntaxe make standard.
Le gros problème est de lui faire afficher les commandes lancées (flag -v).
Comme je suis trop fatigué pour réfléchir clairement, j'ai mis à jour le cvs avec ce qui fonctionne, et sauvegardé le répertoire sur une clé usb.
Une partie d'un jeu stupide achève de me mettre en fail safe.
2005/05/01
Remise au carré du Makefile Unix. Ca fonctionne, mais les binaires sous DosEmu sont toujours générés ==> Il faudra ajouter dans le makefile unix une règle binaire_tcos: DosEmu_bin header/header.bin binaire.COM.
Remise en CVS des makefile, pas de backup sur clé USB.
Sudo doit être utilisé pour générer les images disques (mount -o loop ne peut être fait qu'en tant que root). Avantage : j'ai appris à configurer sudo (fichier /etc/sudoers). Inconvénient : je n'aime pas les 'workaround' touchant à la sécurité.
L'utilisation de sudo est encapsulée dans trois shell scripts (domount, doumount, docp). Ainsi les makefile ne font aucune référence à sudo. Ces scripts sont placés dans ~/src/TCOS/bin. J'espère juste que sudo ne s'amusera pas à demander le mot de passe plusieurs fois lors du make.
Il reste à ajouter le lancement de l'image disque utTestReg sous Bochs ou qEmu.
L'émulateur PC choisi (Bochs, qEmu ou autre) doit être capable
2005/05/04
Je n'ai rien fait depuis la dernière fois. Juste réfléchi un peu (ça arrive...). Le makefile sous DosEmu semble être lancé à chaque fois, effet de bord probable de l'astuce utilisée pour lancer DosEmu depuis make (et récupérer le code retour du make dos DosEmu).
Une solution s'impose de plus en plus : bâtir un makefile unique, avec des directives conditionnelles, du type ifdef DosEmu, else, endif.
Les cibles contruites sous linux ont juste une clause ifndef DosEmu.
Les cibles construites sous DosEmu ont une clause ifdef DosEmu
A voir.
Le mieux serait de supprimer la pause de deux à trois secondes au démarrage de FreeDos (j'ai l'impression de me répéter).
2005/05/08
Le Makefile est maintenant corrigé. Si une cible manque, elle est reconstruite, mais lancer make sous Unix ne fait rien si le dernier make a bien fonctionné. Je n'ai pas encore ajouté les .idef .
Je suis tombé dans un patacaisse nommé FrozenBubble. Très addictif ce petit jeu. On y passe la soirée sans s'en rendre compte. Je l'ai désinstallé vendredi midi. Trop dangereux, ça devrait être interdit à la vente (de toute façon c'est du GPL donc ça ne changerait rien).
2005/05/11
Suppression de la pause au demarrage de FreeDos en utilisant l'option -input \r
Je vais pouvoir gagner du temps lors des compilations.
2005/05/14
Configuration de Bochs et qEmu avec l'image utTestReg. Le Boot secteur affiche bien ses messages (via int $10) en cas d'erreur, mais loader.sys n'affiche rien. Une disquette créée à partir de cette image fonctionne correctement sur le vieux portable Zenith, et sur la machine de développment (démarrage depuis un lecteur sur port USB).
Bref, résultat mitigé : je sais lancer l'émulation PC, mais je n'ai aucun retour de l'exécution.
AMA le problème est dans mes routines d'affichage par écriture directe en mémoire vidéo
Deux choses à faire :
1 - Créer deux tests bidons : le premier doit toujours être Ok (TestAlwaysOk), le second doit toujours être Ko (TestAlwaysKo).
2 - Réécrire mes routines d'affichage de test en utilisant l'int $10 et la sortie terminal de bochs et qEmu (via un out sur un port non utilisé par le matériel du PC).
2005/05/19
J'ai commencé la refonte des makefiles. Le makefile existant ne permettait pas de recréer les binaires manquants sans supprimer un fichier flag ou faire un touch sur le Makefile.
Pour cela j'ai encapsulé l'appel au compilateur tCom dans un .sh . Le .sh lance un tcom.bat sous DosEmu, auquel il faut donner un nom de répertoire existant sous la racine du sandbox, et un nom de source tcom à compiler.
Sous DosEmu cela fonctionne, mais lancer le Makefile sous Linux n'arrive pas à lancer le .bat avec ses paramètres.
Prochain test (trop fatigué pour le faire ce soir) : lancer tcom.sh sous Linux
Bon point pour ce soir : l'utTestReg s'exécute correctement (ie sans plantage) sous Bochs. Les UnitTests sont presque tous Ko, mais l'affichage est correct. Reste encore à dupliquer l'affichage sur le terminal, et à fermer la session Bochs depuis le programme lancé sous ému.
Remise en cvs de ce qui fonctionne, et backup sur clé usb.
Question : comment nommer l'archive ? Incrémenter la partie 'correctif' à chaque création d'archive, ou garder la même version et ajouter la date et le numéro de l'archive dans la journée?
2005/05/21
Creation du makefile "mère", qui lance les makefile dans les répertoires.
Fonctionnement correct. Creation d'un script de creation d'une image disque formatee en fat12, tronquee de son boot sector.
Mise en CVS
2005/05/25
Déplacement des fichiers .bat de ~/dosemu/bin vers ~/src/TCOS/bin, ils sont remplacés par un lien vers leur nouvel emplacement. Ceci permet de conserver un bon fonctionnement de la compilation par tcom depuis linux et une mise sous cvs de tous les fichiers .bat dans un seul repository cvs
Mise en CVS
Enrichissement et amélioration du makefile.
Mise en CVS
Modification de la librairie d'affichage : remplacement de l'écriture directe en mémoire par l'utilisation du port $E9 utilisé par Bochs pour l'affichage sur la console, modification des autres sources impactés.
Résultat : L'affichage sur la console est totalement sans rapport avec ce qui est attendu (rien de déchiffrable).
Mise en CVS avec une note adéquate sur screen.seq.
Pas de backup sur USB (à faire ASAP)
A faire : renommer screen.seq en tty.seq, changer les 'SCREEN.' en 'TTY.' et modifier les sources impactés + les makefile.
2005/05/26
Doublage des sorties bochs sur l'ecran du pc emule, via le VideoBios (int $10).
Renommage de screen.seq en debug.seq, renommage des routines SCREEN.* en debug.*
Correction des sources impactes.
Lancement de l'utTestReg ==> Affichage correct sous bochs, mais toujours pas sur le terminal. La capture d'écran de Bochs produit un fichier texte contenant le contenu de l'écran émulé (note du 20050602)
Mise en CVS
Backup sur USB
2005/05/27
Remaniement de l'arborescence des sources. Regdmp est intégré à bootsct, et utTestReg devient utBootSct.
Compilation Ok, exécution Ok (à part le pb des sorties tty de bochs).
Mise en cvs.
J'approche de la fin de cette itération. Il reste quelques outils à mettre en place (snapshots cvs, wiki, UnitTesting sous DosEmu, ryg bar), et le problème de sortie tty de bochs n'est pas résolu.
La prochaine itération se profile à l'horizon : parcours d'une fat12, et chargement d'un fichier en mémoire.
En conclusion privisoire de cette première itération :
J'ai passé pas mal de temps à mettre en place l'environnement de développement (DevelopmentPlatform).
La mise en place de Bochs n'est toujours pas probante :
Très peu de temps a été passé en codage depuis la décision de relancer le développement sous Linux, mais sont en place :
Les tests sous Bochs ne sont pour le moment pas automatisables, mais ils ne concernent pour le moment que le BootSector.
Dans l'itération 2, seront à tester sous Bochs les routines de lecture de secteurs disque. Le parcours de la FAT pourra être testé en utilisant des stubs de lecture de secteurs, ou des fichiers (voire une image disque).
2005/06/02
Configuration de l'interface eth0 (port Ethernet) en DHCP, redémarrage du service réseau et test de connexion internet : Ca fonctionne!!!
Reste à configurer un peu plus avant (DNS, Firewall), et mettre à jour la Sarge
Backup Usb des sources TCOS
2005/06/07
Mise à jour de la Sarge. Le téléchargement a duré environ une heure pour 1Gb de données, l'installation des packages et la mises à jour des configuration a duré plus de deux heures.
Installation de Mozilla (à configurer), et échec de l'installation du firewall Bastille. Je dois trouver un FrontEnd pour générer le fichier de configuration.
Bochs et DosEmu n'ont pas apparemment gagné en fonctionnalités, et leurs limites n'ont pas été modifiées.
Back to HomePage