Linux 上 PowerShell 中的 DLL 文件支持

Whi*_*clo 7 linux powershell

为什么 Microsoft PowerShell 在安装到 Linux 计算机上时能够安装 DLL 文件并且仍然可以工作?微软内置了一个人们似乎不知道的界面吗?

这是从https://github.com/PowerShell/PowerShell下载二进制 tar 时下载的内容的图像

在此输入图像描述

它包含 .DLL 文件,而不是 .SO 文件。

use*_*686 17

\n

微软内置了一个人们似乎不知道的界面吗?

\n
\n

不需要有特殊的接口。Linux 上动态链接可执行文件的加载是由用户空间库完成的(例如,当您运行 ELF 文件时,它通常指示/lib/ld-linux.so.2为其“解释器”),libc \xe2\x80\x93 不是内核 \xe2\x80\x93实际上是在启动时和稍后通过 dlopen() 处理 .so 文件的加载。

\n

这意味着任何程序都可以实现自己的可执行文件或库加载器,如果它确实想要\xc2\xa0到\xe2\x80\x93,内核的参与主要是在通用系统调用中将文件映射到内存并标记正确的当加载程序请求时,将内存区域设置为“可执行”(mprotect)。(例如,发布此用户空间加载程序是为了替换已删除的对旧“a.out”格式的内核支持。)

\n

另一个例子:Wine 是一个明显非 Microsoft 的项目,它自己也支持加载 PE 格式的 Windows 可执行文件(并允许它们加载 PE 格式的 DLL),其历史比 PowerShell 存在的时间要长得多。(以前Wine自己的.dll内部仍然是ELF,但最近它也将它们完全切换到PE。)

\n

因此考虑到这一点:

\n
\n

为什么 Microsoft Powershell 在安装到 Linux 计算机上时能够安装 DLL 文件并且仍然可以工作?

\n
\n

PowerShell 作为一个整体构建在 .NET 运行时之上,即使在非 Windows 平台上,它也始终使用 PE/COFF \xe2\x80\x93 .NET 运行时有自己的 PE 加载器(很像 Wine 那样),并且是处理整体 .dll 文件格式以及其中的 CLR 字节码。

\n

(此外,即使这些是 PE 文件,它们也不是普通的“Windows”DLL \xe2\x80\x93 请记住,.NET 语言最初并不是直接编译为机器代码,它是一个字节码平台,类似于爪哇。)

\n

对于 .NET,大多数相关 DLL 不会直接进行特定于操作系统的调用 \xe2\x80\x93,它们保留在 .NET“世界”中,并且运行时本身提供抽象层。(.NET 代码可以直接调用外部库,但在错误的操作系统上这些确实会失败。)

\n

.exe在早期,无论平台如何,即使主要可执行文件也曾经是 PE 格式文件。例如,如果您在 GNOME \xe2\x80\x93 中安装了 Banshee 音乐播放器,这是一个用 C#.NET \xe2\x80\x93 编写的完全 Linux 原生应用程序,那么您实际上会拥有 /usr/lib/Banshee.exe,一个 PE32可执行文件,通过 Mono 运行时运行。

\n

(Banshee 在 /usr/bin 中有一个包装脚本来启动它,但 Linux 也有“binfmt-misc”工具,允许将非 ELF 二进制文件的执行透明地委托给解释器 \xe2\x80\x93 \ 很容易将 Mono 或 Wine 声明为MZPE 文件的处理程序。)

\n

  • 重要的是要了解 PE 只是一种容器格式,有点类似于 AVI 或 WAV。容器*内部*可以有很多不同的东西!例如,您是否知道 WAV 容器实际上可以包含 MP3 压缩音频? (6认同)