wie man die DLL entlädt - Seite 2
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
In WinAPI gibt es kein UnloadLibrary(), sondern nur FreeLibrary().
Du hast Recht :-). Mein MSDN wurde aus irgendeinem Grund nicht geladen :-).
.
Das Betriebssystem entlädt eine DLL nur bei einem Ladezählerwert von Null.
In diesem Fall ist die einzige Anwendung, die den dllku lädt, Metatrader.
In diesem Fall ist die einzige Anwendung, die den dllku lädt, Metatrader.
Verwendung einer externen Bibliothek über #import.
Wenn ich den Idnikator entlade, enthält das Terminal immer noch die DLL. Wie werde ich sie wieder los?
Schreiben Sie eine fehlerfreie DLL. Normalerweise werden DLLs von selbst entladen, es sei denn, es gibt irgendwelche Unwägbarkeiten.
Abgesehen von irgendwelchen "Hacker"-Methoden ist dies die einzige Möglichkeit.
Schreiben Sie die DLL ohne Fehler. Normalerweise entlädt sich die DLL von selbst, es sei denn, es gibt irgendwelche Unwägbarkeiten.
Nun, mein lieber Freund.
Ich habe die neueste Dll und habe ernsthaft beschlossen, dir das Gegenteil zu beweisen :-).
Ich habe herausgefunden, dass nach dem Beenden des Skripts sowie nach dem Beenden des Indikators
(durch Schließen des Fensters oder Löschen des Indikators), wird die Dll entladen...
Was die "Alphabetisierung" betrifft... DllMain gibt dummerweise immer TRUE zurück.
Aber ich erinnere mich, dass ich vor etwa einem Jahr Metatrader beenden musste, um die Dll zu ersetzen.
Betriebssystem = WinXP SP3, MT = 225
Ihr seid komisch oder so. Ich habe solche Probleme, die nicht entladen wurden, nur ein paar Mal gehabt, und es war immer auf Fehler im Code zurückzuführen. Dies ist die erste. Die zweite. Ich möchte Sie daran erinnern, dass Microsoft diesen Mechanismus des impliziten Ladens/Entladens speziell zur Vereinfachung der Handhabung von Dll erfunden hat.
Woher kommen diese seltsamen Probleme - ich weigere mich, sie zu verstehen.
Ja, und das, ich persönlich benutze DllMain nicht direkt.
Ihr seid komisch oder so. Ich hatte nur ein paar Mal solche Probleme mit etwas, das nicht entladen wurde, und das war immer auf Fehler im Code zurückzuführen.
Woher kommen diese seltsamen Probleme - ich weigere mich, sie zu verstehen.
Und ich persönlich verwende DllMain nicht direkt.
Hier ist ein Zitat von MSDN:
"Wenn das System die Funktion DllMain mit einem anderen Wert als DLL_PROCESS_ATTACH aufruft, wird der Rückgabewert ignoriert."
D.h. wenn Sie eine Dll-in entladen, ist es dem System völlig egal, was Sie dort von sich als Programmierer denken.
Es kann nicht richtig oder falsch geschrieben werden - wenn man nicht drin ist, kommt es einfach raus. Wenn möglich.
.
Aber da du dich für einen Profi hältst, kannst du wahrscheinlich Anfängern Ratschläge geben, anstatt sie zu zwicken.
Ich sehe nicht, dass Sie etwas Substantielles schreiben - entfernen Sie die dynamische Verknüpfung aus dem Projekt,
Abhängigkeiten von Laufzeitpaketen, sorgfältiger Umgang mit verknüpften Dlls, die dort natürlich nicht verwendet werden.
werden dort natürlich verwendet und arbeiten möglicherweise mit dem COM-Subsystem, wo ein einzelner Aufruf wie OleInitialize die
Dutzende von System-Dlls. Da alle diese Abhängigkeiten auf einmal geladen werden... Mit dem Start ist es einfach,
aber mit Deinitialisierung - zum Beispiel, wenn sowohl Dll als auch Metatrader dieselben Systembibliotheken verwenden -
es könnte Probleme geben - wer weiß schon, was sich hinter dem Betriebssystem verbirgt...
.
Wir sind API-Benutzer, die alle Dll-Funktionen über .h / .lib und das Laden von Bibliotheken nutzen,
höchstwahrscheinlich bei der Initialisierung der Anwendung passiert, können wir *nichts* tun.
Oder wir würden alle Bibliotheken selbst laden und alle Funktionen dynamisch von Hand verknüpfen.
Andererseits sollte bei reiner Mathematik - oder bei einigen API-Funktionen - alles in Ordnung sein.
Windows speichert jede DLL im Cache. Es ist ein sehr starker Cache.
Aufgrund der obigen Ausführungen ist dies ziemlich nah an der Realität. D.h. wenn die dll-ine die Abhängigkeiten einhängt -
Dann kann das Betriebssystem sie nicht entladen, ohne die Anwendung zu laden, die diese DLL geladen hat.
Hier ist ein Zitat von MSDN:
"Wenn das System die Funktion DllMain mit einem anderen Wert als DLL_PROCESS_ATTACH aufruft, wird der Rückgabewert ignoriert."
D.h. wenn Sie eine Dll-in entladen, ist es dem System völlig egal, was Sie als Programmierer dort von sich geben.
Es kann nicht richtig oder falsch geschrieben werden - wenn man nicht dabei ist, kommt es einfach raus. Wenn möglich.
Noch einmal für die besonders Begabten: Wenn die DLL fehlerfrei geschrieben ist, sollte alles funktionieren, wie es sollte. Es gibt keinen speziellen Mechanismus zum Entladen von Bibliotheken, die durch Late Linking geladen wurden. Ist das klar?! MQL4 bietet keinen Dienst für das explizite Laden/Entladen von Dll über Load\FreeLibrary. Ebenso gibt es keinen Zugang zu Beenden.
Aber da Sie sich für einen Profi halten, können Sie wahrscheinlich Anfängern Ratschläge geben, anstatt sie zu zwicken.
Ich sehe nicht, dass Sie etwas Substantielles schreiben - entfernen Sie die dynamische Verknüpfung aus dem Projekt,
Abhängigkeiten von Laufzeitpaketen, sorgfältiger Umgang mit verknüpften Dlls, die dort natürlich nicht verwendet werden.
werden dort natürlich verwendet und arbeiten möglicherweise mit dem COM-Subsystem, wo ein einzelner Aufruf wie OleInitialize die
Dutzende von System-Dlls. Da alle diese Abhängigkeiten auf einmal geladen werden... Mit dem Start ist es einfach,
aber mit Deinitialisierung - zum Beispiel, wenn sowohl Dll als auch Metatrader dieselben Systembibliotheken verwenden -
könnte es Probleme geben - wer weiß schon, was sich hinter dem Betriebssystem verbirgt.
Lesen Sie Richter, ich kann es nur empfehlen. Es wird deutlich, dass es bei der Arbeit mit DLLs keine Magie gibt, und dass Bibliotheken immer entladen werden, sobald sie für den aktuellen Prozessadressraum nicht mehr benötigt werden. Dieser Bedarf wird durch den Zähler bestimmt. Wenn der Zähler zum Zeitpunkt des Entladens des MMS-Programms nicht auf Null gestellt ist, bedeutet dies, dass irgendwo ein Fehler aufgetreten ist, und zwar ein grober Fehler.
Wir sind also in Wirklichkeit API-Benutzer, die alle Dll-Funktionen einbinden - normalerweise über .h / .lib und das Laden von Bibliotheken,
höchstwahrscheinlich bei der Initialisierung der Anwendung passiert, können wir *nichts* tun.
Oder wir würden alle Bibliotheken selbst laden und alle Funktionen dynamisch von Hand verknüpfen.
Andererseits sollte bei reiner Mathematik - oder bei einigen API-Funktionen - alles in Ordnung sein.
Aufgrund der obigen Ausführungen ist sie ziemlich nah an der Realität. Das heißt, wenn die dll-ine die Abhängigkeiten einhängt -
dann kann das Betriebssystem sie nicht mehr entladen, ohne die Anwendung zu entladen, die diese Dll geladen hat.
Die MT4-Entwickler haben sehr gut daran getan, den Mechanismus Load\FreeLibrary nicht in die Hände der Benutzer zu legen. Sehr richtig. Es kommt auf das Niveau der Programmierkultur der Händler an.
Und schließlich sollten Sie die Empfehlungen von Microsoft selbst lesen - dort steht schwarz auf weiß, dass es zwar möglich ist, komplexe DLL-Abhängigkeiten untereinander herzustellen, dass dies jedoch seine Grenzen hat.
Windows speichert jede DLL im Cache. >> Es wird viel gecacht.
Ich würde den Mechanismus der Zuordnung einer DLL zu einem Prozessadressraum nicht als Caching-Mechanismus bezeichnen. Es handelt sich um einen völlig eigenständigen Prozess.
Ich würde den Mechanismus der Zuordnung einer DLL zu einem Prozessadressraum nicht als Caching-Mechanismus bezeichnen. Das ist ein völlig eigenständiger Prozess.
Du bist irgendwie ein komischer Kauz. Es gibt sogar ein dllcache-Verzeichnis im Windows\system32-Verzeichnis, alle Sysadmins der Welt entladen alle dlls mit regsvr32, und Sie erzählen den Leuten hier Märchen. Auf wen zählen Sie? Hier gibt es keine Idioten.