Publié : mer. 12/nov./2008 15:59
Progi1984,
en regardant le code, je viens seulement de percuter, j'ai vu que toutes les fonctions et le reste était dans le même fichier asm. Ca ne doit pas être comme ça pour une lib.
Il y a quelques années, PB ne supportait pas des fichiers asm séparés pour les fonctions. Aujourd'hui oui, car avant même si on utilisait pas toutes les fonctions, elles se retrouvaient toutes dans le fichier exe.
Avant de demander à Fred, tu devrais séparer les commandes comme ceci.
4 fichiers asm, un par commande public (3) et un pour la commande privée, nommes les avec le nom de la fonction, c'est plus pratique (pour le code suivant c'est FunctionTest.asm
le suivant FunctionBis.asm
Je te laisse faire le troisième.
Au début tu donnes le format (format ELF sous linux et format MS COFF sous Windows)
Tu déclares ensuite en public le nom de la fonction avec la règle PB_
Puis tu mets le code de la procedure, tu ne prends vraiment que la fonction qui commence par le mot macro et qui se termine par }
Pour la procedure privée, celle qui ne sera pas connue de l'extérieur, tu la déclares dans le fichier descripteur, tu fais un fichier asm comme ceux ci-dessus sauf que tu ne mets pas de ligne Public suivit du nom de la fonction justement pour qu'elle soit encapsulée dans ta librairie.
Il faut comprendre que cette procedure "privée" sera certainement appelée par une au moins des autres procedures public voire par une procedure privé de cette même librairie.
Pour qu'elle soit reconnue par exemple dans la procedure FunctionTes, il faut qu'elle soit déclarée dans le fichier asm de la fonction FunctionTes comme une commande externe avec le mot extrn
car PB la nommée _Procedure4, ton Tailbite devra la reconnaître et générer la ligne extrn _Procedure4 pour chaque commande qui l'utilise.
Il faut créer un fichier d'initialisation, qui initialise les chaines même si aucune commande ne l'utilise, ça ne mange pas de pain
voilà par exemple le fichier généré par Tailbite dans un exemple que j'ai fait
La fonction d'initialisation est public, elle est déclarée dans le desc en Init fonction
Tailbite génère un code "shared", c'est la section data, les déclarations et les macro du début utilisées par PB. Regarde sous windows comme c'est fait.
Il reste enfin le cas des variables globales, elle sont situées dans la section data lorsque l'on fait sa propre librairie. Dans le cas d'un tailbite, elles se retrouve dans le fichier shared car elles sont en datasection mais elle ne seront pas utilisable dans le code PB utilisant la lib.
Avance doucement, recompile et on regarde ensemble ou ça coince.
en regardant le code, je viens seulement de percuter, j'ai vu que toutes les fonctions et le reste était dans le même fichier asm. Ca ne doit pas être comme ça pour une lib.
Il y a quelques années, PB ne supportait pas des fichiers asm séparés pour les fonctions. Aujourd'hui oui, car avant même si on utilisait pas toutes les fonctions, elles se retrouvaient toutes dans le fichier exe.
Avant de demander à Fred, tu devrais séparer les commandes comme ceci.
4 fichiers asm, un par commande public (3) et un pour la commande privée, nommes les avec le nom de la fonction, c'est plus pratique (pour le code suivant c'est FunctionTest.asm
Code : Tout sélectionner
format ELF
public PB_FunctionTest
section '.text' executable
;
macro MP0{
_Procedure0:
PB_FunctionTest:
PS0=4
; ProcedureReturn PrimParam
MOV eax,dword [esp+PS0+0]
JMP _EndProcedure1
; EndProcedure
XOR eax,eax
_EndProcedure1:
RET 4
Code : Tout sélectionner
format ELF
public PB_FunctionBis
; ProcedureDLL FunctionBis(PrimParam.l, TestSecundo.s)
macro MP2{
_Procedure2:
PB_FunctionBis:
PS2=8
XOR eax,eax
PUSH eax
MOV edx,dword [esp+PS2+4]
LEA ecx,[esp+0]
CALL SYS_FastAllocateString
; ProcedureReturn PrimParam
MOV eax,dword [esp+PS2+0]
JMP _EndProcedure3
; EndProcedure
XOR eax,eax
_EndProcedure3:
PUSH dword [esp]
CALL SYS_FreeString
ADD esp,4
RET 8
}Au début tu donnes le format (format ELF sous linux et format MS COFF sous Windows)
Tu déclares ensuite en public le nom de la fonction avec la règle PB_
Puis tu mets le code de la procedure, tu ne prends vraiment que la fonction qui commence par le mot macro et qui se termine par }
Pour la procedure privée, celle qui ne sera pas connue de l'extérieur, tu la déclares dans le fichier descripteur, tu fais un fichier asm comme ceux ci-dessus sauf que tu ne mets pas de ligne Public suivit du nom de la fonction justement pour qu'elle soit encapsulée dans ta librairie.
Il faut comprendre que cette procedure "privée" sera certainement appelée par une au moins des autres procedures public voire par une procedure privé de cette même librairie.
Pour qu'elle soit reconnue par exemple dans la procedure FunctionTes, il faut qu'elle soit déclarée dans le fichier asm de la fonction FunctionTes comme une commande externe avec le mot extrn
Code : Tout sélectionner
extrn _Procedure4Il faut créer un fichier d'initialisation, qui initialise les chaines même si aucune commande ne l'utilise, ça ne mange pas de pain
voilà par exemple le fichier généré par Tailbite dans un exemple que j'ai fait
Code : Tout sélectionner
format MS COFF
extrn _SYS_InitString@0
Public PB_essaiasm_Init
section '.text' code readable executable
PB_essaiasm_Init:
call _SYS_InitString@0
RET
Code : Tout sélectionner
essaiasm_Init
InitFunction | StdCall
Il reste enfin le cas des variables globales, elle sont situées dans la section data lorsque l'on fait sa propre librairie. Dans le cas d'un tailbite, elles se retrouve dans le fichier shared car elles sont en datasection mais elle ne seront pas utilisable dans le code PB utilisant la lib.
Avance doucement, recompile et on regarde ensemble ou ça coince.
