Création d'une librairie graphique
Neo
-
Neo -
Neo -
Bonjour,
Je crées en ce moment un OS en Assembleur et en C. Ce dernier est assez complexe, il gère le multitâche, les interruptions, pagine la mémoire, etc. Mais il est en mode texte, à la sauce DOS. Je souhaiterais créer une librairie graphique, telle GTK, afin de réaliser une interface graphique pour que d'autres programmeurs, moins expérimentés en programmation système, mais d'avantage en programmation logiciel, puissent réaliser, par exemple, un navigateur (même s'il faut également réaljser une librairie "web").
Je n'est jusqu'à présent rien trouvé de bien interessant. J'espère que vous pourrez m'aider. Je vous remercie d'avance pour vos reponses.
Je crées en ce moment un OS en Assembleur et en C. Ce dernier est assez complexe, il gère le multitâche, les interruptions, pagine la mémoire, etc. Mais il est en mode texte, à la sauce DOS. Je souhaiterais créer une librairie graphique, telle GTK, afin de réaliser une interface graphique pour que d'autres programmeurs, moins expérimentés en programmation système, mais d'avantage en programmation logiciel, puissent réaliser, par exemple, un navigateur (même s'il faut également réaljser une librairie "web").
Je n'est jusqu'à présent rien trouvé de bien interessant. J'espère que vous pourrez m'aider. Je vous remercie d'avance pour vos reponses.
A voir également:
- Création d'une librairie graphique
- Changer carte graphique - Guide
- Creation compte gmail - Guide
- Création site web - Guide
- Création graphique en ligne gratuit - Guide
- Création compte google - Guide
12 réponses
Ceci pourrait t'aider : https://wiki.osdev.org/Drawing_In_Protected_Mode. Pour les contrôles, il suffit de stocker leurs infos (position, état, attributs, contenu) dans des structures (utilise des listes chainées).
PS : si tu comptes faire concurrence à Windows/Linux, va déjà falloir proposer un OS stable et complet. (Surtout au niveau drivers, c'est ça le plus dur.) Puis faudra pas mal de temps, sauf si t'as 5-6 personnes qui travaillent aussi sur le projet. Je ne dis pas ça pour te décourager, mais ne te fixe pas des objectifs bien au-dessus de ce que tu aurais le temps et le courage de faire ...
PS : si tu comptes faire concurrence à Windows/Linux, va déjà falloir proposer un OS stable et complet. (Surtout au niveau drivers, c'est ça le plus dur.) Puis faudra pas mal de temps, sauf si t'as 5-6 personnes qui travaillent aussi sur le projet. Je ne dis pas ça pour te décourager, mais ne te fixe pas des objectifs bien au-dessus de ce que tu aurais le temps et le courage de faire ...
Tes structures décrivant tes fenêtres peuvent aussi être gérées via listes chainées (une par processus). En fait, tu dois les employer à chaque fois que tu serais tenté d'utiliser un tableau de taille variable (pas possible tel-quel en C, heureusement car sinon ça serait malloc+copie+free).
Tu t'es basé sur un truc déjà existant ou t'as passé des jours à tout coder toi-même (juste pour savoir) ?
Tu t'es basé sur un truc déjà existant ou t'as passé des jours à tout coder toi-même (juste pour savoir) ?
Sinon petite question : l'adressage en mode texte se fait en placant un caractère (sur un octet) suivie de son attribut (sur un octet), et ce à partir de 0xB8000. Mais la méthode pour dessiner en 0xA0000 me semble confuse, pourrais-tu m'éclairer !?
D'après ce que j'ai compris, tu dois d'abord définir le mode vidéo en passant par le mode réel et puis seulement jouer avec la mémoire vidéo. Voilà un tuto qui m'a l'air assez complet : http://www.monstersoft.com/tutorial1/. Il n'y a malheureusement pas des tonnes de tutos là-dessus et c'est pas évident aux premiers abords ...
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Attention aux valeurs employées : L'adresse segment vidéo commence à 0xB000, et offset 0 pour la 1ère page écran jusqu'à 0x7FFF, et offset 0x7FFF-0xFFFF pour la 2ème page écran...
Pour utiliser la 2ème page, il suffit d'écrire dedans puis de l'afficher tout simplement, et son intérêt est avant tout d'éviter les scintillements dûs à de nombreux changements...
Je cherche dans ma doc pour savoir comment on sélectionne, mes souvenirs sont un peu lointains !
Et si je me souviens bien, c'est plus qu'une sélection de la page qu'il est possible de faire, mais carrément la sélection de l'offset auquel la carte vidéo va commencer la lecture en mémoire, ce qui permet de faire du défilement...
Source -> La bible PC programmation système ed; 1994 - ça nous rajeunis pas -, encombrante version papier mais très complète, je te la conseille vivement...
Je cherche dans ma doc pour savoir comment on sélectionne, mes souvenirs sont un peu lointains !
Et si je me souviens bien, c'est plus qu'une sélection de la page qu'il est possible de faire, mais carrément la sélection de l'offset auquel la carte vidéo va commencer la lecture en mémoire, ce qui permet de faire du défilement...
Source -> La bible PC programmation système ed; 1994 - ça nous rajeunis pas -, encombrante version papier mais très complète, je te la conseille vivement...
Salut.
En fait, tu as un noyau quoi. Comme Linux. Le noyau Linux ne comporte pas d'interface graphique, C'est le serveur X qui s'occupe de ça. Je te conseil donc d'aller voir comment est fait le serveur X, tu y piocheras peut être des idées.
En tout cas, bonne chance.
En fait, tu as un noyau quoi. Comme Linux. Le noyau Linux ne comporte pas d'interface graphique, C'est le serveur X qui s'occupe de ça. Je te conseil donc d'aller voir comment est fait le serveur X, tu y piocheras peut être des idées.
En tout cas, bonne chance.
C'est un noyau très simple, qui, comme Linux, ne propose pas d'interface graphique native. Etant sous cet OS, je connais le serveur X, mais je n'ai pas trop l'intention de me lancer dans la création d'un véritable OS : il n'arrivera jamais à la cheville de Linux ! C'est plutôt une occasion de découvrir comment fonctionne un PC et un OS, partager ce savoir (aussi maigre soit-il), et éventuellement apporter ma modeste contribution au libre.
Oui ça peut toujours être une bonne inspiration, d'autant plus qu'il sera nécessaire d'externaliser les fonctions d'affichage pour que les programmes puissent les utiliser, ce qui est la moindre des choses qu'un OS, même micro, doit proposer aux applications...
(Je continue hors d'un commentaire, faites de même sinon on peut pas faire +1 et ça devient pénible à lire)
La mémoire flat c'est deux segments qui ont les mêmes début et longueur (0->4GB 32 bit) l'un code et l'autre données ainsi qu'un autre segment pour la pile (perso j'ai base/limit=0 mais je sais pas comment il gère les limites pour une pile + 32 bit + expand-down data). Mon code là : https://pastebin.com/MBS66MpJ. La première entrée (inutilisée par le proco) est utilisée pour stocker GDTR avant de le charger via LGDT.
La mémoire flat c'est deux segments qui ont les mêmes début et longueur (0->4GB 32 bit) l'un code et l'autre données ainsi qu'un autre segment pour la pile (perso j'ai base/limit=0 mais je sais pas comment il gère les limites pour une pile + 32 bit + expand-down data). Mon code là : https://pastebin.com/MBS66MpJ. La première entrée (inutilisée par le proco) est utilisée pour stocker GDTR avant de le charger via LGDT.
Ha oui ça y est j'y suis pour GDT, je ne m'en souvenais plus, c'est loin tout ça et j'en ai jamais eu l'usage, étant depuis longtemps sur des applications non-système.
Et je pense qu'il n'y a pas à s'embêter avec la limite de pile, en la fixant une fois pour toute à une valeur suffisante...
Dans ton code, une valeur par défault remplace sans doute la valeur nulle...
Et je pense qu'il n'y a pas à s'embêter avec la limite de pile, en la fixant une fois pour toute à une valeur suffisante...
Dans ton code, une valeur par défault remplace sans doute la valeur nulle...
A mon avis la limite est ignorée et la base est le minimum (avant GPF - General Protection Fault) vu que c'est expand-down (logique pour une pile sous x86). Le pointeur est en effet défini après avoir modifié CR0 via mov esp, 0xNNNNNN (assez haut pour éviter de taper dans des données ou du code). [Il ne faut pas non plus oublier de définir SS mais c'est le même tarif pour les autres]
Ok, et maintenant revenons à nos moutons : Pour la prog système de la carte graphique sans bios, il faut s'adresser directement à elle via les ports, en entrant les bonnes valeurs au niveau des différents controleurs de la carte. Et là tout se complique, je vais chercher un site qui regroupe ces infos en français, j'ai trouvé qu'en anglais pour le moment, et ça correspond à plusieurs dizaines de pages... Je vois ça demain.
Oui, il n'y aura pas le choix...
Et je pense que la meilleure solution c'est de créer des routines graphiques qui travaille sur un buffer interne représentant l'écran puis de copier tout ou partie du buffer dans la mémoire vidéo ensuite.
C'est sûrement la solution la plus efficace et la garantie que les fonctions resserviront quel que soit le mode vidéo employé. En sachant qu'en mode X les pixels sont entrelaçés par groupe de 4 et que ça peut être encore différent dans d'autres modes, alors développer les routines pour le mode X sans être sûr que c'est définitif n'est pas très rationnel, autrement dit lourd, lent et non portable...
Et je crois avoir trouvé de quoi se passer du mode X et de ses contraintes via la norme VESA 2.0,
autorisant le fonctionnement en mode protégé et l'accès linéaire à la mémoire vidéo, et peut-être un mode 1024*768 24bits ! Je te laisse consulter ça, il y a même des exemples en C, que je maitrise mal :
https://www.drdobbs.com/architecture-and-design/examining-the-vesa-vbe-20-specification/184409592
et plus largement sur la norme vesa:
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#References
Et je pense que la meilleure solution c'est de créer des routines graphiques qui travaille sur un buffer interne représentant l'écran puis de copier tout ou partie du buffer dans la mémoire vidéo ensuite.
C'est sûrement la solution la plus efficace et la garantie que les fonctions resserviront quel que soit le mode vidéo employé. En sachant qu'en mode X les pixels sont entrelaçés par groupe de 4 et que ça peut être encore différent dans d'autres modes, alors développer les routines pour le mode X sans être sûr que c'est définitif n'est pas très rationnel, autrement dit lourd, lent et non portable...
Et je crois avoir trouvé de quoi se passer du mode X et de ses contraintes via la norme VESA 2.0,
autorisant le fonctionnement en mode protégé et l'accès linéaire à la mémoire vidéo, et peut-être un mode 1024*768 24bits ! Je te laisse consulter ça, il y a même des exemples en C, que je maitrise mal :
https://www.drdobbs.com/architecture-and-design/examining-the-vesa-vbe-20-specification/184409592
et plus largement sur la norme vesa:
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#References
Petite question annexe : à l'adresse http://a.michelizza.free.fr/pmwiki.php?n=TutoOS.Task, on peut lire Nous avons vu plus haut que le descripteur de segment de pile est à l'offset 0x30 dans la GDT et qu'il définit un espace mémoire de 4k débutant à l'adresse 0x20000 ! D'autre part, la pile est définie dans le code source comme adressant l'ensemble de la mémoire ! Qqu'un a t-il une explication ?
Sinon, je ne souhaites pas concurencer Linux. Je suis conscient du nombre de personne qui réalisent un tel système. Mon OS n'est pas aussi pointu, c'est un petit kernel monolithique couplé à une interface, pour le moment rudimentaire. Je le vois plutôt comme une occasion de comprendre comment foctionne un PC, et peut-être, à terme, apporter ma contribution à Linux.