Articles of DLL

DLL和STL和静态数据(哦我的!)

好的…..我已经完成了有关相关问题的阅读,还有一些MSDN文章,以及大约一天的Googlesearch。 什么是目前的“最先进的”这个问题的答案: 我正在使用VS 2008,C ++非托pipe代码。 我有一个解决scheme文件与不lessDLL和不lessEXE。 只要我完全控制了构build环境,使得所有的部分和部分都使用相同的标志,并且使用相同的运行时库,并且没有人拥有静态链接的CRT库,那么我可以传递STL对象吗? 看来这应该是好的,但是根据你阅读的是哪篇文章,恐惧,不确定性和怀疑是很多的。 我知道模板在后台产生静态数据有各种各样的问题(每个DLL都会得到自己的副本,导致心痛),但是普通的旧STL又如何呢?

获取DLL文件的CLSID?

我想创build一个小应用程序来添加和删除registry中的用户定义的上下文菜单项。 为了做到这一点,我需要得到一个任意的DLL的CLSID,所以我可以备份以前的条目,如果它们存在之前写入新的。 虽然regsrv32设法创造了这个神奇的号码,但我没有find任何方法来自己得到这个号码。 我希望有比这更好的东西: 扫描DLL名称的registry 如果找不到,请注册,再次扫描,然后再取消注册 如果DLL已经重新命名,我可以看到问题的可能性。

尝试在Windows上运行Qt应用程序的发行版本时出错

我正在尝试构build我的应用程序的Windows版本。 该程序编译和运行良好的Qt造物主,但是当我试图独立运行它会引发以下错误: The procedure entry point _Z17qt_message_output9QtMsgTypePKc could not be located in the dynamic link library QtCore4.dll 我的应用程序文件夹中有所有必需的dll,它们与我从Qt网站下载的二进制文件一样。 这个错误令我疯狂,因为我似乎找不到任何理由。 该应用程序在Linux和MAC OS X上运行良好。

检测DLL的卸载

我有一个特殊的要求,我相信没有其他办法,那就是:检测DLL的卸载。 我search了一下,发现了一个四年的SO 。 我select了相同的解决scheme:钩免费库。 当代码进入MyFreeLibrary ,我将以同样的方式挂钩指定模块的入口点(内联钩子)。 而在MyEntryPoint ,我将首先调用原始入口点,然后检查reason参数 – 如果值等于DLL_PROCESS_DETACH ,则意味着该DLL的清理工作刚刚完成,并且将从地址空间中卸载。 在这一点上,我有机会做我的工作。 有用。 就是这样了 ? 不幸的是,它还没有完成。 一个非常重要的事情被忽视:依赖。 例如, a.dll链接对b.dll和c.dll 。 加载a.dll , b.dll和c.dll将首先被加载(被初始化)。 这是因为b.dll和c.dll在c.dll的导入表中a.dll ,它们是a.dll依赖关系。 同样,卸载a.dll ,如果引用计数减less到零, b.dll和c.dll也可能会被卸载。 我不知道有关加载程序如何发现DLL的依赖关系并将其卸载的详细信息, FreeLibrary的MSDN页面没有提到这一点,我很高兴明白这一点,但是我没有find信息。 所以主要的问题是如何检测卸载DLL模块的依赖关系。 我想有同样的机会去做我的工作。 一个可能的解决scheme可能是导入表,从它的导入表中找出一个DLL的依赖关系,并从它们的导入表中找出依赖关系的依赖关系,找出所有依赖关系,钩住所有入口点,不知道,这听起来很疯狂,我需要一些build议。

如何在C ++中获取DLL文件的版本信息

我需要获取我在Visual Studio 2008 C ++中创build的DLL文件的版本信息。 我如何得到它?

有一个相当于-rpath连接器标志的Windows / MSVC?

在Linux / GCC上,我可以使用-rpath标志来更改共享库的可执行文件searchpath,而不用使用环境variables。 这也可以在Windows上完成吗? 据我所知,dll总是在可执行文件的目录和PATH中search。 我的场景:我想根据它们的属性(32 / 64bit / Debug / Release)将共享库放入位置,而不必考虑唯一的名称。 在Linux上,这很容易通过rpath完成,但我还没有find任何方式在Windows上做这个。 感谢任何提示!

Windowspath在带有清单的LoadLibrary中search

如果你没有path调用LoadLibrary (例如, LoadLibrary("whatever.dll") ,Windows通常会遵循其标准的searchalgorithm,它是用来findEXE的。 我的问题是这样的:假设一个应用程序清单指定了一个特定版本的系统DLL,比如comctl32.dll 6.0。 在这种情况下, LoadLibrary("comctl32.dll")会立即转到正确的并排文件夹,还是执行某种search?

MinGW / gcc:应用程序无法正确启动(0xc000007b)

我一直在使用MinGW和GNU Fortran编译器来编译Windows上的Fortran程序,这一直是一个成功的方法。 不过,我过去4天得到以下错误: The application was unable to start correctly (0xc000007b). Click OK to close the application. 错误只发生在我自己编写的应用程序上,而且我使用MinGW / gfortran组合编译。 当使用Visual Studio和iFort进行编译时,运行应用程序没有任何问题。 错误似乎是追溯的:尽pipe我没有重新编译它们,但很久以前使用gfortran编译并且完全运行的应用程序也崩溃了。 这使我认为这是一个dynamic的图书馆问题。 在线search表明,这可能是64位DLL和32位应用程序之间的兼容性问题 我正在使用Windows 7.在开始解决问题之前,我记得最近做的一件事是尝试更新MinGW; 我使用了mingw-get update和mingw-get升级命令行。 在网上浏览后,我尝试了以下修复: – 重新安装了Visual C ++运行时环境 – 重新安装.NET框架 – 下载并replace了一堆.dll像mscvr100.dll,mscvr100d.dll等… – 卸载并重新安装MinGW,以确保我有最新的gcc版本 – 在一个简单的应用程序(“Hello World!”types程序)上运行Dependency Walker 依赖Walker告诉我,找不到一些.dlls(完整列表:API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL,API-MS-WIN-CORE-WINRT-ERROR-L1-1 -0.DLL,API-MS-WIN-CORE-WINRT-L1-1-0.DLL,API-MS-WIN-CORE- WINRT- ROBUFFER-L1-1-0.DLL,API-MS-WIN-CORE -WINRT-STRING-L1-1-0.DLL,API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL,DCOMP.DLL,GPSVC.DLL,IESHIMS.DLL)。 它也用红色突出显示了libquadmath-0.dll(libgfortran-3.dll似乎依赖于这些文件)。 的确,libquadmath-0.dll似乎是一个32位程序中间的64位DLL。 当用Dependency Walker打开.dll时,我可以看到这个库中的所有模块都是x86,除了库本身是x64(DW的CPU列)。 我不完全确定这是可能的/如何解决这个问题。 该库在Python […]

如何告诉MinGW链接器不要导出所有符号?

我正在使用MinGW工具链构buildWindowsdynamic库。 要build立这个库,我静态地链接到其他2提供了一个API,我有一个.def文件,我写了唯一的符号,我想在我的图书馆出口。 问题是GCC正在导出所有的符号,包括我链接的库中的符号。 是否有告诉链接器只是导出def文件中的符号? 我知道有选项–export-all-symbols但似乎没有相反的意思。 现在构build脚本的最后一行有这样的结构: g++ -shared CXXFLAGS DEFINES INCLUDES -o library.dll library.cpp DEF_FILE \ OBJECT_FILES LIBS -Wl,–enable-stdcall-fixup 编辑:在关于链接器的文档中 ,它表示–export-all-symbols是默认行为,当你不提供def文件时,如果你不提供def文件,它将被禁用。 无论如何,第三方库中的符号都被导出。 编辑:添加选项–exclude-libs LIBS或–exclude-symbols SYMBOLS不会阻止导出库中的符号。

delphi链接到Windows DLL静态或dynamic

我知道,在加载时隐式链接到库可能会导致性能提高,因此我想知道是否是在编译时以这种方式链接的良好做法,从而增加可执行文件的大小(承认这只是边际)在运行时。 我的问题是,当与位于System32中的Microsoft Windows dll文件链接时,在加载时是否“更好”链接,因为您可以确定这些库将存在或遵循显式方法? 使用的语言是delphi(帕斯卡)和有问题的库是WTsAPI32.dll – terminal服务。 编辑:正如所指出的 – 我select的语言是不正确的,并已被修改。 另外,由于Unix中只有每个库都有广泛的链接,所以我可以省略关于可执行文件大小的评论,我相信当时我实际上是指静态链接,把库代码捆绑到可执行文件中,现在我意识到这一点使用dll文件(DUH!)是不可能的。 谢谢大家。