[OS] Coder un nouvel OS, qu'est-ce que on doit recoder ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

30/06/2005, 20h39
AsmCode

[OS] Coder un nouvel OS, qu'est-ce que on doit recoder ?

Voici un topic, des trucs à tenir et ne pas tenir compte lorsqu'on se lance dans le programmation d'un OS, histoire de démêler ce qui est propriétaire à un OS existant et ce qui est "général" du côté de l'asm et du cpu.

Alors je commencerai donc par cette question: Quelles sont les interruptions indépendantes du OS ? Je supposes que celle du DOS 21h est exclu. Alors il ne reste que les interruptions matérielles qui sont indépendantes du OS si je ne fais pas d'erreur ? :oops:

Est-ce qu'on peut en avoir une liste complète quelque part ? :wink:

Si je comprends bien les interruptions logicielles comme 21h de DOS c'est un genre d'API non ?

Donc je devrais les refaire pour mon OS n'est-ce pas ? :lol:
30/06/2005, 21h21
MysticKhal_0

Donc en effet les interruptions DOS sont exlus car propre au syteme DOS.. Et bien entendus tu devras les reprogrammer :D

Par contre il te reste les interruptions du BIOS (la liste ici: http://www.delorie.com/djgpp/doc/rbinter/ix/ ). Celles-ci seulement utilisable en mode réel (aujourdhui on reste rarement en mode réel donc il te faudra aussi les réécrire (c'est justement ça qui est amusent hein :wink: )).

Pour commencer je te conseil ce site http://inferno.cs.univ-paris8.fr/~am...utorial00.html c'est bien documenté avec des exemples (bien sur une fois le stade de cette doc dépassé tu devra te tourner vers d'autres document car la route qui mène à l'OS perso et longue et semée d'embûches :lol: )
30/06/2005, 21h37
AsmCode

Super :)

Mais pour réécrire les int du bios ? Est-ce bien utile ?? Est-ce que Windows s'en sert par exemple ?

Car une fois en mode protégé ils ne sont plus disponible, mais dans ce mode aussi bien faire un driver de base pour la carte vidéo pour afficher des trucs jolies à l'écran ;)

Ah oui, est-ce qu'un jour on va pouvoir booter directement en mode protégé ? On garde le mode réel pour une compatiblité mais il me semble que les vieux programmes on ne s'en sert plus alors pourquoi garder compatibilité ? Un jour il va bien faloir changer de technologie non ? ;)
30/06/2005, 21h42
MysticKhal_0

Oui quand je disais réécrire les interruptions c'étaient effectivement sous forme de drivers (bien qu'on puisse aussi les faire sous forme de int..)
Windows (ou plutot DOS dans ce cas) se sert des interruptions, l'exemple le plus bête serait quand tu programmes et que tu utilises une interruption :wink: )

Pour le boot direct en mode protégé c'est vrai que ça pourrait être pratique ^^ et que la "trainée" de cette retro-compabilité et assez ancienne, mais il ne me semble pas avoir déjà entendus parler de cette solution de virrer le mode réel (et ça pourrait changer pas mal de trucs ,bon ou mauvais).
30/06/2005, 21h49
2PluS4

Citation:

Ah oui, est-ce qu'un jour on va pouvoir booter directement en mode protégé ?

J'ai entendu dire que c'est le genre de gadget que l'on pourra trouver dans les bios de nouvelle génération...
Mais si tu fais ton os, tu peux très bien ne faire que du pmode: grub offre la possibilité de démarrer un kernel au format elf 32 bits (et directement en pmode)... ;)

Dans tous les cas, pour tout ce qui est programmation d'os, n'oublie pas de faire un tour régulièrement sur : http://skan.developpez.com/
30/06/2005, 21h51
AsmCode

Ok :)

Mais pour ce qui est des drivers, j'magine qu'il faut avoir les specs du matériel ? C'est sûr qu'une souris de base, par exemple, à 2 boton et une roulette ne poserais sans doute pas de problème, mais si la souris en question est une logitech avec 7-8 boutons, 2 roulettes, etc. Il faut un driver adapté à cette souris la pour pouvoir utiliser tout ces boutons sous le nouveau OS. À ce moment-la comment fait-on ? Il faut demander les specs au fabricant ou leur demander de faire un driver ? :?:
30/06/2005, 21h56
MysticKhal_0

Interessant le boot en pmode (bien qu'il faille alors attendre que ces BIOS se popularisent sinon la fonctionalité restera inutilisable (ou seulement pour quelques privilégiés..)).

En effet il faut les specification matériel du fabriquant (crois pas qu'ils vont t'écrire un driver adapté pour ton OS! à moins qu'il devienne très populaire (comme le cas de linux et de nvidia par exemple..)). C'est pourquoi pour un OS amateur, seul les fonctions de base sont gérés (une petite équipe peut mal géré toute les spécifications de souris à 8touches, clavier à 150 etc :lol: ).

PS: Cool le site skan commence à avoir du continus! :D
30/06/2005, 21h56
AsmCode

Dans les bios ? Je croyais que le mode réel était géré par le cpu ? :?
30/06/2005, 21h58
2PluS4

Plusieures solutions:
:arrow: Regarder dans le noyau linux
:arrow: Si tu as beaucoup de courage, reverser le driver windows de la souris en question
:arrow: Trouver une doc sur le web
:arrow: Demander une doc au constructeur (qui ne te répondra probablement pas du tout, à moins que tu ne fasse partie d'une communauté de création d'os reconnue, ... et encore !)
:arrow: Faire un driver ne gèrant que les trois boutons standards de la souris... ;)
:arrow: Faire tout au pif et avoir beaucoup de chances (et beaucoup de fromages pour pouvoir amadouer cette %#@?! de souris :roll:)
:arrow: Se lier avec un ingénieur de l'entreprise qui fabrique la souris en question
:arrow: Changer de souris et passer à quelque chose de plus facile...

:wink:

Citation:

PS: Cool le site scan commence à avoir du continus!

Oui oui ca avance 8) Merci de ton soutient ;)
30/06/2005, 21h59
AsmCode

Si j'ai bien compris, une souris multi-fonction ne fonctionne pas sous linux ? :lol:

Ça me surprendrait que MS ait fait un pilote pour linux :wink:
30/06/2005, 22h01
2PluS4

Citation:

Si j'ai bien compris, une souris multi-fonction ne fonctionne pas sous linux ?

Il me semble que logitech fournit certains drivers sous nux (pas sur...)
30/06/2005, 22h03
AsmCode

Citation:

Envoyé par 2PluS4

Citation:

Si j'ai bien compris, une souris multi-fonction ne fonctionne pas sous linux ?

Il me semble que logitech fournit certains drivers sous nux (pas sur...)

Ok :)

Mais en pratique, comment fonctionne un driver exactement ?

Si on prend l'exemple de la souris, si j'appuies sur le 5e bouton qui se trouve sur le "côté" de la souris, il me suffierait d'aller lire sur le port usb non :?:
30/06/2005, 22h07
2PluS4

Citation:

Si on prend l'exemple de la souris, si j'appuies sur le 5e bouton qui se trouve sur le "côté" de la souris, il me suffierait d'aller lire sur le port usb non

Encore faut il savoir:
:arrow: Ce que t'envoie la souris quand tu clique sur le cinquieme bouton
:arrow: Comment interpreter ces résultats (surement envoyés sous la forme de "blocks" de donnés)
:arrow: Comment activer l'utilisation du 5eme bouton
:arrow: Comprendre quelque chose au standard usb, qui est aujourd'hui considéré mondialement comme une des choses les plus complexes de l'informatique.... (pour être franc, je n'arrive même pas à comprendre le premier chapitre des spécifications .... :roll: )
:arrow: Avoir en tête une structure générique de drivers

Un driver se base sur des spécifications précises du matériel.
Son but est d'interagir avec l'os, sous forme de module, ou à l'interieur du kernel, (selon la structure de l'os), suivant un paradigme de drivers particulier: un "modèle générique" de driver.
30/06/2005, 22h12
AsmCode

Mais il reste quand même que un bouton cliqué n'est rien de plus qu'un bouton, c'est au OS de pouvoir offrir une interface sur l'action que doit prendre l'OS en fonction de ce click, je visualise mal en quoi on a besoin d'un spec sur le 5e bouton ;)

Je serais curieux de voir les specs sur port usb, est-ce que tu aurais un lien ? ;)
30/06/2005, 22h46
2PluS4

Citation:

Je serais curieux de voir les specs sur port usb, est-ce que tu aurais un lien ?

http://www.usb.org/developers/docs/ Bonne chance :mrgreen: :mrgreen:

Citation:

je visualise mal en quoi on a besoin d'un spec sur le 5e bouton

Tu en a besoin justement pour que ton driver sache que la souris est en train de lui "dire" que le cinquieme bouton a été enfoncé...

Citation:

c'est au OS de pouvoir offrir une interface sur l'action que doit prendre l'OS en fonction de ce click

Vi, mais, en gros, c'est le driver qui va "dire" au reste de l'os que le cinquieme bouton a été enfoncé, à partir de ce que lui a envoyé la souris....
01/07/2005, 03h04
AsmCode

Citation:

Envoyé par 2PluS4

Citation:

Je serais curieux de voir les specs sur port usb, est-ce que tu aurais un lien ?

http://www.usb.org/developers/docs/ Bonne chance :mrgreen: :mrgreen:

Il y a plein de Docs, laquelle est la principale ? ;)

Citation:

je visualise mal en quoi on a besoin d'un spec sur le 5e bouton

Tu en a besoin justement pour que ton driver sache que la souris est en train de lui "dire" que le cinquieme bouton a été enfoncé...

Oui ça va de soi, un driver ne serait donc qu'une routine qui vérifie à toute les secondes si un bouton de la souris à été enfoncé ? Ou si c'est plutôt qu'il faut programmer une interruption matérielle afin de déclencher un évenement de click puis que le Os exécute ce qu'il faut en conséquence, par exemple un click sur un bouton, l'API du OS fera en sorte que le bouton aura l'air appuyé a l'écran puis exécutera la procédure de cette évenement qui aura été programmé par le créateur du programme en question, est-ce que j'ai tout faux ? :lol:

Citation:

c'est au OS de pouvoir offrir une interface sur l'action que doit prendre l'OS en fonction de ce click

Vi, mais, en gros, c'est le driver qui va "dire" au reste de l'os que le cinquieme bouton a été enfoncé, à partir de ce que lui a envoyé la souris....

Est-ce qu'il y aurait une doc quelque part explicant tout le trajet ? du click jusqu'à l'affichage à l'écran :wink:
01/07/2005, 04h40
2PluS4

Citation:

Il y a plein de Docs, laquelle est la principale ?

Roo mais la première voyons ! :P
http://www.usb.org/developers/docs/usb_20_02212005.zip

Citation:

Est-ce qu'il y aurait une doc quelque part explicant tout le trajet ? du click jusqu'à l'affichage à l'écran

Non je ne pense pas... Mais tu n'as pas compris ce que j'ai posté ? :roll:
01/07/2005, 05h17
AsmCode

Citation:

Envoyé par 2PluS4

Citation:

Il y a plein de Docs, laquelle est la principale ?

Roo mais la première voyons ! :P
http://www.usb.org/developers/docs/usb_20_02212005.zip

Citation:

Est-ce qu'il y aurait une doc quelque part explicant tout le trajet ? du click jusqu'à l'affichage à l'écran

Non je ne pense pas... Mais tu n'as pas compris ce que j'ai posté ? :roll:

Euh pas tout à fait :lol:

Mais est-ce que j'ai deviné juste comme j'expliquais plus haut ? :wink:

Ok, la je viens d'examiner le code de la page:

http://inferno.cs.univ-paris8.fr/~am...utorial02.html

Mais il y a quelques trucs que je ne comprends pas :?

Dabord, le bios charge le secteur de 512 octets à l'adresse 0000:07C00 exact ? mais comment se fait le Jump vers la première instruction ?

Comment est structuré le fichier .bin, ce n'est pas un format d'exécutable d'un OS, donc quelle est sont format et comment le cpu sait ou se trouve la première instruction ainsi que les données à traiter ?

le code:
Code:

1 2 3 4 5 6 mov ax,0x07C0 mov ds,ax mov es,ax mov ax,0x8000 ; stack en 0xFFFF mov ss,ax mov sp, 0xf000
pourquoi toute ces instructions ? à quoi ça sert exactement chaque ligne ?

je sais que ça fait mov, mais pourquoi ces opération exactement ??

ensuite il y a:
Code:

1 2 end: jmp end
NOTE: ça j'ai compris c'est pour mettre le programme en boucle..
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ;--- Variables --- msgDebut db "Hello world !",13,10,0 ;----------------- ;--------------------------------------------------------- ; Synopsis: Affiche une chaine de caracteres se terminant par 0x0 ; Entree: DS:SI -> pointe sur la chaine a afficher ;--------------------------------------------------------- afficher: push ax push bx .debut: lodsb ; ds:si -> al cmp al,0 ; fin chaine ? jz .fin mov ah,0x0E ; appel au service 0x0e, int 0x10 du bios mov bx,0x07 ; bx -> attribut, al -> caractere ascii int 0x10 jmp .debut .fin: pop bx pop ax ret ;--- NOP jusqu'a 510 --- times 510-($-$$) db 144 dw 0xAA55
ça aussi c'est pour la signature et remplir le reste du fichier .bin

Mais le reste ? pourquoi jouer avec la pile au juste ?

Svp, éclairez ma lanterne :wink:

Merci :)

01/07/2005, 17h07
2PluS4
Citation:

Dabord, le bios charge le secteur de 512 octets à l'adresse 0000:07C00 exact ? mais comment se fait le Jump vers la première instruction ?

Un truc à savoir: le bios c'est en gros une suite de programmes en mode réel... Donc à un endroit donné du bios, on a un code qui copie le secteur de boot à 0x0000:0x7C00 et juste parès, on a un ptit jmp 0x07C0:0000 ! Ou quelque chose d'approchant ... ;)

Citation:

Comment est structuré le fichier .bin, ce n'est pas un format d'exécutable d'un OS, donc quelle est sont format et comment le cpu sait ou se trouve la première instruction ainsi que les données à traiter ?

:arrow: Sa structure: pas de structure :P (a part peut être le fait que les octets 510 et 511 doivent être égaux à 0x55 et à 0xAA....)
:arrow: La première instruction est tout simplement la première instruction à l'adresse 0x7C00

Citation:

pourquoi toute ces instructions ? à quoi ça sert exactement chaque ligne ?

Dans ce code, on initialise les registres de segment... Pourquoi ?
:arrow: Pour ds et es: on init à 0x07C0 pour pouvoir avoir accès au données enregistrées à partir de 0x7C0:0x0000, c'est à dire 0x0000:0x7C00
:arrow: pour ss: ben pour définir une stack ....
:arrow: Si tu ne comprend pas bien, relis tes cours sur l'asm !!! Es tu sur d'avoir bien assimilé la notion de segmentation ?

Citation:

ça j'ai compris c'est pour mettre le programme en boucle..

Vi, en effet.. ;)

Citation:

ça aussi c'est pour la signature et remplir le reste du fichier .bin
Mais le reste ? pourquoi jouer avec la pile au juste ?

Tu parles de
Code:

1 2 push ax push bx
et de
Code:

1 2 pop bx pop ax
?
On sauvegarde et restaure les registres ax et bx car la fonction "afficher" les utilise...

Voir 40 message(s) de cette discussion en une page