New technologie - Page 1

Vla j'aimerai creer une nouvelle technologie pour des librarire en mode nostub et kernel mais il me manque kelke info!
Premierement j'aimerais pouvoir compiler un fichier asm ainsi que connaitre l'offset de depart de chaque fonctions ainsi que sa taille et ainsi connaitre son pointeur!
Le but:
des qu'il ya appel d'uns fonction d'une lib elle charge en memoire juste la fonction l'execute puis la desaloue!
C'est techniqement faisable! Et on gagnerai de la ram!
Aussi certaine personne affirme que les data en read only en nostub ne marche pas!
Ben ca marche vraiment bien!!!
Enfin si kelk1 pouvais m'aider!
merci d'avance!

mastergb1 a écrit :
Vla j'aimerai creer une nouvelle technologie pour des librarire en mode nostub et kernel mais il me manque kelke info!
Premierement j'aimerais pouvoir compiler un fichier asm ainsi que connaitre l'offset de depart de chaque fonctions ainsi que sa taille et ainsi connaitre son pointeur!
Le but:
des qu'il ya appel d'uns fonction d'une lib elle charge en memoire juste la fonction l'execute puis la desaloue! C'est techniqement faisable! Et on gagnerai de la ram!

Mais c'est leeeeent...
Les librairies statiques sont bien plus rapides.

Aussi certaine personne affirme que les data en read only en nostub ne marche pas!
Ben ca marche vraiment bien!!!

Ce qui n'est pas possible en _nostub est d'utiliser une librairie dynamique au format kernel en mode _readonly. (Ou plutôt: c'est possible, mais inutilement compliqué.) Évidemment, on peut utiliser un fichier de données de type personnalisé sans problèmes. (Et c'est d'ailleurs la solution à utiliser aussi en mode kernel: il n'y a aucune raison de stocker ses données dans un fichier de type ASM!)

Oui, ça serait bien ce système. De pouvoir executer des fonctions externes en nostub, on gagnerait un peu de place ds le fichier principal pour les grosse fonction !

>Le but:
>des qu'il ya appel d'uns fonction d'une lib elle charge en memoire juste la fonction
> l'execute puis la desaloue!
Tu connais jsr kernel::LibsExec ?

Mais ça ne marche qu'en mode kernel...

et le format de la fat engine ??? c pour qui ??
sa serait pas plutot sa a importer dans les programmes Stub que les lib "dynamique" du stub vers le nostub ?

Le format de la FAT Engine, comme le format des librairies kernel d'ailleurs, ne permet pas le chargement d'une seule fonction à la fois. Il faut toujours charger la librairie entière en RAM.

En fait c'etait juste une idée!
Pour les lib de données externe j'ai creer un outils hyper pratique!
Comme ca pour kirby je fais une nostub et kernel mais les donnés sont les mêmes!
Il suffit jsute d'appeler une fonction pour obtenir les donneés enfin c'est pas mal pratique!

mastergb1 a écrit :
En fait c'etait juste une idée!
Pour les lib de données externe j'ai creer un outils hyper pratique!
Comme ca pour kirby je fais une nostub et kernel mais les donnés sont les mêmes! Il suffit jsute d'appeler une fonction pour obtenir les donneés enfin c'est pas mal pratique!

Si ce n'est pas déjà fait, tu devrais créer un fichier de type personnalisé plutôt qu'une librairie au format kernel. La raison: les fichiers de type ASM sont faits pour du code, les fichiers de type personnalisé sont faits pour des données. Donc c'est idiot de mettre des données dans un fichier de type ASM.

Je te remercie de me le rappeler mais c'est une libriarie a extension personalisé!D'ailleur elle se base sur TTHBin donc...

J'avais bien dit "Si ce n'est pas déjà fait".

Oui et non!
Elle se base sur ttHbin (transforme des données en fichier pour ti)
Mais le systeme qui ya derriere est legerement different!
Ce truc que j'ai fait n'as jamais ete realisé a ma connaissance!
En fait kevin c'est pas vraiment idiot comme idée!
Evidemment c'est lent mais si par exemple tu sais que tu n'as pas besoin de vitesse comme des menus cette methode peut s'averer interressantes!
Il suffit juste de savoir si on l'utilise beaucoup ou non:
De toute facon ce n'est pas la question!
Si tu pouvais repondre vraiment a la question ca pourrait m'aider!
Je suis sur que cette methode pourrait s'averer valable sur certain point!
Merci!

mastergb> oué, ça peut être utile, je confirme.

mastergb> le pb c que dans les menus, t'as pas besoin de vitesse, mais pas besoin de ram non plus... Là où il faudrait économiser de la mémoire, c dans le jeu, mais on a besoin de vitesse

Oui mais les systemes de menu n'on pas besoin de ram mais reside quand même dans le fichier principale!
A titre d'indication au niveau grosseur de l'executable pokered rien que pour les menu prend 10ko de l'executable!
Pour moa ca serait valable!
Donc je redemande la même chose:
j'aimerais pouvoir compiler un fichier asm ainsi que connaitre l'offset de depart de chaque fonctions ainsi que sa taille et ainsi connaitre son pointeur!
Kevin stp peut tu repondre reelement a cette question please

Tu compiles chaque fonction en un fichier .bin à part avec tigcc -outputbin (peu importe si la fonction est écrite en C ou en assembleur - chaque fonction fonctionnera comme un programme assembleur/C à part entière) et tu crées une archive de tous tes fichiers .bin avec ttarchive. Ça te permettra de lancer chaque fonction à part, en la relogeant comme il faut avec EX_patch.

mastergb> à ce moment-là, c pas une question de RAM, mais une question de mémoire archive, et donc :
1) les fonctions de chargement/déchargement sont inutiles
2) les librairies dynamiques existantes (Doors/DLL) sont bien adaptées

Compile chaque fonction dans une lib differente (toto01, toto02, toto03), et regroupe les dans un pack :
kpack toto??.89z totolib

Pour l's regroupement j'ai mon idée!
Merci!

demande à gugusg, il pourra t'aider. c un pro du relogement

Oui mais je peut me debrouiller!
ca sera compatible tinstall!