绕过第 3 方循环 dll 依赖项？
我正在尝试访问第三方应用程序中 TE 编辑（来自 ter32.dll）中的文本。 （关于此的第一篇文章此处）我浏览了< a href="http://www.subsystems.com/tewf_api.htm" rel="nofollow noreferrer">API 并尝试动态加载 dll 以访问函数。不幸的是，ter32.dll 的这个（售后返工）有大量依赖项。我尝试根据需要动态加载每个所需的 dll，但遇到了循环依赖。 ter32.dll 需要 x。 x 需要 y。 y 不会加载，因为它需要 x。我是否必须延迟静态加载这些？我当然希望不会，因为我不希望我的应用程序中出现开销/膨胀/依赖性。
1）我错过了什么？
2）有什么办法可以解决这个问题吗？
3）是否有人有任何其他方式来访问 ter32.dll 的 TE 编辑中的文本？
I am attempting to access text in a TE Edit (from ter32.dll) in a 3rd party application. (first post on this here) I looked through the API and tried to dynamically load the dll in order to access a function. Unfortunately, this (aftermarket rework) of ter32.dll has a load of dependencies. I tried dynamically loading each required dll as needed but ran into a cyclic dependency. ter32.dll requires x. x requires y. y won't load because it requires x. Would I have to statically load these with a delay? I sure hope not as I don't want the overhead/bloat/dependency in my application.
1) what am I missing?
2) is there some way around this?
3) does anybody have any other way of accessing the text in a TE Edit of ter32.dll?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您加载 DLL 时，加载器将为您加载所有依赖项。这些依赖项列在每个 DLL 的导入表中，加载程序会解析它们。你不需要做任何事情。
因此我不明白你是如何得出你自己需要处理 DLL 依赖项的结论的。您是否以非标准方式加载此 DLL？您是否需要 WinSxS 依赖项的清单，即是否需要 MS C 运行时？还有什么我们需要知道的吗？
总而言之，在我看来，将此 DLL 加载到进程中不太可能对从具有自己独立虚拟内存的不同进程中提取文本有很大帮助。换句话说，我非常有信心您当前提取文本的尝试将会失败。绕过虚拟内存屏障的方法是使用挂钩在其他进程中运行代码。
When you load a DLL the loader will load all the dependencies for you. These dependencies are listed in the import tables of each DLL and the loader resolves them. You don't need to do anything.
Therefore I can't understand how you came to the conclusion that you yourself needed to process DLL dependencies. Are you loading this DLL in a non-standard way? Do you need a manifest for WinSxS dependencies, i.e. if the MS C runtime is needed? Is there something else we need to know?
All that said, having this DLL loaded into your process is not likely, in my view, to help much in extracting text from a different process which has its own separate virtual memory. In other words, I am quite confident that your current attempt to extract the text will fail. The way to get around the virtual memory barrier is to run your code in the other process using a hook.