[83PCE] PHASM

[Hayleia]

Oui mais quand un programme "grossit" forcément tous les autres programmes sont décalés. J'ai déjà eu cette expérience avec mon compilateur qui faisait "grossir" les programmes. Me trompè-je ?

En voilà une question qu'elle est bonne...

J'avais pensé à cette "solution" parce que je fais des trucs de ce genre dans certains de mes programmes, mais j'avais oublié que ton hook devait rester valide plus longtemps que juste pendant l'exécution d'un programme...

[Hayleia]

Idée complètement lolwat et aucune idée de si ça marche

Tu mets ton hook en RAM n'importe où, genre là où tu l'as mis au départ (l'endroit qui fait planter Pacman).

Ce que devra faire ton hook une fois installé, lorsqu'on tente de lancer un programme que l'on appellera PROG dans cet exemple :
- recopier ce qui se trouve dans l'appvar PHASM (archivée ou non) dans un programme assembleur désarchivé avec un nom spécifique, par exemple PHASM
- détecter si PROG est en assembleur ou non et ajouter "Asm(" devant la commande si besoin
- ajouter ":Asm(prmgPHASM" à la fin de la commande
- parser la commande

Bien entendu, l'appvar PHASM contient du code qui se charge de remettre ton hook en place là où il était à l'origine. Du coup, après avoir executé la commande "[Asm(]prgmPROG:Asm(prgmPHASM", ton hook peut continuer à s'exécuter.

[Epharius]

Da fuck, c'est vrai que c'est tiré par les cheveux

Sauf que si le programme change pendant son exécution un autre programme ? Il y a toujours le problème de l'insertion de données. La seule solution pour que le programme ne soit pas bougé c'est juste avant le progstart je crois... en tout cas sur ti-83

[Hayleia]

Sauf que osef ce coup-ci s'il change de place puisque c'est la commande Asm(prgmPHASM qui va se charger de retrouver ton programme dans la VAT et de le lancer. T'as pas besoin de savoir où il est. T'as juste besoin de savoir où le code du hook se trouve lorsque le hook est déclenché, et ça c'est bon, l'installeur l'a mis dans la zone de RAM à conflits et prgmPHASM le remet là-dedans après toute exécution.

[Epharius]

Ah OK je comprend. Donc si je résume ça fait ça :
- exécution du hook
- le hook crée un programme PHASM et l'exécute.
- le programme PHASM exécute le programme de l'user si en assembleur
- après le programme exécuté, le programme PHASM copie le hook à son endroit initial et se quitte.
- le hook se quitte.

Cependant j'avais une question qui me rend perplexe. Pour exécuter le programme, il faut mettre le Asm(prgmUSER dans OP1 et faire call _parseInp ? Et même si je faisais ça, comment faire si le programme fait 8 caractères en sachant que Asm( prend deux octets et que OP1 n'en fait que 9 ?
Mateo m'a dit hier qu'il fallait que je fasse insertMem, sauf que OP1 n'est pas extensible, si ? Tout ce que fait InsertMem c'est décaler les octets vers la droite ou la gauche à ce que je sache.

[Hayleia]

Euh, non c'était pas ça mes étapes mais ça marche peut être aussi
Mes étapes c'était que le hook exécute le programme demandé (en ajoutant Asm si besoin) PUIS le programme PHASM (en ajoutant ":Asm(prgmPHASM" à la fin de la commande) pour réinstaller le hook qui peut donc continuer à s'exécuter puisque même si le programme l'a effacé, il s'est réécrit avec prgmPHASM.

Et aucune idée pour les détails
Faut expérimenter ou demander à d'autres mais c'est pas moi qui vais pouvoir t'aider là-dessus...

[Epharius]

Ouais heu je préfère ma méthode quand même
Et puis pas besoin de faire la méthode Asm(), je vais garder ma technique, elle marche c'est tout ce que je veux

Vivement ce soir pour les tests.

[Hayleia]

Ouais mais le truc avec ta méthode c'est qu'elle peut potentiellement avoir des problèmes avec tes histoires de mémoire qui bouge.

Voilà ce que fait ta méthode :
prgmPACMAN
→hook
→→Asm(prgmPHASM
→→→Asm(prgmPACMAN
→→retour à PHASM pour réinstallation du hook

Mais et si PACMAN (ou un autre) bougeait la mémoire ? Comment tu reviens à PHASM ? Je sais pas si ça marche vraiment bien ça. Surtout qu'en plus, là t'es en train d'exécuter deux programmes, l'un dans l'autre et moi ça me semble pas une excellente idée au niveau gestion en général.

Voilà ce que fait ma méthode :
prgmPACMAN
→hook
→→Asm(prgmPACMAN
→→Asm(prgmPHASM pour réinstallation du hook

Et même si PACMAN (ou un autre) bouge la mémoire, osef, c'est le TI-OS qui se débrouille pour faire Asm(prgmPHASM donc il va le chercher où il faut. Et à aucun moment je ne lance un programme depuis un autre.

Bon après, comme tu veux, c'est ton programme

[Lionel Debroux]

Mouais... sans connaître ce genre de détails (ou beaucoup d'autres détails, d'ailleurs ^^) de la programmation TI(e)-Z80, j'aurais tendance à suggérer de privilégier la méthode fiable, en effet...

Je connais bien les lanceurs TI-68k/AMS, où a contrario, on doit faire lancer les programmes par les lanceurs.

[Epharius]

Coucou tout le monde !

Tout d'abord : oui, PHASM avance. Je suis en train de faire la technique d'Hayleia mais j'ai un bug d'exécution, une erreur qui ne devrait pas survenir en utilisant _parseinp, enfin bref, je continue ça ce soir. Ce qui est compliqué ce n'est pas comment faire le programme mais résoudre les dizaines de bugs qu'il y a à chaque fois que j'en résoud un.

Récemment on s'est posé la question si PHASM était vraiment un nom de shell. En effet PHASM serait plus un nom de compilateur (comme TASM ou SPASM). Alors on s'est creusé la cervelle et nous nous sommes dit que Kwarks serait pas mal. En effet c'est dans le même genre que ION ou cesium. Alors en passant, aucun commentaire concernant la provenance du nom

Et donc je poste ici pour savoir ce que vous en pensez : c'est nul ? PHASM est mieux ? un autre idée ?

D'ailleurs le "c'est trop tard pour changer" doit être accompagné d'une autre excuse que "on a déjà fait la news"