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

有人知道部署本机（无COM、无.NET）ANSI C Windows共享库的最佳实践指南吗

我们的产品使用zlib，我们在下载页面上发布与官方zlib页面不同的预构建二进制文件。我猜原因是。官方版本是使用VC++6.0针对msvcrt构建的，VS.NET/2005/2008将使用msvcrt71/80/90

我想做的是创建VS2005/8解决方案和项目，这些解决方案和项目将正确地为我们构建zlib，并在我们现有的基础上分发它们。我想仔细地做这件事，并分发一个适当有用的软件包，然后我还可以将它发送给zlib的策展人，以便将其包含在源代码分发中。然而，找到可靠的信息已经证明是一件麻烦事。我有一大堆关于Win32编程的书，我在网上找到了很多文章，但这些文章似乎都没有详尽地描述您真正需要分发的内容

例如，zlib分发.exp、.lib存根和.def文件，其中fftw分发.def文件，而不是.lib存根和.exp文件。我想我可以把所有看起来有用的东西都放在那里（或者只是镜像官方zlib目前拥有的东西），但我想知道为什么它必须放在那里以及它所属的目录中

是否有源于unix世界的维护良好的Windows库发行版的好例子

澄清：

---

我们分发了一个库，并向（大部分）Windows用户提供zlib，因为他们通常没有可用的zlib。我希望我们的zlib构建作为一个组件在总体上是有用的，而不仅仅是作为我们的产品使用的.dll。我们是开源的，应用广泛，因此我们确实希望使我们的整个构建环境可用，并且可以轻松地适应您想要使用的任何编译器。

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

您将在Windows部分看到下载内容与表单

Lua_5_1_4_Win32_{PLAT}{VER}lib.zip

匹配。{PLAT}可以是Cygwin、VC[6-9]、MinGW或仅仅是DLL，等等

例如，如果要获取

lua5\u 1\u 4\u Win32\u vc9\u lib.zip

，您只会找到一个

lua5.1.lib

文件（加上标题），因为这是静态库（这是在VS2008中编译的）

lua5_1_4_Win32_dll9_lib.zip

包含

lua5.1.lib

和

lua5.1.dll

-您可以在编译时链接到该.lib，这就是您真正需要的

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

据我所知，只需要一个.def文件就可以了。我的理解是，很久以前，VS除了使用.libs之外还使用了.def文件，但现在VS需要的所有信息都只包含在.lib中。您可以在.lib和.def文件之间进行转换（如果无法在其中一个文件上编译代码），但这有点麻烦——例如，您必须使用

pexports

生成.def文件

---

希望LuaBinaries是一个很好的参考，可以帮助您支持很多Win32编译器。但是我真的不确定是否有必要为每个版本的VS创建一个.lib存根，因为我非常确定我已经向使用VS2008的人发送了一个VS2003.lib和.dll，没有问题。

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

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

您可能会想象，可以将CRT静态链接到DLL中，从而避免出现这种问题。然后出现的问题是，当您必须在DLL及其宿主应用程序之间传递分配的指针时，因为混合运行时的大多数问题都来自于在一个进程中有多个

malloc（）

和

free（）

的实现。然而，通过为DLL精心设计和实现的API，这可能是解决方案

如所述的发行版使用大量的构建自动化来安排平台和编译器的多种组合。维护构建过程对其团队来说是相当多的工作。当一个单独的小组决定创建一个为Windows用户提供简单的首次使用体验时，他们决定（我相信是明智的）为他们的产品选择一个单一的CRT版本，并要求他们附带的所有扩展DLL都针对该单一版本进行编译

作为发布包的一部分，您应该遵循的一种实践是，用于验证是否使用了预期的CRT，以及所有其他依赖项是否是托管应用程序安装的系统DLL，或者是否也包含在包中。Dependency walker可以从批处理文件运行，因此它可以作为回归测试套件的一部分来自动执行此验证。例如，在发布基于Lua的项目时，我从Makefile中运行Dependency Walker下的最终构建，作为构建安装包的目标的一部分，并使用perl脚本检查日志，以验证所使用的唯一DLL是否为其中一部分