Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Gestion des évenements
Bonjour, je voulais savoir s'il était possible de faire de la programmation évenementielle en assembleur.
J'ai en effet l'occasion de programmer avec des langages plus haut niveau, mais je souhaite savoir comment la gestion des évenements fonctionne, et ainsi implémenter un programme en asm qui permettrait d'interagir avec l'utilisateur selon ce qu'il fait.
L'assembleur est le langage de ton micro-processeur. Son jeu d'instruction lui est donc propre, même si le principe est à peu près le même sur toutes les machines. Tu ne trouveras donc que des instructions servant à manipuler des données. Formellement : les lire, effectuer des opérations logiques ou arithmétiques élémentaires dessus et les réécrire autre part, plus une poignée d'instructions de contrôle des différents bus et des interruptions.
Il est cependant tout-à-fait possible d'implémenter ce qui ce fait à plus haut niveau. La programmation événementielle, en elle-même, est relativement simple : la clé réside dans la boucle principale. En gros, tu attends un «événement » qui te parvient sous la forme d'un message (qui lui même est en général soit un entier contenant le numéro de l'événement, soit une structure de données), en fonction de ce que tu lis, tu appelles le sous-programme correspondant, et quand celui a terminé, tu « boucles » la boucle et tu te met à l'écoute de l'événement suivant.
Oui donc c'est bien ce qu'il me semblait, une routine analyse en continu une certaine table d'évènements et dès qu'un nouveau champ apparait, on traite la procédure correspondante.
Maintenant, ce que j'ignore totalement, c'est la nature de cette structure:
Est-ce une structure définie et "remplie" par Windows?
Comment la réupérer et l'exploiter?
Salut tout dépend sous quel os tu veux faire un programme en assembleur...Envoyé par sepnar
si c'est sous Windows mais exe-cible ms-dos alors oui il faut faire une boucle de message comme le dit Obsidian.
C'est à toi de tout gérer de A à Z
Maintenant il est possible d'utiliser un assembleur comme MASM et de créer un programme exe-cible Windows /win 32 ( ou bien 64 )..
Mais faire un programme Windows en assembleur n'a aucun intérêt autant prendre un compilateur C/C++..
par contre ce qui est possible à faire c'est d'exploiter les fonctionnalités du multitache , du mode protégé pour les intel x86 mais c'est carrément plus
complexe.
Mais tu ne touches à cela que si tu souhaites faire ton propre OS
« Champ » n'est pas le terme exact. Ce serait plutôt une entrée dans ta table. Et plutôt qu'une « table », c'est surtout une file (un buffer circulaire) qui va te servir à recevoir les messages.
Ce qui veut dire, dans un premier temps, que tu travailles sous Windows, ce qui était loin d'être une évidence. Tu aurais pu utiliser Linux, D.O.S., un autre système d'exploitation encore, où même faire un logiciel de boot qui fonctionne complètement seul. Windows est un logiciel, au même titre que n'importe quelle application. À ce titre, c'est Windows qui utilise le micro-processeur et pas l'inverse.Maintenant, ce que j'ignore totalement, c'est la nature de cette structure:
Est-ce une structure définie et "remplie" par Windows?
Comment la réupérer et l'exploiter?
Si ce que tu veux faire, c'est créer une fenêtre Windows avec les boutons dont tu as l'habitude et récupérer les clics de l'utilisateur, par exemple, alors il faut faire exactement la même chose qu'avec les langages de plus haut niveau : communiquer avec le système d'exploitation en appelant les fonctions des différentes bibliothèques et en utilisant les appels système.
Le mieux est peut-être de partir de ce que tu connais déjà (même si ce n'est pas toujours le cas quand on étudie l'assembleur). Quels langages utilises-tu ? Quels genre d'interfaces as-tu réalisé jusqu'ici et connais-tu le langage C ?
Windows
Je ne comprends pas bien ta réponse. Que l'on soit en 16 ou 32 bit on peut appliquer le principe expliquer par Obsidian.
Mais au final c'est bien sur une architecture X86 32 bits que je veux coder.
Si moi je vois un interêt, le faire par curiosité.. Sinon, je n'aurais pas posté étant donné que j'ai déja codé des appli windows en C
EDIT: Je n'ai pas vu ta réponse entre temps Obsidian. Donc oui en effet c'est bien sous windows. Sinon niveau langage moi c'est du C et du Java (Et visual Adelia au passage mais vu que c'est pas connu..)
Mais de la programmation Windows, c'est essentiellement en Java que j'en ai fait. Ce qui n'est pas une aide puisque c'est l'environnement Java qui gère tout. En C j'ai essentiellement fait des petits programmes en invite de commande (petits jeux, manipulations de sockets etc..) et très peu d'appli windows à proprement parlé
L'ennui, c'est que le Java, non seulement ce n'est pas de la programmation en assembleur, mais ce n'est même pas de la programmation Windows non plus. Java a son propre environnement et ses propres interfaces qui, en coulisses sont mises en relation avec l'O.S. D'autre part, le bytecode n'est pas non plus du langage machine.
Tu devrais essayer de faire un peu de C-API Windows, ou bien d'utiliser la X-Lib sous Unix. Le fonctionnement y apparaît beaucoup plus clairement.
Alors désolé d'être insistant, mais en quoi l'appel à des fonctions de dll windows va me permettre de faire de la prog évenementielle?
Si tu me dis cela c'est donc qu'une (ou plusieurs) des dll se charge de notifier et de me retourner les évenements survenus. Ma question est laquelle (lesquelles)?
Sinon, même si je n'ai que quelques bases de programmation assembleur, je pense en saisir les concepts. Donc après cela ne sera que de la mise en pratique.
Merci pour ta patience
C'est-à-dire que ça dépend de ce que tu cherches à faire réellement au final.
Si tu veux faire un programme générique qui, en soi, traite l'activité de manière événementielle pour l'exercice, tu peux le faire dans pratiquement tous les langages, à commencer par l'assembleur. Mais si tu pars de rien, il faudra que tu écrives tout un environnement dans lequel l'utilisateur est susceptible de provoquer des événements, pour pouvoir les gérer ensuite.
Si ton but est d'exploiter, toujours de manière événementielle, l'interface graphique existante et ses composants, alors il faut utiliser l'API de cette interface, fût-ce en assembleur, en C ou dans tout autre langage.
Il y en a plusieurs, elles sont toutes indépendantes mais fonctionnent toutes, cependant, suivant le même principe. L'API native Windows est décrite ici entre autres. C'est une API C. Pour l'exploiter depuis l'assembleur, il faut utiliser des directives comme INVOKE ou bien reconstruire soi-même l'appel en mettant les arguments dans la pile.Si tu me dis cela c'est donc qu'une (ou plusieurs) des dll se charge de notifier et de me retourner les évenements survenus. Ma question est laquelle (lesquelles)?
Mais tu peux également utiliser d'autres environnements, tel que GTK, qui ont l'avantage d'être portables. Ils gèrent leur propre boucle principale mais, quand c'est possible, ils se contentent de transmettre cela au système.
La X-Lib est la bibliothèque des clients des serveurs X-Window, utilisés sous Unix, et Linux en particulier. Là encore, si c'est un produit complètement distinct des autres, le principe de fonctionnement reste le même.
À toi de choisir donc, ce qui te correspond le mieux. L'API C Windows a l'avantage d'être ce qu'il y a de plus proche du système sous Windows, mais ça commence à faire un bon bout de temps que je n'ai plus développé sous Win, et je ne sais pas dans quelle mesure elle est obsolète ou toujours valable.
Bonjour.
Pour comprendre comment on écrit des programmes Windows en Assembleur, une possibilité consiste à consulter le tutoriel se trouvant à l'adresse : http://win32assembly.online.fr/tutorials.html
On y trouve en particulier la manière de gérer les évènements.
Une traduction en français de ce tutoriel se trouve à l'adresse : http://luce.yves.pagesperso-orange.fr/tutor.html
Je pense que je vais m'intéresser un peu à l'API windows, même si ce n'est pas une fin en soi pour moi: elle fourni en effet un niveau d'abstraction déja suffisement élevé.
En fait je compte analyser comment l'API fonctionne pour, par exemple, le changement de couleur d'un bouton au passage du curseur dessus.
J'ai tout de même ma petite idée sur le fonctionnement: lorsque l'on bouge la souris une interruption doit être générée et à ce moment la il faut comparer la position du curseur sur l'écran avec la postion de l'objet graphique et en fonction du test on effectue ou non les modifications graphiques sur l'objet voulu.
En tout cas merci Obsidian pour tes explications.
Bonjour,
En Assembleur sous Windows, les interruptions ne sont plus valables, et tu ne pourras pas écrire sur certains ports car Windows est en mode protégé (et il est impossible de repasser en mode réel à moins de créer un driver, ce qui est déconseillé car il arrive souvent qu'il y ait des BSOD). C'est pourquoi tu dois obligatoirement utiliser l'API Windows (MASM est le plus simple pour cela car il permet d'utiliser plus facilement les DLLs de l'API au moyen de macros) pour programmer en Assembleur car elle te permet d'utiliser des fonctions telle que la lecture du clavier, la récupération des évènements souris, l'affichage de pixels à l'écran, ...
Oui, mais ce n'est pas toi qui fait ce travail. Sous Windows (et sous la plupart des O.S. modernes), toutes les IRQ sont déjà redirigées vers des routines qui lui sont propres. La position de la souris est mise à jour pour tout le système, et le gestionnaires de fenêtres surveille son activité. C'est lui qui se chargera d'émettre un événement si cela correspond à quelque chose dans son environnement.
Si ce que tu cherches à faire, c'est réécrire depuis zéro un tel environnement, tu en auras pour plusieurs mois même en s'en tenant à quelque chose d'élémentaire. C'est très instructif mais, moi, je ne ferais pas ça sous Windows (plutôt sous D.O.S. si c'est pour se familiariser avec l'affaire, sinon sous un Unix libre).
À ton service.En tout cas merci Obsidian pour tes explications.
Bonjour,
Comme il a été dit auparavant, je te conseille fortement d'étudier l'API win32 pour voir comment tout cela fonctionne.
Tu as un tutorial expliquant tout cela (en C) ici: http://bob.developpez.com/tutapiwin/ .
Sinon, si tu tiens à voir comment est conçue l'API win32, tu peux étudier le code source de ReactOS (ici: http://www.reactos.org ), qui est une sorte de clone libre de windows
Toute question technique envoyée en MP ira directement à la poubelle
Un code ne marchera jamais, il n'a jamais reçu la capacité de se déplacer.
Inutile donc de dire "ça marche pas", donnez plutôt des informations précises afin de mieux pouvoir vous aider.
Grand gourou de la-attitude
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager