1

I looked at this scheme and now i want to know, can one executable be runned in a two systems, which have the same ancestor? (and so probably the same kernel?)

For example, according to the scheme: Solaris <- System V R4 <- BSD 4.3, so, can the BSD* (OpenBSD, FreeBSD, NetBSD) and the Solaris run the same executable?

P. S. may be this question is obvious and meanigless to you, but i am completly new to the *nix, so for me it is important.

  • 1
    The short answer is "No", They're all different operating systems, they all have different kernels, different system calls, different C libraries (and other libs), different filesystem layouts, different supported filesystems, even different executable formats. Some don't even run on similar hardware or have the same kind of CPU. – cas Jul 4 '16 at 12:34
5

Short answer: No.

Medium answer: Maybe, if the target OS supports it.

Long answer...

First thing to be aware of is that different vendors may use different chip sets. So a Solaris binary may be compiled for a SPARC chip. This won't run on an Intel/AMD machine. Similarly AIX may be on a PowerPC. HP-UX might be on PA-RISC. Let's ignore all these problems and just stick with the "Intel/AMD" space.

The next problem is that different OSes may expose different kernel system calls. This means that any call the application makes into the kernel won't do what is expected. This is obviously a problem. However the target kernel may be able to provide an "ABI compatibility layer"; the kernel (let's say a FreeBSD kernel) can detect you are trying to run a Linux binary and can translate between the Linux kernel ABI and the native kernel ABI.

The next problem is one of libraries; a Linux binary would expect to be able to load glibc of a specific version, which may not be present in the hosting OS. This may be solvable by copying the required libraries over. Again an OS may make this easier for you, e.g. by having a package for these libraries to make them easy to install.

After all this your binary may run :-)

Back in the 90s, Linux had a iBCS module which allowed for exactly this sort of thing. It made it possible to run, for example, SCO Unix programs on Linux. I had run SCO Unix Oracle on my machine as a proof of concept. It worked pretty well! Obviously there was no vendor support, so it wasn't suitable for production :-)

Now Linux has a massive foothold in this space other OSes try and add compatibility layers to allow Linux programs to run on their OSes.

So if your OS supports is and if you install and configure it properly then you may be able to run some programs from another Unix.

0

No, and in many cases, an executable can't even run on the same OS of a different version due to changes in the kernel.

A simple example that I ran into the other day: the dmesg command on OpenBSD outputs the system message buffer, which is where all the kernel's messages goes (boot info etc.). I recently recompiled the kernel, and suddenly the dmesg would come back saying

dmesg: sysctl: KERN_MSGBUF: Cannot allocate memory

This was due to not recompiling the user-land utilities, and dmesg, although "working" in the sense that the executable file was recognized as such, could not perform its task (due to changes in the kernel code).

So dmesg from a previous version would not "work" on a later version of the OS.

EDIT (from comments, with additions)

Think of the system calls of the kernel as an API. What would it mean for the API if one couldn't change it, or if one needed to maintain compatibility with previous versions all the time? It's not a design flaw, it is how software works in general.

You can't expect to run code compiled against one API version to work with any other version of that API. As an API/kernel developer, you would become more concerned about breaking backward compatibility than about adding to and improving the operating system.

Luckily, most software on Unix systems are designed according to the POSIX standard, which means that the source of the executable is transferrable between system types and will compile and run almost anywhere. The issue of binary compatibility between Unix platforms only becomes an issue when

  • Non-POSIX extensions are needed, and
  • The source code is closed-source.
  • Components that delve into the inner workings of the kernel definitely aren't likely to work cross-kernel. But Sun showed that outside of those limited programs it was possible to run a SunOS 4.1 program on a Solaris 2.6 machine; a totally different kernel and architecture (BSD->SVr4) but it worked. – Stephen Harris Jul 4 '16 at 13:00
  • Kusalananda, thank you, this is very interesting, that "an executable can't even run on the same OS of a different version due to changes in the kernel". Thats look like a significant design flaw, but as long as the OS is an incredibly complicated software, i wouldn't blame the developers :) – Amabo Carab Jul 4 '16 at 13:30
  • @AmaboCarab Think of the system calls of the kernel as an API. What would it mean for the API if one couldn't change it, or if one needed to maintain compatibility with previous versions all the time? It's not a design flaw, it is how software works in general. You can't expect to run code compiled against one API version to work with any other version of that API. As an API/kernel developer, you would become more concerned about breaking backward compatibility than about adding to and improving the operating system. – Kusalananda Jul 4 '16 at 13:42
  • Kusalananda, as i sad, i don't blame the developers too heavy, and i heard you, and understand you, through stil i think that backward compatibility is an important thing. Anyway, this isn't much related to the topic :) – Amabo Carab Jul 4 '16 at 15:01
  • The Linux kernel has an explicit design goal which amounts to "THOU SHALT NOT BREAK BACKWARDS COMPATIBILITY" with the fine-print saying "(unless absolutely necessary, and even then give due warning for at least a few kernel releases and you should think really hard about whether it's somehow possible to still support the old API no matter how broken it was)". Linus really doesn't like changes that break userland code. Patches that break compatibility or that aren't well thought out (and thus likely to need API changes in future) are often rejected for this reason. – cas Jul 5 '16 at 3:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.