Utilisation de la ligne de commande - Page 1

Kikoo !

Bon, je voudrais lancer le prog Whisky depuis un prog ASM, le tout en utilisant le TI-OS, en passant par la ligne de commande.

En gros ce que je veux faire, c'est la correspondance de ca, manuellement :
mainwhisky() + ENTER

- En gros, comment remplir la ligne de commande
- Et comment lancer son execution

Le tout permettant de boire au final .
Non tt plaisanterie a part, ca serait sympa si vous saviez ou il y a des docs precises la dessus

Et au passage, si il etait possible de faire cette operation, le tout sans que ca apparaisse qd on sort du programme, dans l'ecran HOME et l'historique, ca serait pas mal aussi.
(remarquez, il y a doit bien y avoir une fonction pour vider la ligne de commande, et supprimer une partie de l'historique )

Vala, ca doit pas etre bien dur, mais bon, je suis pas devin :]

Vas sur mon site, j'explique comment executer un prog

Tu l'execute sans même toucher à l'historique, ce qui enlève une partie de tes emmerdes

pour ne pas voir le prog que tu viens d'executer sur l'ecran home utilise les programme basic kbprgm1,2,...

FluF : tu n'as pas compris je crois...
Ok paxal, mais ca m'empechera surement d'utiliser les lanceurs genre ttunpack

Bah paxal, je vois rien sur ton site

"Vala, ca doit pas etre bien dur, mais bon, je suis pas Kevin :]" j'en c rien , mais kevin surement

laule

c clair

Et ma reponse alors

Je me trompe pe mais c pas possible en C ?

euh... ou est le rapport ?

- En gros, comment remplir la ligne de commande
il y a une doc de kevin la dessus. sur son site. (ou ds FLS, il y a les adresses en fn de l'AMS.(thx Kevin))
- Et comment lancer son execution
p e avec les events ?? genre tu donnes le code de la touche [enter]
ça je sais pas, c une id qui me viens à la volée..
[edit]Edité par Pen^2 le 12-09-2001 à 19:02:25[/edit]

Extrait de la source de Doors:
push_parse_text(command_line);
NG_rationalESI(top_estack);

soit en Asm:

 pea command_line(pc)
 ROM_CALL push_parse_text
 ROM_CALL2 top_estack
 move.l (a4),(a7)
 ROM_CALL NG_rationalESI
 addq.l #4,a7

Tu peux ajouter une le procédures de stabilité: ER_Catch, voire OSBreakDisable (ce que fait doors)

Erf et tigcc alors???

Non, n'utilisez pas NG_* pour appeler un programme en assembleur! Sur HW2 AMS 2 sans le HW2Patch et sans mon HW2 AMS 2 TSR support, ça plantera!

Il faut mettre les arguments sur la pile d'expressions, puis enter_ghost_space, puis EX_patch en ajoutant 0x40000 à l'adresse, puis un saut direct, toujours en ajoutant 0x40000 à l'adresse.
[edit]Edité par Kevin Kofler le 12-09-2001 à 20:52:36[/edit]

Ok je vais essayer tout ca

Kevin: mais on sait pas si c une expression qu'on calcule, un programme Basic ou un prog Asm, tu vas pas commencer à étudier la ligne de commande...

Pour un programme Basic ou une expression, si une commande Exec ou un appel à un programme en assembleur ou C est contenu, ça peut aussi planter (sauf si on installe un hook du trap #$b)!

Mais alors, si je veux utiliser la ligne de commande sur HW2, sans pour autant que ca plante, je serai oblige de faire des trucs speciaux :

- pour que mon prog marche sur HW2
- pour que la routine de mon prog (qui lance les progs) marche sur HW2 ? --> i-e routine personalisee, donc impossible d'utiliser la ligne de commande ? Je pourrais toujours ajouter $40000 a l'adresse du prog avant l'execution non ?

Mais alors, si je veux utiliser la ligne de commande sur HW2, sans pour autant que ca plante, je serai oblige de faire des trucs speciaux :

- pour que mon prog marche sur HW2
- pour que la routine de mon prog (qui lance les progs) marche sur HW2 ? --> i-e routine personalisee, donc impossible d'utiliser la ligne de commande ? Je pourrais toujours ajouter $40000 a l'adresse du prog avant l'execution non ?

> Je pourrais toujours ajouter $40000 a l'adresse du prog avant l'execution non ?

Ça, ça marche pour l'assembleur 100%. Pour le Basic appelant un programme en assembleur ou une chaîne Exec, c'est plus compliqué, puisqu'il faut empêcher AMS d'appeler le programme en assembleur "normalement" et ainsi déplacer la zone déprotégée.
Il faut installer au moins temporairement un hook du trap #$b comme dans mon HW2 AMS 2 TSR support (il y a les sources, mais demande-moi avant de publier une version modifiée, pour que je puisse vérifier si ça marche, puisque ces histoires de protection sont vraiment compliquées). Pour le trap #4, tu n'es pas obligé de l'intercepter sauf si tu veux permettre à l'utilisateur de changer les piles pendant que ton hook du trap #$b est actif.

Ok pas de pb.

Ou fait le en kernel...

>Ou fait le en kernel...

En kernel ou en nostub c'est la meme chose là non ?

En tout cas, je viens d'utiliser ta methode que j'ai convertie en ASM Nitro, ca marche super, ca va faire de la pub a PpHd pour RunC
(enfin s'il accepte que je fasse un repertoir distrib dans lequel je mettrai le ZIP complet de RunC )

Et en plus, c ultra simple, ca permet de lancer :
- ppg
- RunC
- ASM
- EXE

Cé ti po bo ?

---> Kevin, je v surement encore te harceler (pour savoir exactement comment deproteger les HW2)

>Nitro: En kernel ou en nostub c'est la meme chose là non ?

Non, en mode kernel, on peut se permettre de présupposer que le HW2patch est installé, car les kernels ne tournent pas sans lui.

>FlashZ: pour savoir exactement comment deproteger les HW2

Il y a la source commentée de enter_ghost_space dans h220xTSR sur http://ti89prog.francais.kevinkofler.cjb.net.
Je te rappelle que ça ne déprotège que l'espace fantôme (et les derniers 4 KO de l'espace "normal").
Pour une déprotection complète, il faut d'abord désactiver la protection Flash ROM et ports I/O, et là, personne ne te dira comment faire.

D'ailleurs, ExePack utilise automatiquement enter_ghost_space, donc tu ne devras pas te préoccuper de cela si tu l'utilises.
[edit]Edité par Kevin Kofler le 17-09-2001 à 20:43:06[/edit]

Euh... en utilisant par exemple mainttstart("gamesfalldown") qui est un jeu non compresse, il y a un plantage en quittant le jeu
A quoi est-ce lie ? Je croyais que ttstart pouvait servir de lanceur non ?

Ah oui deux choses, relativement importante :
- le fait de lancer certains ppg depuis cette technique dans mon explorer (en simulant l'utilisation de la ligne de commande) fait planter avec certains progs comme platcode.ppg ou oth2data.ppg (phoenix et othello2), de quoi cela peut-il venir ? En debuggant je ne vois absolument pas d'ou vient le pb
- apres l'execution d'un programme, en utilisant tjrs la meme methode de la ligne de commande, en quittant le programme reapparait dans la liste en double (que qd il est archive je crois) et le tios ne libere le handle que qd on quitte le shell... qq1 a une solution ?

1. N'utilise pas enter_ghost_space directement. C'est compliqué puisqu'il reste plein de références à des adresses qui ne se trouvent pas dans l'espace fantôme et qui deviennent protégées après enter_ghost_space. Je te conseille donc de compresser ton explorateur avec ExePack, qui s'occupe de tout pour toi.
2. N'utilise pas NG_execute pour lancer un programme! (Pour la nème fois: Ça ne marchera jamais!)
Obtiens le handle du fichier (qui doit être en RAM - s'il est archivé, il faut d'abord le copier en RAM, soit avec EM_twinSymFromExtMem, soit directement), puis:
EX_patch(HeapDeref(handle)+0x40002,HToESI(handle)+0x40000);
ASM_call(HeapDeref(handle)+0x40002);
[edit]Edité par Kevin Kofler le 18-09-2001 à 23:04:08[/edit]

Euh... NG_execute marche tres bien...