How is it that Microsoft PowerShell is able to install DLL files when installing onto a Linux machine and still work? Is there an interface that is built in by Microsoft that people seem to not know about?

Here is an image of what you download when you download binary tar from https://github.com/PowerShell/PowerShell

Enter image description here

It has .DLL files, not .SO files in it.


1 Answer 1


Is there an interface that is built in by Microsoft that people seem to not know about?

There doesn't need to be a special interface. Loading of dynamically-linked executables on Linux is done by userspace libraries (e.g. when you run an ELF file, it usually indicates /lib/ld-linux.so.2 as its "interpreter"), with libc – not the kernel – being what actually handles the loading of .so files both on startup and later via dlopen().

This means that any program can implement its own executable or library loader, if it really wants to – the kernel's involvement is mostly in the generic syscalls to mmap the file into memory and mark the right memory areas as "executable" (mprotect) when the loader asks. (For example, this user-space loader was posted to replace removed kernel support for the old "a.out" format.)

As another example: Wine, a distinctly non-Microsoft project, has also had its own support for loading PE-format Windows executables (and allowing them to load PE-format DLLs) for much longer than PowerShell has existed. (Previously Wine's own .dll's still used to be ELF inside, but recently it has switched them fully to PE as well.)

So with that in mind:

How is it that Microsoft Powershell is able to install DLL files when installing onto a Linux machine and still work?

PowerShell as a whole is built on the .NET runtime, which has always used PE/COFF even on non-Windows platforms – the .NET runtime has its own PE loader (much like Wine does) and is what handles the .dll file format overall as well as the CLR bytecode found within.

(Also, even though those are PE files, they aren't ordinary "Windows" DLLs – remember that .NET languages weren't originally compiled directly to machine code, it's a bytecode platform similar to Java.)

In the case of .NET, most of the DLLs in question do not make OS-specific calls directly – they stay within the .NET "world" and the runtime itself provides the abstraction layer. (It's possible for .NET code to directly make calls to external libraries though, and those would indeed fail on the wrong OS.)

In earlier days even the main executable used to be a PE-format .exe file regardless of platform. For example, if you installed the Banshee music player in GNOME – a fully Linux-native app written in C#.NET – you would actually have /usr/lib/Banshee.exe, a PE32 executable, running through the Mono runtime.

(Banshee had a wrapper script in /usr/bin to launch it, but Linux does also have the "binfmt-misc" facility that allows the execution of non-ELF binaries to be transparently delegated to an interpreter – it's easy to declare either Mono or Wine as the handler for MZ PE files.)

  • 6
    It is important to understand that PE is just a container format, somewhat analogous to AVI or WAV. There can be a lot of different things inside the container! For example, did you know that a WAV container can actually contain MP3-compressed audio? Jun 2 at 12:26
  • @user1686: very interesting and very complete answer. The kernel uses .ko files (kernel object) files. As far as the Linux kernel is concerned it also is responsible for drivers in Linux. You probably knew that, but not everyone will. Jun 2 at 19:08
  • @JörgWMittag: Could you point me to an article about container formats please? I knew that AVI was a container, but PE? Jun 2 at 19:32
  • I have started to wonder about executables as you can execute anything with the right environment. e.g. emulation. This may require its own question so let me know but, is all executable code via a container file in an emulation environment for PE Files, ELF files, Mach-O files. As all of them have run on Intel at some point. Jun 2 at 20:31
  • 1
    @WhitequillRiclo: PE files have "sections", one of those sections contains the "executable text" (e.g. the Intel machine code), but they could contain anything. In most cases nothing is emulated; a Linux x86 ELF contains native Intel x86 machine code and will be directly making Linux library and system calls. If you have a Windows x86 PE .exe that runs on Wine, it still has native x86 code, while Wine only provides the "API emulation" for Windows system calls. (Though if you have an x86 Mach-O that runs on Apple Silicon, then macOS indeed runs x86 machine code in emulation on the Arm CPU...) Jun 3 at 8:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .