我找到了各种令人讨厌的解决方案/黑客,最好的方法是让我的函数返回Pchar,然后调用同一DLL中包含的另一个函数(让我们称之为ReleaseMemory)来释放为PChar保留的内存.
无论如何,最近我发现了FastShareMem库.它说它可以完全按照我想要的方式完成调用ReleaseMemory.另一方面,FastMM似乎做同样的AS LONG,因为DLL和应用程序都使用FastMM作为内存管理器.这会立即杀死使用FastMM作为我的通用DLL的内存管理器的机会.对？
====================
FastShareMem(http://www.codexterity.com/fastsharemem.htm),Delphi 7,Windows XP 32位,Windows 7 64位
您正在混合两种不同的场景：>使用Delphi DLL的Delphi应用程序
>任何使用Delphi DLL的应用程序
在第一种情况下,除非你混合Delphi版本或做一些奇怪的事情,内存管理器是相同的,编译器也是如此.因此,有共享内存管理器的方法,然后编译器能够正确处理分配/解除分配.这就是FastMM和FastShareMem都可以工作的情况 – 而且只有这一个.
在第二种情况下,应用程序和DLL将使用不同的内存管理器,可能是非常不同的内存管理器,并且通常无法共享一个.在这种情况下,最好的方法是永远不要返回在DLL内部分配的PChar,即使你提供了一个释放函数,因为你不能确定调用语言将在以后与你的PChar一起做什么,如果调用者有机会在编译器/解释器之前调用正确的释放例程. COM在你说的方式上有所作为,但它通过自己的内存管理器强制执行内存分配/释放,因此它是安全的.您不能使用普通的DLL强制执行它,因此它不安全.
最好的方法是让调用语言通过一个足够大的缓冲区,并在那里写你的PChar.当然,您需要有一些方法告诉调用者缓冲区的大小.这就是Windows本身的工作方式,并且有很好的理由让他们做出这样的选择.