之前并没有很在乎这方面的事情，直到最近需要在某个bcb编译的程序中集成steam sdk。
故事是这样的，steam sdk提供的接口是c++代码，官方号称支持visual studio和gcc两种编译器。但我不想先做一层包装转换成c的接口再使用，所以打算强行在bcb中链接这些lib。
现在问题来了，由于c++的abi很混乱，微软又喜欢玩花活，一旦接口是c++的格式(class, virtual table)就很微妙。这就牵扯到了calling convention的事情，也就是函数调用约定。这件事情本来很简单，在c的时代只要解决两个问题就好：1、参数个数是不是固定的。2、参数是如何被放到堆栈中的。第二个问题无关痛痒，所以c规定参数一律是从右到左压入栈中，这样用的时候就可以从左到右依次弹出。
所以calling convention只和第一个问题有关，这样就诞生了两个关键字：
__cdecl：支持不固定个数的参数，调用方caller负责清理堆栈。好处是printf之类的东西可以实现，坏处是函数内部不能对堆栈玩花活，因为管理权在外面。
__stdcall：参数个数固定，被调用方callee负责清理堆栈。好处就是函数结尾直接用ret xx解决所有问题，坏处是参数个数固定，因为编译期就得决定ret之后的字节数。顺道说，COM中所有调用都是__stdcall。
目前为止一切还是有序的，直到link的时候，出现了name mangling的问题。M$和Borland使用了截然相反的方式来修饰函数名，具体可以参考《Using Visual C++ DLLs with C++Builder》中的Table A。还好双方都提供了解决方法，任选一种就可以生成合适的符号名，可以愉快的link。
即使link没有问题，问题也还远未解决，一旦开始使用c++的接口，run-time的问题就浮现出来。这就要提到M$的发明：
__thiscall：用于non-static member function，会把this放入ecx，再调用函数。好处就是this指针非常容易找到，调试方便。坏处就是……这是M$的发明，而非标准。还好时至今日很多编译器都支持了__thiscall，巨硬不再孤家寡人。
实际上bcb对this的解决方法非常简单，就是把它当作第一个函数的参数，照样传递进去即可。调试时候也不见得有多麻烦，而且如今编译器对代码的优化非常风骚，ecx在入口可能还有用，进入函数体之后几乎就完全无用了。
__fastcall：时代的眼泪，从名字看很拉风，但定义特别复杂。具体就是说把前几个较小的参数从寄存器里传入，而不是压入堆栈中。这样调用双方省去了很多进出栈的操作，故名fast。时至今日，这些开销似乎没什么人在乎了。
其他的调用约定我没怎么看就不说了，手头的情况只和后两种有关。这个bcb的程序诞生于近20年前，作者大概觉得函数调用开销是一件很重要的事情，所以默认全部函数都采用__fastcall。而steam sdk的c++接口全部用默认的__thiscall，运行的时候caller把参数往寄存器一丢了事，而callee还苦苦在ecx和堆栈中寻找，代码就跑飞了。
解决方案非常悲剧，对于每个class的每个non-static member function，都提供一个静态函数作为wrapper。内部帮他们把参数位置转换一下，然后再调用sdk中的实际代码。
用macro封装的效果如下所示（1个参数）
#define STEAM_API_CALL_WRAPPER1(ret, type, interface, index, var1) \
ret STEAM_API_CALL type##_##interface(type * thisptr, var1) { \
asm { \
MOV eax, [ebp + 4 * 3]; \
push eax; \
MOV ecx, thisptr; \
MOV edx, [ecx]; \
CALL [edx + 4 * index]; \
} \
}
//
使用之前必须逐个定义，还得注意虚函数在虚表中的位置。不幸中的万幸是bcb和vs的虚表排列都是一样的。万幸中的不幸是，steam sdk中居然还有头文件和编译好的lib中虚表里函数顺序不一致的情况。大概是某个程序员手贱没事就调整函数的位置，又不肯重新编译sdk吧……
STEAM_API_CALL_WRAPPER1(bool, ISteamUserStats, SetAchievement, 7, const char *pchName);
经过这么多折腾之后，终于成功在bcb中链接运行了steam sdk。接下来发现还有callback的问题，steam要调用从bcb程序里传入的函数指针！解决方法和上面类似，callback函数也需要有一层wrapper……
只要对所有使用到的接口做上述处理，最终一切都和谐美好的运行起来，完全没有使用额外的dll，直接在bcb中使用了steam_api.dll。我研究了一下网上已有的实现，都是采用包装一个wrapper dll的方式。我这边的方法相对安全一些，否则wrapper可以被轻松的替换掉。当然咯，steam有提供额外的drm措施，简单换掉wrapper并不能移除steam绑定就是了。所以如果不是像我这样有强迫症的话，写个wrapper dll是最简单直接的方式。
结论是如果以后需要写什么对外发布的sdk，还是以c接口的形式提供最具有兼容性。
