Sauts de programmes

[Screetch]

Screetch

#9744

J’ai une petite idée de développement, mais n’ayant pas programmé en C de façon sérieuse depuis des années, je ne sais plus si je peux faire ce que je voudrais. A la limite, je tenterais bien le LUA ou le Python pour ce projet, si ma problématique peut y être résolue.

En gros, à partir d’un programme, puis-je appeler un autre programme avec des paramètres et que ce dernier une fois terminé redonne la main au premier en envoyant également des paramètres ?

En fait, ma problématique refuse que je recompile ou link mes programmes quand j’ajoute des programmes complémentaires (un peu comme des plug-ins) dans un répertoire spécifique. Mon programme maître doit être capable d’appeler ces programmes supplémentaires et partager avec eux des paramètres.

Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !

[elwood]

elwood

#149855

Les pros répondront. Moi je dirai qu’il faut utiliser des message ports.

Site AmigaOS 4 francophone

[Anonyme]

Anonyme

#149856

J’ai tenté avec les ports arexx (enfin, tenté… plutôt essayé de tenter lol) mais j’y arrive pas, le seul truc que j’arrive à faire c’est :

2 programmes hollywood qui s’exécute et se ferme mutuellement en dialoguant via un fichier txt, mais franchement, c’est un système trop pourrie et sa sert à rien à part à mon avis flinguer le DD

[thellier]

thellier

#149857

A mon avis le plus simple (sic) c’est de faire tes plugins comme des .library séparées

Alain

[Screetch]

Screetch

#149858

Cela va pas le faire pour ce que je veux faire…

J’aimerais que mon programme principal lance au hasard (ça c’est pas difficile) un des programmes (prévu à cet effet) pris dans un repértoire spécifique.

Et ainsi ajouter autant de programme (développés exprès) à ma guise. Ceci afin de permettre à d’autres personnes d’ajouter ses propres modules qu’il aura développé.

Et c’est quoi des messages ports ?

Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !

[Gilloo]

Gilloo

#149859

La seule façon propre de faire dialoguer des programmes entre eux est la communication intertâche (ou inter processus) avec des ports de messages et les fonctions WaitPort(), GetMsg(), ReplyMsg() et PutMsg(). les paramètres ont pour base commune la structure Message, (voir les IORequest par rapport à Message)

Pour charger un programme, il y a LoadSeg() (et UnloadSeg() pour libérer les segments) il me semble que l’adresse du code exécutable se trouve à seg * 4 + 4 … (mais de tête je sais plus).

On peut soit exécuter ce code par la tâche en cours, comme une espèce d’overlay (le programme charge et décharge des portions de code pour éviter de tout charger au démarrage) soit créer une autre tâche et synchroniser les deux.

Si c’est un overlay que tu veux faire, tu peux avoir une mémoire partagée par un port nommé ou tu stockes les paramètres et charger /décharger des bouts de programme avec LoadSeg()/unloadseg(). Ce principe a pour avantage de ne gérer qu’un seul process, sans se casser la tête avec des envois/réception de messages entre les pères et les fils (ou les mères et les filles )

Pour trouver la liste des programmes contenus dans un répertoire c’est plus chaud… Examine() et ExNext() fournissent la liste des fichiers présents dans un répertoire, mais seul LoadSeg() est capable de charger un exécutable…

[krabob]

krabob

#149860

bahh …. de base c’est ce qu’un dos sait faire, sur tout les systèmes !

Un programme prend un ou plusieurs paramètres lors de son lancement, et renvoi en sortie un code d’erreur. Il a également un flux d’entrée et des « flux » de sorties.

un programme C par exemple à sa fonction d’entrée de la forme:

int main(int argc char *argv[])

{

corps du prog.

return errorcode;

}

ou le int renvoyé est le code d’erreur, argc le nb de param en entrée et argv la table de params.

la commande printf(texte) écrit un texte visible mais il n’est visible que parce que le flux de sortie est visible. sous tout les dos on peut faire des redirections des flux.

Par exemple si on a un progarmme qui printe hello world:

> proghello >Ram:hello.txt

… va créer un fichier texte contenant les printf de pgroghello. Il y a plein de bidouille dos possible avec ça, quel que soit le langage utilisé.

Note: dans la startup sequence, on utilise >NIL: pour ne pas afficher les messages d’une tâche.

appli

[Gilloo]

Gilloo

#149861

@krabob

ok avec toi, mais tu utilises le shell pour rediriger les paramètres autrement dit le ‘programme principal’ est un shell et les exécutables des programmes compilés ou d’autres shells.

Ca peut le faire aussi bien.

[seg]

seg

#149862

Si tu veux faire un proto rapide sans te prendre la tête, tu la fais bourin avec la fonction system() en C.

Tu peux ainsi lancer un exe avec des paramètres. Par exemple: system(« monprog 123 456 »).

Ton programme « monprog » receptionne les paramètres et travaille avec.

Le problème, c’est que system ne te renvoie qu’un int. Si tu veux plus que ça, tu la fais encore une fois bourin en déposant tes résultats dans une variable d’environnement par exemple. Tu dis à ton « monprog » de retourner 0 si ça s’est bien passé, ou autre chose s’il y a erreur. Puis ton programme initial va chercher les résultats de ton programme externe dans ta variable d’environnement.

Tu vas me dire que si tu lances 2 instances de ton programme, ils vont se marcher dessus. Ben oui. Sauf si tu ruses en faisant en sorte que la variable d’environnement porte un nom différent par instance. Genre, tu génères un nom de variable basée sur l’adresse de ton process, et tu l’envoies via system() à ton programme externe pour qu’il te retourne le résultat dans la variable attendue.

Je dois te dire que je ne suis pas très adèpte de cette méthode bourin. Elle a juste le mérite d’être moins prise de tête quand on veut tester un prototype rapidement.

a+

[Yomgui]

Yomgui

#149863

@screetch: mis-à-part appeler un prog et récupérer des valeurs de ce dernier, qu’est-ce qu’il fait de ces valeurs ton programme principal après?

Sinon dans un shell genre « sh » (avoir le SDK sur MorphOS):

$ cd mon_rép_des_binaires

$ echo «  » >values.txt

$ for name in `ls -1 | sort -R`; ${name} >>values.txt

Et voilà….

[Screetch]

Screetch

#149864

Effectivement, le plus simple est de créer un fichier temporaire où je place mes données d’entrées et de sorties que le programme principal récupèrera après que le programme esclave soit arrêté.

Je veux être sur que le programme principal récupère la main quand le second est terminé.

Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !

[Yomgui]

Yomgui

#149865

Le problème n’est pas comment, mais quoi!

[centaurz]

centaurz

#149866

@Screetch

Je veux être sur que le programme principal récupère la main quand le second est terminé.

Ce sera le cas avec une fonction telle que System() de la dos.library, le comportement par défaut étant d’exécuter la commande de façon synchrone.

Pour échanger des données, tu peux aussi utiliser un pipe Amiga (handler PIPE:). Cela t’évite d’avoir à créer un vrai fichier dans le RAM Disk. Le « plugin » peut par exemple écrire un paramètre sur chaque ligne dans le pipe. Le programme principal lit le pipe ligne par ligne et scanne les résultats (par exemple avec sscanf()).

[AmiDARK]

AmiDARK

#149867

sinon, la DOS library permet d’exécuter un programme et d’attendre qu’il ait rendu la main … Je crois que c’est une fonction genre ExecuteFile … ou quelque chose dans le style.

Faut regarder dans la doc.

[Anonyme]

Anonyme

#149868

Euh!!!! j’espère que vous déconnez les gars, vous allez pas me dire que créé un fichier temporaire dans le DD est la meilleur solution pour un dialogue entre 2 Prg?!?

C’est quoi se bordel?! on peut pas réservé un espace mémoire pour l’échange de donnée entre 2 Prg même en C?