Universal Binaries potential for true portability?
I've been thinking, if mac programmers can make a universal binary for a program that works on PowerPC and x86 macs, why hasn't anyone found a way to make a truly "Universal" binary, that is, one compiled program that can install on any operating system? it seems like such a thing would be all it takes to push machine code programming languages, such as C++ and C back up to the top, over bytecode and interpreted languages, such as Java and Python… then again, people are lazy and don't feel like learning code for another machine so it would probably be useless outside open source projects anyway… even still, maybe, with a batch script, some shell scripts, and a concatenation of binaries for various systems something similar could be conceived. or even a java installer to unpack an archive of binaries for various systems, and just delete the unnecessary files. what do you all think about such an idea? could it be done? I'm sort of new to programming still, so I'm definitely no expert, this is more like a six-year-old's perspective of a complicated matter that seems simple to a mind ignorant to the normal boundaries of possibility.
Entirely insane (kind of). Could possibly be done but ……. I don't even know. There are seriously way too many platform's and OS's and architectures to have a truly universal binary. Any way's ASM is pretty much the lowest of low languages and that is processor dependent which is a lot less discriminant than other languages. Shit you could say that binary itself is universal (zero's and one's) that's what it all comes down too.
The term for this is "fat binary", if memory serves right.
A big issue with this, I believe, is that the binary size would grow substantially larger with each added support for each architecture and OS. This results in a slower, more bulky application and complicates alot of things.
The main reason this method isn't used often is because of its more effective alternatives, such as having the installer choose a architecture-specific binary at install time or compiling from source. Not to mention linux pretty much doesn't have to worry about it because of the wonderful idea of a package respiratory.
So it's not so much that we can't do it, it's just that there is better alternatives or the results of doing a fat binary would be more problems than it's worth.
Hope that cleared it up for you :)
Well, I didn't understand your whole post, but I think you're asking why doesn't a powerpc binary run on x86 or amd64.
There are several problems, like you and others have identified, the machine code is different. What means jne on one doesn't mean the same on the other. But we can get by this, why don't windows x86 binarys run on linux x86?
Well this time there are two issues, firstly the packing loading etc. windows can run code without any special bits such as .com files there are just binary, but linux can't load them linux uses ELF mostly these days.
Another issue is kernel interupts the are widely different from linux to windows. (linux only uses 80h windows use what appear to be random ones) but we can even get past this! How about we just use bios provided interupts. Well then what can I say, if you successfully load the .com file into memory and have it excicute it would run on linux. Theres probably even a way to do this.
But for converting between platforms it just so happens it's more useful to have the compile seperate from the binary to save space.