Articles of DLL

参数对象的成员variables的内存地址在调用dll函数时发生变化

class SomeClass { //一些成员 MemberClass one_of_the_mem_; } 我有一个函数foo( SomeClass *object )在一个DLL中,它是从一个EXE调用。 问题 one_of_the_mem_地址在调用dll调用期间发生变化。 详情 : 呼叫之前 (从EXE): '&(this).one_of_the_mem_' – `0x00e913d0` 之后 – 在dll本身: '&(this).one_of_the_mem_' – `0x00e913dc` 对象的地址保持不变。 每次只有地址移动的成员。 我想要一些关于如何解决这个问题的指针。 代码: 来自Exe的代码 stat = module-> init(this,object_a,&object_b,object_c,con_dir); 在DLL中的代码 Status_C ModuleClass( SomeClass *object, int index, Config *conf, const char* name) { _ASSERT(0); //DEBUGGING HOOK … 更新1: 我根据迈克尔的指示比较了成员的抵消,在两种情况下他们都是一样的。 更新2: […]

知道.lib是静态还是导入

我有从C代码编译的.lib文件。 我怎么知道这个独立的静态库,或只是一个导入库和DLL将在运行时需要? 有一些我丢失的dumpbin选项吗?

WinDbg Dr. Watson minidump – 需要最初为安装的版本生成的pdb / dll?

我有一个目标的应用程序崩溃mindmp文件。 我有可能重build一个版本的软件的dll / pdb文件,并正确windbg加载符号? 我的问题是,我们的pdb文件只保留主要版本(不幸)。 这是一个每天构build,我可以重build我自己,但我越来越绊倒在错误。 使用!sym嘈杂:“图像标题与内存图像标题不匹配”。 DBGENG: C:\…\XXX.dll image header does not match memory image header. DBGENG: XXX.dll – Partial symbol image load missing image info DBGHELP: Module is not fully loaded into memory. DBGHELP: Searching for symbols using debugger-provided data. DBGHELP: C:\…\XXX.pdb – mismatched pdb 注意我已经用dll编译了pdb,它们来自同一个RELEASE目录(我应该构builddebugging吗?) 这些是发布版本(因为发布版本安装在目标和崩溃)我应该以某种方式使用debugging版本DLL获取更多的符号信息?

ASLR和Windows系统DLL的非感知可执行文件?

从微软的文章 : 地址空间布局随机化(ASLR) 当系统引导时,ASLR将可执行映像移动到随机位置,使得利用代码难以可预测地运行。 对于支持ASLR的组件,它所加载的所有组件也必须支持ASLR。 例如,如果A.exe使用B.dll和C.dll,则三者都必须支持ASLR。 默认情况下,Windows Vista和更高版本将随机化系统DLL和EXE ,但由ISV创build的DLL和EXE必须select使用/ DYNAMICBASE链接器选项来支持ASLR。 我不太明白。 以WIndows上的每个进程加载基本系统DLL: NtDll.dll和kernel32.dll 。 如果有一个不知道的可执行文件,这些系统DLL会使用ASLR吗? 也就是说,在Win 7上每次系统重新启动后,它们会在这个可执行文件中加载到不同的基地址,还是像Win XP一样在系统重启之后总会加载相同的基址? 为了更清楚我的意思:我典型的虚拟程序的启动堆栈如下所示: write_cons.exe!wmain() Line 8 C++ write_cons.exe!__tmainCRTStartup() Line 583 + 0x19 bytes C write_cons.exe!wmainCRTStartup() Line 403 C > kernel32.dll!_BaseProcessStart@4() + 0x23 bytes 看看BaseProcessStart的asm,我在我的XP机器上看到: _BaseProcessStart@4: 7C817054 push 0Ch 7C817056 push 7C817080h 7C81705B call __SEH_prolog (7C8024D6h) 7C817060 and dword ptr […]

是否有一个最佳实践指南,分发Windows本地C库?

有没有人知道部署本机(没有COM,没有.NET)ANSI C Windows共享库的最佳实践指南? 我们的产品使用zlib,我们在我们的下载页面上发布与官方zlib页面不同的预构build二进制文件。 我猜测这是为了避免混合C运行时 。 官方的是使用VC ++ 6.0构build的msvcrt,VS.NET/2005/2008将使用msvcrt71 / 80/90。 我想要做的是创buildVS2005 / 8解决scheme和项目,以便为我们正确构buildzlib并将它们分发到我们现在拥有的位置。 我想仔细地做这件事,并分发一个适当的有用的包,我也可以发送给zlib的策展人包括在他们的源代码发行。 但是,find可靠的信息已经certificate很麻烦。 我有一大堆关于Win32编程的书,我在网上发现了很多文章,但是这些文章似乎都没有详细描述你真正需要发布的东西。 例如,zlib分发.exp,.lib存根和.def文件,其中fftw分发.def文件,但不分发.lib存根和.exp文件。 我想我可以把所有在那里看起来有用的东西(或者只是镜像官方的zlib),但是我想知道为什么它必须在那里以及它属于哪个目录。 是否有很好的例子来源于unix世界的维护良好的Windows发行版? 官方zlib二进制发行版(向下滚动) 我们的Windows发行版 澄清: 我们发布一个库,并提供zlib(主要)Windows用户,因为他们通常没有它可用。 我希望我们的zlib版本能够作为一般的组件使用,而不仅仅是作为我们的产品消耗的.dll。 我们是开放源代码并被广泛使用,因此我们希望使我们的整个构build环境可用,并且可以轻松地适应任何您想要使用的编译器。

非COM,非.NET DLL的正确名称?

在Windows世界里,一个好东西的正确名称是什么。 老式的C + + DLL与导出的function? 不是一个COM DLL,而不是一个.NET DLL。 我们通过调用LoadLibrary()和GetProcAddress()调用的那种DLL? 我一直称它们为“平坦的DLL”,因为调用者不能从DLL实例化对象,但是什么是正确的名字? 编辑 感谢您的答案。 只是“DLL”在技术上可能是正确的,但是在我工作的地方,每个人都假设“DLL”意味着COM,或者推着.NET,所以我需要一个术语来区分我的意思。

可执行文件加载相同的DLL已经加载的DLL

我即将开始对我的项目进行重大修改,我只是想澄清一些事情,因为我认为我的devise可能有些复杂。 我有一个可执行文件加载一个dll,让我们调用这个dll1,然后加载dll2。 该可执行文件也加载dll2。 我问的是,我有两个dll2的全局和静态成员variables的实例,第二次加载的dll2发生,或者可执行只有加载1 dll2,即使dll2是由不同的DLL加载? 我知道我应该只有一个dll2的代码在内存中的副本,这很好。 这是我感兴趣的全局和静态variables。

使用C的dll注入

嘿,即时通讯试图注入一个DLL进程,即lsass.exe获取哈希。它有点哈克,但不能帮助我的项目。 我有一个DLL注入的代码,但在Visual C ++中,它给出了错误,如.. 在TEXT(“LoadLibraryA”))))—- >>>参数const wchar与LPCSTR不兼容 在lpFuncAddr ———– >>>参数types“LPVOID”与参数types“LPTHREAD_START ROUTINE”不兼容 码: BOOL InjectDLL(DWORD dwProcessId, LPCSTR lpszDLLPath) { HANDLE hProcess, hThread; LPVOID lpBaseAddr, lpFuncAddr; DWORD dwMemSize, dwExitCode; BOOL bSuccess = FALSE; HMODULE hUserDLL; //convert char to wchar char *lpszDLLPath = "hash.dll"; size_t origsize = strlen(orig) + 1; const size_t newsize = 100; size_t convertedChars = […]

Windows&C ++:extern&__declspec(dllimport)

“extern”和“__declspec(dllimport”)有什么区别/关系? 我发现有时需要使用它们两个,有时一个就足够了。 我是对的: “extern”是用于静态链接的库, “__declspec(dllimport)”用于DLL(dynamic链接库), 两者对于它们各自的链接types实际上做相同的工作, 当您使用导入库(帮助与dll链接的小型.lib文件)时,您需要同时使用它们吗?

在Windows上__cdecl或__stdcall?

我目前正在开发Windows的C ++库,将作为DLL分发。 我的目标是最大化二进制互操作性; 更确切地说,我的DLL中的函数必须可以从多个版本的MSVC ++和MinGW编译的代码中使用,而无需重新编译DLL。 但是,我很困惑哪个调用约定是最好的, cdecl或stdcall 。 有时我会听到像“C调用约定是唯一一个保证与编译器相同的调用约定”这样的语句,这与“ 对cdecl的解释存在一些变化,特别是在如何返回值中 ”等语句形成对比。 这似乎并不阻止某些库开发人员(如libsndfile )在分发的DLL中使用C调用约定,而没有任何可见的问题。 另一方面, stdcall调用约定似乎是明确的。 据我所知,所有的Windows编译器基本上都需要遵循它,因为它是用于Win32和COM的惯例。 这是基于这样一个假设:没有Win32 / COM支持的Windows编译器不会非常有用。 在论坛上发布的很多代码片段声明函数为stdcall但我似乎无法find明确解释原因的单个post。 这里有太多相互冲突的信息,每次search都会给我不同的答案,这并不能帮助我在两者之间做出决定。 我正在寻找一个清晰的,详细的,辩论的解释,为什么我应该select一个在另一个(或为什么两个是相等的)。 请注意,这个问题不仅适用于“经典”function,而且适用于虚拟成员函数调用,因为大多数客户端代码将通过“接口”,纯虚拟类(以下描述的模式在这里和那里 )与我的DLL接口。