Format de programme - Page 4

1) Non, pas forcément. Dépend de l'AMS.

2) progformat.txt dans PreOS, ou cherche sur le forum, on en a déjà parlé plus en détail:
c'est un programme avec deux entrées: une _main si y'a un kernel, une _begin si y'en a pas.
Peut surtout servir pour un shell. (En attendant on fait plus trop de shells ces temps-ci)

1) ça dépend de l'AMS et de la taille du programme.

Bon alors, quelqu'un sait comment ça se passe ?

La seule solution possible, vu que tu n'as pas de kernel, c'est qu'au début du programme kernel, il y a du code qui détecte si tu as un kernel installé et si ce n'est pas le cas, affiche ce message et quitte.

Bon, dans tous les cas, si je veux faire des opérations s'il n'y en a pas je vais devoir me faire du MiStub...

Autre question: (ENCORE !?!?! )

Je voudrais savoir si l'ExePack marche bien avec le kernel.
Je voudrais l'utiliser (ou plus précisément les ttarchive)
En théorie, ça va, mais en pratique, ttarchive + kernel 5 == ???

Y aurait-il une raison d'utiliser des Pack Archive plutôt dans ce cas-là ?
(A PART que c'est inclus dans le kernel et que c'est plus facile... )

Les Pack Archive sont le seul systeme permettant de compresser du kernel, sur a 100%. (Les autres, c'est 99.

Et....... une autre raison de l'utiliser ?
Point de vue compression, c'est plus puissant ou moins que l'ExePack ?

Ca n'a rien a voir puisque les Pack Archive n'imposent aucunemethode de compression.

Bon, disons ça autrement: shrnklib > ExePack ?

(Et pk92lib ?)

snow-tiger :
1)
Quand un programme Kernel est lancé quand il n'y a pas de Kernel, ça quitte avec "Kernel needed". Mais COMMENT ça se passe en détail ?

Cf. sources de TIGCCLIB, fichiers archive/startup/_kernel_program_header.s et archive/startup/_kernel_program_stub.s.
PS: TIGCC 0.95 affiche "Kernel required" et pas "Kernel needed".

2) On peut faire du MiStub en C ?

Non.

snow-tiger
: Je voudrais savoir si l'ExePack marche bien avec le kernel.

Oui, depuis la version 1.11 (2002-02-07) déjà.

Kevin > Je crois que PpHd, ça lui a pas bien réussi avec son CF.

Et toi, tu préfères quoi entre ttarchive et Pack Archive ?
(En regardant tous les aspects, pas seulement que les Pack Archive demandent un
kernel, on te connaît Kevin, hein.... )

snow-tiger
: Kevin > Je crois que PpHd, ça lui a pas bien réussi avec son CF.

Parce que CF utilise un gros hack (des librairies qui référencent le programme principal - vive l'encapsulation ).

Et toi, tu préfères quoi entre ttarchive et Pack Archive ?

ttpack compresse mieux dans mes tests. Tu fais ce que tu veux avec ça.

>Quand un programme Kernel est lancé quand il n'y a pas de Kernel, ça quitte avec "Kernel needed".
>Mais COMMENT ça se passe en détail ?
C'est TIGCC qui ne doit pas appliquer la definition de PpHd à la lettre. Je suppose mais je pense que tu verras le comment en desassemblant ou en passant a l'éditeur hexa.

>2) On peut faire du MiStub en C ?
A priori je dirais non, du moins pas facilement et directement.

>Sans kernel, ça donne 'ASAP or Exec string too long'...
Non ca c'est quand to execute un prog de + de 24Ko(8Ko sous AMS<2.03) sans kernel ou autre tout autre programme(shl, TICTex, launcher PPG, ...) qui enlève la protection.

A quel niveau on fait le stub ? C'est dans les headers, non ?
C'est kernel.h qui permet de faire un prog kernel.

Donc on devrait bien s'arranger à mettre du MiStub en C, en disant à l'utilisateur
de faire 2 fonctions void _main(void) et void _begin(void).

Ensuite c'est dans le header que ça va chier....

A propos de désassemblage, y'a un autre désassembleur que ttdasm ? (qui plante sur ma machine)

C'est dans le linkeur qu'il faut le faire.

Non c'est le linker de TIGCC qui fait le stub donc si tu veut changer ca faudra te plonger dans le code source du linkeur de TIGCC avec comme risque de te facher a vie avec Kevin
kernel.h ne fait qu'ajouter un hack sur le main (a enlever d'ailleurs si on a TIGCC 0.95), définir les nouveaux ROMCALL de PreOS et les appels aux librairie les plus standard(graphlib,ziplib,...)

J'ai vu pour les appels et les libs. Mais en quoi consiste ce hack en gros ?
Si c'est un ajout sur le stub, les programmes kernels en C de PpHd n'ont pas le
même format que les programmes kernel faits en ASM.

Uther :
>Quand un programme Kernel est lancé quand il n'y a pas de Kernel, ça quitte avec "Kernel needed".
>Mais COMMENT ça se passe en détail ? C'est TIGCC qui ne doit pas appliquer la definition de PpHd à la lettre.

C'est PpHd qui n'applique pas la définition de JM à la lettre!

snow-tiger
:A quel niveau on fait le stub ? C'est dans les headers, non ?

Non, c'est dans tigcc.a. Relis le message ./100 s'il te plaît.

C'est kernel.h qui permet de faire un prog kernel.

Non, pas du tout, il suffit de cocher la bonne case dans les options de projet.

Donc on devrait bien s'arranger à mettre du MiStub en C, en disant à l'utilisateurde faire 2 fonctions void _main(void) et void _begin(void).

Non. Un programme C fait avec TIGCC est soit 100% kernel, soit 100% _nostub, on ne peut pas mélanger les deux.

Uther :
Non c'est le linker de TIGCC qui fait le stub donc si tu veut changer ca faudra te plonger dans le code source du linkeur de TIGCC avec comme risque de te facher a vie avec Kevin

Les headers binaires du format kernel se trouvent dans tigcc.a, pas dans le linker.

Et ce que je ne comprends pas, c'est pourquoi tu t'obstines à vouloir faire du "mistub"... Je ne vois aucune utilisation raisonnable de ce mode.

./109 > Un shell. Mais c'est pas tout.

Est-ce qu'il est possible de faire un autre fichier .a, utilisé en lieu et place de tigcc.a, pour linker en MiStub ?
Ou TIGCC va-t-il toujours automatiquement linker tigcc.a au projet ?

>C'est PpHd qui n'applique pas la définition de JM à la lettre!
On peut la trouver ou cette definition? je crois pas l'avoir vue avec UniOS

>Les headers binaires du format kernel se trouvent dans tigcc.a, pas dans le linker.
Autant pour moi ca doit être plus facile a modifier alors

> Et ce que je ne comprends pas, c'est pourquoi tu t'obstines à vouloir faire du "mistub"... Je ne vois aucune utilisation raisonnable de ce mode.
Mais c'est son problème je pense qu'il sait pourquoi il fait ca.

tu dois pouvoir changer toi même le fichier tigcc.a vu que TIGCC est open souce

snow-tiger :
./109 > Un shell.

Très vague, et pas une justification valable. Le TICT Explorer marche très bien en _nostub pur.

Est-ce qu'il est possible de faire un autre
fichier .a, utilisé en lieu et place de tigcc.a, pour linker en MiStub ?Ou TIGCC va-t-il toujours automatiquement linker tigcc.a au projet ?

La documentation, c'est pour les chiens?
Tu peux choisir de ne pas linker avec tigcc.a. Il suffit de cocher une case. À toi de fournir toutes les fonctions indispensables qu'il y a là-dedans.

Très vague, et pas une justification valable. Le TICT Explorer marche très bien en _nostub pur.

J'ai pas d'arguments pour dire si c'est valable ou pas:
L'idée c'est un shell qui a les fonctions normales de ZIP, de KOMP, (d'acf ?) des autres shells,
les ttarchive etc.... et qui lorsqu'il est lancé avec PreOS installé, permet EN PLUS de gérer les Pack Archive
par exemple.


Bon, dans l'absolu tu vas me dire que ça non plus c'est pas valable, selon l'architecture von Neumann
je peux gérer les Pack Archive en NoStub aussi...

À toi de fournir toutes les fonctions indispensables qu'il y a là-dedans.

snow-tiger
:

Très vague, et pas une justification valable. Le TICT Explorer marche très bien en _nostub pur.

J'ai pas d'arguments pour dire si c'est valable ou pas: L'idée c'est un shell qui a les fonctions normales de ZIP

CompLib, ça te dit quelque chose?

de KOMP

Là, il n'y a même pas de librairie kernel, donc je vois mal ce que viendrait y faire le "mistub".

et qui lorsqu'il est lancé avec PreOS installé, permet EN PLUS de gérer les Pack Archive par exemple.

Ben, il suffit de lancer le pack archive comme un programme pour le gérer. PreOs s'occupe du reste. Pas besoin de faire du "mistub".

Ben, il suffit de lancer le pack archive comme un programme pour le gérer.

Hé, quand on lance le pack, ça exécute le premier prog dedans, après éventuelle décompression.
J'ai essayé en groupant flib et flib2 (comme ça on a le code de flib2 qui sert à rien et prend de la place )

Mais j'ai jamais pu gérer un Pack Archive en le lançant.

Si tu cherches un désassembleur, tu peux peut-être en prendre un on-calc

Y'en a ?
C'est quoi son nom ?

db92p a un désassembleur intégré, dissas en est un (de 4ko) -> ils désassemblent du code à la volée. Mon shell CS en a aussi un (qui est aussi capable de donner un fichier source nostub & kernel)

Intéressant