library dynamique - Page 1

qqn pourrai me donner un source comprenant un prog utilisant une lib dynamique avec le fichier header de la lib?
(j 'ai deja regarder le tuto de squale mais j'ai tjs un pb).

Tu as une version récente de TIGCC ?

Tu regardes FAT de Thomas Nussbaumer tict.ticalc.org .

je croyais que les souces de la lib n'étaient pas fournies...

Euh ... il veut sans doute faire une librairie destinée au mode _stub ...
Sinon ca m'étonnerait qu'il réussisse ...

Je ne comprends pas tres bien la question.
Sinon tu as genclib comme exemple.

une lib en nostub... c cho...
et fo un header énorme, je crois, pr le relogement

la tict a réussis, non ?

Pour une lib dynamique simple , tu fais :

Les noms de tes fonctions exportees doivent suivre une certaine nomemclature : NOM, deux '_' et une chaine hexa de 4 lettres '0000'
Ex:

int namelib__0000(int x, int y);
int namelib__0001(int x, int y);
int namelib__0002(int x, int y);
int namelib__0003(int x, int y);
int namelib__0004(int x, int y);
int namelib__0005(int x, int y);

Voila.

je parlais d'une lib en C mode "doors". (mais le mode nostub m interresse aussi!!!)
je regarder le chap 23 du tuto de squale mais je n'arrive pas a compiler mon prog g un probleme au niveau du header. sinon pour ecrire la lib g pas de pb. G essayé avc la version 0.92 de tigcc (g la fleme de mettre la 0.93 meme si je les deja dl).
si ca marche tjs pas je ferai ma lib en ASM tant pis
(et je serais tjs pas comment on fait en C)

oui, la TICT a réussi !
FAT engine, tu crois que c quoi ?

sinon, dnas une vieille version de la TTsuite, y'a un exemple
(mais TN le met plus maintenant)

Il a dit en mode Doors !
Et c'est ce que j'ai vaguement explique

lol faire une lib. en _nostub c'est pas à la portée du premier venu

>je regarder le chap 23 du tuto de squale mais je n'arrive pas a compiler mon prog g un probleme au niveau du header. sinon pour ecrire la lib g pas de pb. G essayé avc la version 0.92 de tigcc (g la fleme de mettre la 0.93 meme si je les deja dl).

En effet, il faut la version 0.93. Il y avait des bogues dans la version de obj2ti livrée avec TIGCC 0.92. Il y en a toujours un qui sera probablement corrigé dans la prochaine mise à jour de TIGCC (j'ai déjà envoyé le patch à Sebastian Reichelt): le stub des librairies n'est pas le bon, donc ça plante quand quelqu'un essaye d'exécuter une librairie compilée avec TIGCC directement.

Y'a pas de stub dans une librairie !

>Y'a pas de stub dans une librairie !

Et comment on peut savoir ça nous ?
J'ai trouvé ça dans les sources les Link je crois, alors qui croire ?

char progstub[] = {
  0x4A,0x78,0x00,0x30,0x66,0x04,0x58,0x8F,
  0x4E,0x75,0x20,0x78,0x00,0x34,0x4E,0xD0};

char libstub[] = {
  0x48,0xE7,0xFF,0xFE,0x48,0x7A,0x00,0x1A,
  0x28,0x78,0x00,0xC8,0xD9,0xFC,0x00,0x00,
  0x03,0x98,0x28,0x54,0x4E,0x94,0x58,0x8F,
  0x4C,0xDF,0x7F,0xFF,0x58,0x8F,0x4E,0x75,
  0x4C,0x69,0x62,0x72,0x61,0x72,0x69,0x65,
  0x73,0x20,0x61,0x72,0x65,0x20,0x6E,0x6F,
  0x74,0x20,0x65,0x78,0x65,0x63,0x75,0x74,
  0x61,0x62,0x6C,0x65,0x00,0x00};

Que Xavier est un idiot d'avoir mis ce stub a la con qui ne fait qu'augmenter la taille de la lib pour des prunes qui ne servent a rien !

Il y a un stub dans un linker écrit proprement!
Obj2ti (enfin, la version corrigée qui va sortir bientôt - JM avait mis par erreur ProgStub au lieu de LibStub et il y a donc dans les toutes versions sorties le stub des programmes normaux même dans les librairies) met un stub qui écrit Libraries are not executable. si quelqu'un essaye d'exécuter une librairie.
Ce n'est pas intelligent du tout de faire des programmes qui quittent sans rien dire si on les exécute. C'est beaucoup plus clair s'ils donnent un message d'erreur approprié.
D'ailleurs, si vous voulez la version corrigée de Obj2ti dès maintenant, mailez-moi.

Je suis contre ! C'est une perte de place. Pour quelqu'un qui prone l'optimisation de place, je trouve que c'est rellement stupide.
Dans le pire ca, on fait un mistub avec son message d'erreur.

Et Nitro, pour des stubs propres, regarde les sources de obj2ti. Le stub des programmes a aussi été amélioré par rapport à celui de Link.exe pour dire Kernel Needed. quand il n'y a pas de kernel et donc enfin mettre fin au problème des newbies qui ne comprennent pas pourquoi le programme met juste Done.

Et je suis pour l'optimisation en place, mais pas pour la suppression de fonctionnalités afin d'épargner de la place. C'est différent.
[edit]Edité par Kevin Kofler le 30-01-2002 à 17:15:35[/edit]

moi je pronne la vitesse me comme en C ou en ASM l affichage est suffisement rapid (pour ce que j en ai est a faire) ben au tant pronné la place
regarder mon aop notement pour le mode calcul g remplacer le solve pour allez + vite me ca prend baucoup de place, tout est fait pour la vitesse. (certainement mon dernier prog en basic).

C'est une idiotie stupide. (Admirez le pleonasme).

Et ceux qui veulent lancer une librairie sans savoir que c'est une librairie? Ils ne comprennent pas pourquoi ça ne marche pas s'il n'y a pas de message d'erreur.
Même chose pour ceux qui veulent lancer un programme pour kernel sans kernel.
Je pense que tous les stubs qui ne mettent pas de message d'erreur (ou carrément vides comme ton "stub" pour les librairies) n'auraient jamais dû être créés. C'est la faute non seulement de ce système contre-intuitif des kernels, mais aussi de ces stubs idiots qu'on a la question "Pourquoi le programme XY ne marche pas, mais met juste Done?" tous les 2 jours depuis longtemps.
Si déjà vous ne respectez pas le format des programmes en assembleur de AMS, mettez au moins un message qui signale que le format n'est pas respecté pour ceux qui ne peuvent pas le deviner.
[edit]Edité par Kevin Kofler le 31-01-2002 à 16:23:59[/edit]

C'est vrai que c'est un message d'erreur serait bien pratique quand on a pas installé de kernel!

Les programmes pour kernel créés avec TIGCC 0.92 ou supérieur en affichent un. Donc si vous respectez les utilisateurs (fait duquel je doûte fortement si vous programmez en mode kernel, mais bon), utilisez TIGCC (même pour l'assembleur)! Mais pour créer des librairies dynamiques, attendez la prochaine mise à jour s'il vous plaît (ou mailez-moi pour avoir une version mise à jour de Obj2ti dès maintenant) à cause du bogue signalé dans le message 14.
[edit]Edité par Kevin Kofler le 31-01-2002 à 16:37:02[/edit]

Kevin> Je n'estime pas que coder en Kernel soit une marque de non respect envers les utilisateurs bien que je code en Nostub.

ET moi j'estime que c'est ultra-idiot. Un point c'est tout. Il ya des readme a lire !

C'est utra idiot mais s'est quand même mieux d'avoir un message d'erreur

Non, ca sert a rien. Si ca marche pas, tu vas lire les readme !

Le problème c'est que dans la majorité des cas, un gars qui n'est pas un nb passe le prog à un copain par link, qui le passe à un autre, et l'"utilisateur final" qui est un newbie suprême, sait jamais pourquoi ca marche pas
Mais bon, tout le monde ne peut pas être doué, non plus.