今天写一个dll准备给.net调用, dll写出之后给用delphi测试一下, 居然出错, 更别说给.net调用了.查来查去原来是参数和返回值使用string类型, 后面看了'Delphi 编写 DLL 返回字符串，.net 调用。' 这篇文章才解决, 顺便也收藏了一下,原来delphi写的dll有这么多限制的.

这一点我们需要注意  
a. 参数和返回值为string、动态数组类型时，DLL和EXE都要把ShareMem作为.dpr工程的第一个单元引用。当然最好是不要使用 string、动态数组类型，可以改用PChar、数组指针类型，如果是混合语言编程使用的话，就一定不能用string、动态数组类型。这样做的原因是 DLL和EXE的内存管理器(MemoryManager)不是一个，而string、动态数组类型是通过引用计数由Delphi自动进行内存管理的，它 何时分配何时释放，我们不能显式的知道的，DLL分配而EXE释放的话，这样就出问题了。用ShareMem就是为了让它们统一使用一个内存管理器进行内 存分配释放。 关于DLL和EXE内存管理器不同这一点，非常重要！ 
b.DLL和EXE的VCL类体系不是一个，它们各自有一套，因此，从EXE传递过去的对象，要在DLL中用is判断类型和as作类型转换，那都不能得到期望的结果。 如果是bpl，就不会有这个问题  
c.DLL中应用ADO、窗体(模态、非模态、MDI子窗体)、线程等的一些相关问题与今天的主题关系不大，就不作多讲了。参考DLL的详细论述请参考《Windows核心编程》第19、20章。

========================================================

对使用Delphi制作DLL复用文件的建议

在公司里有一些需要制作DLL的场合，因为熟悉、方便和简易，大多数使用Delphi来制作。现在就这个主题提出一些个人建议。

尽 量使用标准DLL接口。指的是传递的参数类型及函数返回类型不能是Delphi特有的，比如string（AnsiString），以及动态数组和含有这 些类型成员的复合类型（如记录），也不能是包含有这些类型成员数据成员的对象类型，以避免可能的错误。如果使用了string类型或动态数组类型，且调用 方不是Delphi程序，则基本上会报错。如果调用方是Delphi但调用方或被调用方没有在工程文件的第一包含单元不是ShareMem，也可能会出 错。

如果调用方是Delphi应用程序，则可能可以使用不包含禁止类型（string, 动态数组）数据成员的对象作为参数或返回值，但也应尽量避免。

如果调用方与被调用方都是Delphi程序，而且要使用string或动态数组作参数，则双方工程文件的第一包含单元必须是ShareMem。（C++Builder程序的情况可能与此相同，不过没有测试过。）

如果调用方不是Delphi程序，则string、动态数组、包含string或动态数组的复合数据类型及类实例，都不能作为参数及返回值。

因此，为了提高DLL的复用范围，避免可能存在的错误，应当使用标准WIN32 API标准参数类型，以前使用string的变量，可以使用PChar(s)转换。动态数组则转换为指针类型（@array[0]），并加上数组的长度。

如果因为调用方与被调用方都是Delphi程序，为了编写方便，不想进行上述转换，则推荐使用运行时包的形式。运行时包可以保证动态分配数据的正确释放。这样因为其扩展名（.bpl），显出该文件仅限于Delphi/C++Builder使用（不象DLL）。

其 次，尽量避免使用overload的函数/过程作输出，如果同一操作有多个方式，则可以让函数/过程名有少许差别，类似于Delphi中的 FormatXXXX、CreateXXXX等函数及方法，如CreateByDefaultFile, CreateDefault。

最 后，作为DLL的提供者，应当提供直接编程的接口文件，如Delphi中的.pas或.dcu（最好是.pas，因为可以有注释）、C及C++中的.h 和.lib。而不是让使用者们自己创建。如果非要有overload的函数/过程，这一点显得特别重要。另外，作为Delphi应用，提供的.pas文件 可以是提前连接的（使用external指定DLL中的输出函数），也可以是后期连接的（使用LoadLibrary、 GetProcAddress），DLL提供者提供编程接口文件，既显得正式（或HiQoS），又有保障。