comment décharger la dll - page 2
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Il n'y a pas de UnloadLibrary() dans WinAPI, il y a FreeLibrary().
Vous avez raison :-). Mon MSDN ne s'est pas chargé pour une raison quelconque :-).
.
Le système d'exploitation ne décharge une dll que si la valeur du compteur de chargement est nulle.
Dans ce cas, la seule application qui charge le dllku est metatrader.
Dans ce cas, la seule application qui charge le dllku est Metatrader.
en utilisant une bibliothèque externe via #import.
Lorsque je décharge l'idnikator, le terminal contient toujours la dll. Comment puis-je m'en débarrasser ?
Écrivez un DLL sans erreurs. Habituellement, les dlls se déchargent toutes seules, sauf en cas d'imprévu.
En dehors de toute méthode de "hacker", c'est la seule chose possible.
Écrivez le dll sans erreurs. En général, la dll se décharge d'elle-même, sauf en cas d'imprévu.
Eh bien, mon cher ami.
J'ai la dernière Dll et j'ai sérieusement décidé de vous prouver que vous aviez tort :-).
J'ai découvert qu'après avoir quitté le script, ainsi qu'après avoir quitté l'indicateur
(en fermant la fenêtre ou en supprimant l'indicateur), la Dll est déchargée...
Quant à l'"alphabétisation"... DllMain renvoie toujours stupidement TRUE.
Mais je me souviens qu'il y a environ un an, j'ai dû quitter Metatrader pour remplacer la Dll.
OS = WinXP SP3, MT = 225
Vous êtes bizarres ou quelque chose comme ça. Je n'ai eu de tels problèmes, qui n'étaient pas déchargés, que quelques fois, et c'était toujours dû à des erreurs dans le code. C'est le premier. Le deuxième. Permettez-moi de vous rappeler que Microsoft a inventé ce mécanisme de chargement/déchargement implicite spécifiquement pour simplifier la manipulation des Dll.
D'où viennent ces problèmes étranges - je refuse de comprendre.
Oui, et que, personnellement, je n'utilise pas DllMain, directement.
Vous êtes bizarres ou quelque chose comme ça. Je n'ai eu de tels problèmes de non-déchargement que quelques fois, et c'était toujours dû à des erreurs dans le code.
D'où viennent ces problèmes étranges - je refuse de comprendre.
Et personnellement, je n'utilise pas directement DllMain.
Voici une citation de MSDN :
"Lorsque le système appelle la fonction DllMain avec une valeur autre que DLL_PROCESS_ATTACH, la valeur de retour est ignorée."
C'est-à-dire que lorsque vous déchargez un Dll-in, le système ne se soucie absolument pas de ce que vous pensez de vous en tant que programmeur à cet endroit.
Il ne peut pas être écrit correctement ou incorrectement - si vous n'êtes pas dedans, il sort tout simplement. Si possible.
.
Mais puisque vous pensez être un pro, vous pouvez probablement conseiller les débutants au lieu de les tordre...
Je ne vous vois pas écrire quoi que ce soit de substantiel - retirez la liaison dynamique du projet,
dépendances sur les paquets d'exécution, manipulez soigneusement les Dlls liées - peu susceptibles d'être utilisées ici, bien sûr.
y sont utilisés, bien sûr, et fonctionnent éventuellement avec le sous-système COM, où un simple appel comme OleInitialize peut capter
des dizaines de Dlls système. Comme toutes ces dépendances sont chargées en même temps... c'est facile avec la startup,
mais avec une désinitialisation - par exemple, si Dll et Metatrader utilisent les mêmes bibliothèques système.
il pourrait y avoir des problèmes - qui sait ce qu'il y a derrière l'OS...
.
Nous sommes des utilisateurs d'API qui accrochent toutes les fonctions Dll par le biais de .h / .lib et du chargement des bibliothèques,
se produit très probablement à l'initialisation de l'application, on ne peut rien faire.
Ou bien nous chargerions toutes les bibliothèques par nous-mêmes et lierions toutes les fonctions dynamiquement à la main.
En revanche, tout devrait bien se passer pour les mathématiques simples - ou pour certaines fonctions de l'API.
Windows met en cache toute DLL. C'est un cache très solide.
En raison de ce qui précède, il s'avère être assez proche de la réalité. C'est à dire que si la dll-ine accroche les dépendances -
Le système d'exploitation ne peut alors pas la décharger sans charger l'application qui a chargé cette DLL.
Voici une citation de MSDN :
"Lorsque le système appelle la fonction DllMain avec une valeur autre que DLL_PROCESS_ATTACH, la valeur de retour est ignorée."
C'est-à-dire que lorsque vous déchargez un Dll-in, le système ne fait absolument aucune différence avec ce que vous pensez être un programmeur à cet endroit.
Ça ne peut pas être écrit bien ou mal - si vous n'êtes pas dedans, ça sort tout seul. Si possible.
Encore une fois, pour les plus doués - si la dll est écrite sans erreurs - tout devrait fonctionner comme il se doit. Il n'y a pas de mécanisme spécial pour décharger les bibliothèques qui sont chargées par une liaison tardive. C'est clair ? ! MQL4 ne fournit aucun service lié au chargement/déchargement explicite de Dll via Load\FreeLibrary. De même, il n'y a pas d'accès à Terminer.
Mais puisque vous vous considérez comme un pro, vous pouvez probablement conseiller les débutants au lieu de les tordre...
Je ne vous vois pas écrire quoi que ce soit de substantiel - retirez la liaison dynamique du projet,
dépendances sur les paquets d'exécution, manipulez soigneusement les Dlls liées - peu susceptibles d'être utilisées ici, bien sûr.
y sont utilisés, bien sûr, et fonctionnent éventuellement avec le sous-système COM, où un simple appel comme OleInitialize peut capter
des dizaines de Dlls système. Comme toutes ces dépendances sont chargées en même temps... c'est facile avec la startup,
mais avec une désinitialisation - par exemple, si Dll et Metatrader utilisent les mêmes bibliothèques système.
il pourrait y avoir des problèmes - qui sait ce qu'il y a derrière l'OS.
Lisez Richter, je vous le recommande vivement. Il devient clair qu'il n'y a pas de magie dans le travail avec les dlls, et que les bibliothèques sont toujours déchargées dès qu'elles ne sont plus nécessaires pour l'espace d'adresse du processus en cours. Ce besoin est déterminé par le compteur. Si le compteur n'est pas remis à zéro au moment du déchargement du programme MQL, cela signifie qu'il y a eu une erreur quelque part, et une erreur grossière.
En fait, nous sommes des utilisateurs d'API qui accrochent toutes les fonctions Dll - généralement via .h / .lib et le chargement des bibliothèques,
se produit très probablement à l'initialisation de l'application, on ne peut rien faire.
Ou bien nous chargerions nous-mêmes toutes les bibliothèques et lierions toutes les fonctions dynamiquement à la main.
En revanche, tout devrait bien se passer pour les mathématiques simples - ou pour certaines fonctions de l'API.
En raison de ce qui précède, il s'avère être assez proche de la réalité. C'est-à-dire que si la dll-ine accroche les dépendances -
alors le système d'exploitation ne peut plus la décharger sans décharger l'application qui a chargé cette Dll.
Les développeurs de MT4 ont eu raison de ne pas mettre le mécanisme Load\FreeLibrary entre les mains des utilisateurs. Très juste. Tout dépend du niveau de culture de programmation des traders.
Et enfin, lisez les propres recommandations de Microsoft - il est écrit noir sur blanc que, bien qu'il soit possible de créer des dépendances complexes entre les dlls, tout cela a ses propres limites.
Windows mettra en cache toute DLL. >> Il cache beaucoup de choses.
Je n'appellerais pas le mécanisme de mappage d'une dll à un espace d'adresse de processus un mécanisme de mise en cache. Il s'agit d'un processus totalement distinct.
Je ne qualifierais pas de mécanisme de mise en cache le mécanisme de mappage des dll vers un espace d'adressage de processus. C'est un processus complètement distinct.
Vous êtes une sorte d'excentrique. Il y a même un répertoire dllcache dans le répertoire Windows\system32, tous les sysadmins du monde déchargent toutes les dlls en utilisant regsvr32, et vous racontez des fables aux gens ici. Sur qui comptez-vous ? Il n'y a pas d'idiots ici.