c++ 中的 dll，WINDOWS 部署/依赖项 (mingw-w64)
dll in c++, WINDOWS deployment / dependency's (mingw-w64 )
背景：
我正在为 x64 应用程序编写一个插件（基本上是一个 dll）。
更具体地说，这个 x64 WIN 应用程序带有一个 "plugin manager"（一个 dll），可以加载和卸载第 3 方插件（比如我的）。
我的插件是用 C++ 编写的，我决定用 mingw-w64 编译它。作为 IDE 我选择了 Code::Blocks。
我试图避免使用 MS 工具，因为后来我需要在 Linux 和 MAC 上部署 "the same" 插件（但这是另一个故事，让我们暂时关注 Windows）。
挑战：
有一个严重的问题我无法用我的 knowledge/skill 级别可靠地解决，尽管我在研究和测试的日子里确实很努力：对 WINDOWS dll 的依赖。
我必须确保这个插件 运行 在从 7 到 10 的所有 WINDOWS 版本上（但是仅限 x64）。
应避免运送 MS 可再发行组件，因为在这种情况下不切实际。
显然，c-运行time 库 "MSVCRT.dll" 的静态链接似乎既不被版权所允许，也不是一个可靠的解决方案，因为在各种 WIN 版本上有许多不同的版本。尽管 Microsoft 将其描述为 "known dll"，但我不确定哪个版本可用以及哪个版本能够在某个 Win 版本上 运行。如果某个 MSVCRT.dll 运行s，它是否有足够的 "functionallity" 用于我的插件？ （对我来说太高了）
问题：
在您的专业意见中，就 Windows dll 依赖性而言，确保我的插件在 WINDOWS 7 到 10 (x64) 上的稳定性的可靠方法是什么？
在依赖于部署的情况下，还有其他我应该担心的陷阱吗？
附加信息：
插件的这个开发阶段的依赖性 walker_x64（多么方便的工具！）向我展示了依赖性：
- KERNEL32.DLL
- MSVCRT.DLL（我最担心的就是这个人）
- PM_64.DLL（x64 应用程序的插件管理器）
在我的电脑 (Windows 7 x64) 上，MSVCRT.DLL 显示版本 7.0.7601.17744，好的，有效。但是，如果客户有一台 Windows 10 机器，新安装（可用的 MS 可再发行版本不多），它能可靠地工作吗？
我知道以前讨论过类似的问题，尤其是c-运行时间库"MSVCRT.dll"。然而，其中许多是在 WIN10 之前。
例如，6 年前的 newlib 想法 (http://sourceware.org/newlib/)。
Mingw-w64 附带名为：libmsvcrt.a / libmsvcrtXXX.a 的档案。有什么办法吗？
我已经阅读了我能找到的所有内容，但我不得不承认，现在我的疑惑和问题多于答案...
感谢您的专业建议。谢谢。
您可能依赖至少以下动态库的存在和稳定性：kernel32.dll、msvcrt.dll, user32.dll, gdi32.dll。它们是系统库，在干净 OS 安装后出现在 C:\Windows\System32\ 文件夹中，由 Microsoft 作为用户 API 创建以与 OS 交互。 MinGW 库 libmsvcrt.a（以及非静态 MS 库）没有实际的处理代码，只是从系统文件夹调用这些 DLL 的包装器。
背景： 我正在为 x64 应用程序编写一个插件（基本上是一个 dll）。 更具体地说，这个 x64 WIN 应用程序带有一个 "plugin manager"（一个 dll），可以加载和卸载第 3 方插件（比如我的）。 我的插件是用 C++ 编写的，我决定用 mingw-w64 编译它。作为 IDE 我选择了 Code::Blocks。 我试图避免使用 MS 工具，因为后来我需要在 Linux 和 MAC 上部署 "the same" 插件（但这是另一个故事，让我们暂时关注 Windows）。
挑战： 有一个严重的问题我无法用我的 knowledge/skill 级别可靠地解决，尽管我在研究和测试的日子里确实很努力：对 WINDOWS dll 的依赖。 我必须确保这个插件 运行 在从 7 到 10 的所有 WINDOWS 版本上（但是仅限 x64）。 应避免运送 MS 可再发行组件，因为在这种情况下不切实际。 显然，c-运行time 库 "MSVCRT.dll" 的静态链接似乎既不被版权所允许，也不是一个可靠的解决方案，因为在各种 WIN 版本上有许多不同的版本。尽管 Microsoft 将其描述为 "known dll"，但我不确定哪个版本可用以及哪个版本能够在某个 Win 版本上 运行。如果某个 MSVCRT.dll 运行s，它是否有足够的 "functionallity" 用于我的插件？ （对我来说太高了）
问题： 在您的专业意见中，就 Windows dll 依赖性而言，确保我的插件在 WINDOWS 7 到 10 (x64) 上的稳定性的可靠方法是什么？ 在依赖于部署的情况下，还有其他我应该担心的陷阱吗？
附加信息： 插件的这个开发阶段的依赖性 walker_x64（多么方便的工具！）向我展示了依赖性：
- KERNEL32.DLL
- MSVCRT.DLL（我最担心的就是这个人）
- PM_64.DLL（x64 应用程序的插件管理器）
在我的电脑 (Windows 7 x64) 上，MSVCRT.DLL 显示版本 7.0.7601.17744，好的，有效。但是，如果客户有一台 Windows 10 机器，新安装（可用的 MS 可再发行版本不多），它能可靠地工作吗？
我知道以前讨论过类似的问题，尤其是c-运行时间库"MSVCRT.dll"。然而，其中许多是在 WIN10 之前。 例如，6 年前的 newlib 想法 (http://sourceware.org/newlib/)。 Mingw-w64 附带名为：libmsvcrt.a / libmsvcrtXXX.a 的档案。有什么办法吗？
我已经阅读了我能找到的所有内容，但我不得不承认，现在我的疑惑和问题多于答案... 感谢您的专业建议。谢谢。
您可能依赖至少以下动态库的存在和稳定性：kernel32.dll、msvcrt.dll, user32.dll, gdi32.dll。它们是系统库，在干净 OS 安装后出现在 C:\Windows\System32\ 文件夹中，由 Microsoft 作为用户 API 创建以与 OS 交互。 MinGW 库 libmsvcrt.a（以及非静态 MS 库）没有实际的处理代码，只是从系统文件夹调用这些 DLL 的包装器。