如何卸载dll - 页 5

新评论
 
TheXpert >> :

第一个问题--系统如何知道从哪个进程卸载dll？

问题2--我如何在不加载dll的情况下找到入口点？


现在，基本上是这样。该dll在regsvr期间被加载和卸载，以便正确注册。当然，这对从其他进程中卸载它也没有影响。

不要试图让自己听起来比实际情况更愚蠢。但有一个好处，你可以读取法力。

很明显。除了在执行指标（Expert Advisor）的去初始化时卸载dll外，你还可以做任何与之直接相关的事情，这就把未经授权释放dll变成了黑客，而这又不能保证终端的正确操作。


总而言之--你将无法证明你不是一个傻瓜，祝你好运，继续努力。

2所有：不要考虑雇用他做管理员。

А?什么？

谁能理解，请把这句话翻译成人类语言。

(不，我之前搞错了，TheExpert不可能是MetaQuotes这样的公司的员工，只是我的一个回复很快就被删除了）。

 
AlexEro >> :
黑客叔叔，你的话中没有逻辑：如果库总是被卸载的，为什么 "我的 "FreeLibrary调用按照你的说法 "在很多情况下都不能工作"？在deinit()块中多调用一个FreeLibrary会有什么危害？在你看来，调用FreeLibrary()会不会以某种方式阻止库的释放或其他什么？这是不对的，酷爱黑客的叔叔，这很明显。

这并不难理解。如果dll本身不能正常卸载--那么你的手气很差，你在dll代码中犯了一个错误，（很可能是在DllMain，或屏蔽的exapses）。这是唯一的原因，没有其他原因，因为Windows和终端都对dll非常忠诚。现在，关于FreeLibrary，MT4的开发者已经将其从自以为是的管理员的调皮手中隐藏起来。如果dll代码是正确的--调用这个函数是不必要的，这一点可以从终端的文档中顺便理解，因为所有东西都是自己卸载的。但如果代码是错误的，就像你的情况一样，FreeLibrary可能会导致死锁和/或终端崩溃。请注意，FreeLibrary并不保证在错误情况下的卸载。有时FreeLibrary可能有帮助，有时相反可能会使事情变得更糟。这是一个抽奖活动，所以不建议在这种情况下使用这个功能。建议你写一个好的代码。当然，如果你不能做到这一点，你的Dll也不能帮助你。这倒是真的。


其实，这里已经说过很多次了，也许真的不要再扮演另一个论坛的白痴了。

 
HideYourRichess >> :

这并不难理解。如果dll本身没有被正确卸载，这意味着你手气不好，在dll代码中犯了一个错误，（很可能是在DllMain，或屏蔽的exapses）。这是唯一的原因，没有其他原因，因为Windows和终端都对dll极为忠诚。现在，关于FreeLibrary，MT4的开发者已经将其从自以为是的管理员的调皮手中隐藏起来。如果dll代码是正确的--调用这个函数是不必要的，这一点可以从终端的文档中顺便理解，因为所有东西都是自己卸载的。但如果代码是错误的，就像你的情况一样，FreeLibrary可能会导致死锁和/或终端崩溃。请注意，FreeLibrary并不保证在错误情况下的卸载。有时FreeLibrary可能有帮助，有时相反可能会使事情变得更糟。这是一个抽奖活动，所以不建议在这种情况下使用这个功能。建议你写一个好的代码。当然，如果你不能做到这一点，你的Dll也不能帮助你。这倒是真的。


其实在这里已经讲过很多次了，也许你最好不要再扮演论坛傻瓜的角色。

黑客叔叔，通常在这种时候，按惯例（即使是大型长途公司）会问："你在那里抽什么烟？"，但我会更礼貌地问。

黑客叔叔，你读过马克-吐温的《我是如何编辑一份农业报纸的》吗？你有吗？在那里，报纸编辑写到从树上采摘芦柑，却不知道什么是芦柑。

 

来吧，试图 "让 "马克-吐温这样的 "权威人士 "站在你这边，也是一种廉价的伎俩。


承认你不了解什么是dll以及它的功能。


有什么不明白的呢？ 你是一个糟糕的管理员和一个糟糕的dll作者吗？

 
HideYourRichess >> :

来吧，这是同样的低级伎俩，试图 "让 "马克-吐温这样的 "权威 "站在你这边。


承认你不了解什么是dll以及它的功能。


哦，这就是它的作用吗？是的，但黑客叔叔，甚至微软自己都不知道，和/或不知道如何修复它！。这在专业人士中被称为 "DLL HELL"。你没听说吗？以下是维基百科的链接。

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

最后还有一堆链接，包括一些来自微软的链接。

我很高兴知道，叔叔，我在这个论坛上几乎遇到了一个人，他知道这一切是如何进行的，如何处理这一切。

 

Dll地狱是一个众所周知的老问题，在用户层面，解决它的方法也是众所周知的。


但试着解释一下这个问题与终端的关系如何？


我怀疑你已经略过了这个维基，仍然不明白这个问题。为了以防万一，让我提醒你："问题的实质是旨在支持某些功能 的DLL版本的冲突。DLL地狱 是一个糟糕的编程概念的例子，它就像一个隐藏的地雷，随着系统的复杂化和改进而导致困难的急剧增加"（我从俄罗斯的维基上取了这个描述，因为俄罗斯人关注我们的讨论）。


那么，Dll Hell与终端有什么关系？ 还有，regsvr32或FreeLibrary如何帮助解决这个问题？

 
HideYourRichess >> :

Dll地狱是一个众所周知的老问题，在用户层面，解决它的方法也是众所周知的。


但试着解释一下这个问题与终端的关系如何？


我有一种预感，你已经浏览了这个维基，但仍然不明白这个问题。


那么，Dll Hell与终端有什么关系？ 还有，regsvr32或FreeLibrary如何帮助解决这个问题？

又是笼统的短语，没有具体内容，只是冷言冷语。DLL地狱与问题没有直接关系，它只与你的声明有关，即你知道关于DLL的一切，没有任何问题，每个聪明的人都可以通过对一些未命名的码头的深思熟虑的研究来避免DLL的任何问题。我已经回答了关于上述问题的其余问题，并附有引证和链接。不像你。

 
AlexEro >> :

又是笼统的短语，没有具体内容，只是愤愤不平。DLL地狱与问题没有直接关系，它只是指你说你对DLL了如指掌，没有任何问题，每个人只要不傻，通过对一些不知名的Doku的深思熟虑的研究，就可以避免DLL的任何问题。我已经回答了关于上述问题的其余问题，并附有引证和链接。不像你。

你被冒犯了吗？来吧，以我为例，我不注意你羞辱对话者的小气的廉价企图。


而且真的没有什么复杂的事情，如果你知道你不应该踩到哪个耙子，特别是在巨型配额提供的实施中，它很简单。


你不想承认，避免dll出现问题的唯一方法是把这个非常dll写得称职--这很愚蠢。你在这里需要什么参考资料，是无法理解的。

 

根据我的个人经验，使用动态库是没有问题的（当用Delphi和C++编写时）。我在禁用了使用它们的指标后，让它们立即释放。快速禁用指标+替换dll总是成功的。

我不会因为我的代码_没有明确地调用LoadLibrary而使用FreeLibrary--我不会去修复别人的错误（如果它们是可重复的，并且与我的代码无关--通知开发者更容易）。

我非常怀疑这个问题是由第三方代码（windows或mt）不能正常工作的结果。

 

向大家问好!

这个话题变得很有趣，并决定在终端附带的一个简单的例子（ DLLSample项目）上检查讨论的话题。

在VS 6.0中编译后，烘烤过的dll在终端上成功工作，但却不能自行卸载！为什么？

这里是主要功能。

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);
  }

现在问一下行家们，他们真正了解dll是如何在Windows下工作的，并且知道如何在VS 6.0（例如）下的项目中正确编译它。

主函数的原型是否正确？

如何管理ATTACH/DETACH流？

在哪里可以读到这方面的资料，最好是有实例的？

123456789101112
新评论