how to unload the dll - page 5

New comment
 
TheXpert >> :

1st question - how does the system know from which processes to unload the dll?

Question 2 - how do I find the entry point without loading the dll?


Now, essentially. The dll is loaded and unloaded during regsvr in order to register correctly. And of course this has no effect on unloading it from other processes.

Do not try to sound stupider than you are. But there is one good thing, you can read mana.

Obviously. In addition to the unloading of dll in the implementation of deinitialization of indicator (Expert Advisor), there can be anything directly related to it, which turns the unauthorized release of dll into the category of hacks, which in turn does not guarantee the correct operation of the terminal.


All in all - you will not be able to prove that you are not a dummy, good luck, keep on trying.

2All: don't think about hiring him as an admin.

А? What?

Someone who understands, please translate this into human language.

(no, I was mistaken earlier, TheExpert can't be an employee of such company as MetaQuotes, just one of my replies was deleted very quickly).

 
AlexEro >> :
Uncle hacker, there is no logic in your words: if the library is ALWAYS unloaded, why "my" FreeLibrary call according to you "will not work in many cases"? What harm could come from an extra FreeLibrary call in the deinit() block? Would calling FreeLibrary() in your opinion somehow block the release of the library or something? That's not clear, uncle kool hacker, and it's obvious.

It's not hard to understand. If the dll itself doesn't unload properly - then you have a bad hand and you made a mistake in the dll code, (and most likely in the DllMain, or masked exapses). This is the only reason, there are no others, as both Windows and Terminal are extremely loyal to the dll. Now about FreeLibrary, which MT4 developers have hidden from the naughty hands of presumptuous admins. If the dll code is correct - call of this function is unnecessary, and this incidentally can be understood from documentation for the terminal, because everything is unloaded by itself. But if the code is wrong, as in your case, FreeLibrary may cause deadlock and/ or crash the terminal. Note that FreeLibrary does not guarantee unloading in error situations. Sometimes FreeLibrary may help and sometimes the opposite may make things worse. This is a lottery, so it is not recommended to use this function in this case. It is recommended that you write a good code. Of course if you can't do that, your dll can't help you. That's true.


Actually, it's been said here many times already, maybe really stop playing the part of another forum idiot.

 
HideYourRichess >> :

This is not hard to figure out. If the dll itself is not unloaded properly, it means that you have bad hands and made a mistake in the dll code, (and most likely in the DllMain, or masked exapses). This is the only reason, there are no others, as both Windows and Terminal are extremely loyal to the dll. Now about FreeLibrary, which MT4 developers have hidden from the naughty hands of presumptuous admins. If the dll code is correct - call of this function is unnecessary, and this incidentally can be understood from documentation for the terminal, because everything is unloaded by itself. But if the code is wrong, as in your case, FreeLibrary may cause deadlock and/ or crash the terminal. Note that FreeLibrary does not guarantee unloading in error situations. Sometimes FreeLibrary may help and sometimes the opposite may make things worse. This is a lottery, so it is not recommended to use this function in this case. It is recommended that you write a good code. Of course if you can't do that, your dll can't help you. That's true.


Actually it's been said here many times already, maybe you'd better stop playing the role of a forum fool.

Uncle hacker, usually at a time like this it is customary (even in large long distance companies) to ask "what are you smoking there?", but I'll ask more politely:

Uncle hacker, have you read Mark Twain's "How I edited an agricultural newspaper"? Have you? There, the newspaper editor writes about picking rutabagas from trees without knowing what a rutabaga is.

 

Come on, it's also a cheap trick to try to "get" "authorities" like Mark Twain on your side.


Admit that you don't understand what a dll is and how it functions.


What's not to understand? Are you a bad admin and a bad dll writer?

 
HideYourRichess >> :

Come on, it's the same cheap trick, trying to "get" "authorities" like Mark Twain on your side.


Admit that you don't understand what a dll is and how it functions.


Oh, is that how it works? Yes, but uncle hacker, even Microsoft itself doesn't know that and/or doesn't know how to fix it! It's called "DLL HELL" among the pros. Haven't you heard? Here is the link from wikipedia:

https://en.wikipedia.org/wiki/Dll_hell

There's a bunch more links at the end, including some from Microsoft.

I am pleased to know, uncle, that I have virtually met someone on this forum who KNOWS how it all works and how to handle it all.

 

Dll Hell is an old well-known problem, and the ways of solving it, at user level, are well known.


But try to explain how this problem relates to the terminal?


I suspect that you have skimmed this wiki and still don't understand the problem. Just in case, let me remind you: "The essence of the problem is a conflict of DLL versions intended to support certain functions. DLL hell is an example of a bad programming concept, which, like a hidden mine, leads to a sharp increase in difficulties with the complication and improvement of the system" (I took the description from the Russian wiki, since the Russian people follow our discussion).


So, how does Dll Hell relate to the terminal? And also, how can regsvr32 or FreeLibrary help against this problem?

 
HideYourRichess >> :

Dll Hell is an old well-known problem, and the ways to solve it, at user level, are well known.


But try to explain how this problem relates to the terminal?


I have a hunch that you've glanced through this wiki and still don't understand the problem.


So how does Dll Hell relate to the terminal? And also, how can regsvr32 or FreeLibrary help against this problem?

Again, general phrases and no specifics, just snide remarks. DLL Hell is not directly related to the problem, it is only related to your statement that you know everything about DLL, that there are no problems and that everyone who is smart can avoid ANY problems with DLL through thoughtful study of some unnamed dock. I have answered the rest of the questions on the above problem, with citations and links. Unlike you.

 
AlexEro >> :

Again, general phrases and no specifics, just rancour. DLL Hell is not directly related to the problem, it refers only to your statement that you know everything about DLL, that there are no problems and that everyone who is not stupid by thoughtful study of some unnamed doku can avoid ANY problems with DLL. I've answered the rest of the questions on the above problem, with citations and links. Unlike you.

Are you offended?! Come on, take my example, I don't pay attention to your petty cheap attempts to humiliate your interlocutor.


And there really is nothing complicated about dll, if you know which rake you should not step on, especially it's simple in the implementation offered by mega quotas.


You don't want to admit that the only way to avoid problems with dll is to write this very dll competently - it's stupid. What references you need here is impossible to understand.

 

In my personal experience, there is no problem with dynamic libraries (when writing in delphi and c++). I had them immediately released after disabling the indicators that used them. Quickly disabling the indicator + replacing the dll always succeeded.

I wouldn't use FreeLibrary just because my code _doesn't_ call LoadLibrary explicitly - I'm not going to fix someone else's errors (if they are reproducible and not related to my code - it's easier to inform the developers).

I have strong doubts that this problem is a result of third party code (windows or mt) not working correctly.

 

Greetings to all!

The topic got interesting and decided to check the discussed topic on a simple example that comes with the terminal( DLLSampleproject ).

After compiling in VS 6.0, the baked dll works with the terminal successfully, but does not unload itself!

Here is the main function:

BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
  {
//----
   switch( ul_reason_for_call)
     {
      case DLL_PROCESS_ATTACH:
      case DLL_THREAD_ATTACH:
      case DLL_THREAD_DETACH:
      case DLL_PROCESS_DETACH:
         break;
     }
//----
   return(TRUE);
  }

And now a question to connoisseurs, who really understand how the dll is and works under the Windows and know how to compile it correctly in a project under VS 6.0(for example).

Is the prototype of the main function correct?

How to manage streams ATTACH/DETACH?

Where to read about it and preferably with examples?

123456789101112
New comment