Présentation

Le projet boot.zip propose une archive ZIP classique contenant son propre code source (plus de vingt fichiers, dont boot/ZIPHEAD.COM, setup/entry16.S, util/zippack.c, etc.). La vérification avec unzip -t boot.zip confirme l’intégrité de chaque entrée, aucune erreur n’est détectée dans les données compressées. Le script mk.sh génère l’archive à partir de ces sources, à condition d’avoir zlib installé.

Fonctionnement du secteur de démarrage

Les 512 premiers octets de boot.zip forment un secteur de démarrage BIOS valide. Le dump hexadécimal suivant montre la structure :

00000000: 50 4b 03 04 0a 00 02 80 00 00 eb 44 e4 2e 41 0f
00000010: 01 8f 0a 09 00 00 0a 09 00 00 10 00 00 00 62 6f
00000020: 6f 74 2f 5a 49 50 48 45 41 44 2e 43 4f 4d 00 90
00000030: 02 b0 ad 1b 03 00 01 00 fb 4f 51 e4 30 00 10 00
00000040: 00 00 10 00 bd 72 10 00 bd 72 10 00 31 03 10 00
00000050: fa fc 31 c0 89 c4 8e d8 8e c0 8e d0 ea 61 7c 00

Les quatre premiers octets 50 4b 03 04 correspondent à l’en‑tête local d’un fichier ZIP (local file header) pour boot/ZIPHEAD.COM. Immédiatement après, les octets 02 b0 ad 1b (endianness inversée) forment la constante 0x1BADB002, le « magic » requis par le standard Multiboot. Le code réel du boot‑loader démarre à l’offset 0x50, juste après cet en‑tête.

Boot avec QEMU et support matériel

QEMU accepte l’archive comme noyau grâce à l’option -kernel boot.zip. Le chargeur Multiboot lit le magic, récupère l’adresse d’entrée (définie dans le même bloc) et passe le contrôle au code 16 bits qui active l’A20, passe en mode protégé 32 bits et charge les fichiers suivants depuis le disque. Le même fichier peut être copié sectorielement sur une disquette (dd if=boot.zip of=floppy.img conv=notrunc) ou sur un disque dur ; le boot‑loader interroge alors l’INT 13h pour déterminer la géométrie du support et adapter les lectures.

Analyse technique du format ZIP exploité

Le format ZIP stocke chaque fichier avec une structure zip_entry_t : magic, version, flags, méthode de compression, timestamps DOS, CRC‑32, tailles compressée et originale, longueurs du nom et des champs supplémentaires, puis le nom et les données. Aucun champ de permissions Unix n’est présent, ce qui simplifie le traitement en mode réel. Le projet place le fichier exécutable ZIPHEAD.COM en première position, ce qui garantit que le BIOS lit d’abord un secteur contenant à la fois un en‑tête ZIP valide et le magic Multiboot. Cette dualité repose sur le fait que le lecteur ZIP commence à la fin du fichier pour lire le répertoire central, alors que le BIOS ne lit que les premiers 512 octets. La contrainte principale est que le fichier de boot doit rester non compressé (méthode 0) pour que le BIOS puisse l’exécuter directement. Toute compression ou modification du premier fichier casserait le démarrage. De plus, la taille du secteur de boot est limitée à 512 octets, ce qui impose une implémentation très compacte du code d’initialisation.