how to unload the dll - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
There is no UnloadLibrary() in WinAPI, there is FreeLibrary().
You're right :-). My MSDN didn't load for some reason :-).
.
OS unloads any dll only at zero load counter value.
In this case the only application that loads the dllku is metatrader.
In this case, the only application that loads the dllku is Metatrader.
using an external library via #import.
When I unload the idnikator, the terminal still holds the dll. how do I get rid of it?
Write a dll without errors. Usually dlls are unloaded by themselves, unless there are any contingencies.
Apart from any "hacker" methods, this is the only thing possible.
Write the dll without errors. Usually the dll will unload itself unless there are any contingencies.
Well, my dear fellow.
I've got the latest Dll and seriously decided to prove you wrong :-).
I found out that after exiting the script, as well as after exiting the indicator
(by closing the window or deleting the indicator), the Dll is unloaded...
As for "literacy"... DllMain always stupidly returns TRUE.
But I remember about a year ago I had to exit Metatrader to replace the Dll.
OS = WinXP SP3, MT = 225
You guys are weird or something. I have only had such problems, which were not unloaded, a few times, and it was always due to errors in the code. This is the first one. The second one. Let me remind you that Microsoft invented this mechanism of implicit loading/unloading specifically to simplify the handling of Dll.
Where do you get these strange problems from - I refuse to understand.
Yes, and that, I personally do not use DllMain, directly.
You guys are weird or something. I have only had such problems with something not unloaded a few times, and it was always due to errors in the code.
Where do you get these strange problems from - I refuse to understand.
And I personally don't use DllMain directly.
Here's a quote from MSDN:
"When the system calls the DllMain function with any value other than DLL_PROCESS_ATTACH, the return value is ignored."
I.e. when you unload a Dll-in, the system absolutely doesn't care what you think of yourself as a programmer there.
It can not be written correctly or incorrectly - if you're not in it, it just gets out. If possible.
.
But since you think you're a pro, you can probably advise beginners instead of tweaking-
I don't see you writing anything of substance - remove dynamic linking from the project,
dependencies on runtime-packages, carefully handle linked Dlls-unlikely to be used there, of course.
are used there, of course, and possibly work with the COM subsystem, where a single call like OleInitialize can pick up
dozens of system Dlls. Since all these dependencies are loaded at once... it's easy with startup,
but with deinitialization - for example, if both Dll and Metatrader hook up the same system libraries -
there could be problems - who knows what's in the back of the OS...
.
We are API users who hook all the Dll functions through .h / .lib and the loading of libraries,
most likely happens at application initialization, there's *nothing* we can do.
Or we would load all the libraries by ourselves and link all the functions dynamically by hand.
On the other hand, everything should be fine on bare maths - or on some API functions.
Windows caches any DLL. It is very strong cache.
Due to the above, it turns out to be pretty close to reality. I.e. if the dll-ine hooks up the dependencies -
Then operating system can't unload it without loading application which loaded this DLL.
Here's a quote from MSDN:
"When the system calls the DllMain function with any value other than DLL_PROCESS_ATTACH, the return value is ignored."
I.e. when you unload a Dll-in, the system makes absolutely no difference what you think of yourself as a programmer there.
It can't be written right or wrong-if you're not in it, it just gets out. If possible.
Once again, for the especially gifted - if the dll is written without errors - everything should work as it should. There is no special mechanism for unloading libraries that are loaded by late linking. Is it clear?! MQL4 doesn't provide any service related to explicitly loading/unloading Dll via Load\FreeLibrary. Similarly, there is no access to Terminate.
But since you consider yourself a pro, you can probably advise beginners instead of tweaking-
I don't see you writing anything of substance - remove dynamic linking from the project,
dependencies on runtime-packages, carefully handle linked Dlls-unlikely to be used there, of course.
are used there, of course, and possibly work with the COM subsystem, where a single call like OleInitialize can pick up
dozens of system Dlls. Since all these dependencies are loaded at once... it's easy with startup,
but with deinitialization - for example, if both Dll and Metatrader hook up the same system libraries -
there could be problems - who knows what's in the back of the OS.
Read Richter, I highly recommend it. It becomes clear that there is no magic in working with dlls, and libraries are always unloaded as soon as they are no longer needed for the current process address space. This need is determined by the counter. If the counter is not zeroed to the moment of unloading MQL-program it means that somewhere there was an error, and rough error.
So in fact we are API users hooking all Dll functions - usually via .h / .lib and the loading of libraries,
most likely happens at application initialization, there's *nothing* we can do.
Or we would load all the libraries ourselves and link all the functions dynamically by hand.
On the other hand, everything should be fine on bare maths - or on some API functions.
Due to the above, it turns out to be pretty close to reality. That is, if the dll-ine hooks up the dependencies -
then the operating system can't unload it anymore without unloading the application which loaded this Dll.
The MT4 developers were very right not to put the Load\FreeLibrary mechanism in the hands of users. Very right. It's all about the level of traders' programming culture.
And lastly, read Microsoft's own recommendations - it is black and white stated there that although it is possible to make complex dll dependencies between each other - all this has its limitations.
Windows will cache any DLL. >> It caches a lot.
I would not call the mechanism of mapping a dll to a process address space a caching mechanism. It is a completely separate process.
I would not call the dll mapping mechanism to a process address space a caching mechanism. It's a completely separate process.
You're kind of an oddball. There's even a dllcache directory in the Windows\system32 directory, all the sysadmins in the world unload all the dlls using regsvr32, and you're telling fables to people here. Who are you counting on? There are no idiots here.