问是否有向Windows分发本机C库的最佳实践指南？

EN

如您所知，混合C运行时是一个真正的问题。因此，DLL发行版的一个维度将始终是运行时的选择。有时，这不是一个自由的选择。将由现有应用程序(想想插件)在运行时加载的DLL必须(通常)与宿主应用程序使用的CRT的选择相匹配。

您可能会想象，您可以静态地将CRT链接到您的DLL中，并避免这种担心。出现的问题是，当您必须在DLL和其宿主应用程序之间传递分配的指针时，因为混合运行时的大部分问题来自在一个进程中有多个malloc()和free()的实现。但是，使用为DLL精心设计和实现的API，这可能是解决方案。

像Lua双星这样由马克·拉沙科夫的回答描述的发行版使用大量的构建自动化来安排许多平台和编译器的组合。维护构建过程对其团队来说是一项相当大的工作。当一个单独的组决定创建一个用于Lua的Windows安装程序来为Windows用户提供一个简单的第一次使用体验时，他们决定(我相信明智地)为他们的产品选择一个CRT版本，并要求他们附带的所有扩展all都是根据该单一版本编译的。

作为发行版打包的一部分，您应该遵循的一种做法是使用依赖沃克来验证是否使用了预期的CRT，并且所有其他依赖项都是宿主应用程序安装时的系统DLL，或者也包括在包中。依赖程序可以从批处理文件中运行，因此它可以作为回归测试套件的一部分来自动完成此验证。例如，在发布基于Lua的项目时，我从Makefile中在Dependency下运行最终构建，作为构建安装包的目标的一部分，并使用perl脚本检查日志，以验证所使用的惟一DLL要么是安装的一部分，要么来自系统。

正如其他人所说的那样，如果您的DLL是由不希望使用DLL开发的最终用户使用的(例如独立发布的大型应用程序的插件)，那么您需要打包的就是DLL本身(以及它所具有的任何依赖项、最终用户文档等)。在这种情况下，只需确保DLL使用与应用程序相同的运行时。

如果DLL是针对开发人员社区的，那么您很可能是在Lua二进制文件的多个构建案例中。每个分发包都将包含正确构建的DLL、导入库(.LIB)和所有文档。对于VS构建的DLL，这些DLL预期将与其他编译器的代码相链接，因此可以友好地包含记录实际导出名称的.DEF文件。现代MinGW实际上并不需要它，但是Borland的用户或者可能是C以外的语言的用户可以使用他们所能得到的所有帮助。

鉴于最近流行的动态语言(如Lua、Perl、TCL和Python )，这些语言通常可以很容易地绑定到用C实现的库中，如果您可以向这些语言提供绑定，以及根据“本地定制”编译的二进制文件以供选择CRT，这些用户社区也会非常赞赏它。

作为参考，我想提一下LuaBinaries。简单的背景是，由于Lua是相当可配置的，他们认为最好有一个“标准”发行版，这样任何人都可以分发字节码编译的Lua脚本，而任何使用“标准”Lua二进制文件的人都可以以相同的结果运行它们。

您将在Windows部分看到下载与表单Lua_5_1_4_Win32_{PLAT}{VER}_lib.zip匹配。{PLAT}可以是Cygwin、VC6-9、MinGW或仅仅是DLL等等。

例如，如果要抓取lua5_1_4_Win32_vc9_lib.zip，就只能找到一个lua5.1.lib文件(加上头文件)，因为这是静态库(这个库是用VS2008编译的)。

lua5_1_4_Win32_dll9_lib.zip包含lua5.1.lib和lua5.1.dll -您可以在编译时链接到该.lib，这是您真正需要的。

如果您的唯一目标是Visual，那么在编译成DLL时生成的.lib应该是除了DLL和头文件之外唯一需要的文件--除非您希望用户只调用LoadLibrary和GetProcAddress来访问DLL的所有功能。

据我所知，对.def文件的唯一需要是MinGW与VS之间的互操作DLL。我的理解是，很久以前，VS除了使用.def文件之外，还使用了.libs，但是现在所有的信息和所需的信息都只包含在.lib中。您可以在.lib和.def文件之间进行转换(如果您不能在其中一个文件上编译代码)，但这有点麻烦--例如，您必须使用pexports生成一个.def文件。

希望LuaBinaries能够为如何支持许多Win32编译器提供一个很好的参考。但是我真的不确定是否有必要为VS的每个版本创建一个.lib存根，因为我非常确定我已经向使用VS2008的人发送了一个VS2003 .lib和.dll，而且没有遇到任何麻烦。

如果您的目标是最终用户(即，您只需要运行您的应用程序)，则只需分发dll即可。