建议：YSM Native/JNI 支持 Windows NT 6.0+
如题。
想提一个关于 Windows 老系统兼容性的建议：是否可以考虑让 YSM 的 Native/JNI 部分支持 Windows NT 6.0+，也就是最低从 Windows Vista / Server 2008 开始？
这里并不是要求支持 Windows XP、2000 之类的 NT 5.x 系统，而是希望至少能够覆盖 NT 6.0 / 6.1 这一代 Windows。
之所以想提这个 Issue，主要是因为我有一个一直比较困惑的问题：
JNI 开发都能把 Android 放行了，怎么就不愿意放 Windows 老系统？
现在 YSM 已经使用 C++ Native + JNI，而且 Android 端也已经针对 Native Library 的加载方式做了专门处理。既然项目本身已经需要维护不同平台的 Native 代码，那么 Windows 这边是否有可能提供一个面向 NT 6.0+ 的兼容构建？
我比较想了解，目前阻止 YSM 支持 Vista / Windows 7 的具体原因究竟是什么。
例如：
- 是编译器或工具链本身不再支持 NT 6.0？
- 是 MSVC Runtime / CRT 的最低系统要求？
- 是调用了 Windows 10 才存在的 Win32 API？
- 是 Native Library 依赖了较新的 Windows 功能？
- 是 CPU 指令集要求？
- 还是目前没有维护旧系统构建和测试环境的必要？
如果确实存在无法绕开的技术限制，也希望能够说明一下具体是哪一部分导致 NT 6.0 无法支持。
如果主要只是因为现代构建环境默认已经不再面向 Vista，那么是否可以考虑单独维护一个 Legacy Windows Build？
我个人觉得 NT 6.0+ 是一个还算合理的兼容目标。
Vista / Server 2008 虽然已经非常老，但它们属于 NT 6.0 世代；Windows 7 / Server 2008 R2 则是 NT 6.1。相比 XP 的 NT 5.1，这已经是完全不同的一代 Windows 平台。
另外，据我了解，我也曾在 HMCL 启动器的游戏错误报告群里见到过类似的问题：有人询问 Windows 7 的兼容性时，得到的反馈似乎是连 Windows 7 都无法运行。
当然，这一点只是我在群里的了解，如果实际情况并非如此，还请以 YSM 当前的实际最低系统要求为准。
如果目前确实已经连 Windows 7 都无法运行，那么我反而更想知道其中具体的技术原因。毕竟 Windows 7 已经属于 NT 6.1，而我这里提出的 NT 6.0+ 目标也只是希望至少覆盖 Vista / Server 2008 这一代系统。
另外，我自己目前主要是在虚拟机环境下测试这些老系统，所以这个 Issue 并不只是单纯为了“在虚拟机里玩 YSM”。
现实中仍然有不少用户由于硬件、驱动、设备厂商支持等原因无法升级到更新版本的 Windows。对他们来说，升级系统并不是“点一下 Windows Update”这么简单——有些设备是真的已经被硬件和驱动卡死在旧系统上。
所以我觉得，如果 Native/JNI 部分不存在必须依赖新 Windows API 或新系统 ABI 的硬性限制，那么提供一个 NT 6.0+ 的兼容构建还是挺有意义的。
当然，我也理解维护额外的 Native 构建会增加开发、打包和测试成本，因此这更像是一个兼容性建议，而不是要求项目必须长期维护一套老系统环境。
如果维护完整的 NT 6.0+ 构建确实成本太高，那么至少能否考虑：
- 说明目前 Native 部分最低支持的 Windows 版本；
- 说明不支持 Vista / Windows 7 的具体技术原因；
- 如果条件允许，提供一个 Legacy Windows Build；
最后还是想问一句：
Android 都已经有专门的 JNI/Native 兼容方案了，Windows 这边能不能也稍微给 NT 6.0+ 留一条路？
虽然现在已经是 2026 年了，但总还有一些老设备在认真工作。
老设备：我还能再战十年.jpg
建议：YSM Native/JNI 支持 Windows NT 6.0+
如题。
想提一个关于 Windows 老系统兼容性的建议：是否可以考虑让 YSM 的 Native/JNI 部分支持 Windows NT 6.0+，也就是最低从 Windows Vista / Server 2008 开始？
这里并不是要求支持 Windows XP、2000 之类的 NT 5.x 系统，而是希望至少能够覆盖 NT 6.0 / 6.1 这一代 Windows。
之所以想提这个 Issue，主要是因为我有一个一直比较困惑的问题：
现在 YSM 已经使用 C++ Native + JNI，而且 Android 端也已经针对 Native Library 的加载方式做了专门处理。既然项目本身已经需要维护不同平台的 Native 代码，那么 Windows 这边是否有可能提供一个面向 NT 6.0+ 的兼容构建？
我比较想了解，目前阻止 YSM 支持 Vista / Windows 7 的具体原因究竟是什么。
例如：
如果确实存在无法绕开的技术限制，也希望能够说明一下具体是哪一部分导致 NT 6.0 无法支持。
如果主要只是因为现代构建环境默认已经不再面向 Vista，那么是否可以考虑单独维护一个 Legacy Windows Build？
我个人觉得 NT 6.0+ 是一个还算合理的兼容目标。
Vista / Server 2008 虽然已经非常老，但它们属于 NT 6.0 世代；Windows 7 / Server 2008 R2 则是 NT 6.1。相比 XP 的 NT 5.1，这已经是完全不同的一代 Windows 平台。
另外，据我了解，我也曾在 HMCL 启动器的游戏错误报告群里见到过类似的问题：有人询问 Windows 7 的兼容性时，得到的反馈似乎是连 Windows 7 都无法运行。
当然，这一点只是我在群里的了解，如果实际情况并非如此，还请以 YSM 当前的实际最低系统要求为准。
如果目前确实已经连 Windows 7 都无法运行，那么我反而更想知道其中具体的技术原因。毕竟 Windows 7 已经属于 NT 6.1，而我这里提出的 NT 6.0+ 目标也只是希望至少覆盖 Vista / Server 2008 这一代系统。
另外，我自己目前主要是在虚拟机环境下测试这些老系统，所以这个 Issue 并不只是单纯为了“在虚拟机里玩 YSM”。
现实中仍然有不少用户由于硬件、驱动、设备厂商支持等原因无法升级到更新版本的 Windows。对他们来说，升级系统并不是“点一下 Windows Update”这么简单——有些设备是真的已经被硬件和驱动卡死在旧系统上。
所以我觉得，如果 Native/JNI 部分不存在必须依赖新 Windows API 或新系统 ABI 的硬性限制，那么提供一个 NT 6.0+ 的兼容构建还是挺有意义的。
当然，我也理解维护额外的 Native 构建会增加开发、打包和测试成本，因此这更像是一个兼容性建议，而不是要求项目必须长期维护一套老系统环境。
如果维护完整的 NT 6.0+ 构建确实成本太高，那么至少能否考虑：
最后还是想问一句：
虽然现在已经是 2026 年了，但总还有一些老设备在认真工作。
老设备：我还能再战十年.jpg