Je crois que c'est par manque d'information que tu as publié ce commentaire car ce tuto traite autant des instructions 16 bits que 32 bits mais j'ai décidé de commencer pour les instructions 16 bits car elles sont plus faciles et permettent de bien débuter en douceur. Pour le noyau il est construit entièrement depuis zéro grâce aux connaissances acquises durant le tuto.

Et puis GRUB n'est pas un noyau mais un bootloader quant à la limite dont tu parles (je pense notamment aux 512ko et peut être au mode réèl au démarrage ) il est facilement bypassable en utilisant un bootloader de plusieurs niveaux (genre un stage 1 et puis deux).

-
Edité par cotoporto 6 juin 2014 à 4:12:34

cotoporto a écrit:

Et puis GRUB n'est pas un noyau mais un bootloader quant à la limite dont tu parles (je pense notamment aux 512ko et peut être aux mode réèl au démarrage ) il est facilement bypassable en utilisant un bootloader de plusieurs niveaux (genre un stage 1 et puis deux).

Grub ne fonctionne pas en mode réel mais il l'utilise pour ne pas avoir à créer trop de driver. Pour changer de mode pas besoin de "bypass" ! Il existe une instruction assembleur pour cela et il faut aussi avoir construit la GDT. Un noyau s'il est construit de manière indépendante, doit se charger en mémoire, il est donc au moins bootloader de lui-même ! Quelle est ta définition d'un noyau ? Pour moi c'est un programme qui gère tout ou presque donc il doit être capable de charger des programmes en mémoire, c'est donc aussi un bootloader. De même pour moi un bootloader est un noyau qui ne sait gérer presque rien (au moins une console).

-
Edité par Ictus 4 juin 2014 à 17:44:12

Salut Ictus !

Alors, Tout d'abord quand je parlais de démarrage en mode réel, je faisais en fait référence aux sois disant limites  que tu évoquais en laçant cette phrase : "J'ai alors un assembleur sans limite et ultra rapide." Car quelque soit le bootloader ou chargeur  d'amorçage si tu veux, le démarrage se fait toujours en mode réel au prime abord et on ne dispose que de 512ko pour son bootloader, il demeure néanmoins vrai qu'on peut 'aisément' passer ensuite au mode protégé.

Ensuite quand on dit bypasser cela signifie contourner donc je dis que cette limite dont tu parles, peut être contourné grâce à la méthode que j'ai donné dans mon précédent poste soit : un bootloader en plusieurs stages. D'ailleurs si je ne m'abuse GRUB utilise également ce système de plusieurs stages et c'est après le premier stage qu'il passe en mode protégé.


Enfin comme tu l'as demandé si gentiment je vais te montrer la différence ente un noyau et un booloader :

-un noyau de système d’exploitation ou kernel , est une des parties fondamentales de certains systèmes d’exploitation. Il gère les ressources de l’ordinateur et permet aux matériel et aux logiciels de communiquer entre eux en fournissant des mécanismes d’abstraction du matériel, notamment de la mémoire, du (ou des) processeur(s), et des échanges d’informations entre logiciels et périphériques matériels.

-Un bootloader est un programme qui charge un ou des système d'exploitation(s).

Quant à ta définition du noyau elle est vraiment fautive surtout quand tu avances un argument comme quoi  il doit charger des programmes. Parce qu'en fait un programme est exécuté évidement quand le système est allumé donc après le chargement du noyau donc plus besoin de bootloader ; et en plus c'est  un ensemble de programmes dont le noyau  qui permettent d'exécuter un programme dans un système : un gestionnaire de tâches, un allocateur de mémoire...Donc cela n'a rien avoir avec un booloader dont la tâche simple et unique est de charger le ou les systèmes d'exploitation(s) au cas ou c'est un bootloader muti-boot comme Grub.

La deuxième erreur est de dire qu'un utilitaire (oui c'est bien son nom) comme la ligne de commande ou le shell  fait partie intégrante du bootloader car il ne fait partie ni du bootloader ni du noyau mais est juste un logiciel comme les autres qui est s'exécute en mode utilisateur.

Voici un page similaire qui explique quelques trcs sur le OS : comment font-ils pour créer les OS

J'espère t'avoir aidé et répondu clairement à tes questions, à plus.

Bonjour cotoporto.

Ce qu'il y a de génial dans ce site, et que certains n'ont malheureusement pas compris, c'est la notion de tutoriel. Dans un tutoriel l'essentiel c'est le passage à la pratique car c'est cela qui permet de comprendre les notions en profondeur et c'est toute la différence avec une mauvaise doc (en anglais ils disent RTFM).

On  peut toujours polémiquer sur la définition d'un noyau ou d'un bootlloader mais ce qui est vraiment intéressant c'est la pratique. Pour Grub on peut télécharger le source sur le site http://www.gnu.org/software/grub/ ou sur un site debian (j'utilise Ubuntu) ensuite on peut le compiler et voir comment il marche. Je ne sais pas combien il a de stages pour démarrer, je n'ai quand même pas tout compris au source, je sais par contre qu'il utilise une GDT avec le flat model et pas de mémoire paginée comme les noyaux linux et windows. Quand on tape "c" au démarrage, des instructions sont disponibles comme "dump" qui permet de lire la mémoire. Je sais aussi que pour l'affichage il passe en mode réel avec un programme écrit en assembleur (.S format GAS). Cela lui permet d'utiliser le driver video de la carte mère. Voilà, c'est de la pratique, je ne connais pas la théorie et cela ne m'intéresse pas alors pour moi je dis que Grub c'est un noyau qui me convient parfaitement pour programmer en assembleur sans aucune limite.

Je serais très curieux de voir le noyau que tu aurais réussi à construire pour savoir s'il serait meilleur que celui que j'utilise actuellement (Grub). Même s'il n'est pas meilleur cela m'intéresse.

Salut cher ami. Tout d'abord je m'en vais te dire que je suis entièrement pour plus de pratiques et moins de théories.

Mais malheureusement ce n'est pas pour autant que la théorie devrait être complètement oubliée ; mai passons ce n'est pas l'objet de la discussion. Ce que je m’efforçais de te dire n'a rien avoir avec la théorie proprement dite (et puis pour ton information je suis essentiellement autodidacte dont la pratique ça me connais bien plus que la théorie).

Pour mieux cerner ce que je te dis, je crois que le mieux serait que tu puisses lire mon tutoriel mais malheureusement je n'ai aucune solution pour cela. Quant à mon bootloader, je crois qu'il n'a rien d'extraordinaire vu que son but principale est d'être didactique pour mon tuto ; donc il démarre juste le pc et cherche les noyaux disponibles sur l'unité de stockage de ce dernier et c'est tout !

Et puis pour pouvoir créer quelque chose, il faut tout du moins connaitre sa définition sinon on ne peut utiliser que ce que d'autre on fait sans jamais comprendre à fond le principe de fonctionnement. Bref j'espère que tu aura compris ce que j'écris et tu seras plus ouvert et moins catégorique sur ta manière de penser à l'avenir. Sur ce à bientôt.

Je me demandais quelle taille faisait ton bootloader. Comment l'installer sur le secteur de boot du disque dur ?

Pour ma part je suis un peu sceptique quant à l'intérêt de ce tutoriel car il semble prendre la même tournure que la plupart des tutoriels francophones sur le sujet à savoir:

• mélanger assembleur et langages de programmation: peut-on réellement parler de langage de programmation alors qu'il ne s'agit que de la transcription en mots anglais des codes numériques de chacune des instructions reconnues par le processeur ? En effet la syntaxe du C, du Basic, du Python, ne varie pas selon que vous soyez sur un processeur Intel, un ARM ou un micro-contrôleur. Il y a une notion d'abstraction de la machine sous-jacente qui est par essence même absente dans le cas de l'assembleur (bien que parfois similaires, les jeux d'instructions varient d'un processeur à l'autre).
• mélanger les familles de processeurs: la terminologie x86 désigne la famille de processeurs compatibles avec le jeu d'instructions de l'Intel 80386, processeur 32 bits.
• mélanger modes de fonctionnement du processeur: les processeurs d'Intel ont une qualité formidable: la rétro-compatibilité. C'est à dire que les derniers processeurs 64 bits sont capables de fonctionner de la même façon que le faisaient les processeurs il y a 30 ans. Cela engendre chez les néophyte un mélange sans vergogne entre code 16 bits, 32 bits et 64 bits, chacun associé à un mode d'exécution spécifique de ces processeurs.
• enseigner avec ce foutu mode réel 16 bits: le mode réel est un immondice sans nom, obsolète et datant d'une époque où l'ordinateur personnel n'était qu'un amas de rustines en vue d'obtenir quelque chose d'exploitable. Enseigner le codage des bootloaders destinés à être chargés par le BIOS en considérant que cela est formateur revient à faire un cours d'histoire où l'on se concentrerait sur l'étude des dinosaures en vue de comprendre le fonctionnement de nos sociétés modernes. Pour anecdote, les processeurs 64 bits fonctionnant en long mode (mode que l'on pourrait appeler mode 64 bits) ne supportent plus la fonctionnalité permettant d'exécuter des binaires 16 bits sur un OS 64 bits. D'où la raison pour laquelle il n'est plus possible d'exécuter des .COM sous Windows 7 et 8 64 bits.
• noyer le lecteur sous des détails techniques de fonctionnement (interruptions, segments, pagination, etc...) sans aucun lien précis entre ces notions. Les processeur modernes ont pour vocation à subdiviser le jeu d'instruction en 2 parties (voir plus): une contenant les instructions privilégiées ne pouvant être exécutées que par le système d'exploitation et une contenant les instructions courantes destinées aux programmes utilisateurs. Cela constitue la base de la sécurité des systèmes modernes. Un tutoriel sur l'assembleur x86 doit donc annoncer dès le début de quel côté il se place, à savoir la réalisation d'une application utilisateur classique ou d'un noyau (donc usage du jeu d'instructions privilégiées). Ce n'est pas pour rien qu'Intel découpe sa documentation en deux entre Basic architecture et System programming. Dans le deuxième cas, c'est plus une compréhension générale d'un processeur qui est requise que le simple apprentissage de la syntaxe assembleur.
• ne pas indiquer pour quelle plateforme logicielle on programme: dans le cadre d'une application utilisateur sur l'architecture x86, il est nécessaire d'avoir recours à des bibliothèques (ou au moins au noyau) externes propres au système d'exploitation cible (Windows, GNU/Linux, ...).
• ne pas distinguer dépendance matérielle et dépendance logicielle. Les instruction x86 étant les mêmes sur Windows et Linux s'ils tournent sur le même processeur, il peut être intéressant de constituer une "bibliothèque standard" fournie au lecteur afin qu'il puisse apprendre quelque soit son système. Enseigner "l'assembleur x86 32 bits pour Windows" ne veut rien dire, la dépendance en Windows n'étant ici qu'au niveau de l'ABI et de l'API, donc rien à voir avec le jeu d'instructions.

-
Edité par Anonyme 14 juin 2014 à 22:50:21

tr1691 a écrit:

Un tutoriel sur l'assembleur x86 doit donc annoncer dès le début de quel côté il se place, à savoir la réalisation d'une application utilisateur classique ou d'un noyau (donc usage du jeu d'instructions privilégiées).

Le seul endroit où j'ai vu l'utilisation du langage assembleur est dans le noyau. Ma définition d'un noyau : c'est un programme qui sait démarrer un ordinateur, il n'a donc pas le choix, il doit connaitre les instructions privilégiées qu'aucun autre langage que l'assembleur n'a besoin de connaitre.

Mon tuto se place donc de ce coté et à la vitesse où j'avance il ne sera pas fini avant plusieurs années !

Je trouve méritoire le travail de cotoporto. Il n'était pas concerné par ma remarque du message du 7 juin. J'ai bien vu que son tuto avait de la valeur parce qu'il s'appuyait sur une réelle pratique et non sur une lourde théorie.

Ictus a écrit:

tr1691 a écrit:

Un tutoriel sur l'assembleur x86 doit donc annoncer dès le début de quel côté il se place, à savoir la réalisation d'une application utilisateur classique ou d'un noyau (donc usage du jeu d'instructions privilégiées).

Le seul endroit où j'ai vu l'utilisation du langage assembleur est dans le noyau. Ma définition d'un noyau : c'est un programme qui sait démarrer un ordinateur, il n'a donc pas le choix, il doit connaitre les instructions privilégiées qu'aucun autre langage que l'assembleur n'a besoin de connaitre.

Mon tuto se place donc de ce coté et à la vitesse où j'avance il ne sera pas fini avant plusieurs années !

Je trouve méritoire le travail de cotoporto. Il n'était pas concerné par ma remarque du message du 7 juin. J'ai bien vu que son tuto avait de la valeur parce qu'il s'appuyait sur une réelle pratique et non sur une lourde théorie.

L'assembleur est très loin de se cantonner à ce vague domaine que serait le "noyau".

Il est très utile là où le besoin de performance est de mise et que les optimisations algorithmiques ne sont plus possibles, on a alors recours à des astuces propres à la plateforme cible (ex: le calcul de racines carrées dans Quake 3).

Il est également très utile lorsque le processeur sous-jacent contient un jeu d'instructions limité ou que l'emploi d'un langage plus évolué pourrait être néfaste en terme de performance et de contrôle fin de la machine, ce qui est le cas dans l'embarqué.

Néanmoins les deux exemples précédents constituent des cas très particuliers, tendant même à devenir obsolètes. Il est cependant un dernier point où la compréhension profonde de l'assembleur est primordiale et que l'on oublie facilement: celui de la sécurité informatique.

Dans ce cas précis, le code assembleur considéré n'est pas écrit mais obtenu par désassemblage des fichiers binaires qui nous intéressent, en vue de comprendre leurs comportements ou comment leurs failles sont exploitées par des virus.

-
Edité par Anonyme 18 juin 2014 à 21:05:26

Salut par ici !
@tr1691
Tout d'abord, je ne sais pas si c'est moi mais il me semble complètement étrange de spéculer sur une chose qu'on n'a même pas vu. Donc la première phrase de ton message sur cette page, je cite  : "Pour ma part je suis un peu sceptique quant à l'intérêt de ce tutoriel car il semble prendre la même tournure que la plupart des tutoriels francophones sur le sujet" me semble, sans vouloir te vexer,  complètement dénuée de sens. Mais bien sûr tu me diras si je me trompe.

Ensuite au cas je me serais fait mal comprendre dans l'explication du but de ce tuto, j'aimerais répondre à la longue liste de reproches que tu fais sur mon tuto que tu n'a pas encore vu

Q1
- "mélanger assembleur et langages de programmation: peut-on réellement parler de langage de programmation alors qu'il ne s'agit que de la transcription en mots anglais des codes numériques de chacune des instructions reconnues par le processeur ? En effet la syntaxe du C, du Basic, du Python, ne varie pas selon que vous soyez sur un processeur Intel, un ARM ou un micro-contrôleur. Il y a une notion d'abstraction de la machine sous-jacente qui est par essence même absente dans le cas de l'assembleur (bien que parfois similaires, les jeux d'instructions varient d'un processeur à l'autre)."

R1
- Je vais partir du principe qu'un programme informatique n'est que le résultat  de la traduction (compilation ou assemblage) d'une suite d'instructions écrit dans un langage de programmation en binaire. De ce point  de vu, l'ASM, le c, le Basic ou même le python sont tous des langages de programmation vu qu'ils produisent après traduction,  des programmes informatiques  qui peuvent être exécutés.

 Ensuite d'un point de vue purement mathématique, un langage de programmation est un langage formel construit sur un alphabet (un ensemble de symboles finis, définis par le créateur du langage). En associant ces symboles, on définit la syntaxe du langage de programmation permettant ainsi de définir le comportement de la machine, on dira alors qu'on a programmé.

 D'après ces deux définition donc, il est clair que l'ASM est un langage de programmation au même titre que les autres et le seul facteur de variation auquel il est soumis d'un microprocesseur à un autre ne suffit pas à le "rejeter" du lot des langages de programmation ; donc bien qu'il soit de bas niveau, c'est un langage de programmation.

Q2
-"mélanger les familles de processeurs: la terminologie x86 désigne la famille de processeurs compatibles avec le jeu d'instructions de l'Intel 80386, processeur 32 bits."

R2
-Il n'a jamais été annoncé que je mélangerais quoi que ce soit. Le titre de mon tuto suggère juste que les programmes qui seraient produits durant la phase d'apprentissage prendraient en compte les processeurs compatibles avec le jeu d'instruction du 80386 comme tu le dis toi-même. Je ne mélange donc rien du tout mais au contraire , j'oriente le chemin sur lequel je m'engage.

Q3
-"mélanger modes de fonctionnement du processeur: les processeurs d'Intel ont une qualité formidable: la rétro-compatibilité. C'est à dire que les derniers processeurs 64 bits sont capables de fonctionner de la même façon que le faisaient les processeurs il y a 30 ans. Cela engendre chez les néophyte un mélange sans vergogne entre code 16 bits, 32 bits et 64 bits, chacun associé à un mode d'exécution spécifique de ces processeurs."

R3
-Je crois que tu essais de m'informer d'une chose que je sais déjà. Mais au cas tu essayerais de m'informer sur le risque que le lecteur de mon tuto s'enlise dans les différents modes de fonctionnement du microprocesseur, je crois que j'ai prévu cela.

Q4
-"enseigner avec ce foutu mode réel 16 bits: le mode réel est un immondice sans nom, obsolète et datant d'une époque où l'ordinateur personnel n'était qu'un amas de rustines en vue d'obtenir quelque chose d'exploitable. Enseigner le codage des bootloaders destinés à être chargés par le BIOS en considérant que cela est formateur revient à faire un cours d'histoire où l'on se concentrerait sur l'étude des dinosaures en vue de comprendre le fonctionnement de nos sociétés modernes. Pour anecdote, les processeurs 64 bits fonctionnant en long mode (mode que l'on pourrait appeler mode 64 bits) ne supportent plus la fonctionnalité permettant d'exécuter des binaires 16 bits sur un OS 64 bits. D'où la raison pour laquelle il n'est plus possible d'exécuter des .COM sous Windows 7 et 8 64 bits."

R4
- "C'est au bout de l'ancienne corde qu'on tisse la nouvelle" Sous l'orage -- seydou Badian. Juste pour signifier qu'on ne peut réellement commencer une nouvelle chose en faisant complètement abstraction du passé. Et comme je l'ai de nombreuses fois écrit sur ce billet de discussion, commencer avec le mode réel est didactique à cause de la simplicité des programmes, de l'absence de format des binaires produits... Bref j'explique tout cela dans mon tuto sans rien mélanger ou du moins j'y fais attention au maximum.  Et puis si ,comme tu le dira plus tard, au lieu de produire un programme applicatif, on comptait produire un OS, tu crois que passer à côté de ce mode fonctionnement permettrait à chacun d'obtenir l’expérience nécessaire? Enfin laisse moi te dire que les autres modes de fonctionnement sont abordés mais seulement quand le lecteur sent et comprend le besoin de l’évolution vers ces modes.

Q5
- "noyer le lecteur sous des détails techniques de fonctionnement (interruptions, segments, pagination, etc...) sans aucun lien précis entre ces notions. Les processeur modernes ont pour vocation à subdiviser le jeu d'instruction en 2 parties (voir plus): une contenant les instructions privilégiées ne pouvant être exécutées que par le système d'exploitation et une contenant les instructions courantes destinées aux programmes utilisateurs. Cela constitue la base de la sécurité des systèmes modernes. Un tutoriel sur l'assembleur x86 doit donc annoncer dès le début de quel côté il se place, à savoir la réalisation d'une application utilisateur classique ou d'un noyau (donc usage du jeu d'instructions privilégiées). Ce n'est pas pour rien qu'Intel découpe sa documentation en deux entre Basic architecture et System programming. Dans le deuxième cas, c'est plus une compréhension générale d'un processeur qui est requise que le simple apprentissage de la syntaxe assembleur."

R5
- Je crois simplement, qu'ici la seule  lecture de mon tuto devrait balayer du revers les doutes que tu as. Mais je tiens à préciser que entre chaque chose que j'explique, je me suis arrangé pour insérer des liens qui rendent la compréhension plus facile et que je ne me suis pas contenté de produire un manuel technique.

Q6
- "ne pas indiquer pour quelle plateforme logicielle on programme: dans le cadre d'une application utilisateur sur l'architecture x86, il est nécessaire d'avoir recours à des bibliothèques (ou au moins au noyau) externes propres au système d'exploitation cible (Windows, GNU/Linux, ...)."
R6
- Je crois que tu devrais encore un peu plus creuser cette question avant de la posée. En effet si beaucoup de livres qui traitent du sujet de l'ASM décident bien souvent de scinder en plusieurs parties leurs cours par  rapport à la plateforme choisie ou carrément créer différents bouquins par rapport à cela, c'est bien pour une raison. Mais personnellement je vais t'exposer quelques une de mes raisons :

*Tout d'abord la façon dont fonctionne Windows et les systèmes Unix (Linux inclus) est radicalement différent. Par exemple, sur les architecture  32 bits, Linux est complètement 32 bits et (si je ne m'abuse) n'autorise pas les instructions en mode réel  (à moins peut être de s'armer d'un émulateur) alors que Windows est  plus permissif. Devoir donc écrit un code ASM "portable" pour les deux OS juste parce qu'ils fonctionnent sur le même type de microprocesseur pourrait aboutir à des complications qui risquent d'empêcher même la compréhension du livre.

*écrire une bibliothèque pour "normaliser" l'utilisation de l'asm sur les deux plate-formes est à mon avis sans intérêt bien que ce soit possible car cela dépendrait de leur api (donc compliquerait beaucoup le code) . Par exemple sous Linux, la libc fait partie intégrante du système et presque chaque interruption y fait appel alors que l'autre coté c'est l'api Windows qui est utilisable nativement ( à moins qu'on link une libc  ou autre lib externe au code ASM). En plus ce ne serait plus vraiment de l'assembleur pur.

Bref parmi tant d'autres, ce sont des raisons qui dès le départ, m'ont poussé à préciser pour quelle plate-forme ce tuto est destiné ; bien que plusieurs détails se répercutent sur les autres plate-formes aussi.

Q7
- "ne pas distinguer dépendance matérielle et dépendance logicielle. Les instruction x86 étant les mêmes sur Windows et Linux s'ils tournent sur le même processeur, il peut être intéressant de constituer une "bibliothèque standard" fournie au lecteur afin qu'il puisse apprendre quelque soit son système. Enseigner "l'assembleur x86 32 bits pour Windows" ne veut rien dire, la dépendance en Windows n'étant ici qu'au niveau de l'ABI et de l'API, donc rien à voir avec le jeu d'instructions."

R7
- Je crois que ma réponse précédente y donne partiellement solution.  Mais je désire néanmoins ajouter que la dépendance est théoriquement seulement au niveau  de l'api mais ce n'est pas réellement ou toujours le cas, car ce n'est pas parce que les instructions du micro sont compatibles que le même programme va fonctionner sur les deux plate-formes ; il y aussi la façon dont les appels à ces instructions sont faites et cela , c'est le système qui le gère (par exemple au niveau de Linux ce sont des appels systèmes  alors qu'au niveau de Windows lorsqu'il permet le mode 16 bits, il passe la main au BIOS ou au "sous-système" DOS (int 0x21 par example) ou si c'est le mode 32 bits, il permet l'appel de son api via des interfaces de fonctions.)

J'espère avoir répondu clairement à tes inquiétudes sur l'utilité de ce tuto et la tournure qu'il compte prendre.

NB:
 l'ASM est extrêmement utile dans des domaines comme, tu le dit ,de la création des OS , la programmation des micro-contrôleur,  l'optimisation du code et  la sécurité informatique (ceci est un peu vague et je me permets donc de le détailler) c'est à dire  dans le cracking ( bien qu'illicite ) , l'espionnage industriel car grâce au binaires d'un programme on peut remonter aux sources et reproduire les fonctionnalités d'un programme (reverse engineering), en virologie, la programmation des DSP...J'en passe. J''en ai donné un bref aperçu dans mon tuto et il faut aussi préciser que pour lire un code désassemblé il faudrait au préalable comprendre l'ASM encore qu'un code désassemblé ne contient ni commentaires, ni nom de "variables" (pseudo-variables pour être plus précis) ou de fonctions mais juste du code ASM et des chiffres hexadécimaux d'où une importante compréhension de l'ASM est nécessaire. Et là ce sont des domaines où on ne peut nier la suprématie de l'ASM.

cotoporto a écrit:

Salut par ici !
@tr1691
Tout d'abord, je ne sais pas si c'est moi mais il me semble complètement étrange de spéculer sur une chose qu'on n'a même pas vu. Donc la première phrase de ton message sur cette page, je cite  : "Pour ma part je suis un peu sceptique quant à l'intérêt de ce tutoriel car il semble prendre la même tournure que la plupart des tutoriels francophones sur le sujet" me semble, sans vouloir te vexer,  complètement dénuée de sens. Mais bien sûr tu me diras si je me trompe.

Ensuite au cas je me serais fait mal comprendre dans l'explication du but de ce tuto, j'aimerais répondre à la longue liste de reproches que tu fais sur mon tuto que tu n'a pas encore vu

Q1
- "mélanger assembleur et langages de programmation: peut-on réellement parler de langage de programmation alors qu'il ne s'agit que de la transcription en mots anglais des codes numériques de chacune des instructions reconnues par le processeur ? En effet la syntaxe du C, du Basic, du Python, ne varie pas selon que vous soyez sur un processeur Intel, un ARM ou un micro-contrôleur. Il y a une notion d'abstraction de la machine sous-jacente qui est par essence même absente dans le cas de l'assembleur (bien que parfois similaires, les jeux d'instructions varient d'un processeur à l'autre)."

R1
- Je vais partir du principe qu'un programme informatique n'est que le résultat  de la traduction (compilation ou assemblage) d'une suite d'instructions écrit dans un langage de programmation en binaire. De ce point  de vu, l'ASM, le c, le Basic ou même le python sont tous des langages de programmation vu qu'ils produisent après traduction,  des programmes informatiques  qui peuvent être exécutés.

 Ensuite d'un point de vue purement mathématique, un langage de programmation est un langage formel construit sur un alphabet (un ensemble de symboles finis, définis par le créateur du langage). En associant ces symboles, on définit la syntaxe du langage de programmation permettant ainsi de définir le comportement de la machine, on dira alors qu'on a programmé.

 D'après ces deux définition donc, il est clair que l'ASM est un langage de programmation au même titre que les autres et le seul facteur de variation auquel il est soumis d'un microprocesseur à un autre ne suffit pas à le "rejeter" du lot des langages de programmation ; donc bien qu'il soit de bas niveau, c'est un langage de programmation.

Q2
-"mélanger les familles de processeurs: la terminologie x86 désigne la famille de processeurs compatibles avec le jeu d'instructions de l'Intel 80386, processeur 32 bits."

R2
-Il n'a jamais été annoncé que je mélangerais quoi que ce soit. Le titre de mon tuto suggère juste que les programmes qui seraient produits durant la phase d'apprentissage prendraient en compte les processeurs compatibles avec le jeu d'instruction du 80386 comme tu le dis toi-même. Je ne mélange donc rien du tout mais au contraire , j'oriente le chemin sur lequel je m'engage.

Q3
-"mélanger modes de fonctionnement du processeur: les processeurs d'Intel ont une qualité formidable: la rétro-compatibilité. C'est à dire que les derniers processeurs 64 bits sont capables de fonctionner de la même façon que le faisaient les processeurs il y a 30 ans. Cela engendre chez les néophyte un mélange sans vergogne entre code 16 bits, 32 bits et 64 bits, chacun associé à un mode d'exécution spécifique de ces processeurs."

R3
-Je crois que tu essais de m'informer d'une chose que je sais déjà. Mais au cas tu essayerais de m'informer sur le risque que le lecteur de mon tuto s'enlise dans les différents modes de fonctionnement du microprocesseur, je crois que j'ai prévu cela.

Q4
-"enseigner avec ce foutu mode réel 16 bits: le mode réel est un immondice sans nom, obsolète et datant d'une époque où l'ordinateur personnel n'était qu'un amas de rustines en vue d'obtenir quelque chose d'exploitable. Enseigner le codage des bootloaders destinés à être chargés par le BIOS en considérant que cela est formateur revient à faire un cours d'histoire où l'on se concentrerait sur l'étude des dinosaures en vue de comprendre le fonctionnement de nos sociétés modernes. Pour anecdote, les processeurs 64 bits fonctionnant en long mode (mode que l'on pourrait appeler mode 64 bits) ne supportent plus la fonctionnalité permettant d'exécuter des binaires 16 bits sur un OS 64 bits. D'où la raison pour laquelle il n'est plus possible d'exécuter des .COM sous Windows 7 et 8 64 bits."

R4
- "C'est au bout de l'ancienne corde qu'on tisse la nouvelle" Sous l'orage -- seydou Badian. Juste pour signifier qu'on ne peut réellement commencer une nouvelle chose en faisant complètement abstraction du passé. Et comme je l'ai de nombreuses fois écrit sur ce billet de discussion, commencer avec le mode réel est didactique à cause de la simplicité des programmes, de l'absence de format des binaires produits... Bref j'explique tout cela dans mon tuto sans rien mélanger ou du moins j'y fais attention au maximum.  Et puis si ,comme tu le dira plus tard, au lieu de produire un programme applicatif, on comptait produire un OS, tu crois que passer à côté de ce mode fonctionnement permettrait à chacun d'obtenir l’expérience nécessaire? Enfin laisse moi te dire que les autres modes de fonctionnement sont abordés mais seulement quand le lecteur sent et comprend le besoin de l’évolution vers ces modes.

Q5
- "noyer le lecteur sous des détails techniques de fonctionnement (interruptions, segments, pagination, etc...) sans aucun lien précis entre ces notions. Les processeur modernes ont pour vocation à subdiviser le jeu d'instruction en 2 parties (voir plus): une contenant les instructions privilégiées ne pouvant être exécutées que par le système d'exploitation et une contenant les instructions courantes destinées aux programmes utilisateurs. Cela constitue la base de la sécurité des systèmes modernes. Un tutoriel sur l'assembleur x86 doit donc annoncer dès le début de quel côté il se place, à savoir la réalisation d'une application utilisateur classique ou d'un noyau (donc usage du jeu d'instructions privilégiées). Ce n'est pas pour rien qu'Intel découpe sa documentation en deux entre Basic architecture et System programming. Dans le deuxième cas, c'est plus une compréhension générale d'un processeur qui est requise que le simple apprentissage de la syntaxe assembleur."

R5
- Je crois simplement, qu'ici la seule  lecture de mon tuto devrait balayer du revers les doutes que tu as. Mais je tiens à préciser que entre chaque chose que j'explique, je me suis arrangé pour insérer des liens qui rendent la compréhension plus facile et que je ne me suis pas contenté de produire un manuel technique.

Q6
- "ne pas indiquer pour quelle plateforme logicielle on programme: dans le cadre d'une application utilisateur sur l'architecture x86, il est nécessaire d'avoir recours à des bibliothèques (ou au moins au noyau) externes propres au système d'exploitation cible (Windows, GNU/Linux, ...)."
R6
- Je crois que tu devrais encore un peu plus creuser cette question avant de la posée. En effet si beaucoup de livres qui traitent du sujet de l'ASM décident bien souvent de scinder en plusieurs parties leurs cours par  rapport à la plateforme choisie ou carrément créer différents bouquins par rapport à cela, c'est bien pour une raison. Mais personnellement je vais t'exposer quelques une de mes raisons :

*Tout d'abord la façon dont fonctionne Windows et les systèmes Unix (Linux inclus) est radicalement différent. Par exemple, sur les architecture  32 bits, Linux est complètement 32 bits et (si je ne m'abuse) n'autorise pas les instructions en mode réel  (à moins peut être de s'armer d'un émulateur) alors que Windows est  plus permissif. Devoir donc écrit un code ASM "portable" pour les deux OS juste parce qu'ils fonctionnent sur le même type de microprocesseur pourrait aboutir à des complications qui risquent d'empêcher même la compréhension du livre.

*écrire une bibliothèque pour "normaliser" l'utilisation de l'asm sur les deux plate-formes est à mon avis sans intérêt bien que ce soit possible car cela dépendrait de leur api (donc compliquerait beaucoup le code) . Par exemple sous Linux, la libc fait partie intégrante du système et presque chaque interruption y fait appel alors que l'autre coté c'est l'api Windows qui est utilisable nativement ( à moins qu'on link une libc  ou autre lib externe au code ASM). En plus ce ne serait plus vraiment de l'assembleur pur.

Bref parmi tant d'autres, ce sont des raisons qui dès le départ, m'ont poussé à préciser pour quelle plate-forme ce tuto est destiné ; bien que plusieurs détails se répercutent sur les autres plate-formes aussi.

Q7
- "ne pas distinguer dépendance matérielle et dépendance logicielle. Les instruction x86 étant les mêmes sur Windows et Linux s'ils tournent sur le même processeur, il peut être intéressant de constituer une "bibliothèque standard" fournie au lecteur afin qu'il puisse apprendre quelque soit son système. Enseigner "l'assembleur x86 32 bits pour Windows" ne veut rien dire, la dépendance en Windows n'étant ici qu'au niveau de l'ABI et de l'API, donc rien à voir avec le jeu d'instructions."

R7
- Je crois que ma réponse précédente y donne partiellement solution.  Mais je désire néanmoins ajouter que la dépendance est théoriquement seulement au niveau  de l'api mais ce n'est pas réellement ou toujours le cas, car ce n'est pas parce que les instructions du micro sont compatibles que le même programme va fonctionner sur les deux plate-formes ; il y aussi la façon dont les appels à ces instructions sont faites et cela , c'est le système qui le gère (par exemple au niveau de Linux ce sont des appels systèmes  alors qu'au niveau de Windows lorsqu'il permet le mode 16 bits, il passe la main au BIOS ou au "sous-système" DOS (int 0x21 par example) ou si c'est le mode 32 bits, il permet l'appel de son api via des interfaces de fonctions.)

J'espère avoir répondu clairement à tes inquiétudes sur l'utilité de ce tuto et la tournure qu'il compte prendre.

NB:
 l'ASM est extrêmement utile dans des domaines comme, tu le dit ,de la création des OS , la programmation des micro-contrôleur,  l'optimisation du code et  la sécurité informatique (ceci est un peu vague et je me permets donc de le détailler) c'est à dire  dans le cracking ( bien qu'illicite ) , l'espionnage industriel car grâce au binaires d'un programme on peut remonter aux sources et reproduire les fonctionnalités d'un programme (reverse engineering), en virologie, la programmation des DSP...J'en passe. J''en ai donné un bref aperçu dans mon tuto et il faut aussi préciser que pour lire un code désassemblé il faudrait au préalable comprendre l'ASM encore qu'un code désassemblé ne contient ni commentaires, ni nom de "variables" (pseudo-variables pour être plus précis) ou de fonctions mais juste du code ASM et des chiffres hexadécimaux d'où une importante compréhension de l'ASM est nécessaire. Et là ce sont des domaines où on ne peut nier la suprématie de l'ASM.

Je base mon analyse à partir de ceci: http://fr.openclassrooms.com/informatique/cours/1837751?status=draft

Si cela ne constitue pas le premier jet du tutoriel dont on discute alors je prie la totalité des intervenants de bien vouloir m'excuser, dans le cas contraire je poursuivrai  mon analyse:

Point 1: tu as omis une étape essentielle dans ton analyse des langages de programmation: le processeur ne reconnaît qu'un nombre fini d'instructions, encodées sous forme de nombres. Que l'on donne un moyen mnémotechnique pour les retenir en leur associant un mot en langue anglaise ne constitue pas en soit un changement majeur (quand bien même appellerai-je un chat un chien il continuerait de miauler). Au contraire, quand tu écris dans un autre langage de programmation tu n'es jamais assuré de la traduction qui sera faite en terme d'instructions machine. D'où la différence fondamentale entre l'assembleur et le C, l'assembleur désigne juste une façon de nommer explicitement des instruction d'une machine. Un code C est a priori compilable et exécutable sur n'importe quelle machine disposant d'un compilateur à qui est laissé le choix de la transcription.

Bref ce que j'essaie d'expliquer depuis mon premier message c'est que sans avoir recours au bulldozer de la théorie des langages, la notion de langage assembleur en tant que tel est un abus de langage (sans jeu de mot) car il ne dispose pas d'une définition unique (ne serait-ce que parce qu'il dépend au moins de la machine que l'on programme).

Point 2: la confusion 80386 et 8086. Dès le premier programme tu introduis du code 16 bits, prévu pour tourner en mode réel (au vu de l'usage qu'il est fait de l'instruction 0x21 de MS DOS, système d'exploitation pour le mode réel).

;-----------------------------------------------------------------
; Ce programme affiche Hello World à l'écran une fois exécuté
;
;-----------------------------------------------------------------
;***************************************
; ORG Permet à NASM de faire un 
; décalage de  256 chaque 
; fois qu'il rencontre une adresse
;(c'est spécifique aux fichiers .com)
; *************************************
    ORG   256
mov  DX, hello ; on passe l'adresse de hello au registre DX
mov  AH, 0x9   ; fonction 9h de l'interruption 21h utilisée pour l'affichage 
int  0x21     ; appel de l'interruption du DOS 
ret ; arrêt du programme et retour à la console

Point 3: rien à redire

Point 4: quitte à revoir les bases je propose de revenir au bon vieux temps des cartes perforées! Ta justification tombe à l'eau au vu de ce que tu avances au point 6:

"*Tout d'abord la façon dont fonctionne Windows et les systèmes Unix (Linux inclus) est radicalement différent. Par exemple, sur les architecture  32 bits, Linux est complètement 32 bits et (si je ne m'abuse) n'autorise pas les instructions en mode réel  (à moins peut être de s'armer d'un émulateur) alors que Windows est  plus permissif."

Ce n'est pas que Windows soit plus permissif, c'est juste qu'en mode protégé, les processeurs d'Intel fournissent un mode dit Virtual 8086 qui permet de façon sécurisée d'exécuter du code prévu pour fonctionner en mode 16 bits. Ce mode n'est plus disponible en mode long (64 bits). Les élucubrations des défenseurs de l'assembleur 16 bits n'y changeront rien.

Ce qu'il faut bien comprendre c'est la raison pour laquelle Microsoft a exploité ce mode avec Windows NT avant l'avènement des processeurs 64 bits: il permettait aux clients de Microsoft passant des systèmes DOS aux systèmes NT de conserver en l'état leurs logiciels afin de pouvoir amorcer en douceur la transition. Il n'a jamais été prévu pour autoriser les programmeurs à garder les mauvaises habitudes du mode réel. De toute façon l'histoire a donné tort à ce genre d'individu, le mode étant maintenant mort et enterré. Au contraire Linux a été dès le début conçu pour le mode protégé du 80386 et n'a donc pas besoin d'assurer une quelconque rétro-comptabilité.

Bref la question que je te pose est la suivante: à l'heure où les processeurs 64 bits sont sur le marché depuis près de 10 ans et que les systèmes d'exploitation 64 bits également, crois-tu que ton tutoriel quand il sortira pourra être intéressant car s'appuyant sur des technologies dépassées depuis au moins 10 ans ?

Alors certes l'inertie de certains justifiera que oui, les plus consciencieux réaliseront peut être que 10 ans dans l'informatique est ce qui nous sépare du moyen-âge. Je n'ai pas envie de débattre davantage sur les autres points. Celui-ci constitue déjà la raison pour laquelle ce tutoriel est mort né. Cela est d'autant plus dommage que la première partie constitue une bonne entrée en la matière.

Puisque cela semble être la mode je vais laisser une petite citation: "Tout devrait être rendu aussi simple que possible, mais pas plus." (Albert Einstein).

Ce site a trop longtemps souffert de ces tutoriels où au nom de la simplicité on supprime tout l'effort nécessaire pour acquérir un savoir utile et actualisé.

-
Edité par Anonyme 2 septembre 2014 à 12:48:55

Pour faire simple :

Je me demandais quelle taille faisait ton bootloader. Comment l'installer sur le secteur de boot du disque dur ?

Je voulais savoir si j'avais une chance d'arriver à le désassembler.

Qu'est devenu le projet ? Je vois un premier jet en ligne mais où est la suite ??? Je suis ce tutoriel depuis quelques jours et j'aimerais bien y accéder en intégralité. Quelqu'un pourrait-il me renseigner ?

Merci !

le projet est toujours en cours et actuellement je le rédige toujours la suite et aussi j'essai de peaufiner au mieux le début. Donc pass de panique je compte bientôt livrer la suite du tuto.

Je n'arrive pas à y accéder à ce jour...

Salut GeeksdelaCave !

En fait je suis dans une phase d’échange avec l'équipe éditoriale autrement dit je suis en phase de validation de mon tuto pour qu'il devienne un cours officiel et comme l'a su bien dire  Anouck   dans l'autre topic où tu es intervenu, la sortie de ce cours est imminent donc un peu de patience et tu en profitera pleinement !

-
Edité par cotoporto 18 novembre 2014 à 21:11:33

Super nouvelle, merci !

Salut, je viens de remettre le cours en ligne et le lien d'accès est : https://openclassrooms.com/courses/1837751?status=waiting-for-publication

Merci !

j'attends tes commentaires GeeksdelaCave afin d'améliorer encore plus ce boulot

Je vais le lire très lentement malheureusement, à cause de mes études... :/

Cependant je te tiendrai au courant !

super ! C'est déjà pas mal

Sic...

Finalement ça se goupille comme je l'avais annoncé en 2014 (voir mes messages plus haut) : une introduction lourde a la programmation 16 bits et a l'ABI et l'API MSDOS.

L'introduction sur le fonctionnement d'un ordinateur et d'un processeur est bonne ainsi que les diverses explications sur les opérations mathématiques courantes et les encodages de nombres. Cependant il aurait été plus judicieux et plus ambitieux de proposer une création d'un binaire Windows/Linux en encapsulant les appels systèmes propres a chaque plateforme via une petite bibliothèque (un .inc pour NASM par exemple).

Cela aurait permis de se concentrer sur la maitrise des diverses instructions courantes pour réaliser des structures de contrôle classiques (boucles, conditions,...) puis enchainer par des programmes un peu plus évolués (le plus ou moins ? ) plutôt que de se pencher sur DosBox et les interruptions DOS.

La suite aurait été un interfaçage avec le C et ou le désassemblage de programmes C.

Le passage MSDOS/16 bits me semble être un piège classique des tutoriels assembleurs sur internet : c'est une technologie obsolète et qui n’inculque pas de bonnes pratiques.

Bref. Le tutoriel n'est pas mauvais en soit (il est même plutôt bon), mais il ne se démarque pas de l'existant et c'est bien dommage car il suit une route extrêmement boueuse.

-
Edité par Anonyme 8 mars 2016 à 17:15:04

bonjour tr1691. Je sais que c'est dans l'optique d'apporter un plus a ce tuto que tu es aussi rigoureux sur le chemin qu'il semble prendre selon toi et je t'en remercie. Cependant, selon moi, bien que cela soit discutable, il est préférable de passer par là car :

-je compte faire comprendre le fonctionnement des bootloader plus tard,

-je ne compte pas compliquer le code dès le départ (imagine que je crée cette lib, il faudra néanmoins  faire passer des paramètres aux fonctions via la  pile d'où je devrais peut être expliquer trop tôt ce qu'est la pile ou encore ce qu'est une fonction...bref je pense qu'il faudra être rudement instructif pour éviter d'emballer le lecteur vers des complications inutiles.)

-de toutes façon je viens progressivement vers l'assembleur 32 bits (et 64 bits) bien sûr avec une bonne pédagogie qui empêchera le lecteur de s'embrouiller.

Mais si trouves néanmoins qu'il y a une brique que tu peux apporter à l'édifice, je t'invite vivement à me poster une ébauche d'un plan détaillé qui  contourne les problèmes que tu énonce. Merci

[édit] j'en profite pour annoncer qu'il y a de nouvelles parties disponibles (l'explication de la pile, les sauts et boucle, les fonctions.. bref que du neuf. Mais je voulais déjà vos avis sur ce qui est en ligne avant d'en ajouter plus)

-
Edité par cotoporto 10 mars 2016 à 8:31:04

[up] début semaine prochaine ajout de nouveaux chapitres.

Bonjour sadounno. Alors, pour commencer, je te rassure : ta question n'est pas bête. D'ailleurs d'autres y ont pensé avant toi : https://fr.wikipedia.org/wiki/JavaOS .

Par contre la solution à laquelle tu pense est quelque peu...euh... mal pensée. En effet, comme expliquée dans mon tuto, le bios est celui qui lance l'os, donc il ne sert à rien de le remplacer et tu ne peux pas y mettre une jvm non plus.  Tu peux en revanche faire de la jvm le composant principal de ton os afin que tout programme soit lancé par lui. mais tout cela se passe après le démarrage du bios et le lancement de ton noyau. J'espère avoir convenablement répondu à ta question

-
Edité par cotoporto 24 mars 2016 à 7:17:46

Merci pour cette réponse, qui va certainement m'aider dans le future car je sais que la réalisation d'un OS demande beaucoup de savoir et de temps de programmation, mais au moins tu me dis pas de lâcher(car a chaque fois qu'on demande des infos des informaticiens sont la pour nous décourager).

autre chose, on est entrain de faire dans ce cour du 16 bit et cela date du MsDos... Mais des que Windows 3.11 est apparue l'aire de la 32 bit a commence .

es que avec Nasm seule on peut realiser un Os avec des fenêtres et un affichage 32 bit, et biensur reconnaissance de tous les perifs, sans l'aides de bibliotheques ou autre langage haut level.

Bonsoir, je viens de finir tous les chapitres ecrits jusque la, et je serai ravi de voir les nouveaux, svp quand sont prevus les prochains chapitres, et surtout ....   DE LA PRATIQUE SVP ....

sadounno a écrit:

Merci pour cette réponse, qui va certainement m'aider dans le future car je sais que la réalisation d'un OS demande beaucoup de savoir et de temps de programmation, mais au moins tu me dis pas de lâcher(car a chaque fois qu'on demande des infos des informaticiens sont la pour nous décourager).

autre chose, on est entrain de faire dans ce cour du 16 bit et cela date du MsDos... Mais des que Windows 3.11 est apparue l'aire de la 32 bit a commence .

es que avec Nasm seule on peut realiser un Os avec des fenêtres et un affichage 32 bit, et biensur reconnaissance de tous les perifs, sans l'aides de bibliotheques ou autre langage haut level.

Théoriquement oui on peut réaliser entièrement un système d'exploitation en assembleur c'est le cas de MenuetOS : http://www.menuetos.net/

Cependant c'est introduire une difficulté technique pour peu de gain. Ce qui se fait dans les systèmes plus conséquents (Windows, Unix, Linux) c'est d'interfacer l'assembleur avec un langage de plus haut niveau comme le C ou le C++.

L'assembleur n'est alors utilisé que pour les phases techniques : démarrage, configuration des périphériques, du processeur ou localement pour quelques optimisations (copier des zones de la mémoire, etc...) en fonction de ce que permet le jeu d'instruction de la machine ciblée.

Tu peux trouver des exemples sur le site http://wiki.osdev.org/Main_Page

-
Edité par Anonyme 26 mars 2016 à 5:36:37