Lancement AMS/PedroM - Page 1

J'avais posté ça à l'époque : blogs/blog.php?id=400&i=19#com

Mais sans tester. Le jmp truc__0000, ça va faire qu'au relogement du loader, le programme ou la lib truc va être relogé, non ? Donc ça sera relogé sous AMS et PedroM de toute façon ? Comment faire ce que je veux ?

2 programmes (lié dans une pack archive).
Le premier qui est relogé mais tout petit. Qui va récupérer toutes les adresses et les tables qu'il va donné
au second programme, taggué read only, sans relogement, qui sera en flash.

Ce que tu me montres est le premier programme.

C'est exactement ça que je fais quand je code pour PedroM uniquement, et ça marche très bien. Mais ça passera pas sous AMS à cause du tag read-only. Comment faire alors ? Le tag va tout faire foirer, vu que PreOS le respecte également sous AMS (à ma connaissance).
Un truc crade, mais qui devrait marcher, serait de ne pas mettre le tag, puis :

- Sous AMS : kernel::LibsExec ou kernel::exec sous AMS (ça sera relogé en RAM, même si la grosse partie ne contient en fait pas de relogement)

- Sous PedroM : kernel::LibsBegin, puis kernel::LibsPtr(partie principale, fonction 0000), puis un LibsEnd, et enfin un jsr ptr0000. Le pack archive ne bougera pas en archive, ne bougera pas en RAM non plus vu que le loader sera relogé et en cours d'exécution, mais c'est crade quand même, non ?

En tout cas, ça devrait marcher comme ça ?

Non. Mieux vaut faire deux binaires différents.

Ca pourrait casser ? Et c'est lourd de faire deux binaires différents (pour les end-users (si je finis mon prog (si je release )))

L'end user de pedrom sera assez intelligent pour utiliser son programme dédié

Oui, je suis d'accord. Mais entre deux cours, pas pouvoir passer un soft à un copain parce que l'un est sous PedroM et l'autre sous AMS c'est con (oué ok remarque, ça risque pas d'arriver )

Sinon, ma méthode aurait marché ?

Non, car kernel::LibsExec ne relogera pas en ram.

Ah bon ? LibsExec ne reloge pas en RAM ? Ca foire alors s'il y a des relogements à résoudre ? Ou ça ne reloge en RAM que s'il y a des relogements ?

35-kernel::LibsExec(char *lib_name, WORD function, BYTE version, ...) (Preos only)

The parameters are pushed on the stack.
It calls the function without modifying the registers, and it pops its argument
during the call (LIB_DESCRIPTOR, function, and version).
BYTE doesn't follow the C convesion for char (Sorry). Uses macro instead.

It relocs the library, calls the function and unreallocs the library.
The parameters pushed on the stack are corrupted. If there is an error, the parameter 'lib_name' equals zero after the call.

Je cherche à comprendre, si ce n'est pas un des deux raisons que j'ai donné...

A cause du flags read only qui assure aucun relogement.

Ok, donc ça va planter lamentablement si jamais fallait en faire quand même.
La solution est donc de créer un handle en RAM sous AMS, d'y copier le code et de l'exécuter. #tripropre#

#trideuxprogrammesseraitplussimpleetprendraitmoinsdeplace#

C'est sûr

Ce que tu peux faire, c'est coder ton programme comme un programme _nostub, puis rajouter un fake stub qui ne fait que lancer le programme sans passer par le kernel: PedroM reconnaîtra le programme comme un programme kernel et le lancera directement en archive, respectant le flag readonly, AMS lancera le programme comme un programme _nostub avec la recopie en RAM automatique.

Sauf via un lanceur de programme externe. Mauvais idée.

Bah, le TICT Explorer va aussi lancer ça de la manière conventionnelle.

Oui, mais j'ai l'impression que ce n'est pas ce que PpHd veut

Si je comprends bien ce que tu as écrit dans ./14, PedroM regarde un peu mieux l'intérieur des programmes kernel-based que ne le font, par exemple, ttstart (pas du tout) et TICT-Explorer 1.40 Beta (juste pour la détection et l'affichage du fait que c'est un programme kernel-based). PedroM est donc capable de lancer des programmes kernel-based sans recopie en RAM (s'il y a le flag qui va bien), même si leur stub n'appelle pas kernel::Exec (0x34.l, il me semble), et cette capacité est perdue si on utilise ttstart et TICT-Explorer 1.40 Beta (qui recopient inconditionnellement en RAM).
J'ai bien compris ?

oui

PpHd (./12) :
#trideuxprogrammesseraitplussimpleetprendraitmoinsdeplace#

Je pense avoir trouvé la solution : kernel::LibsExec sous PedroM, et kernel::ExtractFromPack//kernel::exec sous AMS.