如果我想对 DLL 进行变基，我该怎么做呢？
这是这个问题的延续。
我正在测试 .NET DLL 是否变基，并且 NGENning 它们将为我在终端服务器上的内存中提供更多共享代码。
然而，我的计划似乎有一个缺陷，那就是我似乎无法找到一种工作方法来找出一组工作地址。
我认为我能做的如下：
- 只需构建并 NGEN 一切
- 启动程序，确保所有 DLL 均已加载
- 使用 LISTDLLS /R PROGRAMNAME 获取正在运行的实例当前正在使用的地址列表
- 的新基地址的 DLL 的地址
- 使用那些已重新映射为这些 dll UN -NGEN 一切，并从 1 开始
但是，这已经变成了 薛定谔 练习，因为显然，对某些 DLL 进行变基的行为要么会改变加载顺序，要么会改变操作系统重新定位其他 DLL 的方式。
例如，假设在初次运行后，我有一个列表，其中显示 DLL A、B 和 C 需要位于地址 1000、2000 和 3000。没有提及 DLL D、E 和 F，它们也是相同的系统。 据推测，这些是在其当前基地址加载的，否则我会认为 LISTDLLS 会告诉我这一点。
所以我改变了A、B、C的地址，重复一切，现在DLL C、D和E已经被重新定位。 A和B现在还好，E和F已经搬迁，C还在洗牌中。
我意识到这个练习有点徒劳，因为无论我在我的机器上弄清楚什么，在目标终端服务器上使用和注入的 DLL 可能会扰乱这张图片，但我认为如果我至少可以确保一些DLL 可以位于其规定的基地址，那么同一程序的多个实例之间的共享代码量将会增加。 只是说，这样就不需要“提醒”我了:)
因为我们所有 DLL 的原始基地址都是默认的，这意味着每个 DLL（可能除了第一个加载的）都被重新定位，并因此被映射对于页面文件，我认为会有高于 0 的潜在增益。
有什么建议吗？
This is a continuation of this question.
I'm in the process of testing whether rebasing the .NET DLLs, and NGENning them will provide me with more shared code in memory on terminal servers.
However, my plan seems to have a flaw, and it's that I seem unable to find a working method to figure out a working set of addresses.
What I thought I could do was as follows:
- Just build and NGEN everything
- Start the program, ensuring all the DLL's have been loaded
- Use LISTDLLS /R PROGRAMNAME to get a list of current in-use addresses for the running instance
- Use the addresses of those DLL's that was remapped as the new base-address for those dll's
- UN-NGEN everything, and start back at 1
However, this has turned into a Schrödinger exercise because the act of rebasing some DLLs apparently either change the load order or how the operating system relocates other DLLs.
For instance, let's say that after the initial run I have a list that says that DLLs A, B and C needs to be at address 1000, 2000 and 3000. There's no mention of DLL D, E and F, which are also part of the same system. Presumably these were loaded at their current baseaddress, otherwise I would assume LISTDLLS would tell me about that.
So I change the address of A, B, C, repeat everything, and now DLL C, D and E have been relocated. A and B are now OK, E and F now became relocated, and C is still being shuffled around.
I realize that this exercise is somewhat a futile one, since regardless of what I figure out on my machine, DLLs being used and injected on the target terminal server might disturb this picture but I thought that if I could at least make sure some of the DLLs could be located at their prescribed base address then the amount of shared code between multiple instances of the same program would go up. Just saying, just so that there is no need to "remind" me of that :)
Since the original base addresses of all our DLLs was the default, which meant every DLL (possibly except the first one loaded) was relocated, and thus mapped to the page file, I would think that there would be a potential gain above 0.
Any advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以使用 DUMPBIN（Visual Studio 中提供）找出 DLL 的首选加载地址和内存范围，并根据这些数字进行规划。
dumpbin /headers 会给你：
如果你根据首选加载地址进行计划，你应该没有问题。
You can find out a DLLs preferred loading address and memory ranges using DUMPBIN (comes within Visual Studio) and do your planning based on those numbers.
dumpbin /headers would give you:
If you plan according to preferred loading addresses you should have no problems.