是否有针对Windows分发本机C库的最佳实践指南？ [英] Is there a best practices guide to distributing native C libraries for Windows?
问题描述
有人知道用于部署本机（无COM，无.NET）ANSI C Windows共享库的最佳实践指南吗？
我们的产品使用zlib并进行分发我们的下载页面上的预编译二进制文件与官方zlib页面上的二进制文件不同。我猜想这是避免混合C运行时的原因。官方版本是使用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当前拥有的东西），但是我想知道为什么必须存在于其中以及它属于哪个目录。
是否有很好的例子来证明Windows发行版在unix世界中的存在？
< a href = http://www.zlib.net/ rel = nofollow noreferrer> zlib官方二进制发行版（向下滚动）
< a href = http://www.hdfgroup.org/ftp/lib-external/zlib/1.2/bin/windows/ rel = nofollow noreferrer>我们的Windows发行版
要澄清：
我们分发一个库，并将zlib提供给（大多数）Windows用户，因为他们通常没有此库。我希望我们构建的zlib总体上可用作组件，而不仅仅是作为我们产品使用的.dll。我们是开源的并且被广泛使用，因此我们希望使我们的整个构建环境可用并轻松适应您想要使用的任何编译器。
您知道，混合C运行时是一个真正的问题。因此，DLL分发的一个维度始终是运行时的选择。有时这不是一个自由选择。通常，现有应用程序（例如插件）将在运行时加载的DLL必须与托管应用程序使用的CRT选择相匹配。
您可能会想到您可以将CRT静态链接到您的DLL中，而不必担心。然后出现的问题是当您必须在DLL及其托管应用程序之间传递分配的指针时，因为大多数混合运行时的麻烦都来自于多个实现 malloc（）和 free（）。
使用诸如DLL的经过精心设计和实现的DLL可以解决问题。
像 Lua Binaries 由 Mark Rushakoff的答案使用大量的构建自动化来安排平台和编译器的众多组合。维护构建过程对其团队来说是相当大的工作量。当一个单独的小组决定创建 Lua的Windows安装程序为Windows用户提供简单的首次使用体验时，他们决定（我认为是明智的选择）为其产品选择一个CRT版本，并要求针对该版本编译其附带的所有扩展DLL。
在发布包装中应遵循的一种做法是使用 Dependency Walker 来验证预期的使用了CRT，并且所有其他依赖项都来自宿主应用程序安装中的系统DLL，或者也包含在软件包中。 Dependency Walker可以从批处理文件运行，因此可以用作回归测试套件的一部分来自动执行此验证。例如，当发布基于Lua的项目时，我将最终生成的文件从Makefile运行在Dependency Walker下，作为构建安装包的目标的一部分，并使用perl脚本检查日志以验证使用的唯一DLL是否是其中的一部分
正如其他人所说，如果您的DLL被不希望与其一起开发的最终用户（例如插件）占用，到独立分布的较大应用程序中），则只需要打包DLL本身（以及它所具有的任何依赖关系，最终用户文档等）。在这种情况下，只需确保DLL使用与应用程序相同的运行时。
如果DLL是针对开发人员社区的，那么您很可能会在许多-构建Lua Binaries的案例。每个分发包将包含正确构建的DLL，以及导入库（.LIB）和所有文档。对于由VS构建的DLL，这些DLL有望与其他编译器的代码链接在一起，可以包括.DEF文件，该文件记录了实际的导出名称。现代MinGW实际上并不需要它，但是Borland C或可能使用非C语言的用户可以使用他们可以获得的所有帮助。
鉴于最近的流行Lua，Perl，TCL和Python等动态语言通常可以很容易地绑定到用C实现的库，如果您可以提供对这些语言的绑定以及针对这些语言编译的二进制文件，那么这些用户社区也将非常感激。用于选择CRT的本地习惯。
Does anyone know of a best practices guide for deploying native (no COM, no .NET) ANSI C Windows shared libraries?
Our product uses zlib and we distribute pre-built binaries on our downloads page that differ from those on the official zlib page. I'm guessing that the reason for this is to avoid mixing C runtimes. The official ones are built against msvcrt using VC++ 6.0 and VS.NET/2005/2008 will use msvcrt71/80/90.
What I want to do is to create VS2005/8 solutions and projects that will properly build the zlib for us and distribute them in place of what we have now. I'd like to do this carefully and distribute a properly useful package that I could also then send off to the curators of zlib for inclusion in their source distribution. Finding reliable information has proven troublesome, though. I have a bunch of books on Win32 programming and I've found a lot of articles on the web but none of this seems to do a thorough job of describing what you really need to distribute.
For example, zlib distributes the .exp, .lib stub and .def files where the fftw distributes the .def files but not the .lib stubs and .exp files. I guess I could just dump everything that looks useful in there (or just mirror what the official zlib currently has) but I'd like to know why it has to be there and in what directories it belongs.
Are there good examples of well-maintained Windows distributions of libraries that originated in the unix world?
Official zlib binary distributions (scroll down)
TO CLARIFY:
We distribute a library and provide the zlib to (mostly) Windows users since they typically don't have it available. I want our build of the zlib to be useful as a component in general, not just as a .dll that our product consumes. We're open source and widely used so we do want to make our entire build environment available and easily adaptable to any compiler you'd like to use.
As you know, mixing C runtimes is a real problem. So one dimension of a DLL distribution will always be a choice of runtime. Sometimes that is not a free choice. A DLL that will be loaded at runtime by an existing application (think plugin) must (usually) match the choice of CRT used by the hosting application.
You might imagine that you could statically link the CRT into your DLL and avoid the concern. The problem that arises then is when you have to pass allocated pointers between the DLL and its hosting app since most of the trouble with mixed runtimes comes from having more than one implementation of malloc() and free() in a process. With a carefully designed and implemented API for a DLL, this can be the solution, however.
Distributions like Lua Binaries described by Mark Rushakoff's answer use a large amount of build automation to arrange to make so many combinations of platform and compiler available. Maintaining the build process is a fair amount of work for its team. When a separate group decided to create a Windows installer for Lua to provide a simple first use experience for Windows users, they decided (I believe sensibly) to pick a single CRT version for their product and to require that all of the extension DLLs they ship with it are compiled against that single version.
One practice that you should follow as part of your release packaging is to use Dependency Walker to verify that the expected CRT is used, and that all other dependencies are either a system DLL, from your hosting application's installation, or also included in your package. Dependency walker can be run from a batch file, so it can be used as part of a regression test suite to do this validation automatically. When releasing projects based on Lua, for instance, I run my final build under Dependency Walker from the Makefile as part of the target that builds the installation package and use a perl script to inspect the log to verify that the only DLLs used are either part of my install or from the system.
As others have said, if your DLL is consumed by end users that don't expect to develop with it (such as a plugin to a larger application distributed indepently) then all you should need to package is the DLL itself (and any dependencies it has, end-user documentation, as so forth). In that case, you just make sure that the DLL uses the same runtime as the application.
If the DLL is for a developer community, then you are likely in the many-builds case of Lua Binaries. Each distribution package would contain the correctly build DLL, along with an import library (.LIB) and all documentation. For DLLs built by VS that are expected to be linked against code from other compilers, it can be friendly to include the .DEF file which documents the actual exported names. Modern MinGW doesn't actually need it, but users of Borland C or possibly languages other than C can use all the help they can get.
Given the recent rise in popularity of dynamic languages such as Lua, Perl, TCL, and Python that often can be easily bound to libraries implemented in C, it can also be greatly appreciated by those user communities if you can supply bindings to those languages, along with binaries compiled against the "local custom" for choice of CRT.
这篇关于是否有针对Windows分发本机C库的最佳实践指南？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
