在启动时检查是否为明确不支持 HMCL 的操作系统并提示

[WhatDamon]

在启动器运行在 Haiku OS 和 OS/2 (包括其 OEM 版本，例如 ArcaOS) 时报错提示用户不支持
目前添加检测的系统其所支持的 OpenJDK 应该都支持 AWT/Swing，但不支持 JavaFX

如果有其他明确不支持 HMCL 的小众操作系统能够运行 OpenJDK 17 及更新版本并且支持 AWT/Swing，均可在这里添加

为什么？

因为我真的见过有些爱折腾的用户会尝试在这些小众系统运行 HMCL，而 HMCL 所依赖的 JavaFX 不支持这些操作系统（OS/2 及其 OEM 版本更是无法运行 MC）
有一个明确的信息可以阻止他们在这方面浪费时间

[zhuWin]

Haiku 的官方称谓就只是 “Haiku” ，名称没有 OS。不过可以把 “OS” 改为 “操作系统”。

[WhatDamon]

我在想要不回退本地化内容，因为正如上面的图片所示，Haiku 似乎并不能正确显示 AWT 中的中文字符

[3gf8jv4dv]

我在想要不回退本地化内容，因为正如上面的图片所示，Haiku 似乎并不能正确显示 AWT 中的中文字符

boot.unsupported_os.haiku 可以只留英文。
不知道 CI 会不会检查 boot.properties，如果报错了的话，zh 和 zh_Hant 里可以直接写英文进去。

[WhatDamon]

boot.unsupported_os.haiku 可以只留英文。 不知道 CI 会不会检查 boot.properties，如果报错了的话，zh 和 zh_Hant 里可以直接写英文进去。

HMCLBoot 没有 checkTranslate 可以通过测试
已删除本地化后的文本

[3gf8jv4dv]

lgtm

[WhatDamon]

同类 PR #5518 中提及本地化可以通过同时显示双语的方式解决，我也计划在此 PR 这么操作

[Glavo]

为什么要在 HMCLBoot 里做检查？

[WhatDamon]

为什么要在 HMCLBoot 里做检查？

因为我认为操作系统不支持的警告应该先于 checkDirectoryPath()，没有必要让用户先让 HMCL 运行在合法的文件目录后再行警告，移到 HMCL 中与我所希望的尽早阻止爱折腾的用户浪费时间的想法相悖

另外一点就是我所指出的这两个操作系统均明确不支持 JavaFX，虽然 HMCL 中有可以使用 Swing，但我觉得没有必要加载到 HMCL 本体在检查，这么做可能能让应用不加载相较 HMCLBoot 更庞大的 HMCL 本体

如果有其他好的解决方案也可以提供下，我评估下来如果更好我会进行更改

[Glavo]

HMCLBoot 之所以要分离出单独一个模块，原因是为了用 Java 8 编译，这样在使用 Java 8～16 运行时才能给用户弹出提示，此外任何功能都不应该在这个模块里实现。

因为我认为操作系统不支持的警告应该先于 checkDirectoryPath()，没有必要让用户先让 HMCL 运行在合法的文件目录后再行警告，移到 HMCL 中与我所希望的尽早阻止爱折腾的用户浪费时间的想法相悖

之所以要把 checkDirectoryPath() 移动到 HMCBoot 里，就是因为在非法路径中无法正确显示 Swing 对话框（#5259），checkDirectoryPath() 里的注释也有相关说明。你在 checkDirectoryPath() 之前做检测只会让提示无法正常显示。

另外一点就是我所指出的这两个操作系统均明确不支持 JavaFX，虽然 HMCL 中有可以使用 Swing，但我觉得没有必要加载到 HMCL 本体在检查，这么做可能能让应用不加载相较 HMCLBoot 更庞大的 HMCL 本体。

我没有看懂这有什么意义。根本就不存在一个独立于 HMCBoot 的“庞大的 HMCL 本体”，不管 HMCL、HMCLCore 还是 HMCLBoot， 所有子项目中的所有类都位于单一 JAR 中，都是 HMCL 的一部分。Java 加载类时也是按需加载，只会加载几个相关的几个类，并不存在只要用到 HMCL 子项目中的类就会一下子把这个子项目中所有类一起加载这种情况。

而且哪怕存在这样一个“庞大的 HMCL 本体”，我也不理解避免加载它有什么收益。这不是高频操作，多消耗几毫秒没有任何实质性的影响。

[WhatDamon]

HMCLBoot 之所以要分离出单独一个模块，原因是为了用 Java 8 编译，这样在使用 Java 8～16 运行时才能给用户弹出提示，此外任何功能都不应该在这个模块里实现。

已经迁移到了 EntryPoint