comment décharger la dll - page 6

 
VBAG писал(а) >>

Le prototype de la fonction principale est-il correctement sélectionné ?

Comment gérer les fils ATTACH/DETACH ?

Où trouver des informations à ce sujet, de préférence avec des exemples ?

Jeffrey Richter "Windows pour les professionnels".

 
VBAG >> :

Salutations à tous !

Le sujet est devenu intéressant et j'ai décidé de vérifier le sujet discuté sur un exemple simple fourni avec le terminal (projet DLLSample).

Après avoir compilé dans VS 6.0, la dll cuite fonctionne avec le terminal avec succès, mais ne se décharge pas !


Comment savez-vous que ce n'est pas le déchargement ? Mon DLLSample fonctionne bien.

 
HideYourRichess писал(а) >>

Comment savez-vous que ce n'est pas le déchargement ? Mon DLLSample fonctionne bien.

Indirectement, le corps du fichier dll n'est pas écrasé jusqu'à ce que vous fermiez le terminal.

.

J'ai un couple de tableaux statiques déclarés au niveau global, peut-être que cela l'affecte.

.

Je veux comprendre comment accorder correctement le projet et prescrire "soigneusement" l'attachement/le détachement comme je le dis.

 
 
VBAG >> :

Salutations à tous !

Le sujet est devenu intéressant et j'ai décidé de vérifier le sujet discuté sur un exemple simple fourni avec le terminal (projet DLLSample).

Après compilation dans VS 6.0, la dll cuite fonctionne avec le terminal avec succès, mais ne se décharge pas !

Voici la fonction principale :

Et maintenant une question aux connaisseurs, qui comprennent vraiment comment la dll est et fonctionne sous Windows et savent comment la compiler correctement dans un projet sous VS 6.0 (par exemple).

Le prototype de la fonction principale est-il correct ?

Comment gérer les flux ATTACH/DETACH ?

Où puis-je trouver des informations à ce sujet, de préférence avec des exemples ?

Qu'est-ce qui est ataché ? Quel dtach ? La fonction DllMain d'une dll normale n'est pas du tout nécessaire ! Le linker l'insère dans la dll à votre place.

http://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx

/MD, /MT, /LD (Utilisation de la bibliothèque d'exécution)


/LD

Crée une DLL.

Passe l'option /DLL à l'éditeur de liens. L'éditeur de liens recherche, mais n'exige pas, une fonction DllMain. Si vous n'écrivez pas de fonction DllMain, l'éditeur de liens insère une fonction DllMain qui renvoie TRUE.

Lie le code de démarrage de la DLL.


http://msdn.microsoft.com/en-us/library/ms682583(VS.85).aspx

Fonction de rappel DllMain

Un point d'entrée facultatif dans une bibliothèque de liaison dynamique (DLL).
 
VBAG >> :

Indirectement, le corps du fichier dll n'est pas écrasé jusqu'à ce que vous fermiez le terminal.

.

Cependant, j'ai quelques tableaux statiques déclarés au niveau global, ce qui peut avoir une incidence.


Donc, vous n'avez pas réellement un échantillon DLLS, comme vous l'avez prétendu plus tôt ? c'est exact.

VBAG >> :

J'aimerais comprendre comment régler "soigneusement" le projet pour écrire attacher/détacher comme je le dis.

 
HideYourRichess писал(а) >>

Donc, vous n'avez pas réellement DLLSample, comme vous l'avez prétendu plus tôt ? c'est exact.

Eh bien, en général, oui, si vous utilisez explicitement DllMain. Et en général, tous les paramètres du projet doivent être pris dans l'échantillonneur. Megakvot recommande de prescrire DllMain explicitement, bien que si vous écrivez en Delphi vous ne pouvez pas prescrire DllMain là et mettre tous les attach/detach dans l'initialisation et la finalisation.

Sauf que j'ai ajouté deux tableaux statiques au niveau global, tout le projet est tiré de DLLSample.

J'appelle la fonction primitive dans l'EA exécuté dans le testeur. Lorsque le test est terminé, la DLL est conservée en mémoire. Voici la situation.

 
VBAG >> :

Sauf que j'ai ajouté deux tableaux statiques au niveau global, tout le projet est tiré de DLLSample.

J'appelle la fonction primitive dans l'EA exécuté dans le testeur. Lorsque le test est terminé, la DLL est conservée en mémoire. Voici la situation.

Aha, donc le problème se produit dans le testeur. Il ne s'agit ni d'un script ni d'un indicateur - c'est le conseiller expert. Comment cette EA se comporte-t-elle dans des conditions normales, et non dans le testeur ?


À propos, "deux tableaux statiques au niveau global" ne devraient en théorie pas affecter la dll de quelque manière que ce soit. Surtout si vous n'utilisez pas du tout de DLL pour y accéder.


Drôle. Il manque une partie du texte de mon message auquel vous répondiez, même si je ne l'ai pas supprimé. Le forum est défaillant.

 
HideYourRichess >> :

Aha, donc le problème se pose dans le testeur. Et ce n'est ni un script, ni un indicateur - c'est une EA. Comment cette EA se comporte-t-elle dans des conditions normales, hors test ?

En fait, j'ai eu tous ces problèmes avec la dll il y a un an aussi, quand j'avais l'EA...

J'ai comparé l'exécution de mon testeur à celle du système.

Mais... quelqu'un a réussi à rabaisser tout le monde à plusieurs reprises en parlant de mains croches et d'erreurs dans le programme.

Dieu interdit à quelqu'un d'être un tel patron :-(.

P.S. : polinked dll avec les bibliothèques runtime VC 2005 : après l'indicateur et le script

>> tout se décharge normalement.

 
jartmailru >> :

En fait, j'ai eu tous ces problèmes avec la dll il y a un an aussi, quand j'avais l'EA...

J'ai comparé l'exécution de mon testeur à celle du système.

Mais... quelqu'un a réussi à rabaisser tout le monde à plusieurs reprises en parlant de mains croches et d'erreurs dans le programme.

Dieu interdit à quelqu'un d'être un tel patron :-(.

P.S. : Je viens de polycopier la dll avec les bibliothèques d'exécution de VC 2005 : après l'indicateur et le script

tout se décharge bien.

Encore une fois, je n'ai aucun problème avec la dll où que ce soit. Si vous avez un problème, c'est votre problème de programmation, ce n'est probablement pas la faute de MS ou de MT. Et le fait que vous deviez utiliser un "ancien" VC - cela devrait être clair.

Raison: