Yes, of course, because there are different operating systems. But why exactly? How is that technically?
I mean when I e.g. B. I installed Mac and Windows on the same laptop and then compile a program in Windows and want to start it on Mac, it does not work. But wasn't it compiled for the same cpu?
I mean that I can't just start an Intel program on a Mac with m1 is clear. But if I have an Intel with a program that is compiled for Intel? Then why doesn't it work?
does it have something to do with binary compatibility?
I work as a software developer and have no idea about it
Every operating system needs different interfaces. Eg ne jar goes everywhere because it runs in a vm that has been adapted for each
Quite simply: You programs are not only compiled for a processor architecture but also for an operating system. The program has certain dependencies on interfaces provided by the operating system. They differ depending on the OS.
I work as a software developer and have no idea about it
Uff.
A program is not only bound to one CPU architecture. It also has other specifics. Let's just start by loading the program through the operating system: there are certain formats for executable files. Windows has its own, Linux has another, and MacOS again (although MacOS is much closer to the Unix world).
When we have overcome this, however, we're faced with the next problem: every program has dependencies on the operating system. Logical, because it doesn't want to have to fetch the bytes itself directly from the hard drive, or from the mouse, or talk about pixels with the graphics card just because a window is shown. And that looks completely different.
In practice there's still something like a "standard library" between your program and the operating system. This shifts the problem a bit, but it is not solved. Only in extreme cases do you have an entire runtime environment (such as the Java VM), then the program really doesn't care which operating system it is running on.
To some extent, some of these differences can also be ironed out by quasi-emulators like WINE.
Conclusion: you should take a close look at what operating systems do. Unfortunately, a lot of people seem to confuse the GUI with the operating system - in fact, that's a minor issue.
The software depends not only on the processor architecture, but also on the programming interfaces of the operating system.
And every operating system expects the executable program data in different formats. A macOS binary has a different structure than a Windows binary or a Linux binary.
Therefore, you can, for example, run software that is created with Java on different operating systems, since the Java Runtime itself has been adapted for these different operating systems and encapsulates their peculiarities in a uniform manner and also has its own format for the program files. But here too, platform independence ends when you do things that only work on one platform.
But if you compile software "directly" (without middleware), then it does not only depend on the processor type, but also directly on the respective operating system.
Thanks for your answer but isn't Mac OS in the Unix world?
So. You are right that e.g. Code compiled for x64 is basically executable on the x64 processors. But there are some things that bring incompatibilities into there
For example, if you If you look at the .exe of a Windows application and a Mac program, you will notice that although both are binary files, they have a different data format.
Windows uses the Portable Execution Format (PE) and macOS uses the Mach-O format. Linux, on the other hand, uses the ELF format.
What is common to all formats is that the binary files contain the compiled code and all the necessary data to be able to execute the application.
But the 3 operating systems all have different kernels. This also means different memory management. They have different syscalls (kernel functions for low-level tasks) etc. So a lot is different.
So what happens when a program is compiled?
Well, on the one hand, a program depends on the CPU architecture, but also on the kernel and its functions.
Take simply opening a file as an example. This is implemented completely differently under the 3 operating system kernels. So the source code has to be translated completely differently. The standard libraries of the various languages must also be compiled / implemented separately under the respective operating systems.
On the other hand, the compiled files are then linked either in PE, Mach-O or ELF format.
It is different when you program "bare metal". But then you no longer have an underlying operating system and you really have to program EVERYTHING yourself.
MacOS has its own kernel that is not or only partially based on classic Unix, but presents itself externally (userland) as a relatively classic Unix (in BSD flavor). So you can see differentiated.
Yes - but there are differences here too. The fact that macOS emerged from a Unix system does not mean that it is still compatible with all Unix systems.
MacOS IS a Unix because it is in direct descent from Unix: Unix → BSD → FreeBSD → Darwin (which is the basis of macOS)
Mac OS is similar to Unix or Linux and most of the shell commands are identical. Nevertheless it is an in-house development and therefore not compatible.
Not compatible.
Well compatible with what? Unix is no longer an operating system, but rather a few principles and interfaces for operating systems. The only notable specification is POSIX, and MacOS fully complies with it (and Linux almost fully).
Compiled Mac OS programs will not run on Windows, Linux, Solaris, AIX or HP-UX. So not compatible.