Execution d'un prog dans un prog en C - Page 1

Voial la situation : j'ai un programme en C _nostub, et je voudrais lancer d'autres programmes a partir de celui la (au hasard, c'est un shell ).
Au début, je mets #define EXECUTE_IN_GHOST_SPACE.
Pour exécuter un prog ASM, je fais ça :
handle = (SymFindPtr (SYMSTR (str), 0))->handle;
len = *(unsigned short*)(src = HLock (handle));
EX_patch (src + 2, src + len + 1);
ASM_call (src + 2);
HeapUnlock (handle);

Est-ce que le programme appelé sera exécuter dans le ghost_space ? (c'est pas très clair dans la doc de #define EXECUTE_IN_GHOST_SPACE)

De meme si j'appelle un prog ASM avec NG_execute comme ça :
strcpy (str2, "hibtext(")
strcat (str2, str);
strcat (str2, ")")
push_parse_text (str2);
handle = HS_popEStack ();
NG_execute (handle, FALSE);
HeapFree (handle);

C'est le seul moyen que j'ai trouvé pour lancer un prog ASM avec arguments. Est-ce que le prog est exécuté dans le ghost-space ?

Regarde le topic sur le launcher dans la FAQ. Je crois que le code est différent de celui que tu utilises...
Pour le fait que ça soit exécuté dans le ghost space, je ne connais pas la réponse...

Il y a d'autres moyens de lancer un programme avec arguments (regarde les fonctions d'estack.h). En plus, il y a un gros bug dans ton deuxième bout de code: tu ne mets pas de TRY/ONERR/ENDTRY autour d'un call à une fonction du TI-BASIC (si jamais une erreur est lancée, ça fait au minimum un gros memory leak) !

guilc a écrit :
Voial la situation : j'ai un programme en C _nostub, et je voudrais lancer d'autres programmes a partir de celui la (au hasard, c'est un shell ).
Au début, je mets #define EXECUTE_IN_GHOST_SPACE.

Et tu fais bien.

Pour exécuter un prog ASM, je fais ça :
handle = (SymFindPtr (SYMSTR (str), 0))->handle;
len = *(unsigned short*)(src = HLock (handle));
EX_patch (src + 2, src + len + 1);
ASM_call (src + 2);
HeapUnlock (handle);
Est-ce que le programme appelé sera exécuter dans le ghost_space ? (c'est pas très clair dans la doc de #define EXECUTE_IN_GHOST_SPACE)

Non, il faut mettre:
handle = (SymFindPtr (SYMSTR (str), 0))->handle;
len = *(unsigned short*)(src = HLock (handle));
EX_patch (src + 0x40002, src + len + 0x40001);
ASM_call (src + 0x40002);
HeapUnlock (handle);

De meme si j'appelle un prog ASM avec NG_execute comme ça :
strcpy (str2, "hibtext(")
strcat (str2, str);
strcat (str2, ")")
push_parse_text (str2);
handle = HS_popEStack ();
NG_execute (handle, FALSE);
HeapFree (handle);
C'est le seul moyen que j'ai trouvé pour lancer un prog ASM avec arguments. Est-ce que le prog est exécuté dans le ghost-space ?

Non (sauf si h220xTSR est installé).
Il ne faut pas utiliser NG_execute pour lancer un programme en assembleur/C (ni d'ailleurs pour lancer un programme BASIC qui utilise des programmes en assembleur/C comme flib ou des chaînes Exec - c'est pour ça que TICTEX se contente de copier le nom des programmes BASIC dans la ligne d'entrée plutôt que de les exécuter directement).

La solution correcte est:
ESI top_estack_backup=top_estack;
push_END_TAG();
push_expr_quantum (SYMSTR(str2), STR_TAG); /* workaround parce que push_string de AMS est bogué */
handle = (SymFindPtr (SYMSTR ("hibtext"), 0))->handle;
len = *(unsigned short*)(src = HLock (handle));
EX_patch (src + 0x40002, src + len + 0x40001);
ASM_call (src + 0x40002);
HeapUnlock (handle);
top_estack=top_estack_backup;

D'ailleurs, si tu travailles proprement, tu fais toujours ça:
ESI top_estack_backup=top_estack;
push_END_TAG();
...
top_estack=top_estack_backup;
quand tu lances un programme!

Kevin: Je suis étonné: ta routine est buggée!


ESI top_estack_backup=top_estack;
SYM_ENTRY* symentr;
push_END_TAG();
push_expr_quantum (SYMSTR(str2), STR_TAG); /* workaround parce que push_string de AMS est bogué */

symentr = SymFindPtr (SYMSTR ("hibtext"), 0);
if (!symentr)
//le fichier n'était pas trouvé
else
{
handle = symentr->handle;
if (HeapGetLock (handle)
{
src = HeapDeref (handle);
handle = 0;
}
else
src = HLock (handle);
len = *(unsigned short*)src;
EX_patch (src + 0x40002, src + len + 0x3FFFF);
asm ("movem.l %a2-%a6/%d3-%d7,-(%a7)")
ASM_fastcall (src + 0x40002);/*ASM_fastcall parce qu'il faut des nop's*/
asm volatile ("nop; nop; nop; nop;")/*il les faudra si le prog appelé a un "#define RETURN_VALUE"*/
asm ("movem.l (%a7)+,%a2-%a6/%d3-%d7")
if (handle)
HeapUnlock (handle);
top_estack=top_estack_backup;
}

Parce que handle devient libre même s'il n'était pas avant ta routine, et ça peut planter une calc.

EDIT: J'avais oublié de voir si le fichier était trouvé.

joelt49
a écrit : Kevin: Je suis étonné: ta routine est buggée!

Je n'ai même pas essayé de la compiler.

Parce que handle devient libre même s'il n'était pas avant ta routine, et ça peut planter une calc.

Je vois mal pourquoi un handle traînerait en état locké (sauf par erreur, et à moins que quelqu'un n'essaye de lancer le shell lui-même à partir du shell), mais il est vrai que c'est plus sûr comme ça (j'y ai pensé quand j'avais déjà posté mes routines).

Et pour le RETURN_VALUE, je n'y ai pensé qu'après aussi, et j'ai été trop paresseux pour corriger (puisque ça complique un peu).

>>Je n'ai même pas essayé de la compiler.
Ni moi

>>Je vois mal pourquoi un handle traînerait en état locké
On ne sais jamais, mais c'est possible. Quelque chose d'autre:
il faut voir si le fichier est dans l'archive:
if (symentr->flags.bits.archived)
//il faut utiliser SymAddTwin
Et tu as oublié (comme j'ai presque fait de voir si le fichier était trouvé.

Kevin Kofler a écrit :
Non, il faut mettre:
handle = (SymFindPtr (SYMSTR (str), 0))->handle;
len = *(unsigned short*)(src = HLock (handle));
EX_patch (src + 0x40002, src + len + 0x40001);
ASM_call (src + 0x40002);
HeapUnlock (handle);

Ok, je pensais que le fait de mettre #define EXECUTE_IN_GHOST_SPACE dispensait de rajouter le décallage de 0x40000...

Merci aussi pour l'autre routine.

Tant que j'y suis, une autre question : y a-t-il un truc faux la dedans :
unsigned short folder (char **fold)
{
short c = 0;
SYM_ENTRY *SymPtr;
SymPtr = SymFindFirst (NULL, 0);
while (SymPtr)
{
fold = (char **)realloc (fold, (c+1) * sizeof (*fold));
*(fold+c) = (char *)malloc (strlen (SymPtr->name) + 1);
strcpy (*(fold+(c++)), SymPtr->name);
SymPtr = SymFindNext ();
}
return c;
}
au début, fold est a NULL, bien sur.
Je dois me melanger quelque part avec les doubles pointeurs, vu que le résultat est foireux, mais je vois pas ou...

Je ne sais pas pour le reste, mais ça, c'est faux:
>*(fold+c) = (char *)malloc (strlen (SymPtr->name) + 1);
>strcpy (*(fold+(c++)), SymPtr->name);
On ne peut pas utiliser strlen ni strcpy ici parce que la chaîne ne sera pas terminée par un 0 si le nom fait exactement 8 caractères!
Je propose (j'utilise la notation fold[c] plutôt que *(fold+c), c'est plus lisible):
fold[c]=malloc(9);
fold[c][8]=0;
strncpy(fold[c++],SymPtr->name,8);

Apparement, ça regle pas mon probleme, alors ça doit venir d'ailleur.
Au passage, y a ça dans la faq de tigcc sur SymFindPtr :
counter = 0;
SymPtr = SymFindFirst (SYMSTR ("main"), FO_SINGLE_FOLDER);
while (SymPtr)
{
strcpy (names[counter++], SymPtr->name);
SymPtr = SymFindNext ();
}
Remarque le strcpy, je sais pas si il faudrait pas signaler ça...

Voila un shot de mon prog : a gauche, c'est la liste des répertoires

Mis a part la routine de listage du post 6, j'affiche comme ça : void affiche_fold (char **lsfold/*tableau des noms de repertoires*/, unsigned short tfold /*nombre total de folders*/, unsigned short dfold/*index du premier repertoire a afficher*/, unsigned char *charset/*table de caractères pour la routine d'affichage rapide (la meme que tthdex)*/) {      void *backb = (void *)(charset + 8*256 + 5*256 + 2*256 + LCD_SIZE);      unsigned short a, der;      SCR_RECT ECRAN = {{0, 0, CALCULATOR ? 239 : 159, CALCULATOR ? 127 : 99}};      ScrRectFill(&(SCR_RECT){{1, 9, 55, CALCULATOR ? 121 : 93}}, &ECRAN, A_REVERSE);      der = dfold + (CALCULATOR ? 16 : 11);      for (a = dfold; a < min (tfold, der); ++a)           NormalString (7, 8*(a-dfold+1)+4, *(lsfold+a), backb, charset);/*ça, c'est pas buggué, c'est la routine de la tict :) */ }
Pour info, dans le screen shot, c'est sur une calc resetée, donc le seul répertoire est main, et il n'y a que mon prog dedans...
Je vois vraiment pas ce qui foire.

guilc a écrit :
Apparement, ça regle pas mon probleme, alors ça doit venir d'ailleur. Au passage, y a ça dans la faq de tigcc sur SymFindPtr :

Oups... Tu ne pourrais pas me donner le nom du fichier exact (clic droit / propriétés)? Ça irait plus vite pour le corriger.

Au fait, ce n'est pas si grave que ça parce que le champ qui suit ("compat") est à 0 normalement.

Vala : TIGCC.chm::/vat_SymFindPtr.html

Ah, j'aurais pu deviner le nom de page.

Voila, j'ai trouvé mon probleme, c'est assez bizarre, mais c'est à cause des realloc :
si j'alloue en une seule fois, a l'EXTERIEUR de la fonction (que je rappelle) :
unsigned short folder (char **fold)
{
short c = 0;
SYM_ENTRY *SymPtr;
SymPtr = SymFindFirst (NULL, 0);
while (SymPtr)
{
fold = (char **)realloc (fold, (c+1) * sizeof (*fold));
fold[c]=malloc(9);
fold[c][8]=0;
strncpy(fold[c++],SymPtr->name,8);
SymPtr = SymFindNext ();
}
return c;
}
Ca marche.
Quite strange isn't it ? Il me semble pourtant que ce que je fais est autorisé en C !
Est-ce qu'il serrait possible que ce soit un bug de TIGCC, ou j'ai pas vu une grosse connerie dans mon code ?

Pour ce ki est de la recuperation des noms de vars, j'avais créé un piti prog ki stockait tout ça dans un tableau et ki les affichait dans un popup, j'avais fait ça pour me familiariser avec la VAT, je peut t'envoyer les sources si tu veux...(donne moi juste une adresse où envoyer)...le code est pas optimiser du tout vu ke je debute en C, mais tu pourrais voir ce ki colle pas avec le tien..

trop tard...

guilc a écrit :
Ca marche.
Quite strange isn't it ? Il me semble pourtant que ce que je fais est autorisé en C ! Est-ce qu'il serrait possible que ce soit un bug de TIGCC, ou j'ai pas vu une grosse connerie dans mon code ?

La "connerie", c'est que realloc (et même malloc!!!) entraînent une réorganisation de la RAM et que tu n'as locké le bloc de la VAT nulle part.

Extrait de la documenttion de SymFindFirst:

Note: Since this routine and subsequent calls to SymFindNext and SymFindPrev return direct pointers to the symbol table, heap compression will cause subsequent results to be invalid or may crash the system. In other words, heap compression will invalidate all pointers returned necessitating another call to SymFindFirst. Therefore locking the folder table (using FolderOp) during the complete operation is highly recommended.

Donc:
unsigned short folder (char **fold)
{
short c = 0;
SYM_ENTRY *SymPtr;
FolderOp(NULL,FOP_LOCK|FOP_ALL_FOLDERS);
SymPtr = SymFindFirst (NULL, 0);
while (SymPtr)
{
fold = (char **)realloc (fold, (c+1) * sizeof (*fold));
fold[c]=malloc(9);
fold[c][8]=0;
strncpy(fold[c++],SymPtr->name,8);
SymPtr = SymFindNext ();
}
FolderOp(NULL,FOP_UNLOCK|FOP_ALL_FOLDERS);
return c;
}

Ok, je vois.
De toute façon, c'est bon maintenant, je fais en fait comme dans tictex : en 2 passages : une fois pour trouver le nombre, puis allocation mémoire, puis deuxième passage pour mémoriser les noms. D'ailleur ça doit être plus rapide, vu qu'on perd pas de temps à réallouer à chaque fois (ça doit être long il me semble), meme si on parcour les repertoires 2 fois...
Merci Bylos, j'en ai plus besoin

Pour revenir au sujet d'origine du topic : comment on lance un prog basic (sans NG_Execute). J'ai vu dans tictex, il copie le nom du prog dans la ligne de commande de home, ça ok, mais comment on la valide, la ligne de commande ?
Et y a t il une autre methode ?

guilc
a écrit : Pour revenir au sujet d'origine du topic : comment on lance un prog basic (sans NG_Execute). J'ai vu dans tictex, il copie le nom du prog dans la ligne de commande de home, ça ok, mais comment on la valide, la ligne de commande ?

On attend que l'utilisateur le fasse.

Et y a t il une autre methode ?

On détourne le trap 11 comme le fait h220xTSR (pour empêcher que ça plante si le programme BASIC appelle un programme en assembleur/C ou une chaîne Exec - mais attention, ne le détourne en aucun cas vers DUMMY_HANDLER; il faut le détourner avec le code de h220xTSR - demande-moi la permission si tu veux vraiment faire ça, mais c'est compliqué, et je n'ai jamais eu le temps de faire une routine standard pour ça - on peut utiliser h220xTSR tel quel, mais le mieux serait une version spéciale qui se désinstalle automatiquement quand tu as fini de lancer le programme BASIC), et après on utilise NG_execute.

Bon, la première methode est beaucoup plus simple, c'est celle sue je vais choisir

Finalement, la méthode avec NG_execute m'intéresse, c'est vachement mieux.
Pourrais-tu m'expliquer vers quoi tu détourne le trap 11, stp ? J'ai regardé les sources de hw2tsr, j'ai rien compris

Tu ne comprendras pas mes explications non plus alors.

ce qui y a, c'est que je pige rien a l'ASM, mais je sais ce que veut dire rediriger un vecteur d'interruption (du style autoint ou trap)

Le problème, c'est que pour la manipulation du trap 11, il faut connaître l'ASM (il faut manipuler des registres utilisés par AMS pour changer l'adresse du programme ASM qu'AMS va lancer).

meuuh
Tu pourrais pas faire une chtite fonction qui fait ça, stp ? Ca serait bien aussi de l'introduire dans TIGCC, ça serait pratique pour tous les programmeurs C qui connaisent rien à l'ASM... en plus, dans la doc de NG_execute, ils parlent pas de ça, donc on fait vite une erreur . Si tu fait une telle fonction, il suffit que ce soit précisé dans la doc, et vala, ça fait un truc standard pour lancer les progs basic.

Des trucs d'aussi bas niveau ne seront peut-être pas intégrés dans TIGCC...

en librairie statique à côté (puisque vous semblez aimer les librairies statiques )


(ne voyez rien de méchant dans mon post, juste de l'ironie, éventuellement)

Je ne vois rien de méchant ici. De toute façon, tu n'as pas pour habitude de faire des posts méchants.

Et je pense sincèrement que ça ne sera pas intégré... C'est un peu dangereux, la trap B étant la trap pour travailler avec la Flash/l'archive. Si le programmeur fait une petite erreur, il risque d'y avoir des *petits* problèmes. La calculette risque de faire entendre 'le bruit étrange que fait une touche ON qui ne réveille plus la bête' (ou un truc comme ça, je crois que c'est ExtendeD qui avait dit ça).

alors si en plus maintenat on a pu le droit de faire n'importe quoi avec sa Ti ...

arf