将软件的界面分离出来是开发普通桌面应用的常用方法，这样可以带来多种好处，比如方便软件的自动更新和维护（我们很少看到将一个软件的所有东西都写到一个EXE里面）。通常的办法是将业务逻辑或者核心封装在一个独立的组件中，例如COM甚至标准的DLL库。我们这里讨论普通的DLL。
在DLL中只提供普通的函数或过程肯定是不行的，面向对象的设计和开发，良好的模式应用是必不可少，这需要我们在DLL中提供外界访问其中对象的办法。例如DELPHI可以使用BPL包，或者Interface来访问DLL中的对象，Visual C++就更简单了，MFC扩展DLL甚至允许导出这个类。不过Delphi和VC在开发中各有优势，Delphi其快速开发能力非常的适合做界面，并且还有大量的第3方界面库可用，可以开发出很漂亮的界面，这一点我个人认为要比VC好很多（当然.Net托管C++例外，因为其可以直接使用.Net提供的库）；而VC的优势在于C++语言本身的灵活和高效性，非常适合做软件的核心部分（例如你还可以使用Intel C++编译器来重新编译代码，大幅度提高在Intel平台中的性能）。要是我们可以使用DELPHI来开发软件界面，用VC来开发核心业务逻辑不是很好吗？Delphi访问C++ DLL中的普通导出函数当然没有问题，但怎样通过接口来访问其中的对象呢？我研究了一两天，仔细分析了下C++和Object Pascal的对象模型，终于搞定了，在这里分享一下我的心得：
Object Pascal中的interface和C++中的接口是很不同的，例如我们可以象下面申明一个C++接口
struct IFoo:public IUnKnown
{
virtual int _stdcall Add(int x,int y)=0;//由于需要导出，接口和实现它的类中的虚函数都应使用_stdcall惯例
virtual int _stdcall Divd(int x,int y)=0;
};
然后我们使用一个导出函数来通过这个接口导出C++对象：
extern "C" _declspec(dllexport) IFoo* GetMainInterface()
{
return dynamic_cast(MainFoo);//MainFoo是实现IFoo的一个类的对象指针，在DLL被加载时初始化
};
在Delphi中声明对应的接口和接口指针：
IFoo = interface
function Add(x,y:integer):integer;stdcall;
function Divd(x,y:integer):integer;stdcall;
end;
PIFoo = ^IFoo
然后通过下面的步骤来导入对象：
GetMainInterface:function:PIFoo;stdcall; //对应C++中的导出函数
...
Libhwnd:=loadlibrary('DLL的路径');
@GetMainInterface:=GetProcAddress(Libhwnd,'GetMainInterface');
MainIntf:=GetMainInterface; // MainIntf的类型就是PIFoo;
OK，我最先以为这样就全部搞定了，很简单嘛，但是当我通过MainIntf^.Divd(15,3)来调用时，出了内存错误什么都没发生，后来通过分析才知道Object Pascal中的Interface本来就是一个指针，虽然它的类型不是指针，但是它的确是指向接口VMT的一个指针，PIFoo就是一个指针的指针了，而C++中的IFoo*并不是一个2重指针，看下面的汇编代码：
MOV eax,[ebx+$000002fc] //取得接口的首地址给EAX寄存器
PUSH eax //不用管它
MOV eax,[eax] //将接口内存中的前32位首地址看为一个指针，这个指针的内容就是VMT的入口了
...
MOV eax,[eax]
//最关键的就是这里了，其实这条指令是多余的，这样就不知道指到哪块内存去了，下面的调用当然就会有内存访问错误了。为什么会有这条多余的指令呢？就是上面我所说的原因了，MainIntf是一个2重指针，Delphi的编译器认为要经过两次MOV eax,[eax]才能得到对象VMT的入口，所以就出现了问题，由此也可见Object Pascal、VCL、Delphi IDE的架够确实很优秀，但是结合的却太紧密的。
CALL dword ptr [eax+$10] //VMT的入口在加上适当的偏移动就是要调用的方法指针了
怎么解决这个问题呢？我们只用把MainIntf这个2重指针强制转化为Delphi里的接口就可以了（IFoo(MainIntf).Divd(15,3)就是一个正确的调用）。