20 年前的 exe 现在仍然可以在 Windows 上运行，linux 呢？

403 条评论 | |

论点 我们应该创建一个默认通过 Wine 运行 Windows 二进制文件的 Linux 发行版。

Linux 环境是不稳定的

我可以下载一个 20 年前的 exe，而且现在仍然可以在 Windows 上运行。试着用一年前的 Linux 二进制文件做同样的事情。我们无法保证它在更新后仍能运行。由于同样的安装库版本问题，也不能保证今天在 Linux 上生成的二进制文件甚至能在今天的各种 Linux 发行版上运行。

虽然 Linux 系统调用本身非常稳定可靠，但其上的 c 库却并非如此。几乎所有的用户界面都基于 libc，因此，Linux 本身也存在二进制兼容问题。

二进制分发是个问题

由于上述问题（还有更多问题），Linux 没有很好的二进制分发方式。有四种（是的，四种！）主要的二进制文件分发方式，但它们都存在问题：

  1. 原始二进制文件。如果这种方法行得通，我们就不需要其他解决方案了。
  2. AppImage 完全独立的人工制品，将所有依赖项与二进制文件捆绑在一起。
  3. Flatpak. 为每个应用程序提供沙盒的软件包管理器。
  4. Snaps。另一种在沙箱中运行应用程序的软件包管理器。

还有更多分发二进制文件的方法，但这些都是主要的。最疯狂的是，所有这四种方法都可以在一个系统中同时使用，每种方法都有自己的安装、更新和删除应用程序的方法。在此我就不一一列举每种方法的优缺点了，但每种方法都有各自的争论点。

所有这些方法的一个主要缺点是，它们基本上都无法保存应用程序。一个人可以将一个应用程序存档 20 年，从垃圾箱中取出，然后不费吹灰之力地执行它吗？对 AppImage 来说可能吗？谁知道呢？其他三种方法肯定不行。

Win32 是答案

几年前，Arek Hiler 写了一篇博文《Win32 是 Linux 上唯一稳定的 ABI》。他说得完全正确，我相信这一见解是解决 Linux 兼容性问题的答案。事实上，Win32 设计中的一个天才决定让这一切成为可能。

在 Linux 中，你可以直接进行系统调用。只需填满一些寄存器，然后进行系统调用中断即可。

在 Windows 中，你不能直接进行系统调用。取而代之的是动态链接到为你进行系统调用的库。这样，微软就可以在内核层面做各种小动作，同时为用户空间提供稳定的 API。这个小天才让我们可以在同一台机器上同时使用 Linux 和 Windows。

仔细想想，Windows 应用程序和 Linux 应用程序只有两个主要区别。其一，它们使用不同的可执行文件格式。其二，Windows 使用动态链接库进行系统调用。只要使用 PE 格式而不是 ELF 格式，加载几个库，你就基本上拥有了一个 Windows 应用程序！我们还有一种运行 Windows 应用程序的简单方法，那就是 Wine。

Wine 是一个神奇的项目。它提供了与 Windows 应用程序惊人的兼容性，可以一直追溯到 32 位 Windows 95 时代。它甚至还实现了 DirectX！随着时间的推移，Windows 支持的应用程序与 Wine 支持的应用程序之间的差异已经趋近于零（尤其是在坚持使用 Win32 的情况下）。Wine 就是我们解决问题的法宝。

新发行版

想象一下，我们制作了一个新的 Linux 发行版。这个发行版提供的桌面环境与 Windows 非常接近，Windows 用户无需培训即可使用。你可以像在 Windows 上一样安装和运行 Windows 应用程序，不需要做任何额外的工作。如何实现？

发行版会预装 Wine，Linux 内核也会打上一些小补丁。对 “exec “系列系统调用稍作修改，在可执行类型上进行分派，就能让任何 Linux 应用程序毫不费力地分叉并执行 Windows 应用程序。

每个用户都可以设置一个 wine 前缀，桌面环境将根据该前缀运行，向用户和用户应用程序提供类似 Windows 的文件系统。我们所熟知的 Linux 仍然可用，但对于普通图形用户界面桌面用户来说，它是隐藏的。

真正的多平台

Wine 可在 Linux、FreeBSD、ReactOS、macOS、Android 和 Haiku 上运行。如果我们将所有应用程序都发布为 Windows/Win32 应用程序，我们就可以不费吹灰之力实现多平台兼容性。

迫在眉睫的未来

MacOS 和 Windows 这两大商业操作系统正朝着同一个方向发展。这些操作系统正变得越来越封闭，侵犯了用户的隐私，使用户无法控制自己的计算环境。可以说，这两种操作系统都在其操作系统中植入了不折不扣的间谍软件。Windows 会每隔几秒对你的屏幕进行截图，并让人工智能对其进行分析。MacOS 有一个名为 “守门员”（Gatekeeper）的功能，它限制你只能在 Mac 上运行苹果批准的应用程序。苹果和微软都在增加扫描电脑中 “非法 “文件并向当局报告的功能。

这些功能都是以方便和 “儿童安全 “为名，但最终的结果却是数十亿用户失去了对自己电脑的控制权。当你不再能控制自己的电脑时会发生什么？当你的操作系统是一个订阅系统时会发生什么？如果你做了这些公司不喜欢的事情，并被禁止使用任何电脑，会发生什么？

微软已经取消了在没有在线账户的情况下运行 Windows 的功能。如果你失去了账户，哪怕是一个错误，你就失去了运行电脑的能力。

注：我并不反对苹果或微软。他们都有了不起的工程师！我不认为他们有恶意。相反，我认为这些公司的激励机制不恰当。经济和政府力量正在引导它们走上这条道路。他们完全可以改变策略，尝试赋予用户权力，但我认为我们不应该认为这会自然而然地发生。

这就是为什么我认为我们需要一个 “Windows “的 Linux 发行版。它不仅能解决我们的二进制兼容性问题，还能为今年 10 月将被迫 “升级 “到 Windows 11 的 Windows 用户提供一个过渡平台。如果能有一种无障碍的方式来切换 Linux，那岂不是更好？

这只是我的一个想法。

本文文字及图片出自 Convert Linux to Windows

你也许感兴趣的：

共有 403 条讨论

  1. > 论文： 我们应该创建一个默认通过 Wine 运行 Windows 二进制文件的 Linux 发行版。

    在 Debian 上，你只需要一个软件包：

     sudo apt install wine-binfmt

    否则你还是很接近的：

     echo 'none /proc/sys/fs/binfmt_misc binfmt_misc defaults 0 0' >> /etc/fstab
 mount -a
 echo ':DOSWin:M::MZ::/usr/bin/wine:'。> /proc/sys/fs/binfmt_misc/register
    回复

    1. 这太棒了！有人提到 binfmt_misc，我还不知道呢。

      回复

      1. 下一步是隔离 Windows 应用程序：可以使用不同的 WINEPREFIX，但我认为更好的方法是像 Android 那样：每个应用程序只有一个 “用户”。

        这不仅是为了防止应用程序读取其他应用程序的文件，也是为了对每个应用程序单独设置防火墙

        例如，如果你不想让映射到用户 ID 1001 的应用程序有任何网络连接，可以使用 iptables，使用“-m owner –uid-owner 1001 -j DROP”

        几年前我从 Windows 转到了 Linux，但我仍然非常喜欢一些 Windows 应用程序（主要是 Word 和 Excel），多亏了 wine，我才能一直使用它们。

        它们的运行速度也非常快：在我的笔记本电脑上冷启动 Word（或 Excel）只需不到一秒钟的时间，而且占用的 RAM 也少得多

        就我个人而言，我宁愿从 ebay 上购买几个收缩包装的旧版 Office，也不愿为 LibreOffice、Abiword 或在线版 Office 费心。

        编辑：我找不到我以前录制的显示它有多快的录音了，但这是它在我的 hypland 桌面上的样子：你可以在 btop 中看到它没有占用多少资源 https://www.reddit.com/r/unixporn/comments/11w3zzj/hyprland_…

        回复

        1. > 下一步是隔离 Windows 应用程序：你可以使用不同的 WINEPREFIX，

          以防你不知道，葡萄酒前缀各自使用自己的设置，但并不相互隔离。

          https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#how-good-is-…

          > 但我认为更好的办法是像安卓系统那样：每个应用程序只有一个 “用户”。

          假设你不在一个用户的 X 会话中运行所有应用程序，这将会有一些帮助。在 Linux 上，某些桌面环境有一个 “切换用户 “操作，可以在另一个虚拟控制台上以另一个用户的身份启动一个单独的桌面会话。您可以使用 Control+Alt+F2 等在它们之间切换。

          回复

          1. > 如果你不知道，葡萄酒前缀各自使用自己的设置，但并不相互隔离。

            说得好！

            我知道，所以我建议每个 wine 应用程序都应在不同的用户名下运行： 我不希望任何特定应用程序访问它不绝对需要的任何内容

            > 如果你不在一个用户的 X 会话中运行所有应用程序，这样做会有一些帮助

            当我启动一个特定的 wine 应用程序时，启动它的脚本会允许该用户 ID 在我的 Xwayland 上进行渲染

            这不像在各自的 X 会话中运行那样安全，但 wayland 合成器可以根据需要提供更多隔离。

            回复

        2. Lutris 会为应用程序/游戏创建专用的 wine 前缀，因此你可以直接使用。很多应用程序也可以通过 Lutris 本身提供的一些补丁进行安装

          回复

        3. 这真的很有趣。

          我还以为在 Linux 上无法运行较新版本的 Office。

          我自己通常更喜欢 LibreOffice，但有更多的选择就是更多的选择！

          回复

          1. Office 2013，最后一个非 Click2Run 版本，几年前在 Wine 上运行得很好

            回复

            1. 在我做测试时，Office 2007 和 2010 是最稳定的

              我会试试 Office 2013（我想要一个在 wine64 上运行良好的版本！）

              回复

              1. 我没有存档具体的设置，但我相信我的基础是当时 winetricks 中包含的一个脚本，它基于脱机 2013 proplus 32bit iso 安装 Office 2013 professional。

                WineHQ 报告称，2013 64bit 的安装程序是 “黄金”，但应用程序需要进行一些调整才能应用，而且访问有时会失败。

                根据我检查的几个应用程序，2013-2016 年的版本一般都能在 Wine 上运行

                回复

        4. 为此推荐的最新可用 Office 版本是什么？

          回复

    2. 是的，这已经是很多 Linux 发行版的默认版本了（如果你安装了 wine）。

      回复

      1. 我不确定我是否希望我的父母能够双击 Windows 二进制文件，并以他们的权限执行

        回复

        1. 我的父母不能这么做。他们用的是 macOS。

          回复

          1. Wine bottler 可以很好地解决这个问题。

            回复

            1. wine 和 wine bottler 是否适用于新的苹果芯片 mac？也许旧的 intel 机器可以，但不太确定新的 mac 是否可以。

              回复

              1. 是的，可以！不过你可能需要先安装 Rosetta 2。

                回复

    3. 是我的问题，还是葡萄酒需要更多的打磨？对话框和菜单都是用一些奇怪的微型字体渲染的。GDI 文本渲染似乎没有使用字体回退，因此即使是 Scintilla 或电子书阅读器之类的软件在 wine 下也无法正常运行。

      回复

      1. 许多常用的 Windows 字体都是根据专有条款授权的，因此无法与 Wine 一起使用。

        可以使用 Winetricks[1] 直接从微软获取并安装一套默认字体。

        此外，Windows 的字体回退功能与 Linux 和类似系统的字体回退功能大相径庭，后者通常使用 Fontconfig 和 FreeType，并在配置文件中定义字体关系。相比之下，Windows（以及 Wine）采用的是字体链接机制[2]。Windows 本机处理字体链接，而 Wine 则需要手动注册表配置[3]。

        [1] https://github.com/Winetricks/winetricks

        [2] https://learn.microsoft.com/en-us/globalization/fonts-layout…

        [3] https://stackoverflow.com/questions/29028964/font-recognitio…

        回复

        1. 我安装了 Windows 字体。AIU 还不够吗？

          wine 不是委托 FreeType 进行渲染吗？还不如把字体回退委托给 FreeType。

          回复

        2. Wine 自带字体的度量标准应与专有字体相同。请注意，虽然字体文件受版权保护，但字形本身是可以自由复制的。我们已经让 DejaVu 项目重新创建了与现有字体等价的字体，没有理由我们不能为 Segoe 和 Calibri 系列创建同样的字体。

          回复

          1. 我更感兴趣的是在 Linux 中其他地方也能使用的字体回退。反正渲染也不匹配，所以度量也没什么用。

            回复

      2. > 是我的问题，还是葡萄酒需要更多打磨？对话框和菜单使用了奇怪的微缩字体。

        是你的问题。我设置了 DPI 和高分辨率选项来运行旧版 Office 应用程序，它们在我的 2k 笔记本电脑 4k 屏幕上都有非常漂亮的字体。

        试试 `xprop -root -f _XWAYLAND_GLOBAL_OUTPUT_SCALE 32c -set _XWAYLAND_GLOBAL_OUTPUT_SCALE 2`

        回复

  2. > 我可以调出一个 20 年前的 exe，现在仍然可以在 Windows 上运行。试着用一年前的 Linux 二进制文件做同样的事情。IMHO，你只是在比较两种不同的东西。在 Windows 上安装应用程序的传统方法是打包所有动态依赖项。而在 Linux 上，应用程序之间共享动态依赖关系。因此，当你更改应用程序的依赖关系时，它就会停止工作，这并不奇怪。

    有几种方法可以解决这个问题，你可以自由选择：

    – 像在 Windows 上一样分发

    – 静态链接

    回复

    1. 除了比较两种不同的东西外，正如你正确指出的，我认为即使是作者最初的断言也不是真的。也许对某些 exe 文件是这样，但我怀疑对所有甚至大多数 exe 文件都是这样。

      我曾参与过用 Linux + Wine 替换 Windows 系统的工作，因为（关键任务工业）传统软件停止工作了。无论如何调整都无法让它在现代 Windows 系统上运行。一旦找到所有需要的 DLL 文件，使用 Wine 系统就能顺利运行。

      虽然 Wine 可能确实相当稳定，是运行传统 Windows 软件的良好解决方案。我认为，无论是在 Windows 还是 Linux 上，任何动态链接的传统软件都可能造成问题。内核变化也可能是个问题。虽然 Windows 经常被宣称为向后兼容，但实际情况可能会有所不同。很显然，我的客户就发现了这一点，而且还付出了高昂的代价。

      回复

      1. > 我曾参与过用 Linux + Wine 替换 Windows 系统的工作，因为（关键任务工业）传统软件停止工作了。无论如何调整，都无法让它在现代 Windows 系统上运行。在找到所有需要的 DLL 文件后，使用 Wine 就能顺利运行。

        我从 Windows 11 迁移到 Linux 也是出于同样的原因：我使用的是旧版本的 Office，因为它比附带的应用程序更快：完整 Word 的启动速度比 Wordpad 更快（甚至与记事本不相上下！）旧版本 Office 的 Outlook 比 Windows 附带的 Outlook 占用更少的内存，响应速度更快！

        当我换了一台新笔记本电脑时，我身边的旧版本 Office 在安装时都出现了问题，有传言说旧版本 Office 会被阻止。

        我不想冒这个险，于是开始了迁移。

        > 虽然 Windows 经常被宣称为向后兼容，但实际情况可能会有所不同

        ，它是完全向后兼容的： 我真的很喜欢 Windows（还有 AutoHotKey 和许多其他东西），但现在我很喜欢 Linux。

        回复

        1. > 我真的很喜欢 Windows（还有 AutoHotKey 和许多其他东西）

          哦，你知道 – 如何配置 Win+1、Win+2 等切换到相关的虚拟桌面？还有–如何禁用这种缓慢的动画……直接切换？

          也许你有我应该搜索的地方。我使用 Linux 作为操作系统已经有很长一段时间了，但现在我的工作需要使用 Windows。因此，我正试图让我的 Windows 使用体验尽可能接近 Linux 上熟悉和常见的体验。

          回复

          1. 您可以禁用所有系统动画，网址是

            设置 > 辅助功能 > 视觉效果 > 动画效果

            没有内置方法来设置热键以切换到特定桌面。我最苦恼的是无法设置热键将指定窗口移动到不同的桌面。

            回复

          2. > 因此，我试图让我的 Windows 使用体验尽可能接近 Linux 上熟悉和常见的体验。

            我看到你得到了关于缓慢动画的答案。对于大多数用户界面调整，regedit 是一个很好的起点。

            你可能也喜欢 powertoys，但我建议你花时间创建 AHK 脚本，例如，如果你想让你的工作流程以键盘为中心

            > 所以，我试图让我的 Windows 使用体验尽可能接近 Linux 上熟悉和常见的体验。

            我在 arch 上借助 hyprland 做到了相反的效果，但我花了好几年时间才接近在 Windows 上的效率，因为 Windows 上有很多非常完善的工具，可以做任何你能想到的事情。

            回复

    2. 在以二进制文件发布的 Windows 程序中，你不需要从系统层捆绑任何东西。在 Linux 上，系统库和可选库并没有适当的区分，所有东西都可能是系统库和可选库，也没有 API / ABI 保证。因此，”只需捆绑依赖库 “根本行不通。你不能捆绑 Mesa、libwayland 或 GTK，但你也不能完全依赖它们而不破坏兼容性。

      在 Windows 端，没有人会捆绑 Windows GUI 库、OpenGL 驱动程序或音效库。在 Linux 上，系统库必须存在于容器中的某个位置，而且你必须希望它仍然兼容。

      你也不能静态链接所有库。从 Glibc 开始，就有许多库在静态链接时无法完全或根本无法工作。

      回复

      1. 我相信这是真的。但我似乎在用 cmake 为 C/C++ 创建静态可执行文件和库方面取得了不错的成绩（据推测，cmake 会将 -static 传递给 clang/gcc）。

        在 docker 镜像（例如）中使用共享库似乎总是很奇怪，因为如果有任何变化，你都必须重建镜像。

        回复

    3. 只是每个案例中的 “你 “都不一样。你为分发者提供的是选项。这句话说的是用户的选择，用户必须处理分销商的任何问题。从用户需求的角度来看，分销商的选择完全没有用处，如果他们在过去的某个时候被选中，他们的生活就会变得更轻松。

      回复

    4. 我需要静下心来看看 YouTube 上关于这个问题的视频，里面会举例说明。这显然是计算机工程中经常出现的问题，但我一直没有完全理解；我时不时会看到像这样的评论，看起来非常清楚，但我确信还有很多细微差别，我可以从学习中受益。

      回复

    5. 但我认为这并不简单。首先，我认为 opengl 驱动程序的情况很复杂，我听说你需要用户本地的硬件库，而这些库基本上都需要动态链接。从这个角度看，windows 二进制文件是在 linux 上发布游戏事实上最稳定的方式。

      我也不确定 linux syscall ABI 的稳定性，或许还有内核中的其他东西？

      回复

      1. > 我认为 OpenGL 驱动程序的情况很复杂，我听说你需要按硬件划分的用户域库，而这些库基本上都需要动态链接

        是的。你确定 OpenGL ABI 的稳定性有问题吗？我从来没听说过它有什么破坏性变化

        回复

    6. 我也是这么想的。多年来，当我的存档 EXE 因为 DLL 丢失而生气时，我遇到过很多问题。

      同样，正如作者所说，Linux 本身并不存在二进制兼容性问题。如果这是你面临的一个问题，而且你正在考虑制作一个默认通过仿真层运行 EXE 的发行版，那么你最好还是使用 Alpine 或其他基于 musl 的发行版。

      回复

    7. 这就像在克里姆林宫前高喊 “打倒美国总统 “的苏联笑话。在这种情况下，我也可以在 Linux wine 上运行 20 年前的 Windows 二进制程序。

      回复

  3. 我认为不需要新的发行版。大多数常用的 Windows 应用程序都可以通过 wine 运行，但用来运行一个应用程序的黑客技术可能会破坏其他应用程序，反之亦然。同样，每个人都需要对设置进行个性化设置，才能让程序正常运行。在一个人的机器上能用的东西，在另一个人的机器上可能就不能用，因为实际上，配置并不一致。

    在我看来，最简单的解决方案就是分发装有 wine 的容器（或其他沙盒），以及让 windows 程序（只有一个）在容器中运行的必要技巧，然后分发即可。每个人都能得到同样的工具，而且总是能正常运行。无需再对葡萄酒设置做任何手脚，因为无论软件是什么，它都是内置的。

    是的，这样做的空间效率非常低，所以下一步将是如何缩小 wine 的体积，以便在容器中使用。

    这个系统的唯一真正障碍是许可和软件反模式。你可能需要施展一些黑魔法，才能在容器中安装软件。

    回复

      1. TIL。我去看看。很高兴看到有人已经在研究这个问题了，因为在我看来，这是一件非常有意义的事情。你会觉得，如今我们有了这么多层的抽象层，应该可以在任何底层系统上以符合人体工程学的方式运行软件，即使不一定高效。

        回复

        1. 它的效率极高：从旧的 Office 套件冷启动 Word 要比启动 Libreoffice 快得多。它使用的内存也更少。

          几年前，我在 ebay 上购买了几个收缩包装的 Office，每个版本都是 Wine 声称支持得最好的版本，然后用 wine32 和 wine64 进行了测试，最后得出的结论是，在 wine32 中，Office 2010 是 “最佳选择”（随着 Wine 的不断发展，它可能已经发生了变化）

          是的，这是一款 15 年前的软件，但它在使用 Unicode xkb 符号时运行得非常完美！由于它没有任何网络访问权限，而且每个应用程序都被隔离在不同的用户 ID 中，我认为它不会造成任何问题。

          我仍然可以使用 vim 来完成我需要的一切，而且它不会让我意外地看到任何不必要的更改，我不明白为什么我不能以同样的方式使用旧版本的 Excel！

          回复

          1. 看到 90 年代的 Office 套件，我不禁想知道哪些地方确实需要改进。谷歌文档率先在云端实现了 “自动保存”，这是我唯一能想到的。

            回复

            1. 谷歌文档中的自动保存功能无疑更好，但在 Windows 3.1 的 Word 6.0 中，可以以分钟为单位设置自动保存间隔。

              那时，Word 的自动保存功能会更新你正在处理的文件，而不是创建一个单独的备份文件。我比较喜欢这种方式，不过在后来的 Word 版本中，改变这种方式可能是有原因的。

              回复

            2. 协同编辑？”跟踪更改 “就是不一样。

              回复

              1. 这是个好问题。也许 Google Docs 才是办公套件的巅峰之作。

                回复

            3. > 想知道真正需要改进的地方

              也许并不多？

              几个月前，我的电脑没电了（我的失误，我使用全屏应用程序以避免分心，所以我没有意识到我的电源被拔掉了）

              ，插上电源并重新启动 Linux 以及我正在使用的古老版本的 Word 后，我得到了一个惊喜：我正在编辑的文档的 “自动保存 “版本，没有任何丢失！

              至于 llm，Excel 2010 可能不是为人工智能而生的，但葡萄酒复制/粘贴和一些脚本的效果出奇地好！

              回复

              1. 自动保存一直是 Excel 的一部分。早在 20 世纪 90 年代初，我就启用了自动保存功能，当时的版本是与 Word 6 一起作为 Office 4.3 的一部分发布的（我不记得 Excel 的版本号了）。

                回复

                1. 当前的 Excel 自动保存功能在与 ODSP 一起使用时是不同的–更改是单独自动保存的（更改单元格、自动保存、格式化表格、自动保存）。它们对最终用户完全透明。

                  Word 与之类似。

                  回复

              2. 所以你是说你使用的是 Word 2010，而且最近创建的文件没有问题？我对现代 Word .docx 兼容 15 年前的 Word

                回复

                1. 感到惊讶。现代 Word 套件的基本格式是在 Word 2010 中引入的。因此，只要创建文档的人使用的是 Word 2010 以前的功能，就不会有问题。

                  以后版本的功能要么不会显示，要么显示为方框

                  回复

                2. 不过这并不奇怪。它是压缩的 xml。未来的版本可能会在 xml 中添加可选节点，这些节点会被之前的版本忽略。

                  回复

          2. > 每个应用程序都被隔离在不同的用户 ID 中

            我一直很喜欢这个想法；但你不会遇到文件权限问题吗？如果不会，那不就意味着有关程序无论如何都可以访问你的所有文件，从而消除了隔离的好处？

            回复

            1. 当我使用 Office 时，文件来自一个共享目录，可以通过 Z:

              访问。我使用脚本自动处理所有事情，包括允许 wine 使用 Xwayland（因为在我启动我想要的应用程序之前，它的用户id 不允许在我的显示器上显示内容）

              如果你想尝试使用不同用户id 的 wine，可以尝试从 /tmp 中的一个目录开始，比如 /tmp/wine，它是组可写的，你的 windows 应用程序和你的用户属于同一个组。

              回复

      2. 我很喜欢瓶子的想法。我希望能有办法把它捆绑到一个发行版中，让用户看不到它，这样我就可以用它来设置我的朋友和家人了。

        回复

          1. GlassBottle，希望幻觉不会被打破！

            回复

    2. 你可以将 Wine 作为 Flatpak 平台进行分发。Flatpak 已经是在所有发行版上都能运行的容器。使用同样的工具，以同样的方式制作一个 Win32 基本版并不困难。

      回复

      1. 曾有过 Winepak（可惜已被弃用）：https://winepak.github.io/

        回复

    3. Flatpak 可以更好地工作，因为它已经知道如何去掉共用部分，所以它可以只引入一个（或几个）版本的 Wine。

      回复

      1. 不幸的是，Flathub（最大的 Flatpak 仓库）不允许使用 Windows 应用程序，尽管它在技术层面上是可行的

        回复

        1. https://docs.flathub.org/docs/for-app-authors/requirements 说，

          > 使用 Wine 的 Windows 应用程序提交，或任何非 Linux 桌面原生、使用某种模拟或翻译层的提交，只有在上游正式提交并有意以官方身份维护的情况下，才会被接受。

          不过，我很好奇为什么；他们对非官方软件包似乎没有什么意见，所以我不知道为什么翻译层会有什么不同。这似乎与使用其他运行时没有什么不同（例如，没有提到 Java 或 .net）。

          回复

          1. 可能是因为它暗含盗版。没有人会以这种方式共享 Windows 免费软件，因为没有需求。它将是 MS Office、Photoshop、CAD 等。– 这些软件仍然没有很好的开放源码软件替代品，而且进入门槛很高。

            这需要一个有足够人脉的大型组织来突破。你可能需要达成一项协议，这样你就可以分发他们的软件，你还需要为用户提供购买机制。即便如此，也会面临各种许可方面的挑战，因为你将分发的是同一个安装包，所以成千上万（或数百万）的 “安装包 “实际上将拥有相同的序列号或许可证号。

            这并非易事，但基本思路是直接可行的。挑战在于 Windows 软件的分发和许可方式，而非技术问题。

            回复

            1. 我只是在胡思乱想。如果能像共享 Docker 文件那样共享可复制的配方，岂不是更好？具体来说，对于 wine 来说，可以类似于使用 FROM wine-1.23。只要我们保持配方的维护，并将其 “固定 “在旧的依赖关系上。

              我认为这可以作为一个转换层，因为容器已经在系统调用层面抽象掉了一切。

              必须有一个图形用户界面来实现这一点，它可以为每个应用程序轻松创建多个沙箱，并记住你在其中配置和安装的内容（并将其添加到 Winefile 中）。

              关于共享序列号的问题：你可以很容易地将 wine 添加到那里的 .reg 文件进行差异化，如果在 \software 中弹出任何东西，你可以认为这是一个自定义字段，并将其作为容器的环境变量？

              回复

            2. 他们在 https://docs.flathub.org/docs/for-app-authors/requirements#l 中确实提到了这一点… 但在一般情况下我并不买账，因为 Windows 并不等同于专有软件，也不等同于不可重新分配的许可证。当然，我怀疑是否有合法的方式在 flathub 上发布 Microsoft Office，但我认为有很多共享软件都可以（当然，这是我的个人观点），甚至是碰巧针对 Windows 的 FOSS。例如，Notepad++是GPLv3[0]和WINE白金级[1]，为什么不能在flathub上使用呢？

              [0] https://github.com/notepad-plus-plus/notepad-plus-plus/blob/… [1] https://appdb.winehq.org/objectManager.php?sClass=applicatio…

              回复

              1. 我觉得也不一定是这个原因。他们可能只是想保证应用程序能继续运行，而不是有人提交了上百个葡萄酒应用程序，最后都坏掉了。

                回复

            3. > 可能是因为它暗含盗版。

              其实不必如此。旧软件很便宜，即使是收缩包装的（”新旧库存”）

              回复

          2. 他们只是想优先考虑 linux 应用程序，而不是阻止那些想通过 wine 支持 linux 的开发者这样做。

            关键的区别在于，在 wine 下运行的应用程序总是会有一些细微的怪癖和错误行为，从而破坏了可用性，而开发者可以在有机会的情况下解决这些问题。

            回复

        2. 这在我看来是合理的，当然它应该有自己的版本库。

          回复

    4. >我认为不需要一个新的发行版。大多数常用的 Windows 应用程序都能通过 wine 运行

      ，我认为我们的想法是提供类似 Windows 的无缝体验，这样用户就能像在 Windows 下工作一样工作。用户无需摆弄、修改配置，也无需纠结于不同的设置。只需点击并运行即可。

      回复

      1. 是的，这也是我在后面的文章中提到的。你可以分发一个装有 wine 的容器，只需进行必要的配置即可让软件在容器中运行。编写一个薄薄的抽象层是很简单的，它可以拉动容器（安装），并为你提供一个可执行文件，你可以双击并启动它。

        最终用户无需修改配置或进行设置，因为上游已经为你完成了这些工作。你只需获得一个可以点击运行的文件。从其他帖子来看，Proton 和 Steam Deck 已经做了类似的事情，这在概念上也与 AppImages、Flatpaks 等的工作方式类似。

        回复

    5. 这就是 Steam 中 Proton 的工作方式

      回复

    6. 在这一点上，没有人会去学习一个新的系统。人们已经知道如何编写和打包 exes，这才是关键所在。

      > 但用来使一个应用程序正常工作的黑客技术可能会破坏其他应用程序，反之亦然

      我认为，如果有一个以支持 Windows exes 为唯一目标的单一操作系统，很多问题都可以避免。

      回复

      1. 这个系统已经存在，它叫 SteamOS。

        回复

        1. 如果没记错的话，Proton 的一个重要功能就是控制每个应用程序的单独配置，这正是为了让你能在本地进行所需的调整。

          回复

          1. 是的，您可以进行这种针对特定应用程序的调整，但与过去相比，现在基本上不需要了。

            回复

            1. 一般要求少还是用户要求少？在我的印象中，Proton 所做的部分工作就是将所有这些调整捆绑在一起，这样你就不用考虑这些问题了，但实际上我还没有深入了解过。

              回复

        2. SteamOS 很明显是 Linux 系统，而这并不是博客所暗示的。

          回复

      2. 使用 docker 作为软件包管理器是可行的。我以前的工作正是如此，因为我们需要为应用程序编译某些依赖项，而它简化了整个过程。

        你没有理由不在 docker 周围创建一个小的抽象层，这样你就可以安装 “可执行文件”，而这些文件其实只是在容器中启动而已。我的意思是，这不正是 flatpak、snaps 和 appimages 背后的理念吗？

        重点是利用现代抽象技术，让人们无需学习新系统。

        回复

        1. 这可以通过使用类似 llamafile 的东西来实现，因为它将是一个包含软件包的小型通用可执行文件。

          它甚至可以支持在 Windows 上作为自包含的应用程序运行，并提供所有需要的 DLL。

          回复

    7. 如果你改变了 Linux 系统的很多东西，那么你就是在制作一个新的发行版。

      无论如何，这种不兼容性有一半是因为 Linux 的灵活性。我的系统和你的系统不一样，有人在两个系统上都测试过吗？如果你想要一个更稳定的 ABI，那你就需要一个更稳定的系统。

      回复

      1. 你不必改变任何底层系统，这才是关键所在。无论底层系统如何，容器的工作原理都是一样的，因此它们可以避免每个人的机器存在的各种差异。我在家里的 Fedora 和 Ubuntu 系统上经常使用相同的容器，没有任何问题，而在工作中，我也为 RHEL 和其他各种系统制作容器。容器的一半意义在于消除开发系统和部署之间的差异。

        与其让每个人都在自己的机器上运行软件，不如让软件在容器中运行一次，然后直接分发。

        回复

        1. 容器之所以能工作，是因为你的内核几乎完全相同，而其他所有东西都是自己拷贝的，这使得它们变得臃肿，在用户模式层面也不兼容（没有图形驱动程序！）。如果我的内核也与你的大相径庭（可能只是几个内核选项或主要版本），我就需要虚拟机了。

          回复

  4. 这个问题与以下事实有关：Linux 发行版通常会动态链接可执行文件，不会保留这些库的旧版本，而 Windows 则会。

    这是 Windows 基本安装比一般 Linux 基本安装重得多的众多原因之一。

    Windows 保留旧版本的可执行文件而 Linux 不保留的原因是，Windows 没有像 Linux 发行版那样的软件包管理器。好吧，现在有了 Windows Store 以及最近基于众多非官方软件包管理器之一的 CLI 工具，但传统上安装 Windows 应用程序的方式是手动下载和安装。因此，这些安装程序通常会捆绑安装所需的共享库，而且这些共享库通常位于应用程序目录中。这就导致了大量库的重复。

    在 Linux 中，你也可以很容易地做同样的事情，但由于 Linux 发行版的软件包管理器一般都非常好，所以需求较少。但有些第三方软件包管理器确实采用了这种方法，如 Nix、Snap 等。

    因此，这并不是说 Linux “不稳定”，而更多的是人们在 Linux 上以完全不同的方式来解决同样的问题。

    拖放安装能在 macOS 上运行这一事实表明，并没有类似 UNIX 的限制阻止 Windows 风格的安装。更多的是，Linux 发行版偏爱不同的应用安装方法。

    回复

    1. 这不仅仅是动态链接可执行文件的问题。从时间上来说，Linux 的用户态域并不像 Windows 那样稳定，尤其是以几十年为单位。

      举个例子，Linux 的最新 Atari Jaguar 链接器 (aln) 早在 1995 年就发布了。它是一个专有的、静态链接的 32 位 Linux a.out 可执行文件。要在现代 Linux 系统上运行它，你需要

      – 将 vm.mmap_min_addr 从 65536 降到 4096，这是一个特权操作 ;

      – 使用 a.out 加载器，因为 Linux 内核早在 2022 年就放弃了对 a.out 的支持 ;

      – 如果你的系统不支持 32 位 x86，可能需要使用 qemu-user。

      这是最好的情况，因为一些旧的 Atari Jaguar SDK Linux 二进制文件是动态链接的 a.out 可执行文件，而你基本上只能在虚拟机中运行古老的 Linux 内核。AtariAge 论坛上有人曾认真考虑使用我的脱链黑魔法将这些老程序移植到现代 Linux 中。用 Ghidra 对可执行文件进行逆向工程以导出可重新定位的对象文件来重新链接（还有一些额外的步骤我就不多说了），这甚至是一个摆在桌面上的选项，这就很能说明问题了。

      当然，只要有足够的决心和大量的黑客手段，你或许可以在现代系统上强行运行任何老式的随机 Linux 程序，但 Windows（或 Wine 或 ReactOS）很有可能只需极少的兼容性调整就能运行三十年前的 32 位 x86 PE 程序。Linux（包括发行版和内核）根本不关心这种使用情况，以至于如果有人能运行企鹅 Tux，我会感到非常惊喜： A Quest for Herring》能在现代系统上正常运行，我会感到非常惊喜。

      回复

      1. > 这不仅仅是动态链接可执行文件的问题。从时间上看，Linux 的用户界面并不像 Windows 那样稳定，尤其是以几十年为单位。

        这正是动态链接可执行文件的本质：用户界面

        > 举例来说，Linux 的最新 Atari Jaguar 链接器（aln）早在 1995 年就发布了。它是一个专有的、静态链接的 32 位 Linux a.out 可执行文件。

        这不是用户土地的问题。这是 CPU 架构问题。Windows 解决了这个问题，WOW64 为 32 位指针等提供了一个兼容层。

        Linux 也有 32 位的兼容层，但它们都是“……”。如果你运行的是 a.out 文件，这将会有所帮助，因为它是一种完全不同的可执行文件格式（即不等同于 32 位静态编译的 ELF）。

        Windows 的 COM 文件（早期的 DOS 可执行文件格式）也有类似的问题。Windows 上的许多 COM 可执行文件也无法运行。Windows 可以通过仿真来解决这个问题，而 Linux 也可以。Linux 的尴尬之处在于，它没有将这些虚拟机作为基本安装的一部分，但为什么要这样做呢，因为几乎没有人会去运行随机下载的 32 位 a.out 文件。

        说白了，我并不是说 Linux 的向后兼容性比 Windows 好。显然不是。但问题的答案并不是因为 Linux 不能向后兼容，而是因为 Linux 传统上并不需要向后兼容。不过，Windows 在兼容性问题上使用的所有工具，Linux 也可以用于 Linux 可执行文件。

        回复

        1. >> 举例来说，Linux 下最新的 Atari Jaguar linker (aln) 早在 1995 年就发布了。它是一个专有的、静态链接的 32 位 Linux a.out 可执行文件。

          > 这不是用户土地的问题。这是 CPU 架构问题。Windows 解决了这个问题，WOW64 为 32 位指针等提供了一个兼容层。

          在这种特殊情况下，这确实是一个用户土地问题。

          我费尽周折才把这个特定的可执行文件转换成静态链接的 32 位 x86 ELF 可执行文件[1]，以便在现代 x86 和 x86_64 Linux 系统上原样运行。除了以更高的虚拟地址重新编排和编写大约 10 行汇编来桥接入口点外，它的二进制代码与原始文件完全相同。除非你特别禁用或移除 32 位 x86 仿真，否则它就能在未安装 32 位用户态兼容层的 x86_64 内核上运行。

          为了好玩，我还把它转换成了动态链接的可执行文件（使用了一些胶水来连接 glibc 1.xx 和 glib 2.xx），甚至转换成了可以在 Windows 上运行的 x86 PE 可执行文件（使用了更多胶水和 MSYS2）[2]。

          > Windows 对 COM 文件（早期的 DOS 可执行文件格式）也有类似的问题。很多 COM 可执行文件在 Windows 上也无法运行。Windows 通过仿真解决了这个问题，而在 Linux 上也能做到这一点。

          这些情况并不等同。COM 和 MZ 是用于 MS-DOS 的 16 位可执行文件[3]，NE 是用于 16 位 Windows 的可执行文件；它们都可以在 32 位 x86 Windows 系统上正式运行，无需变通方法（NTVDM 的兼容性确实有问题，但这一点是成立的）。在这里，我们讨论的是 32 位 x86 代码，因此 COM/MZ/NE 在这里并不适用（据我所知，从来没有 16 位 Linux 程序）。

          Windows 开箱即有 32 位兼容性，Linux 发行版默认情况下不安装 32 位兼容性层是一回事，但 Linux 上的这些兼容性层只适用于与主机系统共享同一版本的程序（最坏的情况是只适用于同一发行版）。同样，试试运行企鹅 Tux： 在现代系统上运行 Tux Penguin: A Quest for Herring（无论是 32 位还是 64 位安装，这部分在这里并不重要），如果不进行大量重写和重新编译，或者不把 2000 年代的 Linux 用户空间移植到 2020 年代的 Linux 用户空间上（不，虚拟机不算，它必须在主机上运行），我很乐意证明自己是错的。

          [1] https://boricj.net/atari-jaguar-sdk/2023/12/18/part-3.html

          [2] https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html

          [3] 我知道 32 位 DOS 扩展器，但如果不把这些扩展器加进来，就已经够复杂了。

          回复

          1. >

            a.out 在新的 Linux 内核中甚至都不支持，这怎么会是用户的问题呢？然后你又重复了我的观点，通过描述它是如何作为 ELF 运行的，来说明这不是用户土地问题。）

            > 这些情况并不等同。COM 和 MZ 是用于 MS-DOS [3] 的 16 位可执行文件，NE 是用于 16 位 Windows 的可执行文件；它们都可以在 32 位 x86 Windows 系统上正式运行，无需使用变通方法（NTVDM 的兼容性确实有问题，但这一点是成立的）。在这里，我们讨论的是 32 位 x86 代码，所以 COM/MZ/NE 在这里并不适用（据我所知，从来就没有过 16 位 Linux 程序）。

            你没听懂我在说什么。

            COM 和 a.out 是等价的，因为它们都是原始格式。即使在 32 位 NT 系统上，COM 也需要仿真。

            问题在于，它们的文件格式更像是原始机器码，而不是现代容器格式。

            所以，没错，一个是 16 位，一个是 32 位，但你所说的问题是文件格式在没有仿真的情况下无法适应不同的 CPU 架构，而且在很多情况下，完全无视用户土地。

            你自己也承认，32 位 PE 和 32 位 ELF 在各自的 Windows 和 Linux 系统上运行得非常好，无需任何破解。

            这里的区别在于，Windows 将 WOW64 作为基本安装的一部分，而主流 Linux 发行版并不将 32 位库作为基本安装的一部分。但这并不意味着您需要为 32 位设置黑客。例如，在 Arch 上，只需在 pacman.conf 中取消一行注释即可。

            我的意思是，如果你想发布一个支持随机 ELF 二进制文件的 Linux 发行版，那么你就可以做到。像 Nix 这样的软件包管理器就证明了这一点。

            在 Linux 上更难的原因不是因为它需要黑客。而是因为 Linux 在安装应用程序方面有着完全不同的设计，因此向后兼容随机 ELF 通常不值得费力气。

            此外，说 a.out（一种定义于上世纪 70 年代的格式，在所有类 unix 系统中早已被淘汰）是 Linux 不向后兼容的证据，也实在是不公平。ELF 作为 Linux 的主要文件格式已有近 30 年的历史，而 a.out 只是最近才从内核中完全删除。

            而 COM 在 Windows NT（包括 Windows 2000 和 XP）上一直都存在问题。

            回复

    2. >这是 Windows 基本安装比一般 Linux 基本安装重得多的众多原因之一。

      如果能为用户带来无缝体验，这难道不是一件好事吗？存储很便宜。

      回复

  5. 在此补充一点，我认为在某种程度上，我们已经看到旨在将 Windows 用户转化为 Linux 用户的发行版正朝着这个方向发展。Zorin OS 几乎开箱即支持 Wine 的 .exe，还有 Steam OS / Proton，其中（如果我没记错的话）Steam Deck 的官方指南规定，开发者不应为新游戏创建原生 Linux 移植，而应围绕 Proton 本身进行优化。

    回复

    1. 我在阅读时也有同样的想法，而且…… 我觉得自己老了。

      回复

    2. 是的，我记得这个！在某些时候，他们甚至声称 “Windows “这个词太笼统，不受保护，他们想在项目中使用这个词……

      回复

    3. 一个厂商必须在头版写一条新闻，说明自己的产品还没有死？也许这不是最吸引人的样子。

      回复

      1. Lindows 在 2001-2002 年期间引起轰动，其目的是弥合差距，通过 “点击并运行 ”服务为 Linux 上的 Windows 应用程序提供适当的支持。

        在微软起诉他们并改名之后，泡沫破灭了，当 Ubuntu 出现时，它作为初学者发行版的优势也逐渐消失了。

        一两个月前，我从迈克尔-MJD的一段视频中听说它还活着，感到非常惊讶。

        回复

    4. 啊？Linux Mint 看起来更像 Lindows 而不是 Linspire。

      回复

      1. 幸运的是，我猜你还没用过 windows 11。

        回复

  7. > 虽然 Linux 系统调用本身非常稳定可靠，但其上的 c 库却并非如此。几乎所有的用户态都基于 libc，因此，Linux 本身也存在二进制兼容性问题。

    主要使用 Linux 的人经常会忘记，Windows 也有同样的问题。在 Windows 中，libc 是作为 Visual C++ 运行时的一部分发布的。每个版本的 Visual Studio 都有自己的 V C++ 运行时版本，应用程序需要重新分发它所需的 V C++ 版本。

    Windows 唯一做得好的地方就是确保在发布新版 Visual Studio 之前保持 libc 的向后兼容性。

    回复

    1. 在 Winapi 领域，与 “c 库 “相对应的是 NTDLL、其包装器和其他支持库（advapi32、userenv 等……以及 Win32 特定库，我认为它们等同于 X11 库）。在我看来，MSVCR 的作用是为 C/C++ 程序提供标准库。在 Linux 环境中，提供 C stdlib 的库还封装了系统调用，而在 Windows 环境中，C stdlib 是 Windows api 的封装器/接口。

      我认为它们都很棒。我非常喜欢 Windows API 的简洁和深思熟虑。与 Linux 对应程序相比，它们非常稳定，而且更易于使用。但这并不意味着这两种操作系统上的 C stdlib 实现有什么问题。但就系统 API 而言，Linux 有点乱，这种乱是由许多人各持己见造成的，也是 Linux 试图遵循 Unix 模块化用户空间生态系统原则的结果。

      例如，Linux 没有 “Linux 图形 api”，有 X11 和 Wayland，谁知道还有什么其他的，但它们都与 Linux 项目无关。做一些简单的事情有很多不同的方法，Linux 就应该是这样。同样，在 Linux 上安装应用程序只需查询软件包管理器即可，但在 Windows 上却没有一个 “微软软件包仓库”，每个人都在那里发布自己的应用程序（尽管他们正试图通过多种方式解决这个问题），而这也正是 Windows 的应有之义。

      让 Linux 做 Linux，让 Windows 做 Windows。如果你欣赏它们的本质，并相应地使用它们，那么它们都很棒。

      回复

      1. 解释得非常好，谢谢。

        > 让 Linux 做 Linux，让 Windows 做 Windows。如果你欣赏它们的本质并相应地使用它们，那么它们都很棒。

        如果你在技术上更喜欢 Windows 的方式，但又担心微软在商业策略、锁定、隐私等方面的行为，那该怎么办？

        作者设想了一个技术上像 Windows 一样稳定，但又像 Linux 一样自由的系统。

        回复

        1. 微软一直对最终用户怀有敌意。你可以黑掉它）

          反向设计它的不良行为，减轻它的影响。真正让我害怕的是基于硬件的东西（例如安全飞地计算），以及它为防止我们黑客攻击而采取的法律措施。

          ReactOS 和 Wine 都存在。Linux 是一个纯粹的单片内核，而 NT 则不同，它是一个混合内核，其中包含子系统的概念。Linux 必须有子系统的概念，并有一个 NT 互操作层（可能基于 Wine），我看不出它比 Wine 有什么优势。

          最后，我要问的是，需求来自哪里？在我看来，不是来自 Linux 开发人员。我想，以 Wine 为核心的发行版可能会取悦像你这样的人，但 Wine 本身有很多 bug 和错误，即使这么多年过去了。我甚至怀疑它是否能跟上 Windows11 的所有变化，在我看来，作者的建议并不实用，至少如果你期望获得比 ReactOS 或 Wine 更好的体验的话是如此。如果只是 Win32/winapi 互操作层，也许可行，但开发人员需要它，否则谁会使用它呢？

          根据我的经验，Linux 用户是最 “固步自封 “的，试着说服任何 Linux 开发人员停止使用 gtk/qt 并为 “这个新的类似 Windows 的 api 接口来创建图形应用程序 “编写应用程序吧。

          ，但最终，除了浪费时间和资源外，尝试一下并无坏处。我也希望看到一个在很多方面（尤其是安全措施）都能学习和模仿 Windows 的生态系统。

          回复

      2. >做一些简单的事情有许多非常有主见的方法，Linux 就应该是这样的

        我仍然相信，如果 BSD 在 Linux 之前就准备好被采用的话，我们的情况会更好。Linux 是一个内核，是由内核和不同的零碎部件组装而成的一个广泛的操作系统家族，而 BSD 则从一开始就试图成为一个非常连贯的操作系统。

        回复

    2. 我记得曾试图在 Windows 上安装一个程序。它抱怨说我没有正确的 VC 可重新发布程序。

      我大概安装了十个，我想有几个是同一年安装的！- 因为每个程序通常都捆绑了自己的程序。

      我找到了我需要的 vcredist 安装程序的确切版本，但它拒绝安装，因为我已经有了一个稍新的版本。所以我不得不先卸载那个版本。

      据我所知，这个问题在 Wine 中依然存在，我昨天在 Wine 中安装了一些东西，不得不使用 winetricks 命令从微软服务器上获取 vcredist 安装程序。(还非法下载了一些字体，否则我的安装程序拒绝启动……）。

      回复

      1. 下次再遇到这种情况，请搜索 “vcredist aio”。我不能为任何脚本背书，但有很多脚本可以从微软下载字体，并使用无人值守标志进行安装。

        回复

    3. libc 更新真的是 Linux 上 ABI 中断的主要问题吗？虽然 Glibc 并不完美，但它已经对符号进行了很长时间的版本控制。我猜问题实际上出在其他库的废弃版本上（如 SDL1、旧版本的 gtk2？

      回复

      1. 是的，glibc 非常稳定，你可以确信现在用它编译的应用程序在未来也能正常运行。人们只是道听途说，完全忽视了这一事实，也忽视了从 glibc 二进制文件中移除一个未使用的符号散列表破坏了一些试图解析它的 anticheat 系统。

        问题通常出在其他库上。当 ABI 以一种向后不兼容的方式发生变化时，人们通常会很好地更改库的 .so 版本。通常情况下，发行版会同时提供两个版本，直到所有发行版本都升级或被移除。像 appimage 这样的解决方案可以让你在应用程序中使用这些库。

        回复

        1. 一切都很好，直到遇到 64 位文件偏移和 time_t 等不匹配情况。

          回复

          1. 如果你是认真的，那么好消息就是：现在你可以拥有一个单一的 glibc，支持使用或不使用 -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 编译的程序。

            回复

      2. 问题在于向后兼容性。

        有人在最新的 Linux 发行版上构建了自己的软件。但它却无法在旧版本（甚至许多当前版本）的 Linux 桌面上运行。人们诅咒 Linux ABI 不稳定，因为新的二进制文件不支持旧的操作系统。事实上，这与 Windows 的情况恰恰相反，旧版本的软件可以继续在新操作系统上运行，但要让最新的 Windows 软件在 Windows 95 桌面上运行，那就祝你好运了。人们很快就会把这两种情况混为一谈，以便在互联网上获得更多虚假的分数。

        这种情况并不局限于台式机。例如，一种非常流行的商业 source forge 网络服务无法在 10 周前发布的浏览器上运行。网络本身已经变得极不稳定，除了人工智能机器人消费其他人工智能机器人的东西之外，几乎无法使用任何东西。

        回复

    4. > Windows 唯一做得比较好的是确保在发布新版 Visual Studio

      之前保持 libc 的向后兼容性，但它们是并排安装的，至少是主要版本。

      回复

    5. 一个很大的区别是，你可以很容易地安装一个最新的 MSVCRT。如何在 RHEL 8 上升级 glibc？据我所知，基本上不能。

      回复

      1. Linux 是基于开放源码软件的，所以答案就是从源代码重新编译。

        除此之外，还可以在容器中运行

        回复

    6. Windows 在 Win10 中使 libc 稳定（ucrt.dll 又名 “通用 CRT”）。只有 C++ 运行时仍需重新发布。

      回复

  8. 我饶有兴趣地阅读了这篇文章和评论。我只想问一个问题：如果 Windows ABI 如此稳定，以至于 20 年前的程序都能保证运行，那为什么还有一些装有 Win95 或 NT 的计算机没人敢动，以免某些特定软件停止工作？我在工业环境中看到过很多这样的情况，但在公共图书馆、公司数据库等地方也有。

    回复

    1. 实际上，这些机器本身就是一种环境。这并不是说它们不能升级，而是说如果出现硬件故障，它们甚至可能无法重建。他们所冒的风险是，系统因被触碰而损坏的可能性比硬件故障更大。我们中的大多数人都能证明这一点，但事实并非如此。

      与此相关的是，在之前的一份工作中，我们运行着一个绝对古老的软件，它对我们的开发工作流程至关重要。这台机器出现了某种问题，于是有人对硬盘进行了镜像，将其作为虚拟机启动，我们又恢复了正常工作。我最后一次听说它还在运行，没有被动过，也没有人维护。

      回复

    2. > 如果 Windows ABI 如此稳定，20 年前的程序都能保证运行

      实际上并非如此；没有任何保证。微软会尽最大努力确保大多数应用程序都能继续运行。但应用程序多达数十亿，并不是所有程序都能正常运行。许多应用程序甚至无法正确遵从 Win32 API。如果应用程序足够重要，微软有时会确保行为不端的应用程序也能正常运行。

      回复

    3. 这通常与驱动程序有关，而不是应用程序。Windows 驱动程序模式无法保持长期兼容性。

      回复

    4. 为什么要碰它？这些设备通常不直接连接互联网。有些可能是虚拟化的。在 linux 上 “更新 “使用 wine 本身就是一项艰巨的工作，你会遇到无法预见的问题。没有人愿意为此付出代价，也没有人愿意在净收益为零的情况下为这些问题负责。

      回复

    5. 我知道，在我的使用案例中，所有这些古老的机器都是与一些古老的硬件交互所必需的，而不是葡萄酒特别有用的情况。

      回复

    6. 因为它们就是能用。没人在乎他们的核磁共振成像仪是否运行 Win2000，他们在乎的是这台机器是否能发现脑癌。

      回复

      1. 他们关心的程度是一定的，而这个程度就是趋势科技为防火墙产品精心调整的酬劳大小，该产品可以让 Windows 2000 核磁共振成像仪与医院 DC 安全地共存于网络中。

        回复

  9. FYI：运行 exes 不需要内核补丁。binfmt_misc 可以处理这个问题，而且 wine-binfmt 已经存在，可以通过 Wine 自动运行 PE 文件。

    回复

  10. 我认为这种对 Linux ABI 的态度可能已经过时了–对于 20 年前的 Linux 二进制文件来说，那只是 2005 年的事情，所以几乎可以肯定它将使用 glibc（没有过时的 libc5）。Glibc 具有很好的向后兼容性，只要你拥有所有 .so 文件，二进制文件就能在今天的任何 glibc 发行版上运行，就像在 Windows 上需要 .dll 文件一样。

    回复

      1. glibc，而不是 glib。那是另一个库。

        回复

      2. 这说的是 “glib”，与 “glibc ”不同。

        Glib 是 GTK 项目的一个库，提供与 GTK widget 工具包相关的实用功能，而 glibc 是 GNU C 库。

        有趣的是，这类超越核心的库总是给我带来麻烦，而不是真正的核心 GNU C 库。

        回复

    3. > Glibc 有很好的向后兼容性

      我们显然不是生活在同一个宇宙里。

      glibc 的向后兼容性太可怕了。

      Every. 单。时间。我试着在现代发行版上使用一个旧的二进制文件，它就炸了，通常会出现一些难以理解的错误信息，其中 GLIBC 是大写的。

      如今，你甚至无法静态链接 glibc，一旦尝试，它就会对你狂吠不止。

      事实上，正如文章所指出的，glibc 的这一缺陷完全否定了 Linus 不惜一切代价保持用户态向下兼容所做的工作。

      回复

    4. 有几个问题：

      1. GNU libc 在兼容性方面是个例外。

      2. 你不能只在二进制文件旁边放一堆 GTK 库，然后指望它能正常工作。这些库通常需要非常特殊的文件系统布局。

      回复

      1. 2005 年，炙手可热的 Windows 新技术是 .NET Framework 1.1 或 2.0。你也不能只把 Framework 1.1 的库放在二进制文件旁边就指望它能工作，它需要正确安装。

        回复

        1. 没错，但你现在仍然可以在 Windows 上安装 .NET 3.5，它可以很好地运行 .NET 2.0 应用程序。

          .NET 1.x，没错。

          回复

        2. 最新的.NET Framework 仍然保留了 1.1 程序集，以保证兼容性。没错，.NET烂透了，最终被半抛弃。

          回复

          1. 这一定是来自另一条时间线。.NET目前的情况除了0%被遗弃之外，没有任何其他可能。

            回复

            1. .NET Framework 1.x 运行时已不再受支持，.NET Framework 2.0 运行时（v2.0-3.5 应用程序使用）在 2029 年后将不再受支持。他们正在慢慢放弃对旧版应用程序的支持。

              (是的，如果你在配置文件中做了手脚，它们可能会在 .NET 4.0 运行时上运行。但这不是普通用户能做/会做的事情）。

              回复

          2. 它保留了向后兼容的类，而不是程序集。有些代码仍未从它们中迁移，以免造成无谓的混乱。此外，它还具有网络扩展性，因为无类型集合可以像 javascript 一样保存不同类型的值。

            回复

          3. 你在说什么？.NET从未被抛弃！.NET从未被抛弃！如果说.NET现在达到了一个非常高的水平的话。它是跨平台构建应用程序的顶级框架之一。

            回复

            1. 他们指的是（我希望是）.NET 框架，该框架仅适用于 Windows，最新版本为 4.8。它的寿命应该很长，因为微软的服务器基础架构就是建立在它的基础上的（SharePoint/Exchange）。

              回复

            2. .NET Framework 与 WPF 和 .NET 1.1 时代的其他技术一样，确实正在被边缘化。

              回复

      2. 我仍在运行一个 2012 年未修改的 GTK2 应用程序，因为我不喜欢 GTK3 版本，我只是从一个古老的 debian 版本中抓取了一个 .deb。

        回复

      3. 容器化（cgroups 和命名空间）解决了这一问题，大约 12 年前出现的 docker 最早普及了容器化。而像 flatpak 和 snap 这样的新生事物只是容器化的附加功能而已。

        回复

        1. 我有一些几年前的 flatpak，但由于一些 GL 问题，它们（Krita）已经不能用了。

          回复

          1. 我听说 OpenGL 的兼容性很差，这也是游戏使用 DirectX 的原因。

            回复

  11. Valve 的 Steam OS（以及受其启发的发行版）基本上已经做到了这一点。它以游戏为中心，但其他一切（如果你幸运的话）在 Linux 中都得到了原生支持。

    你可以在 Proton 上运行非游戏。大多数东西都能运行。

    回复

  12. 问问 IBM 这个想法效果如何。

    我认为可以说，OS/2 的 Windows 兼容性（在那个时代）比 Wine 提供的更好（在这个时代）。问题在于，随着 Windows 95 的推出，微软对其进行了彻底改变。虽然旧的 Windows 应用程序可以继续在 OS/2 下运行，但 IBM 认为，为 Windows 95 引入兼容层将耗费太多精力。如果我没记错的话，这涉及到 OS/2 处理内存的限制。

    此外，由于 Linux 中使用的大部分软件都是开源的，因此二进制兼容在 Linux 中从来都不是一件大事。人们希望它能与更新的库进行编译和链接，但现有的二进制文件却没有保持兼容的真正动力。如果软件无法编译更新版本的库，那么 Windows 也有类似的问题。

    回复

    1. 如果 OS/2 的销售量更大，windows95 兼容性层本来是可行的。

      最新的多平台打包系统（如 Nix 或 Flatpak）在很大程度上解决了二进制兼容性问题，但也提供了一些库版本的保证。这种方法在拥有廉价存储和快速带宽的现代环境中更有意义。

      回复

  13. 我不知道为什么会有这么多反对者。自从蒸汽甲板发布之初，我就有同样的想法，并认为这是个好主意。在我的设想中，用户不会发现任何 Linux 的痕迹。

    回复

  14. > 在 Linux 中，你可以直接进行系统调用…

    > 在 Windows 中，你不能直接进行系统调用，而是要动态链接到为你进行系统调用的库。

    既然 Linux 的系统调用接口是稳定的，那么实际问题难道不是出在 glibc 共享库上吗？(正如 “不要破坏用户空间 “所承诺的那样）–例如，我希望能在现代 Linux 上运行一个 20 年前的 Linux 二进制程序，它只做系统调用，这个假设有错吗？

    Windows 系统 DLL 的 ABI 稳定性也只是一个方面，从历史上看，微软一直在努力为流行的应用程序保留向后兼容性，即使这些应用程序依赖于 Windows 中的错误，而这些错误已在后来的 Windows 版本中得到修复。

    我认为，Windows 的引擎盖下有很多特定应用程序的黑客，可以让特定的旧应用程序正常运行。

    例如，仅仅使用 WINE 作为桌面 Linux API 是不够的，还必须将 “不破坏用户空间 “的承诺从内核扩展到桌面运行环境，即使这意味着要与旧版本 “逐个兼容”。

    回复

    1. 是啊，直接的系统调用接口不是问题，因为它非常稳定。问题几乎完全出在 glibc 上。如果 GCC 能有一个 –glibc-version=2.14 或其他的标志，那么 99% 的问题都会迎刃而解。

      为了解决这个问题，我倾向于在非常老的发行版上编译。实际上，你需要在 Mac 上做同样的事情，只是问题不大，因为 Mac 更容易更新。

      问题的另一面是，整个 Linux 生态系统对捆绑依赖关系和二进制发布普遍持敌对态度，所以它如此糟糕也就不足为奇了。

      回复

    2. > 既然 Linux 的系统调用接口是稳定的，那么实际问题不就是 glibc 吗？

      是的

      > 我希望我可以把一个 20 年前的 Linux 二进制程序（只做系统调用）在现代 Linux 上运行，这个假设有错吗？

      你说得没错。但这些应用程序非常简单，我们编译它们的速度可能比它们实际运行的速度还要快。

      > 我认为 Windows 的引擎盖下有很多针对特定应用程序的黑客技术，可以让特定的旧应用程序正常运行。

      是的 [0]！

      > 仅仅使用 WINE 作为桌面 Linux API 是不够的，还必须将 “不破坏用户空间 “的承诺从内核扩展到桌面运行环境

      是的，但是。Windows 在很大程度上就是用户空间和内核。因此，windows back compat 同时适用于桌面运行环境和内核。

      你可能会说这是一个错误的等价关系，从技术上讲你是对的。但这并不能改变我的应用程序在 Linux 上无法运行，而在 windows 上却能运行的事实。

      [0] https://news.ycombinator.com/item?id=35203390

      回复

      1. 我并不想为 Linux 辩护，而且我很欣赏微软的向后兼容性（我经常玩的一些 Windows 游戏都是上世纪 90 年代末出品的）。

        我只是想指出，Windows 之所以如此向后兼容，可能并不只是因为 ABI 的稳定性，很可能还有大量 “枯燥 ”的质量保证和维护工作。

        顺便提一下，我参与开发的一些早期 D3D9 游戏在 Windows 上已无法开箱运行（主要是因为与切换到全屏相关的问题），我想这些游戏并没有流行到足以在现代 Windows 版本中实现向后兼容的地步吧；)

        回复

        1. 同样，你在技术上是正确的，但我认为这并不重要。

          Windows 提供了（实际上）DE、用户空间和内核的稳定性，而各种 Linux 发行版却没有。如果你想改变 Linux 生态系统以提供稳定性，这很重要，但如果你想运行一个旧的应用程序，这并不重要。

          回复

  15. Zorin OS 支持直接运行 .exes（当然是通过 Wine）。https://help.zorin.com/docs/apps-games/windows-app-support/

    回复

    1. 这是我第一次听说这个 [Ubuntu?] 发行版。我很想知道使用它作为日常驱动程序的人使用效果如何，以及它与 Linux 方面的 Mint 等相比如何。

      回复

      1. 我妈妈用它作为日常驱动程序，处理所有普通用户的电脑事务。在运行两年后，一次更新彻底毁了它。不幸的是，更新后崩溃是 Ubuntu 和大多数基于 Ubuntu 的发行版的典型问题，所以这并不奇怪[1]。后来，我给她换了一个不可变的发行版（Aurora [2]），它一直很稳定。

        [1] https://ounapuu.ee/posts/2025/02/05/done-with-ubuntu/ [2] https://getaurora.dev/en

        回复

  16. 这根本说不通：在 Linux 上发布所有依赖项（例如发布一个容器镜像）可以实现完美的二进制兼容性，这正是 flatpak/snap/appimage 所做的。

    也可以通过静态链接、发送所有需要的库并使用设置 LD_LIBRARY_PATH 的 shell 脚本加载器来实现。

    此外，glibc（与作者的虚假说法相反）和适当设计的库是向后兼容的，因此原则上只需将旧版 Debian/Fedora 的 debs/rpms 添加到打包库中，并运行 apt/dnf 即可。

    Win32 显然不适合 GNU/Linux 应用程序，而且你在这里也会遇到同样的依赖性问题，解决办法也是一样的（发送整个 Wine 前缀，或者发送一堆 DLL）。

    回复

    1. > 发送所有依赖项（例如，发送一个容器映像）可在 Linux 上实现完美的二进制兼容性

      这对于使用硬件 3D GPU 的图形用户界面程序是行不通的。Linux 没有通用的 GPU API：有些系统有 GL，有些系统有 GLES，有些系统有 Vulkan，这三种系统都有兼容性有限的多个版本，而且许多可选功能都是针对特定供应商的。

      相比之下，如果不使用 Direct3D 11.0，就无法运行现代 Windows，因为 dwm.exe 桌面合成器需要它。如果一个软件使用 Direct3D 11.0，并且不需要任何可选功能（例如，着色器中的 FP64 数学支持是一个可选功能，但坚持使用所需的功能集在实践中并没有太大的限制，除非您需要支持没有实现 11.0 功能级别的非常老的 GPU），那么它就可以在任何现代 Windows 上运行。令人惊讶的是，它还能在支持 Wine 的 Linux 系统上运行：如果没有支持 Vulkan 的 GPU，运行速度会很慢，但由于使用了 Lavapipe，它仍能正常运行，而 Lavapipe 是微软在 Windows 计算机上使用的 WARP（没有硬件 3D GPU）的 Linux 版本。

      回复

      1. 请注意，这也强调了帖子中关于 Windows 拥有简单稳定的 ABI 的前提–win32 当然是稳定的，但这已不再是应用程序的编码标准。

        当然，你可以运行 20 年前的应用程序，但这与当前的应用程序在 20 年甚至 5 年后仍能运行是不同的。

        回复

        1. > 这已经不是应用程序的编码标准了

          我不太明白。当然，大多数现代程序并没有使用带有 GDI 的老式 WinAPI，但它们后来添加的内容也相当稳定。例如，我正在查看的基于 Chromium 的浏览器使用 Direct3D 11 制作图形。它在上面实现了一些抽象层（ANGLE、Skia），但这些都是浏览器而非操作系统的一部分。

          我认为，Direct3D、Direct2D、DirectWrite、Media Foundation 等所有现代技术都只是 WinAPI 的更新部分。我敢肯定，微软将继续长期支持它们。例如，他们甚至不能废弃已有 23 年历史的 DirectX 9，因为它仍在被广泛使用，例如当前版本的微软自己的 WPF 图形用户界面框架就依赖于 Direct3D 9 的图形功能。

          回复

          1. 我同意。在 Linux（其实还有 Mac）上，新的 API 会取代旧的 API，旧的二进制文件也会停止工作。

            在 Windows 上，新的层被应用到旧的层上。有 DirectX 9-12。新的二进制文件可能会使用 12，但仍在使用 9 的二进制文件则会非常满意。.NET 也是如此。你可以安装多个依赖于不同 .NET 版本的应用程序。

            回复

            1. 但代码不一定相同。但 COM 对于像这样稳定的 ABI 来说是不错的选择–只要你的接口版本保持一致，应用程序就可以通过 QueryInterface 找到他们需要的旧版本，并知道它就在那里，即使它只是新版本的一个薄薄的封装。

              回复

          2. 不过，这些在 Linux 上都是一样的 – mesa 可能会改变，但应用程序使用的是 OpenGL 和 GLX。更现代的应用程序可能会使用 EGL 而不是 GLX，或者改用 Vulkan，但这并不会破坏旧代码。

            如果应用支持较新的硬件，你也可以运行应用创建时的旧 mesa，但我更愿意将其视为平台的一部分，就像你将 DirectX 库视为 windows 的一部分一样。

            回复

              1. 抱歉，”我听说…… “不是一个例子。

                回复

                1. 你引用的短语并非来自我链接的评论；你引用的是一个回复。这是我在上面链接的评论：

                  > 我有一些几年前的 flatpaks（Krita），由于一些 GL 问题，现在已经无法使用了。

                  这就是 Linux GPU API 在实践中不稳定的一个例子，而容器映像无助于解决这个问题。

                  回复

        2. 对于操作系统 API 而言，Win32 是相当广泛的。它涵盖了从系统调用和页面分配等底层内容，一直到本地化、简单的媒体访问和图形用户界面。因此，从 glibc、libsystemd、libpam 到 Linux 上的 libalsa 和 egl，应有尽有。而且都很稳定。

          微软也为 DirectX 和其他扩展 API 提供了相当好的稳定性。只要不采用 “海勒姆定律”（Hyrum’s Law）并依赖于明显的行为，你仍然可以顺利运行旧的 .Net 应用程序。

          回复

          1. 当然，win32 包含图形用户界面位，但现代应用程序并不使用这些图形用户界面位。

            由 mesa 提供的 OpenGL 和 Vulkan ABI 在 Linux 上也很稳定。不过，这篇文章的重点还是放在了 win32 的简单性上，这也是我要反驳的地方，因为它与今天的新应用程序同样相关。

            > 只要他们没有对你使用海勒姆定律

            他们 “使用海勒姆定律 “是肯定的，问题只是他们依赖于什么明显的行为。

            回复

        3. > 请注意，这也强调了帖子的前提，即 Windows 有一个简单稳定的 ABI – win32 当然是稳定的，但这已经不再是应用程序的编码标准了。

          的确如此，但这也触及了他们提出的另一个问题：应用程序编码所依据的是其他动态链接库。wine（或其他主机环境）可以提供这种动态链接库，而无需干扰内核。

          回复

      2. 从应用程序开发人员的角度提出问题： 对于跨平台的 Vulkan 应用程序有什么影响？例如，我的 3D 应用程序全部使用 Vulkan，它们在 Windows 和 Ubuntu 上都能编译和运行。这是否意味着在其他或更老的发行版上，它们可能无法运行？

        回复

        1. 我认为支持与发行版关系不大，主要变量是硬件。如果你的台式电脑是在过去 5 年内购买的，那么支持应该没问题，但对于超过 5 年的硬件，支持就无法保证了。GeForce GT 730（2014 年推出）不支持 Vulkan，英特尔只从 2015 年推出的 Skylake 开始支持 Windows 上的 Vulkan。

          还有质量问题。如果你在网上搜索 “Windows Vulkan 问题”，你会发现许多最终用户的游戏崩溃，游戏开发者的游戏引擎崩溃，https://github.com/godotengine/godot/issues/100807，建议更新驱动程序或在注册表中禁用某些 Vulkan 层，等等。

          在 Windows 上，Vulkan 的可靠性根本不如 D3D。原因包括市场份额、D3D 是渲染桌面的必要条件、D3D 运行时是微软支持的操作系统的一部分（Vulkan 完全依赖于 GPU 供应商），以及 D3D 较旧（VK 规范的第一个版本于 2016 年发布，而 D3D11 是 2009 年发布的）。

          另外，在 Linux 上，移动和嵌入式系统对 Vulkan 的支持情况并不理想。一些嵌入式 ARM SoC 只支持 GLES 3.1（顺便说一下，从功能上看，GLES 3.1 与 D3D 11.0 相差不大），但不支持 Vulkan。

          回复

          1. 总体上同意。我只想指出，Vulkan 可在英特尔 Haswell 上运行。我有一台 2013 款 MacBook Air 和一台 2013 款 Mac Pro，它们都采用 Haswell 处理器。Linux 内核 6.14 实际上包含英特尔自己提供的 Haswell Vulkan 更新。

            回复

            1. > Vulkan 可在英特尔 Haswell 上运行

              除非你运行的是 Windows，否则就不行。英特尔根本没有开发驱动程序。

              回复

        2. > 这是否意味着在其他或更老的发行版上可能无法运行

          没错。虽然 Vulkan API 定义清晰且基本稳定，但并不能保证在 Linux 上的实现也同样稳定。此外，Khronos 图形应用程序接口只有在分配了缓冲区并与操作系统和 GPU 驱动程序进行了所有握手操作后，才能处理相关问题。而在 Linux 上，这些应用程序接口/ABI/运行时配置都无法保证稳定性。基本上，只要链中有一个库破坏了兼容性，它就能正常工作。

          回复

        3. 我不知道他们在说什么。他们可能也不知道自己在说什么。

          我熟悉的所有 Linux 都运行 Mesa，它提供 OpenGL 和 Vulkan。

          回复

      3. 没有支持 Vulkan 的 Gpu，你仍然可以通过 wined3d 获得 3D 加速。除非你的意思是没有任何 gpu :s

        回复

        1. 说得好。我忘了，除了 DXVK，他们还有 WineD3D。

          回复

    2. > 此外，glibc（与作者的虚假说法相反）和适当设计的库是向后兼容的，因此原则上只需将旧版 Debian/Fedora 的 debs/rpms 添加到打包软件源中，并运行 apt/dnf 即可，理论上是可行的，但不幸的是，由于程序员和发行版维护者的普遍无能，实际上可能行不通。

      明白了。所以说，一切设计都是正确的，但不知何故，很多人的无能却阻碍了它的运行。我敢肯定，工程设计的原则就是在别人无能的情况下也能让东西正常工作。

      虽然 glibc 是向后兼容的，而且一般都能正常工作，但 glibc 却不是向前兼容的，这可是个大问题–这意味着你必须在你能找到的最古老的二进制基础上进行构建，这样构建的二进制文件才能在你试图运行它的任意机器上正常工作。而在 Mac 和 Windows 上，在我最新的系统上构建针对旧版本的应用程序却非常容易。

      回复

      1. Windows 工具链（甚至是 gnu）只是提供了旧版库链接。这在 linux 上应该同样有效，而 zig 也是这么做的。

        回复

        1. Windows 工具链提供了可与之链接的导入库，这些库基本上只是将函数名称映射到 DLL 导出表中索引的表格。只要不使用新函数，与现代 Windows SDK 链接的应用程序就能在旧版 Windows 上正常运行，这与 glibc 的情况不同。

          回复

        2. 是啊，也许我应该抱怨 Rust 工具链（或者说发行版）应该包含旧版本的预构建 glibc 来进行链接？

          回复

      2. > 所以说，一切设计都是正确的，但不知何故，却有许多普遍的不称职阻碍了它的运行。

        但事实上，它确实在运行：

        * 如果你用 apt、yum、zypper 等软件的二进制文件更新发行版，它们就会工作。- 它们就能运行。

        * 如果你下载静态链接的二进制文件，它们就会工作。

        * 如果下载 Snaps/Flatpak，它们也能工作。

        > 这意味着你必须在你能找到的最古老的二进制文件上构建，这样构建的二进制文件才能在你试图运行它的任意机器上运行。

        只有当你想发布没有依赖关系的动态链接二进制文件时，才会这样做。即便如此，你也必须使用该发行版的工具链，而不是发行版本身。

        回复

        1. > 只有当你想发布动态链接的二进制文件时

          即使是静态链接的代码也会针对 glibc 进行动态链接。你基本上是在说 “它可以工作，但前提是你必须使用操作系统中的软件包管理器”。换句话说，这对商业 3p 二进制软件的发布来说是破坏和敌对的，这也解释了 Linux 上商业 3p 二进制软件生态系统的现状（不仅仅是这样，但积极敌对地使软件更容易在你的平台上发布是一个复杂的因素）。

          我非常不喜欢 snaps/flat pack，因为它们是特定于发行版的，而且如果我进行静态链接，而唯一的动态依赖是 glibc，它们就会显得矫枉过正。

          回复

          1. 扁平封装并不针对特定的发行版。

            至于 “矫枉过正”，从最终用户的角度来看，你肯定能看到采用单一统一发行版格式的好处吧？当然，这对你的情况来说可能有些矫枉过正（虽然应用程序隔离并不只是依赖关系的问题），但重要的是，这是一个你可以使用的有效解决方案，用户只需知道如何安装和管理它们。

            回复

            1. 你必须先安装平面包运行时，因此这是分发的一个障碍。而且它也不像你想象的那样能真正隔离–例如，处理音频仍然是一团糟，因为有 4 种不同的主要音频接口。现在我还得托管一个平装软件仓库，如果是专有软件，还得让用户添加我的软件仓库。这真的远不如在 Windows/Mac/Android/ios 上那么流畅和简单。

              回复

          2. Glibc 在所有方面都非常稳定且向后兼容，我认为你夸大了 Windows 的向后兼容性。微软通过其 Microsoft Visual C++ distrubutables（仅举一例）遇到了与 Linux 完全相同的动态链接库问题。同样，Windows 也存在向前兼容性问题（如果你在 Windows 11 中创建一个程序，由于种种原因，你将很难在 Windows XP/Vista 上运行该程序）。

            如果你在 2005 年就在 Linux 上创建了一个只使用 glibc 动态链接的静态链接程序，那么该程序今天在 Linux 上运行时应该是完全一样的。Windows 软件也是如此。

            回复

            1. 我敢肯定，如果在 Visual Studio 中的目标集是有效的，那么将 Windows 11 内置的二进制文件发布到 Windows 7 和 Windows 10 上是安全的。由于 c++ BS（没有稳定的运行时）和 c++ 并非 Windows 的官方组件，因此 c++ 运行时是它自己的事情。这只是他们提供的一种开发工具。但您可以静态链接 c++ 运行时，这样您就可以在 Windows 11 上使用最新的运行时构建程序，然后发布到旧版 Windows 上。

              Linux 是唯一一个必须在带有旧版 glibc 的发行版快照上进行构建才能发布软件的领域。如果你使用的是 C++ 语言，那么你将面临巨大的损失，因为该语言的版本现在只能使用 5 年多前的旧发行版快照时可用的版本，除非你自己从头开始构建一个更新的编译器。Rust 至少要容易得多，因为他们在旧版本的 Linux 上构建了自己的工具链，因此他们的二进制文件同样很容易分发，而且在旧版本的 Linux 发行版上也很容易获得最新的 Rust 编译器。

              源代码 888/2/skissane

              > 虽然 glibc 是向后兼容的，而且一般都能运行，但 glibc 却不是向前兼容的，这是个大问题–这意味着你必须在你能找到的最老的 bistro 上构建，这样构建的二进制文件才能在你试图运行它的任意机器上运行。

              在容器中构建不是很容易解决这个问题吗？很多人都会这么做–我一直都在这么做，因为这样可以将构建工作与底层构建代理的变化隔离开来–如果 CI 团队决定将构建代理操作系统升级到下个月的新版本，或者将它们迁移到不同的发行版，那么在容器中构建（大部分情况下）就可以将我的构建工作与这种变化隔离开来，而直接在代理上构建则会暴露给它们

              回复

        2. 嗯……这并不能以任何有意义的方式将你隔离开来，因为你的周边操作系统仍然是多年前带有 Linux 基本镜像的容器？

          回复

    3. > 这没有任何意义：在 Linux 上发布所有依赖项（例如发布容器镜像）会带来完美的二进制兼容性，而这正是 flatpak/snap/appimage 所做的。

      没错，但很可悲。在 Linux 上实现兼容性的方法是以整个 Linux 系统的 tar 包形式发布应用程序。这就是 “去他妈的 “解决方案。

      当然，我想，Windows 的东西被静态链接或在安装程序中附带每个 DLL 也是常有的事，”以防万一”。这也是一种 “去他妈的 “解决方案。

      回复

      1. > 以整个 Linux 系统的 tar 包形式发布应用程序。

        当 Linux 从一张只有 2Mb 内存的软盘上运行时，情况并没有那么糟糕。遗憾的是，每个库都变得越来越大，却没有任何实用的方法来生成更轻量级的应用程序特定版本。

        回复

        1. 此外，64 位代码，尤其是数据，也变得越来越大，因为每个地址都是 8 字节，数据必须至少以 4 字节边界对齐。

          你仍然可以在极小的 m0 内核上使用非常小的 Linux 和相对现代的内核，而且还有适用于 16 位内核的 ELKS。

          回复

      2. 对于服务器应用程序的容器镜像，你也可以这么说。(打包很难。）

        回复

        1. 如果 Linux 用户空间的库具有稳定的 ABI，你只需将二进制文件压缩成 tar 或 zip 文件，它们就能正常工作。你不需要捆绑系统层。这就是在 Windows Server 系统上部署服务器应用程序的方法。只需解压，它们就能运行。

          这不是打包问题。这是一个系统设计问题。除了内核之外，Linux 生态系统对于二进制发布来说并不友好。

          回复

          1. Linux 的感觉有点不同，因为整个系统不是由一个供应商控制的。多个发行版都有自己的内核版本、libc 版本、库依赖关系等。

            Mac OS 已经解决了这个问题，但它显然是由单一厂商提供的。FreeBSD 有很好的向后兼容性（通过 -compat 软件包），但也是单一厂商的产品。

            回复

            1. 是的，如果系统层只有一个供应商，那么二进制发行版的向后兼容性通常会更好。

              这也是为什么我认为，由于 Linux “赢得 “了 Unix 战争，世界变得更糟了。

              回复

            2. -compat 包也存在于类似 fedora 的系统中，通常允许运行旧版本。我也说不上来有多早，但 RHEL 的 -compat 包通常是当前版本 – 1。

              回复

        2. 打包很 “难”，但手机和应用程序商店可以做到。

          它们通过在操作系统中制定标准、部分容器化，以及最重要的一点：应用程序不是 “安装 ”在操作系统上的。它们是自包含的。它们还被囚禁起来，通过应用程序接口（API）进行交互，授予它们权限或允许它们通过代理进行操作。这不仅有助于提高安全性，还有助于实现模块化。安装程序 “其实并不存在。

          一个应用程序被安装在系统中的多个位置，这种想法必须消亡。这是旧 PC 和/或特殊雪花 Unix 服务器时代遗留下来的问题，当时世界上的机器并不多，每台机器都有自己的管理员。那时的事情也不那么复杂。对于管理员或 PC 所有者来说，浏览文件系统并查看一切都很容易。现在，即使我的 Mac 笔记本电脑也有数千个进程和一个巨大的文件系统，比 90 年代的大型 UNIX 服务器还要大。

          回复

          1. 我想不出有什么东西能让我在计算中获得的最后一点快乐消失得更快。如果我在这样的世界中醒来，我会立即在应用程序中重新实现 Linux，然后完全忽略主机操作系统。

            回复

          2. 我同意。虽然苹果公司（其实是 NeXT）的 .app 目录格式是正确的，甚至在应用程序商店之外也是如此。

            回复

    4. glibc 真的不想被静态链接，所以如果你走这条路，你的选择就是发布另一个 libc。这确实可行，但也有自己的问题–主要围绕 nss。

      回复

      1. NSS 定义了用户名如何与 uids 匹配、DNS 如何工作、本地化如何工作等等。如果你要修改 libc，你还需要发布整个发行版，因为它无法正确使用 glibc 发行版的系统库。

        回复

  17. > 我可以调出一个 20 年前的 exe，现在仍然可以在 Windows 上运行。

    为什么，哦，为什么，我不得不处理那些还不到 5 年历史的 exe 文件，而且更新后还不能在我的 Windows 笔记本电脑上运行…… 我真希望自己生活在作者的世界里……

    回复

    1. 你可以的！只要你能找到正确的 DLLs

      回复

    2. 兼容模式通常可以解决这些问题。

      回复

  18. 他说得没有错。我用 Borland Delphi 1.0 编译的软件在 Linux 和 Windows 下都能很好地与 Wine 兼容。

    我是作为 Java 开发人员说这番话的。Delphi 最终证明了自己是真正的 “一次编译，随处运行”。可以想象，在 .NET 时代之前为 Windows 编写可执行文件的其他人也会有类似的经历。

    回复

  19. 如果 Wine 能继续进步，而 Win32 不能加速发展，对 Windows 应用程序的一流支持也许就能实现。在之前的 Windows 版本中，有一些生活质量方面的改进，但 Win32 最大的变化似乎发生在很久以前，这是有道理的： Win32 是稳定而成熟的。它仍然是一个移动的目标，但移动的幅度已经不大，即使微软想为了移动而移动它，他们也可能会发现阻力大于他们所能完全克服的阻力。不过就目前而言，我认为 Wine 还不够好，不建议人们什么都用它。它是不可思议的，但不可思议并不意味着可以安装 Photoshop。

    不过，我也认为我们可以 “解决 “很多兼容性问题。

    有很多旧的 Linux 二进制文件已经无法使用了。但是 它们可以 很多旧的二进制文件，当然是绝大多数，绝对可以在现代内核上运行。问题在于用户空间。二进制文件本身包含了大量信息，可以用来找出运行所需的信息，只是没有任何措施来确保这些信息可用。

    我真的相信，我们可以让发行版开箱即用，让旧的二进制文件 “只需运行”，双击即可运行。想用你的 .rpm 或 .deb 安装一个老游戏？系统可以识别出那是什么基本操作系统，然后将其安装到自己的 chroot 中，并为其创建桌面图标。执行失败？缺少库？Xlib 错误？让我们用图形显示错误信息，并提供可操作的帮助。

    无论如何，这都是可以做到的。如果你想在这里遵循 Windows 的精神，那么这样做是正确的，而且还能帮助那些发现了一个自称支持 “Linux “的程序的用户，以他们希望和期待的方式运行该程序。它真的会实现吗？除非有人让它成为现实，并让发行版、桌面和所有其他利益相关者相信它值得发布，然后继续维护和改进它。当你意识到实现这一点的技术部分基本上是最不具挑战性的部分，至少对于概念验证来说是这样，这就有点令人沮丧了。

    回复

  20. > 想象一下，我们制作了一个新的 Linux 发行版。这个发行版提供的桌面环境与 Windows 非常接近，Windows 用户无需培训即可使用。你可以像在 Windows 上一样安装和运行 Windows 应用程序，不需要额外的工作。

    为什么不使用 ReactOS？

    回复

    1. ReactOS 漏洞太多，不能用作操作系统的日常驱动程序，但它作为 Windows 内核参考代码却非常棒。你想知道内核模式函数是做什么的吗？要么阅读文档，要么看看 ReactOS 的功能。(是的，泄露的 Windows 代码也存在，甚至还在微软旗下的 Github 上，但你不能合法地查看这些东西！）。

      回复

      1. > 但你不能合法地查看这些东西！

        嗨，是我，劈头发先生：据我所知，阅读源代码并不违法，但在自己的应用程序中使用源代码是违法的，因为你不是它的作者，也没有它的许可证

        这其实就是为什么 Wine 和 ReactOS 的人想要取消阅读源代码的人的资格，因为他们担心他们会无意中 “借用 “实现的想法，而不是能够向法官解释他们自己是如何想到实现的。关键在于，Wine 和 ReactOS 只是取消某人的资格，而不是监禁或罚款

        回复

      1. 也许我们应该资助 ReactOS 用于最终用户应用。Win32 已经根深蒂固，不会消失。那么为什么不利用微软的 API 设计工作呢？

        回复

        1. 但 “我们 “是谁？这对游戏制造商来说可能很有价值，但基于 Wine/Linux 的系统似乎已经足够满足他们的需求了。那么还剩下谁呢？

          回复

          1. >那么还剩下谁？

            喜欢并需要 Windows 应用程序的人，希望在运行这些应用程序时拥有开箱即用体验的人，不喜欢使用 Wine 时性能下降的人，总体上喜欢 Windows 但又希望在不喜欢微软 Windows 开发方向的情况下有一个替代选择的人。

            这样的人很多，包括我在内。但是，由于 Windows 体验在某种程度上还可以忍受，因此并没有多少人愿意为 ReactOS 投入时间或金钱。没有企业赞助，因为桌面操作系统赚不到钱，除非你像苹果那样利用它们来销售昂贵的硬件。

            像 Valve 这样的公司本可以赞助 ReactOS，但他们认为用 Wine 就能实现自己的目标，而且花费更少。

            ReactOS 的另一个赞助商可能是像中国或欧盟这样的国家行为者，他们腰缠万贯，希望并需要运行 Windows 软件，但又不希望自己的桌面受美国控制。

            回复

            1. 任何喜欢 Windows 的主要设计而非 Unix 的人也是如此。

              > ReactOS 的另一个赞助商可以是中国或欧盟这样的国家行为者，他们财大气粗，希望并需要运行 Windows 软件，但又不希望自己的桌面受美国控制。

              实际上，我很希望欧盟能这样做。也许我们应该以公民的身份提出这样的建议。

              回复

    3. 这款软件还能稳定使用吗？上次我用 ReactOS 作为日常驱动时，它非常不稳定。

      一些基本的应用程序，如 Jetbrains，几乎无法运行。对我来说，充其量也就是经常死机。

      回复

    4. 几个月前，我曾在虚拟机中使用过 ReactOS，即使是在相对可控的环境中，它仍然经常崩溃。

      我一直希望 ReactOS 能成为真正杀死微软 Windows 的东西，但这真的没有发生；似乎是通过将大量应用程序转移到浏览器以及 Wine 和 Proton 等兼容性层的组合来实现的。

      如今，Linux 对驱动程序的支持已经相当不错，而在驱动程序之外，Wine 对应用程序的支持也同样出色，甚至更好。

      回复

  21. 这是一个绝妙的想法，如果创建者能召集到合适的开发者和用户，它就能成功。它真正需要的是 Ubuntu 层级的品牌和用户体验工作。这在 Linux 桌面领域是非常罕见的。

    我希望 SteamOS 能给我们带来类似的东西。

    回复

    1. >它真正需要的是 Ubuntu 级的品牌和用户体验工作。

      这意味着要有人出钱。设计师和用户体验专家可不像许多程序员那样在乎免费工作。

      回复

  22. suckless项目为我们带来了stali linux，一个静态编译的Linux发行版。

    静态编译不就解决了这里所说的很多问题吗？

    https://sta.li/

    回复

    1. 是的。这与 AppImage 能够成功的原因是一样的–如果授权许可允许在镜像中包含所有库，因为 Linux 的系统调用接口一般都很稳定。

      “我们不会破坏用户空间”

      回复

      1. AppImage 有一些问题。你见过执行 AppImage 需要安装多少依赖项吗？

        你还需要在一个可以创建 FUSE 文件系统的环境中。而且，参考实现需要使用已过时的 fuse2 库。

        Snaps、Flatpaks、AppImages 和静态链接都是解决实际问题的方法。但我不认为 AppImages 是一个特别好的解决方案。

        我曾与理查德-布朗（Richard Brown）讨论过在 Aeon（OpenSUSE 不可变发行版）中支持 AppImages 的问题。但他认为，为了支持 AppImage 运行时（包括已过时的 fuse2 支持），基本系统需要过多的依赖性。

        回复

  23. > 由于相同的安装库版本问题，也无法保证今天在 Linux 上生成的二进制文件甚至可以在今天的各种 Linux 发行版上运行。

    在 Linux 上，你应该共享源代码，而不是二进制文件。FOSS 源代码比二进制文件更容易修复。这就是 FSF 存在的原因。

    回复

    1. 99% 的 Windows 用户甚至不知道什么是编译，更不用说自己从源代码编译了。

      回复

  24. 我仍然无法让 MS Office 365 在 Linux 上通过 Wine 运行，而任何替代方案都无法让我感到舒适。如果不讨论 Wine 的兼容性，比较 Linux 和 Win32 在 Linux 上的 ABI 就是无稽之谈。

    回复

    1. 你最近查看过 OnlyOffice 吗？如果有的话，我很好奇你觉得它与 M365 相比缺少哪些破坏性功能。

      回复

  25. > 试试对一个刚用了一年的 Linux 二进制文件做同样的事情。

    AppImages 已经快要解决这个问题了。我不确定这个问题是已经解决了还是即将解决。

    回复

    1. Linux 版 Adobe Reader 自 2013 年以来就没有更新过，但 flatpak 仍然运行正常。

      回复

  26. 为什么这么复杂？如果你需要运行现有的二进制文件，Wine很酷，但当你编写自己的软件时，为什么不把独立于平台的部分编译成二进制文件，而把依赖于平台的部分做成一个小库（开源）呢？

    回复

  27. 有多个发行版可以让这一切变得非常简单–就像下载一个 .exe 或 .msi 并点击它一样：https://help.zorin.com/docs/apps-games/windows-app-support/

    其中有些发行版已经有很长的历史：https://en.wikipedia.org/wiki/Linspire

    它们从来没有那么成功过。

    我认为，想要使用 Linux 的用户与急需运行 Windows 应用程序的用户之间没有足够的重合度，因此 Linux 并不可行。

    最大的问题是游戏，即使 Steam 做出了最大努力，但目前看来，并非所有 Windows 游戏都能在 Linux 上运行。

    回复

  28. 按专有的调子跳舞是有风险的–如果竞争过于激烈，他们可能会决定更改应用程序接口或对你提起诉讼。

    你可以在 Linux 中提供向后兼容性–你可以继续安装旧版本的程序库。商业发行版在更大程度上做到了这一点。这与 Windows 的做法大致相同。

    这只是一种成本安排，由于大多数发行版并没有赚取数十亿美元的许可费，所以他们选择不支付这笔费用。

    显然，我并不反对以葡萄酒为重点的发行版，但我自己也不会浪费一秒钟的时间来编写针对 Windows API 的代码。

    回复

  29. 文章的 “迫在眉睫的未来 “一章。我都不知道还有这么多 “hortiboe ”计划。

    回复

  30. 这是一个绝妙的想法。不过我还是有些疑虑。它可能无法提供无缝体验。

    仅仅把 Windows 系统调用转换成 Linux 系统调用是不够的。还应该有某种形式的仿真。

    许多应用程序（如游戏）都使用硬件，这就意味着需要额外的仿真层。

    >想象一下，我们制作了一个新的 Linux 发行版。这个发行版提供的桌面环境与 Windows 非常接近，Windows 用户无需培训即可使用。你可以像在 Windows 上一样安装和运行 Windows 应用程序，不需要额外的工作。

    但我认为，这将带来粗糙的用户体验、一些性能损失和许多错误。

    但我希望我是错的，因为这个想法听起来真的很有前途。

    回复

  31. 问题不仅在于运行，身份验证和授权也很重要。我曾尝试用 Wine 运行各种音频插件，但它们要么根本无法运行，要么只能一次性运行，这对于任何长期设置都是不可行的。888/0/amelius

    > 虽然 Linux 系统调用本身非常稳定可靠，但其上的 c 库却并非如此。几乎所有的用户界面都是基于 libc 的，因此，Linux 本身就存在二进制兼容性问题。

    我们就不能冻结 libc 的功能吗？ 为什么它需要频繁更新？

    即使我们修改了它的实现，如果底层应用程序接口（API）还是一样的，为什么还要提高版本号呢？

    回复

  32. 如果微软将来做了这样的事情，我也不会感到惊讶。将 Win 32 作为 Linux 的一个层。

    他们似乎对锁定硬件并不感兴趣，而且他们并没有从销售 Windows 中赚到多少钱，这一点显而易见。Windows 并没有太多强有力的改进，感觉 Windows 只是他们用来销售其他产品赚钱的一个平台–他们在 Windows 上的处境与谷歌在 Android 上的处境类似。

    回复

  33. 我想要的恰恰相反：我希望能有一种方法，用 Windows 运行 Windows 内核、驱动程序和大多数低级操作系统，但同时使用 Linux 用户界面： Cinammon、apt 和所有 debian 的东西。

    我将 Mint 作为我的主操作系统，但硬件兼容性仍是 Linux 系统令我头疼的问题。

    回复

    1. 你可以复活 SFU 并为资源管理器创建一个替代图形用户界面。你无法摆脱 Win32，但你可以掩盖它的大部分功能。实现 Personality 将是 Windows 实现这一目标的途径，因为它就是为你的要求而设计的。

      回复

    3. 如果你购买的笔记本电脑没有预装 Linux 系统，也没有得到硬件供应商的支持，你将会很难使用。

      你可能会走运，但听起来你并不走运。

      回复

      1. 我从没买过专用的 Linux 笔记本电脑，但我在 AMD 的产品上运气还不错。

        我现在的笔记本电脑是 Thinkpad P16s AMD 2 代，用 NixOS 运行起来非常简单。不需要特殊的驱动程序，包括 WiFi 和键盘上的功能按钮在内的所有东西都能正常工作，不需要任何特殊的让步。

        我的上一台非 Mac 笔记本电脑也是如此，从 2017 年到 2020 年，我在上面安装了 Ubuntu，没有遇到多少麻烦，而且它也不是特定的 Linux 笔记本电脑，虽然同样是 AMD。

        回复

      1. WSL 1 有，WSL 2 在虚拟机中运行。

        回复

  34. > 我可以调出一个 20 年前的 exe，现在仍然可以在 Windows

    上运行，勉强可以吧–大多数大型程序并没有遵守所有标准，而是在后续的 Windows 版本中进行了引擎盖下的自定义修复。

    此外，2001 年左右是桌面从 DOS 到 NT 的重大架构变革，因此这可能看起来像是在选择时间框架。

    回复

  35. 我在使用 Steam、质子和我的游戏库时几乎就是这么做的。99% 的时间都能正常运行。

    回复

    1. 遗憾的是，有几款模拟赛车游戏根本无法运行，VR 也是时好时坏（不过使用 WiVRN 或 ALVR 的 Quest3 似乎运行得很好）

      不过，我还是宁愿这样做，也不愿意处理日常驾驶 Windows 的问题！在过去几年里，Linux 上的游戏体验变得如此出色，这让我感到非常惊讶。

      回复

    2. 如果你主要玩单人游戏，当然可以。

      任何带有反作弊功能的在线游戏通常都会被破解。

      回复

  36. 将 Linux 应用程序打包为 Windows 应用程序如何，这样它们就能利用 Win32 ABI 的稳定性？有没有可能使用人工智能自动完成这项工作的方法？

    回复

  37. 在第三段中就已经确定作者并没有意识到 AppImage 并不捆绑 libc，我还能读懂多少？Flatpaks有，而Snaps是一个捆绑_Ubuntu_的封闭系统，所以答案确实是Flatpaks。世界上其他地方也都得出了这样的结论。

    回复

  38. 感谢你写下这些想法。

    我在从零开始构建 ZeeeroOS 时也得出了类似的结论。

    还有一些 “胖 ”二进制文件（与arch无关）也应考虑在内，但在为Linux构建时却没人这样做。

    [1] https://github.com/zeeeroos

    回复

  39. > 虽然 Linux 系统调用本身非常稳定可靠，但其上的 c 库却并非如此。

    那就别用那个库？或者不要做那种可笑的事情，在运行时拼命摸索，寻找本应包含在二进制文件中的可执行页面。

    回复

    1. 这不是 “在它们之上的某个 c 库”，而是 glibc。你可以使用另一个 libc，但这意味着你将在配置方面与发行版的预期不兼容，因为那是由 glibc 处理的，所以你只是把不稳定性推到了系统的另一部分。

      回复

  40. 这篇文章的大前提并不差，但却充满了奇怪的技术误差。

    在某些地方，他谈到了系统调用、libc（我猜是 glibc）、PE 与 ELF 以及 “ABI”。这些都是不同的东西，而且 IIUC 在 Linux 上都相当稳定，不稳定的是 GTK 和 QT 等用户空间库。那么，我们在说什么呢？

    还有这样的说法，我不是内核开发人员，但听起来好得有点不真实：

    > 只要对 “exec “系列系统调用稍作修改，在可执行类型上进行分派，就能让任何 Linux 应用程序毫不费力地分叉并执行 Windows 应用程序。

    他接着谈到了 “网守”（可以禁用）、“召回”（默认情况下是禁用的）和使用微软账户登录（可以轻松绕过，不过他链接了一篇文章，说他们可能会取消这一功能）。他还提到了 “扫描电脑中的非法文件”，我不知道这指的是什么，但我在谷歌上唯一能找到的就是苹果的 iCloud CSAM 扫描功能。这不是在你的电脑上进行的，而且它遭到了很多人的反对，以至于被取消了。

    这些公司和他们的服务有很多值得批评的地方，不必夸大其词，Linux 通过 Wine 与 Win32 兼容的想法也不错。

    回复

    1. > > 还有这样的说法，虽然我不是内核开发人员，但听起来好得有点不真实：

      > 对 “exec “系列系统调用稍作修改，在可执行类型上进行分派，就能让任何 Linux 应用程序毫不费力地分叉并执行 Windows 应用程序。

      这不是 “好得不像真的”，而是 “好得不像真的”–不需要修改内核，因为 Linux 内核已经通过 binfmt_misc 支持这一功能。 你只需对其进行配置即可。根据你安装 Wine 的方式，你可能会发现它甚至已经为你配置好了。

      回复

  41. > 我可以调出一个 20 年前的 exe，现在仍然可以在 Windows 上运行。

    当然可以，但微软还能允许这种未签名的古老二进制文件存在多久呢？

    随着微软对 Windows 的不断完善，使用 Linux 运行 Windows 程序将成为当务之急。

    回复

    1. 我真的不认为微软会阻止未签名的 exe。有太多的旧 Windows/DOS 软件仍在使用，有时还在运行关键的基础设施。

      回复

      1. 就像有人说过的那样，这将是一个循序渐进的过程。

        Windows S 模式已经是一个测试。

        唠叨、警告和直接 “阻止”（同时在 “更多信息 “下隐藏 “无论如何运行 “按钮）是第一步。这已经是对软件供应商的警告，说明将会有一些事情发生。

        下一步将是在家庭版（不包括专业版或企业版）上阻止未签名的 exes，这样软件供应商和大多数依赖未签名旧软件的地方就可以转而使用签名软件了。

        这样，Windows 的家庭版和专业版就不能再运行未签名的软件了，如果需要运行未签名的软件，就必须使用企业版。

        最后一步是 Windows 不再能运行未签名的软件，如果您需要运行未签名的软件，您需要在仍能运行未签名软件的 Windows Azure 实例上运行该软件，或者（如果您不能/不想在云中运行软件）您需要联系微软购买特殊的 Windows 版本，这将花费大量资金。但是，如果你的业务依赖于一个未签名的 exe 文件，你可能愿意为这个文件付费。

        回复

  42. 每隔一两年，我都会查看 ReactOS 的状态，希望有一天能有一个很好的 Windows 替代品。今天查看了项目状态后，似乎这一天还遥遥无期。

    回复

  43. 有类似 Wine 的库可以帮助在 Linux 上运行 macOS 应用程序吗？

    回复

      1. > 使用 SwiftUI 构建的适用于 macOS 的现代 Wine 封装器

        我想你误解了 GP 关于 “在 Linux 上运行 macOS 应用程序 “的要求，所以你交换了主机和客体操作系统，然后在 “仿真 “下移植了客体操作系统

        回复

  44. > MacOS 有一个叫做 Gatekeeper 的功能，它限制了 Mac 上可以运行的软件，只能是苹果批准的应用程序

    这是谎言。Gatekeeper 绝不会限制你可以运行的软件。如果开发者选择将从浏览器下载的软件提交给苹果公司进行恶意软件扫描，那么它将为你提供更便捷的启动体验。

    回复

  45. >想象一下我们制作了一个新的 Linux 发行版

    想象一下我们制作了一种新的棕色

    说真的，这是你能用 Linux 做的最老套的事情了。

    回复

  46. 那么……这已经存在了。Valve 基本上已经将其作为产品销售。大家都知道吧？Steam Deck 是一个 linux 盒子，运行作为本地应用环境的 wine 可执行文件。虽然赚钱的应用程序都是 “游戏”，但这并不能改变技术。

    回复

    1. Steam OS 显然不是博客所提出的，我不能直接跳过桌面模式，通过 MSI 安装火狐浏览器。

      回复

      1. 不是[1]，但你可以原生启动 Windows 可执行文件，以兼容的方式链接 DLL，根据需要在 32 位和 64 位之间切换，使用原生 API 访问 Linux 文件系统、网络和 IPC 环境，与 .NET 和 msvc 运行时集成，访问原生速度的 DirectX 仿真，等等……

        是的，你必须对它进行抛光和打磨。但 “给它涂上一些铬 “并不能算是一篇博文。

        [1] 事实上，你确定答案是 “不 “吗？如果某个有心的极客在 github 上发布了实现 MSI 提取器和安装程序的源代码，我一点也不会感到震惊

        回复

    2. 他们是如何做到这一点的？他们的做法是发布一个伪ubuntu14，作为原生 Linux 游戏的 “steam 运行时”。这并不是一个糟糕的解决方案，但对于通用软件来说并不理想，因为在通用软件中，游戏大多是独立运行的。不过，他们在 Proton 上的工作令人惊叹。

      回复

      1. 等等，Steam OS 现在不是基于 Arch 吗？

        回复

        1. 这里有三件事：

          – 蒸汽运行时： 一套通用的 Linux 原生游戏库，用于兼容多个发行版，我相信它仍然使用 Ubuntu 作为上游

          – Steam OS： Steam操作系统：基于拱形结构的发行版，预配置为开箱即可运行Steam，由Steam Deck使用，带有gamescope等额外功能，可解决其他发行版在VRR、HDR等方面存在的各种问题。

          – 质子 在 Linux 上运行 Windows 游戏

          回复

  47. 每个人都在评论可能的实现方式或类似的解决方案已经存在。我想重点谈谈一个被忽视但非常重要的事实：Linux 生态系统中的大多数重要软件都是开源的。是的，20 年或 25 年前的 ELF 二进制软件可能开箱就不能运行了，但你拥有源代码，可以访问所需库的全部源代码。这肯定不是一次零努力的冒险，也不会适用于专有和封闭源代码软件，但对于大多数被遗弃的旧 Linux 软件来说，这是可行的。

    回复

  49. 虚拟化的效果比酒好得多。只需将窗口帧缓冲区复制到 Linux 主机即可。

    回复

    1. 作为一个被困在 macOS 中试图运行 docker 的人，我可以告诉你，”文件 “是什么、它的 “位置”、”在 localhost 上监听 “的含义以及应用程序有多少 “内存 “之间的阻抗失配，使得虚拟化对于在不同于日常

      的操作系统（或架构）上运行一个程序来说绝对是可怕的。 888/0/pjmlp

      采用 GNU/Windows，问题就解决了。

      回复

  50. 看来，在 Linux 用户区识别并修复 ABI 兼容问题要比把 Linux 转换为 Windows 更容易。

    回复

    1. 如果 Linux 用户区不是由互不关联的开发者组成，而且他们都有自己的做法和发布节奏，那么这也不失为一种选择。这就是为什么我们有 LTS 发行版，公司会投入大量工作来保持二进制兼容性。

      但这样做的代价是，你的软件仓库中的软件将变得非常陈旧。在 RHEL 支持周期结束时，库将会过时十年。

      回复

        1. 破坏兼容性。他们经常删除或重命名功能，并公开表示不会保持兼容性。

          回复

          1. 有很多可供选择的 SSL 库。

            观点仍然成立：解决这些库的问题似乎比把 Linux 变成 Windows 更省事。

            回复

  51. 20 年前的游戏在现代 windows 上根本无法正常运行，这只是一个反例，不知道你的观点从何而来。

    回复

    1. 这确实取决于游戏，但一般来说，20 年前（即 2005 年）的游戏在现代 Windows 上运行得很好。而 Win9x 时代开发的游戏通常比较麻烦。

      回复

    2. 我最近在我的 Linux 笔记本电脑上玩了《Sinistar Unleashed》。

      我一直无法在普通 Windows 硬件上运行这款游戏，即使我买了全新的游戏并尝试在现代电脑上运行它，但它在 Wine 和 Proton 下运行得很好。

      而我安装的 Windows 10 双启动系统（只是为了玩游戏）却无法运行这款游戏。

      当然，即使使用 Wine 也不是件小事，但也没那么糟糕。这款游戏其实还不错，我小时候很喜欢玩，但显然我得等上 25 年才能用 Wine 来玩。

      回复

      1. 你用 wine 使用光驱模拟吗？

        回复

        1. 实际上，我并没有使用光驱模拟，我使用 linux 载入 ISO，然后直接运行可执行文件进行安装，然后在安装路径上对 Wine 进行设置，最终让游戏启动。

          回复

  52. glibc多久会引入一次破坏性改动？

    回复

  53. 我有点数要烧，所以我就发帖子了，因为我知道这会让一些人误解–在此先表示歉意。

    我使用 Windows。事实上，我喜欢 Windows。我认识很多（好吧，不止 5 个）灰头土脸的人，他们也有同样的感觉。我不想让 Linux 成为 Windows，但我也不想让 Linux 出现在我的个人桌面上。

    我的办公桌上有一台 Mac Mini M1，我用它来做它擅长的事情，主要是视频会议。它也是我的第二台 Adobe Creative Suite 电脑。

    在我的 Win11 桌面上，我使用 WSL2 和 Ubuntu 24.04 来运行它所擅长的功能–目前是 Python、SageMath、CUDA 和 ffmpeg。为了解决 Unix 问题，我在 Windows 上使用 Git Bash (MSYS2) 来解决 “日常常见的 Unix 问题”。

    需要时，我还会在我的电脑上使用 PowerShell 和 Windows 脚本。

    为什么呢？首先，这很简单，而且我还有事情要做。其次，成本不是问题–我买的 Windows Pro 许可证是在 Win7 的时候买的，大约 180 美元。那大概是 15 年前的事了。他们慷慨地为我升级了每一步–Win7 -> Win10 -> Win11，所有这些都是免费的。即使我不得不买，我的塔可钟（Taco Bell）账单在任何一个月都比 Windows 许可证高（喜欢这种通货膨胀）。

    还有其他原因吗？一切正常。我不会收到恼人的弹出窗口，也不再担心硬盘上的垃圾邮件，因为它们已经离我远去；想浪费 50GB 内存吗？当然，请便。

    但最重要的原因是什么？我的硬件得到了支持。我的显示器看起来很棒；打印机、扫描仪、鼠标、USB 驱动器和钥匙都能正常工作。事实上，90% 以上的时间里，所有东西都能正常工作。此外，我可以毫不费力地与我的 Mac 共享，我所有的 Linux 服务器都支持 SMB (CIFS)，Wireshark 可以正常工作，我的程序也都支持，包括大多数开源软件。我还时不时地运行 20 多年前的应用程序。

    实话实说，我也试过每天驾驶 Linux，向别人解释我的东西为什么与众不同或有什么不足，但都是一箩筐的废话。最要命的是，我的客户并不在乎纯度或酷炫程度。

    Linux 有它的用武之地。但请不要把它放在我的主机上，也请不要把它送给我的家人。让他们忍受次等的桌面体验，才是对他们好。要想与 Windows 或 MacOS 保持一致，总是需要付出巨大的努力，而没有人真正愿意把钱花在刀刃上。

    请不要误解。我钦佩并尊重开源软件的作者，我的服务器也感谢他们。但是，作为一个逆向思维者，对 KDE 和 GNOME 推出的产品嗤之以鼻，与 Nvidia 和 AMD 抗争，应对不断变化的驱动程序接口，得不到适当的商业软件支持，这可不是我想要的乐趣。那是 30 年前的事了。今天呢？我宁愿和女儿一起玩，或者写点代码。

    这些发行版已经用了 35 年。我不知道还能说什么。

    回复

    1. 我也有同样的经历。从 2000 年开始，我就尝试使用 Linux 作为桌面。试了又试。年复一年，一个发行版接着一个发行版。

      直到我意识到，Linux 的桌面体验永远无法与 Windows 相提并论，我需要的只是能用就行，而不是不停地摆弄来让它们工作。

      我发现 Gimp 不是 Photoshop，Libre Office 也不是 MS Office。我还发现，在 Wine 下运行并不总是很好。

      我发现我需要并希望运行 Windows 软件。

      我发现我喜欢开箱即用的硬件。

      对我来说，Windows 作为桌面系统非常棒。我开发的基于微服务的应用程序在云中的 Linux 容器/Kubernetes 下运行。

      Docker Desktop、WSL 和 Hyper-V 可以满足我对 Linux 的所有潜在需求。

      我还有一台 MacBook Pro，但我不太关心操作系统，我买它主要是为了电池续航时间长，在床上、沙发上或旅行时用它浏览网页和看电影。

      回复

    2. > 但最重要的原因是什么？我的硬件支持。我的显示器看起来很棒；打印机、扫描仪、鼠标、USB 驱动器和钥匙都能正常工作。事实上，>90% 的时间，所有东西都能正常工作。

      ，20 多年来，我的许多机器中只有一台打印机和一块显卡出现过问题，所以我可以说，我的 Linux 管理超过了 95% 的 “正常工作”。

      回复

    3. > 次等的桌面体验。

      我坚决不同意。如今，Linux（KDE）的桌面体验远远优于 Windows 11。你见过新的 Win11 任务栏和糟糕的 “开始菜单 ”吗？整体用户体验也大打折扣–比如像 “窗口颜色和外观”（没有替代品）这样的经典控制面板小程序被移除，Copilot 和强制 MS 账户等不受欢迎的垃圾程序不断出现–比如，连时钟程序都需要登录（为什么？MS PAINT 中甚至还有广告 [2]！告诉我这是否可以接受？

      > 要想与 Windows 或 MacOS 看齐，总是需要付出巨大的努力，而且没有人真的愿意把钱花在刀刃上。

      我也不同意这种说法，事实上，Linux 在很多方面已经超越了 Windows 和 MacOS。

      以更新为例：尤其是在具有原子更新功能的发行版上，与 Windows 相比，它们要可靠得多，更新体验也更令人愉悦。原子事务意味着更新要么应用要么不应用–不存在部分/失败状态，因此不会出现更新失败并可能导致电脑瘫痪的情况。此外，提供原子更新的发行版还提供简便的回滚功能（直接从启动菜单），以防出现任何倒退。更新也不会打断你的工作，也不会强迫你意外重启–你想什么时候重启就什么时候重启，没有任何烦人的唠叨信息。

      最重要的是，更新不会像 Windows 那样挟持你的电脑，”请稍候，不要关闭电脑 “是 Windows 最令人讨厌的地方。

      令人惊讶的是，即使微软拥有 40 年的发展历史和数万亿美元的资金，他们仍然无法解决如何正确进行更新的问题。

      最后，您的电脑将在其整个实际使用寿命内持续接受更新/升级，而不像 Windows（普通版本）那样会将一台性能良好的电脑变成电子垃圾。Win11 屏蔽 Kaby Lake 和更老的 CPU 就是计划报废的最好例证，老实说，像你这样的人竟然觉得这种做法是可以接受的，真是令人厌恶。

      Linux 还有其他一些闪光点，比如不可变发行版、Flatpak 应用程序、sched_ext 调度器、x86_64 微架构优化、低资源使用率…… 我可以就此写一篇文章，但这会让这篇冗长的文章变得更长。

      > 但是，作为一个逆向思维者，我还是要对 KDE 和 GNOME 所推出的产品进行狗粮式的评价

      请不要把 KDE 和 GNOME 放在一起说。自从 GNOME 基金会发布了令人憎恶的 GNOME 3 之后，他们就失去了理智，背叛了他们的粉丝。另一方面，KDE 仍能满足用户的需求（忽略 KDE 4 时代）。与 Win11 不同，KDE v6 的体验近乎完美，而且仍然拥有经典、熟悉的桌面用户体验，任何老一代 Windows 用户都会爱不释手、如鱼得水。

      > nVidia 烂透了，这完全是 nVidia 的错，因为他们没有提供完全开源的驱动程序栈（他们新的开放式内核模块是一个进步，但许多驱动程序组件仍然是专有的，依赖于他们的 GSP）。

      另一方面，AMD 在过去几年中的表现却让人超级满意。自从 Valve 推出 Steam Deck 后，AMD 驱动程序、KDE、Wine 和其他一些相关领域都得到了巨大的改进。如果你在最近的发行版上试用过 AMD GPU，我很怀疑你会对它有什么大的抱怨。

      > 没有适当的商业软件支持

      你的家庭需要什么样的商业软件？我的家人不需要（我也不需要）。还在工作的家庭成员都有自己的工作用 Windows/macOS 笔记本电脑，所以这就解决了商业方面的问题，而在工作之外，我们不需要任何商业软件–我们可以做大多数普通 PC 用户所做的一切–上网、基本的文档/图形/视频编辑、打印/扫描、文件/照片备份等。在 Linux 下一切都运行得很好，所以我不知道我们不使用商业软件会错过什么。

      > 这些发行版已经使用了 35 年。我不知道还能说什么。

      也许不要使用停留在过去的古老发行版？试试像 Aurora [3] 或 Bazzite [4] 这样的现代不可变发行版，你会发现事情已经发生了多大的变化。

      [1] https://old.reddit.com/r/Windows11/comments/ztv70n/since_a_f…

      [2] https://bsky.app/profile/d3xt3r.bsky.social/post/3lhhltgbtos…

      [3] https://getaurora.dev/en

      [4] https://bazzite.gg/

      回复

      1. “也许不要使用停留在过去的古老发行版？试试像 Aurora [3] 或 Bazzite [4] 这样不可更改的现代发行版，你会发现事情已经发生了多大的变化”。

        这一直是对 “Linux-for-normies “怀疑论者的反驳–“你还没试过这些现代发行版，X、Y、Z”。

        我已经试过好几次了，它们总是有问题，从驱动程序到配置设置，与 Windows 甚至 MacOS 相比都太不一样了。

        非技术人员（尤其是年长者）通常会对晦涩难懂的Linux发行版抱有期望，而这些发行版（尽管用心良苦）却无法满足他们的期望；它们可能很适合那些对自己解决问题更有信心和好奇心的用户，但这种 “这次与以往不同 “的想法最终还是要由发行版的拥护者来证明；他们过去已经错了太多次了。

        回复

        1. > 我已经在这条路上走了好几次，它们总是有问题，从驱动程序到配置设置，与 Windows 甚至 MacOS 相比都太不一样了。

          你真的应该试试基于 KDE 的发行版，它的用户界面与传统的 Windows 用户界面并无太大区别。事实上，我觉得 KDE 比 Windows 11 更像 Windows 7 的用户界面。

          此外，只要硬件兼容，驱动程序也不是问题。作为推荐/安装 Linux 的人，你有责任确保他们拥有兼容的硬件。根据我的经验，任何超过几年的主流品牌硬件都能正常运行。仅有的几次需要手动安装驱动程序的情况是打印机，但由于无驱动程序/IPP 打印技术的发展，现在这也几乎不成问题了。

          > 非技术人员（尤其是年长者）通常会有一些期望，而这些期望是那些不起眼的 Linux 发行版（尽管它们用心良苦）无法满足的

          我很惊讶你提到非技术人员和年长者，因为他们正是我理想中的 Linux 目标用户，因为他们的需求简单、可预测，而且通常不会改变。通常是那些精通技术、有复杂软件需求和特定工作流程的年轻人很难适应 Linux。我的情况也是如此，我有超过十年的自定义 AutoHotkey 脚本和对各种专有软件的精神依赖，我不得不在最终切换之前让自己摆脱这些依赖。

          年纪较大、不懂技术的人，大多只用浏览器和文档编辑器就可以了。我妈妈就是这样，我的大部分亲戚也都是这样。只要你把桌面设置成熟悉的样子（也就是在桌面上创建快捷方式），他们就不会大惊小怪。一开始，他们可能会问 “我该怎么做 “或 “XXXX 去哪儿了？”，这取决于他们的需求/工作流程。至少在我妈妈的情况下，在向她演示了基本操作后，就没有什么问题了。

          我很好奇你认识的老年人有什么需求，是 Aurora 这样基于 KDE 的原子发行版无法满足的。

          回复

      2. 我同意。与我尝试过的其他桌面相比，我更喜欢 KDE，尽管我也喜欢 XFCE。

        > 请不要把 nVidia 和 AMD 放在同一句话里。

        ，一般来说，我没有遇到过硬件问题。只要购买专为 Linux 设计的硬件，就能完全避免硬件问题。

        回复

      3. > 你见过新的 Win11 任务栏和糟糕的开始菜单吗？

        是的，这是 W11 核心功能最大的明显降级之一！它很糟糕，漏洞百出，但有 Windhawk mods、菜单替代品和应用程序启动器，所以它可以重新调整得很好（尽管他们在任何 W7 或其他版本中都没有完善任何东西、 没有一个完美的用户界面组件）

        > 整体用户体验已经大不如前–比如像 “窗口颜色和外观 “这样的经典控制面板小程序被移除（没有替代品）

        又是糟糕的东西，虽然经典控制面板也很糟糕，但唯一值得安慰的是，在稳定状态下，你不会经常使用

        > 时钟程序要求你登录（为什么？) [1]. MS PAINT 中甚至还有广告 [2]！告诉我这是否可以接受？

        不能，但即使没有广告，你为什么还要使用这些糟糕的股票应用程序呢？还有更好的选择吗？

        但是，与无法拥有像 Directory Opus 这样出色的文件管理器，或者无法使用 Everything 即时查找任何地方的任何文件，或者无法拥有一堆其他应用程序相比，所有这些大多可以解决的烦恼都显得苍白无力（然后你还会遇到很多其他问题，比如调整操作系统 UI，或者出现人们一直抱怨的睡眠或硬件兼容性问题）

        回复

    4. Windows 仍处于瘫痪状态，每个人都需要一个退出计划。

      对于家庭用户，我认可 macOS。对于 Windows 应用程序，我已经通过 GPU 虚拟了 win11 IoT。我的显示器有多个输入，我甚至看不出它不是原生的。

      回复

    5. TLDR: I’ve got stuff to do.

      我也有同感。最近，我给岳父买了一台 M4 iMac，他觉得这是份莫名其妙的好礼物。

      哦，其实也有一些令人信服的理由。我的技术支持工作量大大减少，他也非常高兴。双赢。

      回复

  54. > 试试对一个刚用了一年的 Linux 二进制文件做同样的事情。

    我经常这么做。只要链接到静态的 glibc 或 musl 就可以了。

    回复

    1. 我很想静态链接 OpenGL 和 Vulkan，但它们都不使用线协议（不像 X11 或 Wayland）。整个 “加载库 “方案对于任何初学图形编程的人来说，都像是在本已复杂的图形应用程序接口基础上又增加了新的麻烦。

      回复

      1. 我知道至少对于 OpenGL 而言，并非所有显卡/驱动程序都能实现整个功能集。因此，动态链接和逐个引入功能是合理的。

        回复

        1. 我认为有线协议可以通过查询支持的版本和功能来支持这一点。动态链接的决定消除了序列化的开销，但也消除了静态链接的选择。

          回复

    2. 是的，这只是我的想法。与其费尽周折、开销巨大地使用 Win32 的糟糕 API，还不如直接静态链接 musl。当然，这两种方法都有缺点和局限性。

      回复

  55. > 我可以调出一个 20 年前的 exe，现在仍然可以在 Windows 上运行。试着用一年前的 Linux 二进制文件做同样的事情。

    这怎么能算是好事呢？

    回复

    1. 向后兼容通常是件好事。当然，它也有自己的缺点（比如安全性），这取决于向后兼容性技术的好坏。

      回复

  56. 25 年前，Corel 和 Lindows 都试过这样做。人们并不喜欢。

    回复

    1. 我确实都喜欢它们。与当时的其他 Linux 发行版相比，它们给人的感觉要精致得多。

      回复

  57. Wine/Proton 基本上就是 Windows 的 Linux 子系统。

    回复

    1. WSL1、WSL2 是 Hyper-V 虚拟化。

      回复

  58. > 我们也已经有了运行 Windows 应用程序的简单方法，那就是 Wine。

    你嗑药了？Wine 一点也不简单。它既是一团糟，又是技术杰作，但它并不简单。

    回复

    1. 视情况而定。Proton 和 CrossOver 非常简单，尤其是对受支持的应用程序而言。

      回复

          1. 同样，当然。https://www.christopherspenn.com/2021/08/simple-is-not-easy/

            回复

    2. 对最终用户来说相当简单，但实现起来并不简单。

      回复

      1. 就像任何操作系统中的很多东西一样，这取决于你走多远的路。我认为有很多刚接触 Linux 的游戏新手都是通过 steam 来接触 wine 的，而 steam 一般都会为他们打包，并将细节隐藏在启动器后面。如果你需要深入了解兼容性的细节，或者你想用前缀来区分不同的东西，那么它肯定没有那么完美和优雅，但我认为，你也可以这样说，windows 与一些老游戏或 PCGamingWiki.com 等网站的兼容性会小很多，因为多年来，windows（或 DOS）+驱动程序+硬件的组合并没有带来完美一致的兼容性。

        回复

  59. OS X/Classic 的反向过渡，如果你愿意的话……

    回复

  60. > “在 Windows 中，你不能直接进行系统调用。相反，你可以动态链接到为你进行系统调用的库。这样，微软就可以在内核层面做各种恶作剧，同时为用户空间提供一个稳定的 API”。

    或者换句话说，”我们可以通过引入额外的间接层来解决任何问题”。

    回复

  61. 或者像一个（有用的）疯子一样静态编译所有二进制文件

    回复

  62. > 在 Windows 中，不能直接进行系统调用。取而代之的是动态链接到为你进行系统调用的库。这样，微软就可以在内核层面做各种恶作剧，同时为用户空间提供稳定的 API。这个小天才让我们可以在同一台机器上同时使用 Linux 和 Windows。

    完全正确。Linux 从来就不应该允许来自 libc 或大型 vdso 之外的系统调用。

    回复

  63. 他忽略了一点。Flatpak/Snap 不仅仅是运送二进制文件的另一种方式。它们是隔离应用程序及其功能的方法。Landscape 已从保护系统或用户免受他人攻击，转变为保护同一用户的应用程序及其数据免受他人攻击，尤其是在桌面环境中。这在 Windows、其安全模型和应用程序的地图上都找不到。这是一个巨大的倒退。

    回复

    1. 每个应用程序都应该是自己的 “用户”（子用户），而登录用户/管理器应该是所有这些 ‘子用户’/“代理 ”的组长。

      从 20 世纪 70/80 年代开始改变安全模式，可能有助于提高安全性和隔离性。不过，如果不能在桌面环境/shell 中实现真正流畅的管理，同样的安全性通常也会让人头疼。

      回复

    3. Windows 在这方面做了很多沙箱处理，但你的意思是什么？

      回复

  64. 人们总是谈论 “我可以运行 20 年前的 .exe 文件”，但当我告诉你，30 多年来我从未需要运行过 20 多年前的可执行文件时，我不禁哑然失笑……是啊，然后呢？

    当然，我相信向后兼容性是一个很好的功能，但我从来没有，我想我也永远不会需要运行 20 多年前的软件。

    回复

    1. 我在桌面上打开了一个终端，运行的是 1983 年的 ZORK，已经有 42 年的历史了。

      是的，有现代的移植版和更新的版本，但这类复古游戏和实用程序还有很多人在使用。

      回复

    2. 我的经验是，20年前的exe文件在wine中运行的几率比在windows中运行的几率要大，而20年前的Linux可执行文件会失败，因为它所依赖的共享库无法获得

      回复

      1. 我的经验是：

        ，如果20年前的exe文件触及了一些相对晦涩的东西，那么它们在Windows和WINE上都会失败。不过，在WINE下用文件解决问题更容易（如果你破坏了某些东西，可以直接扔掉前缀）。WINE犯下的最大错误就是默认使用单一共享前缀（第二宗罪也与此类似–天真地试图整合文件夹和菜单）。

        20年前的Linux动态二进制文件如今几乎总能正常运行；snapshot.debian.org上有你需要的所有旧库。可能的例外情况是，这些动态二进制文件触及了一些硬件或需要独占访问权限的东西，但这仍然比 Windows 上的情况要好。

        由于文件系统和文件布局发生了变化，Linux 上已有 20 年历史的静态二进制文件经常会出人意料地失效。

        回复

    3. 你可以拥有一个具有相同功能的 Electron 应用程序，但一个较老的程序很可能可以做到这一点，而不需要 Electron 或 web 应用程序。

      回复

    5. 我使用 Nikon Scan 4.0.0。它发布于 2008 年或 2004 年。

      回复

  66. 顺便说一句，Wine 在支持旧版 Windows ABI 方面比 Windows 本身更稳定。

    应该有人为 Linux 本身开发一个类似软件。例如，支持旧版/历史性 ABI，并将其转化为现代 Linux 所拥有的任何功能。

    Wine 本身已经存在，你无需再为在 Linux 上运行 Windows 程序而开发新的发行版。只要改进 Wine 就可以了。

    回复

    1. 没错，windows 程序只需要 Wine 就够了。我们有 snap、flatpak、docker 和其他一些用于 Linux 的东西。

      几年后，当 MS 的某个人意识到他们可以在 Linux 仿真层上使用 wine 来运行 MS 过去三十多年来的任何旧版软件，然后清理 Windows 的其他部分，不再支持旧版 API 时，我们可能会感到有些讽刺。因为拥有这些都是多余的。模拟器很棒。没必要原生运行古老的软件。

      回复

  67. 当然，人们可以在 Linux 中设计一个可以调用系统调用的库，并动态链接到它。

    回复

  68. Java 在很大程度上已经解决了这个问题。整个 ABI 的废话真让我头疼。从根本上说，这只是把软件编译成可疑的 blob 并发送给用户这一愚蠢决定的结果。如果你能发布一个与平台无关的源代码中间表示法，保留足够的语义以消除 ABI 问题，然后将编译的最后一步留给操作系统，那么你就能摆脱大量的恶意软件，并大大简化软件的发布。发布二进制文件从各方面来说都很糟糕。

    回复

    1. > 运送二进制文件从各方面来说都很糟糕。

      .class 和 .jar 文件不就是 “二进制文件 “吗？

      > Java 在很大程度上已经解决了这个问题

      也许，只是也许，有一些缺点意味着事实上这个问题并没有解决。否则，Java 可能已经完全淘汰了 C、C++。例如，我们中有些人设计的应用程序无法忍受最坏情况下的 GC 停顿。我们中的一些人在设计应用程序时无法忍受花费额外的时间对几乎所有内容进行堆分配。

      回复

      1. >.class和.jar文件不是 “二进制文件 “吗？

        .jar只是一个后缀名不同的压缩包 +META-INF中的一些元数据（包括依赖关系）。.class是编译过的java文件，但它们确实包含各种元数据，包括变量名和调试信息（如果您选择保留的话）。它们包含所有方法和字段的原始名称（以及注释），因此反射 API可以正常工作。反编译类文件非常容易，甚至可以还原原始行号。

        >否则，Java 可能会彻底淘汰 C

        Java 确实需要一个主要用 C/C++ 编写的托管运行时。

        >我们中有些人设计的应用程序无法忍受最坏情况下的 GC 停顿

        当前的 GC 品种或低延迟 GC（不含停止-世界阶段）应该足以满足大量应用程序的需求。

        >我们无法承受花费额外时间对几乎所有内容进行堆分配。

        这已经不是问题了，堆分配可以省略，正常情况下只是指针碰撞。每个线程的私有分配是迄今为止最常见的情况–非旧版引用对象的垃圾回收也是完全微不足道的（即 memset）。即使是共享（跨线程/区域）分配，在大多数情况下也只是 CAS 碰撞。注意：复制/代际垃圾收集器会将被非旧代引用的对象复制到另一个区域，然后将原始区域清零。

        尽管如此，Java（和托管语言）也不是万能的。

        回复

        1. Java 可以被优化得面目全非，变成无法再用 Java 语言表达的字节码。至少过去是这样。除了目标系统是虚拟 CPU 而非真实 CPU 之外，它与其他二进制文件并无不同。

          多年来，Java 还废弃了各种东西。更不用说小程序被彻底封杀了。我有一些 25 年前的 Java 二进制程序，在 10-15 年前就已经无法在现代运行时中运行了。

          更不用说现实世界中的大部分 Java 都是特定于平台的。也许本地代码并不常见，但像硬编码路径或忘记正确使用路径分隔符等更微妙的事情却时有发生。安装程序过去通常也是特定平台的。也许这个问题已经解决了，但如果安装程序只支持当代的 Windows 和 Mac 系统，那么在安装旧 Java 应用程序时还是会遇到麻烦。

          回复

          1. > Java 可以被优化得面目全非，变成 Java 语言无法再表示的字节码。

            我不清楚这是怎么做到的，Java 全靠 JIT。字节码几乎无关紧要。就我个人而言，我可以阅读汇编（几年前[几十年前]，我只能阅读十六进制）。因此，即使是经过混淆（未优化）的 Java 也很好读。不过，类文件确实保留了所有方法声明、所有常量池条目和所有字节码（反编译起来也很琐碎）。当然，类的格式变化不大。

            > 如果您需要更短的时间，Java 8 可以满足您的需求。

            需要更短的时间，Java 8（10 年前）可以运行几乎所有 Java 1.0（甚至 0.9）版本的程序。Java 9（2017 年）才是引入项目拼图的最近版本。在此之前，Java 是迄今为止向后兼容性最好的平台。对于大多数应用来说，现在依然如此。请注意 “弃用”（deprecation mean(t)）–不要在新项目中使用，因为它已被移除；同样，这些都是最近的变化。

            >更不用说现实世界中的大部分 Java 都是针对特定平台的。

            再说一遍，如今这种情况已经很少见了。像 zstd 这样的东西可能会加载一个库，但即便如此，本地代码接口在几乎所有平台上都是一样的。当然，如果你说的是原生用户界面，那就有点道理了。

            >正确使用路径分隔符。

            Windows 的反斜杠已经臭名昭著，但 25 年前就已经没有理由再使用反斜杠了。所有 Windows 路径都可以使用斜线分隔符（java.io.File 中也有分隔符）

            回复

      2. > 我们中有些人设计的应用程序无法忍受最坏情况下的 GC 停顿，例如

        首先，我想指出的是，这些人绝大多数都是被蒙蔽了，他们在没有实际测试过假设的情况下就得出了这样的结论。但无论如何，JAR 文件的概念并不需要垃圾回收。我们已经可以从 Wasm 等产品中看到这一点，尽管它并没有达到我想要的效果。

        回复

    2. 你指的是 ABI 问题，比如无法在 java 8 运行时上运行 java 11 jar？

      回复

      1. 不，我指的是 ABI 问题，比如无法更改结构体中字段的顺序。

        回复

    3. > dubious blobs

      我想你只是建议用其他二进制 blobs（如 CLR/.NET 程序集/可执行文件或 WebAssembly 文件）来替换二进制 blobs。

      或者用 JavaScript 的方法：分发压缩后的最小化（有点像编译过的）源代码，然后运行时 JIT 对其进行编译（例如 V8 引擎的 Turbofan 编译器）。

      回复

      1. 我正试图用独立于平台且不易更改的文件取代依赖平台且容易损坏的二进制文件。是的，这些文件仍然是二进制文件，但计算机上的所有文件都是如此。这些新格式的用处在于，它们保留了更多的源代码信息。

        回复

    4. 为什么 Libre Office 的启动时间比 MS Office 长？为什么感觉迟缓？

      至少你没有提议用 Javascript 编写所有内容。

      回复

      1. 虽然 Java 实现是次优的，但确实没有必要这样。我认为最理想的方法是运行编译器优化等功能，然后生成与 C89 语义相似的输出。然后，在第一次运行程序时，在目标机器上调用一个简单的编译器并进行少量优化，然后将结果缓存在某个地方。在随后的所有运行中，由于编译器不需要保留 ABI，因此可以执行内联动态链接库调用等操作，因此你得到的程序实际上比预编译的 C 代码运行得更快。

        回复

        1. 你知道有什么软件能做到这一点吗？

          回复

          1. 可惜没有。Wasm 正在尝试做类似的事情，但它缺少某些对实现这一点很重要的东西（在一个模块中指定未知大小的类型，然后在链接时在另一个模块中查询其大小）。

            回复

    5. java 类有 “abi”。可执行代码的任何二进制表示都必须定义一个应用程序二进制接口，才能与其他代码交互。

      回复

      1. 关键在于 “abi “是独立于平台的（而且绑定时间很晚）

        回复

  69. 说实话，我有同样的想法已经有一段时间了。是的，你可以安装 wine 和 binfmt_misc，但它不是默认的。它应该是默认的。在这个时代，没有人应该分发二进制 Linux 应用程序，尤其是桌面应用程序。Win32 从一开始就为桌面应用程序设计得更好，这一点都不好笑。举个简单的例子–Win32 .exe 有一个图标，可以立即告诉用户它是什么，但 Linux 应用程序却需要一大堆黑客和额外的文件（什么是 .desktop），一不小心就会失去同步。此外，ABI 确实很稳定。你不必担心图形和音频 API 会消失等问题。

    就像我们的音频栈一样： OSS 已过时，因此应使用 ALSA，实际上直接访问 ALSA 设备已过时，应使用带有大量插件的特殊 ALSA 配置，实际上直接调用 ALSA 已过时，应使用 aRts，实际上 aRts 只能在 KDE 上运行，应使用 ESD，实际上 ESD 已过时，应使用 pulseaudio，实际上 pulseaudio 占用了太多 CPU，应重写所有内容以使用 JACK，实际上 JACK 只适用于音频工作站，应使用 pulseaudio，实际上 pulseaudio 已过时，应改用 pipewire…… 我敢肯定，再过 6 个月，我就会读到 pipewire 被淘汰的消息，而新的 Linux 音频栈的最终形式也将出现（由 Rust 和 Emacs Lisp 共同编写）。

    总之，Linux 的二进制兼容性只是一场小丑表演，操作系统本身并不是为开发图形桌面应用程序而设计的。我们不应该再装模作样了，应该把所有面向用户的程序都编译成 Win32 ABI，或许在这里或那里做一个小小的扩展。

    回复

  70. 最糟糕的是，这只会鼓励在开放平台上开发封闭源代码软件，给厂商另一个不进行本地移植的理由。

    祝你好运，你正在建造一个地狱般的世界。

    回复

    1. 我不在乎是否能访问源代码。我只使用应用程序，不想查看源代码或编译它们。

      因此，只要它能满足我的需求，以我需要的方式运行，打开/关闭我都不在乎。

      我觉得我不是唯一有这种想法的人。

      回复

      1. 你肯定不是一个人，你的心态是用户的心态，而不是开发者的心态。

        这就像期望只吃食物的人了解食物是如何制作的一样。只是你不是目标而已。

        回复

        1. 我两者都是。但我并不觉得有必要查看我使用的所有软件的源代码或对其进行修补。

          回复

  71. > 注意：我并不反对苹果或微软。他们都有了不起的工程师！我不认为他们有恶意。相反，我认为这些公司的激励机制不恰当。

    不恰当的激励机制？谁说了算？

    按照自己董事会的指导方针实现利润最大化是 “不当 “吗？

    我有一种感觉，OP 有一些预定义的高尚观念，他们希望人们在某种程度上按照这种观念行事。

    回复

    1. 是的，这是作者的价值判断。不择手段地追求利润最大化是病态的。这里的许多人都会同意这一点。

      回复

    2. > 按照自己董事会的指导方针实现利润最大化是 “不正当 “的吗？

      从最终用户的角度来看，激励机制是不恰当的。如果他们生产的是锤子，他们就会在许可协议中规定锤子必须与特定类型的钉子配合使用，并积极阻止用户使用竞争对手的钉子。他们也会确保昨天的锤子不足以敲击今天的钉子，他们会添加摄像头来观察用户在做什么，以便销售 “有针对性的 ”广告–在此期间，锤子不会敲击任何钉子，而是像《谁陷害了兔子罗杰》中的那把会唱歌的剑一样唱歌–他们还会确保，无论用户使用锤子有多么灵活，这东西都不会是 100% 可靠的。

      当然，锤子远没有计算机和操作系统那么复杂。这也许是因为它们是由工具制造商而非技术公司制造的，也许是因为它们是古老的技术。如果福特听从客户的要求，生产出更快的锤子，他就会生产出现代锤子。或者，也许–很可能–有时候，获得更快的马、钛合金锤子或自由软件操作系统会更好，因为它们只适合你，而不适合其他人。

      回复

  73. > 试试对一个刚满一年的 Linux 二进制文件做同样的事情。

    我经常这么做。效果很好。你有具体的例子吗，还是这只是一个匆忙构建的稻草人？

    回复

  74. > 论点： 我们应该创建一个默认通过 Wine 运行 Windows 二进制文件的 Linux 发行版。

    “我们应该”？你是指我吗？我有一大堆自己的项目要忙。

    你为什么不说 “我应该创建……”？如果你觉得这是个好主意，没有什么能阻止你实现它。你自己去做吧。

    回复

  75. > Linux 环境不稳定

    你知道有多少导弹是运行 Windows 系统的？

    回复

    1. 你知道有多少运行 Linux 的？它们中的大多数要么是专门的裸机操作系统，剩下的是 VxWorks。

      回复

  76. 在 Linux 上，二进制文件的发布之所以 “不稳定”，是因为用户不能像在 Windows（以及 Mac 上）那样随意从任何地方下载二进制文件。用户要么从发行版中获取二进制文件，要么从源代码中编译二进制文件。无论哪种情况，用户都不会看到二进制发行版 “不稳定 “的问题。这就是问题所在。想要使用被破坏的 Windows 软件模式的人可以直接运行 Windows。任何理智的 Linux 用户都不希望把 Linux 变成 Windows。我运行 Linux 就是为了避免使用 Windows。

    回复

    1. 除了软件包/软件管理之外，还有很多原因可以避免使用 Windows。

      Linux 有 appimage，它已经能够像 Windows 那样运行 “松散 “的本地可执行文件。Flatpak、Snap 和 Docker 都打破了 “发行版仓库或从源代码编译 “的模式。玩视频游戏的主要方法是安装 Steam 并在容器内运行 Windows 软件。你对 Linux 的这种纯粹主义看法并不存在。

      回复

      1. > 你对 Linux 的这种纯粹主义看法并不存在。

        我的电脑上有，我猜很多 Linux 用户的电脑上也有。

        回复

        1. Linux 用户？也就是说，使用运行 Linux 的设备的人？比如安卓？

          或者你指的是台式机 Linux 用户，不过也不是 “很多”。虽然有商业/科普/科学部署，但我认为我们讨论的不是这个，而是具体的家庭使用。所以我们说的主要是爱好者。我可以想象，其中许多人，甚至大多数人至少会轻度玩游戏，而 Steam 实际上是在 Linux 上购买游戏的默认场所。你在模拟器上运行过游戏吗？不纯净！用火清理！

          软件仓库+源代码编译模式不是 “Linux”，甚至不是 “桌面 Linux”。Linux 可以用无数种不同的方式执行软件，Linux 之所以是 Linux，就在于它具有无限的灵活性。

          回复

          1. > 你是指桌面 Linux 用户

            很明显，因为这正是这篇文章和这次讨论的主题。

            > 没有 “很多 “这样的用户

            我想，这取决于你认为 “很多 “是指什么。本讨论所涉及的这篇文章显然认为有足够多的 Linux 用户，因此它提出的 “将 Linux 转换为 Windows “的建议值得一试。

            回复

            1. > 很明显，因为这正是这篇文章和这次讨论的主题。

              我只是想说明，Linux 并不是一件单一的东西，它无所不包。你想让操作系统按你的意愿处理事情？你想要，其他人也应该享有同样的特权。对 Linux 生态系统中存在的某些实现或功能跺脚是愚蠢的，自由与开放源码软件的全部意义就在于它们都可以存在。

              > 这篇讨论的文章显然认为，有足够多的功能使其 “将 Linux 转换为 Windows “的提议值得一试。

              摘自这篇文章 “想象一下，我们制作了一个新的 Linux 发行版。这个发行版将提供一个与 Windows 足够接近的桌面环境，Windows 用户无需培训即可使用。

              这个发行版并不是为使用 Linux 的人设计的，而是为使用 Windows 但可能想转用 Linux 的人设计的。我就是其中之一，去年我把我的游戏电脑从 Windows 换成了 EndevourOS，尽管过去 20 年里我一直在其他设备上使用各种发行版。我换电脑的原因是，Windows 正在变成一坨屎。我对 Linux 了如指掌，我使用 Blender、Krita、Gimp、Inkscape 和 Reaper，这些都是原生应用程序，但有时我只想安装一个 Windows 应用程序，因为我需要的功能让它变得非常必要。双启动非常麻烦，虚拟机会破坏工作流程，虽然有时我可以用 Wine 运行，但还是很麻烦。我可能不会使用拟议中的操作系统，但可以无缝安装 Windows 软件的组件呢？我很希望这些组件能够存在。

              回复

    2. 正是如此。事实上，如果一个发行版不是一个维护良好的应用程序目录，那它又是什么呢？

      回复

    3. >想要使用残缺不全的 Windows 软件模式的人可以直接运行 Windows

      数十亿人就是这么做的。:)

      回复

    5. 说说你自己吧。我使用 Linux 已经有十年了，如果像 Windows 那样的独立应用程序设置成为软件发布的标准，我将别无所求。

      集中式软件包管理是一种诅咒。应用程序应该对自己的更新负责，而不是操作系统。

      回复

      1. 不过，我认为应用程序的安装是一项独立于 $THING_THIS_APP_DOES 的技能。

        因此，我宁愿应用程序的作者只专注于完善他们的应用程序，而这些应用程序可以由经过培训的不同人员进行批量打包和分发，以应对这些挑战。

        我当然不希望

        * 应用程序在启动时自动检查更新–因为它们无法在关机时检查–导致不必要的数据泄露，通过网络了解我何时启动哪些应用程序（因为无论使用何种 TLS，它们都会拨号到可预测的位置）

        * 应用程序不断用自己定制的更新程序（和 “加速器”，这只是意味着应用程序全天候运行，但被最小化到托盘中；P）填满系统托盘。

        * 应用程序启动更新程序，更新程序窗口显示 “由于应用程序正在运行，因此无法更新”。关闭应用，等待更新，现在我不得不去找我最初打开应用时使用的文档。下一次应用程序启动更新程序时，我会让它停留在闪屏上，然后去关闭应用程序，这样自然也就关闭了更新程序，因为这次更新程序是另一个程序的子进程。(我记得早期版本的 Wireshark 就在这些方面给我带来了很多麻烦）

        * 黑客感染我的电脑的攻击面更加多样化：与其试图攻击至少在防御中毒方面有一定经验和既得利益的发行版，不如攻击任何一个在发行版安全方面不那么专业的软件作者，并接管他们的发行渠道。

        回复

      2. 好消息，有一个发行版叫 Slackware，它放弃了集中式软件包管理（除了为预装软件包提供更新之外）。在你开始使用 Linux 之前，它已经存在了约 20 年。如果你想摆脱集中式软件包管理的束缚，像个真正的男人一样运行”./configure && make && sudo make install”，你应该试试它。

        回复

        1. 独立应用程序安装程序≠从源代码编译

          回复

      3. > 应用程序应负责自己的更新，而不是操作系统。

        发行版并不完全是 “操作系统”。运行 Linux 不需要发行版。

        就 Linux 应用程序而言，发行版扮演的角色更像是 Windows（或 Mac）世界中的应用商店。当然，苹果公司的智能手机自诞生以来就一直是这样，而他们的桌面操作系统也越来越像这样。Windows 也是如此。

        回复

        1. > 当然，苹果公司已经以这种方式锁定了他们的智能手机… Windows 也是如此。

          我们希望桌面 Linux 也这样吗？

          回复

          1. 如果你的意思是，我们希望桌面 Linux 有发行版，那么这艘船几十年前就已经启航了。是的，运行 Linux 不需要发行版（正如我之前所说），但大多数运行 Linux 的人都使用发行版。

            不过，Linux 发行版虽然扮演着类似应用商店的角色，但与 Windows 或 Mac 应用商店仍有很大不同。首先，它们不限制你在系统上安装其他东西；你不必越狱才能在 Linux 电脑上安装发行版没有打包的东西。其次，它们不会坚持要求你注册一个账户并交出个人信息，如果你不这么做，它们也不会不停地唠叨。

            回复

      4. 鉴于每个操作系统都在朝着集中式应用更新的方向发展。Windows 应用商店就是这样做的。我猜 MacOS 的应用商店也是如此。在主要的移动操作系统中，这几乎是所有用户安装任何东西的唯一方式。

        回复

        1. 其他操作系统的最大区别在于，打包工作由原作者完成，他们不必担心发行版的发布周期（以及软件包冻结等问题）。

          在这方面，Windows Store 与 Flathub 最为相似。

          回复

    6. 非常感谢！我正要发表几乎相同的内容，所以我还是回复你的帖子（并向上投票）：

      读到有人以发布二进制文件的困难为由批评 Linux 软件的发布，这实在是太有趣了。

      这是windows最大的安全漏洞之一。第三方分发二进制可执行文件。

      至少在典型的 linux 发行版中，二进制文件是由发行组织构建的，并对源代码的来源进行一定的审查。

      而从互联网上下载 Windows 应用程序时，人们根本不知道二进制文件中包含了哪些源代码。

      我也不喜欢非二进制系统，比如 flatpack。同样，我更喜欢由发行版构建的二进制文件，如果需要的话，也可以在本地构建。

      回复

      1. > 至少在典型的 Linux 发行版中，二进制文件是由发行版组织构建的

        ……发行版经常会对上游代码打补丁，而上游既不认可也不想支持这些补丁。然后，当出现问题时，用户无法向上游求助，而发行版软件包维护者也根本没有足够的时间来处理所有的用户报告。

        回复

      2. > 至少在典型的 Linux 发行版中，二进制文件是由发行组织构建的，并对源代码的来源进行一些审查。

        这种 “功能 “在非自由软件中就会失效，而大多数商业应用程序都是如此。你可以使用 Spotify 和 Steam 的 PPA，但同样不知道其中包含了哪些源代码。

        回复

      3. 向我解释一下，为什么要限制我只能运行发行版供应商指定提供的二进制文件，或者通过无尽的麻烦来获取和构建源代码（顺便说一下，源代码可能根本无法获取或构建）。如果我有一个 5 年、10 年、15 年前的二进制文件，我他妈的就应该能够在我的电脑上运行它。

        回复

  77. 什么 “我 20 年前的软件还能用！！！”。谁会真的运行未经维护的废弃软件？我更希望操作系统开发人员不要浪费时间维护旧软件，而是与时俱进。

    回复

    2. 我玩 2005 年发行的《寂静猎人 III》。有时也玩《半条命》。所有老游戏都是主机游戏。

      企业运行的都是老游戏。

      回复

    3. 这是讽刺吗？我最喜欢的一些游戏都有 20 年历史了。Windows 在很多制造领域都很流行，因为设备软件不会更新，只能通过 16 位串行端口连接旧程序。

      有一大堆传统软件在那里乐此不疲地运行着，不需要更新。

      回复

      1. 好吧，但你也可以让它运行在旧的操作系统上。花钱买一个 RHEL 许可证，然后就再也不升级了。

        回复

        1. 但我不想用 15 年、20 年、25 年的旧硬件单独运行一台机器，来维持操作系统的运行。

          回复

    4. 我还在玩 1997 年的《全面歼灭》。

      很棒的游戏。

      回复

    5. 很多嵌入式设备的控制软件都很老旧。

      回复

    6. > 谁会运行未经维护的废弃软件？

      个人电脑是为个人服务的。他们不会从纯度测试的角度来看待对自己系统的使用。

      > 我更希望操作系统开发人员不要浪费时间维护传统的垃圾软件，而是与时俱进。

      那就不要用你的钱去支持那些维护旧系统的人。如果市场显示它不同意你的观点，我也不会感到非常惊讶。

      回复

    7. 人们反对这种做法，但苹果公司就是这样做的，而且他们似乎做得很好。

      回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注