Vous n'êtes pas identifié.
Un tel nom de topic insinue que je vais parler de modification du contenue d' une fonction donc en gros chargement de fonction a partir de fichier externe ( des semblants de dll)
J' ai pour projet de travailler dessus pour les prochaines vacances, les idées suivantes ne seront appliquées jusque la pas par moi lol
Bon pour le moment voici mes idées:
une structure fonction:
typedef struct
{
unsigned int fonctionlenght; // La longueur mémoire de la fonction
char *typearg; // Les types des arguments de la fonction
void *code; // Le code executé de la fonction
} EXT_FUNC;
avec une fonction :
EXT_FUNC *loadfunc(char *sfl,char funcname); argument: le chemin de la librairies de fonction partagée(Shared Functions Librairie: extension officiel lol .sfl) et le nom de fonction
qui va se charger de faire une alloc mémoire, charger la fonction dans cette alloc et retourné le pointeur de fonction externe et si ça foire un pointeur nul
Une autre fonction va se charger d' initialiser un pointeur de fonctions vers le code de la fonction
void initfunc(void (*func)(void),EXT_FUNC *fonc);
J' ignore comment on fera, mais g pensé que dans un premier temps le compilo genera des Warnings pour avertir, mais il sera possible de faire ça:
char (*drawcircle)(int x,int y,int r);
EXT_FUNC *func_drawcircle;
puis lors de l' initialisation du programme:
loadfunc("L:/SHARED.SFL","drawcircle");
initfunc(drawcircle,func_drawcircle); // Warning: Mismatch type
Et lors de l' appel à cette fonction:
if ((*drawcircle)(64,32,10) == 0) blablabla...
Voila
Hors ligne
Oui c pas mal mais je vois pas l'intérêt d'avoir 2 fonctions loadfunc() et initfunc()? Pourquoi un seule ne suffirait-elle pas?
Sinon comme on l'a dit les .sdl pourraient sans doute simplement etre des .obj "déguisés"... C'est à voir
Hors ligne
1: que fait tu des instructions de saut dans la fonction ? les adresses ne seront plus valides...
2: et si la fct dans la dll appelle des autres fonctions, ou des fonctions de la librairie standard (par exemple multiplication/division de "long") ?
3: appels de fonction + lents
le premier probleme peut etre resolu (difficilement, et c pas moi qui vais m'emmerder a le faire)
le second est tres limitant, ce qui veut dire qu'on ne pourra faire que des petites fonctions (autant les inclure ds le programme, et ca veut dire aussi que memzones ou d'autres => impossible)
et enfin le troisieme... c une perte de vitesse tres minime mais c tjs embetant.
Hors ligne
Julien> pour le cas ou on voudrais associer plusieurs "prototypes" à une fonction lol
oublié de préciser, mastermage, que si déjà on arrive à faire ceci on aura déjà bien avancés!
la 1 exige quelque essais, j' en convient, et un calcul d' adresse doit avoir lieu avec une conversion
les appels de fonction dans la dll vers d' autre fonctions peut ètre résolu, mais faut voir comme c'est fait dans les dlls PC!
Le 3 est évident, c vrai.
Toute façon c'est qu' un début, mastermage, si on arrivait à charger la fonction de notre choix ça pourrait etre déjà bien non ?
Hors ligne
je pense que les points 1 et 2 sont liés, en fait c à nous de compléter le travail qui n'a pas été fait par le linker puisqu'il y a un (ou plusieurs) .obj qui n'aura (n'auront) pas été traité(s).
Il faudrait se pencher sur son mode de fonctionnement, et voir comment on pourrait faire ca... :?
Hors ligne
c'est assez difficile mais donc réalisable !!
Je vais essayer de trouver de la doc sur la génération des .obj !!
Hors ligne
Pour le problème des sauts, je pense que ca devrait aller, puisque tous les .obj sont en fait des "codes relocatables", dont les adresses commencent toujours au meme endroit (càd au debut du segment de code); c de nouveau au linker de tout coordonner pour que tous les morceaux soient bien réorganisés...
Par contre pour ce qui est des appels aux autres fonctions :?:
Hors ligne
bin pê mettre ds la struct ext_func un ptr ds lekel on mettrait les adresses des fonctions filles :?: Mais dans ce cas là faudra ajouter un argument pour les préciser ...
Hors ligne
bon je vs explique:
les dll windows fonctionnent un peu comme des programmes normaux, a cela près qu'ils sont chargés et déchargés au besoin.
-une dll peut etre utiliséé par plusieurs programmes simultanement
-il existe dans windows une fonction LoadLibrary qui charge la dll si elle n'est pas deja chargée et appelle la fonction DllMain de la Dll si cette fonction existe, ensuite il faut utiliser la fonction GetProcAdress qui retourne l'adresse de la fonction voulue, mais cette fonction n'est pas copiée dans le prog, elle reste dans la Dll
la fonction DllMain est aussi appelée au moment du déchargement de la Dll, de l'attachement ou du detachement a processus (car c le principe que plusieurs progs l'utilisent en meme temps)
oui bien sur les .obj sont relocatables (sinon en pourrait pas linker )
bon en fait c pas que je veux pas de librairies dynamiques...
en fait je pense qu'on peut s'y prendre d'un autre facon, par exemple avec des TSR... mais le gros defaut de ta methode Xthunder c que ca va etre tres difficile avec le C, mais parfaitement faisable en ASM (et meme directement sans conversion pour peu qu'on connaisse bien les possibilités de NASM)
Hors ligne
Moi j'aimerais bien faire ca en POO C++, mais bon :P
Hors ligne
lol libre a toi mais si tu utilises des classes ca va pas etre possible car la maniere d'appeler les fonctions n'est pas la meme...
ca ne marchera qu'avec des fonctions globales qui n'existent pas en differentes version (cad: pas plusieurs configurations pour les parametres) et il faudra utiliser donc la convention d'appel "cdecl"
Hors ligne
Arf oui c vrai que pour les fonctions surchargées, il va y avoir un souci... :?
J'avais vu que l'appel de fonctions ne se faisait pas de la meme facon pour les classes, mais je v essayer de regarder comment ca marche (si je ne me trompe pas, les adresses des fonctions membres se trouvent qq part dans les données de chaque instance, ne pourrait-on pas les bidouiller un peu :?: )
Hors ligne
alors pour les fonctions dans les classes, ca peut dependre du compilateur, mais il y a un argument supplémentaire: this
et les adresses des fonctions membres ne se trouvent pas dans les données de chaque instance (faut pas etre fou, si tu as 50 instances de la classe sprite dont les donnees prennent 32 octets, et que tu as 10 methodes pour cette classe, ca rajouterais 20 octets aux données !), en fait une fois compilé les données sont separees des fonctions, on peut comparer ca (de tres loin) a des fonctions agissant sur des structures.
Je ne me suis jamais vraiment penché sur l'appel des fonctions en C++.
en fait ca parce qu'un jour g voulu faire une DLL en C++ appelee par un prog en C et j'y arrivait pas parce que les compilateurs ajoutent une decoration au nom de fonction C++ et g desassembler ma DLL et g vu comment ca fonctionnait en details
Hors ligne
8O
Mastermage = dieu
Hors ligne
Salut
Voila, en gros, ce qui fonctionne :
- DLL_inst.exe installe une fonction DrawM21Bitmap(memory_zone *memz, ushort segm) qui permet d'afficher une bitmap avec masque a l'ecran. La fonction est installée dans une memzone "DLL_func".
- SW appelle et utilise cette fonx comme une fonx classique.
Il reste toujours le probleme des appels de fonctions standards (ou non) a l'interieur de la fonx.
Mais bon, ca permettrait toujours de mettre les fonctions de dessin de bitmaps et de sprites en dehors de l'exe principal...
Hors ligne