Ask Slashdot: What Would Happen If All Software Ran On All Platforms?

Slashdot reader dryriver writes: We live in a computing world where the OS you use -- Windows, OS X, Linux, Android, iOS, others -- often determines what software can and cannot be run on a given electronic device. (Let us pretend for a moment that emulators and other options don't exist). What if -- magically -- such a thing as as Universally Compatible Software Application were possible. Software, in other words, that is magically capable of running on any electronic device equipped with enough CPU, GPU and memory capacity to run the software in a usable way.

Example: 3D CAD software that runs on Windows 14, Playstation 7, an Android Smartphone, Nintendo's latest handheld gaming device and an Ubuntu PC in exactly the same way with no compatibility problems whatsoever occurring. What would and would not change in such a computing world?
He also asks an even more important question: will this ever be possible or feasible from a technical standpoint? So leave your best answers in the comments. Will it ever be possible to run all software on all platforms -- and what would happen if we could?

Comments

Re: Java

[Anonymous Coward]

This is the answer I was going to post, and is our current best bet for achieving what OP wants. Now if the Java VM's were opened up and had heavy optimizations for each platform this would be good stuff. I don't see this happening though, Oracle and all..

What would happen?

[nospam007]

The same thing that happened during the mainframe days, when we could use all sorts of terminals and terminal emulators we wanted.
We would bitch about the speed.

Re:Java

[Wootery]

I was thinking the web. Gmail is the same on every browser, every OS.

In my opinion though Java, and multi-platform frameworks like Qt, do a better job than the cynics are willing to admit.

Won't happen -- it's like the halting problem

[Anonymous Coward]

What platform do you use to write the platform that can run all software?

Will it be able to run on itself?

Will it be able to run on the version of itself that checks to see if an arbitrary program will run to completion -- the unsolvable halting problem -- before running it?

Will it be able to run on the version of itself that only runs programs that won't compile?

And so it goes ...

Re:Java

[StormReaver]

I'm just going to address the Java aspect of your posting.

That's why it's called Write Once, Debug Everywhere!

I think this is just an attempt at humor, as it does not in any way, shape, or form reflect my experiences in my 18 years of Java programming. Native programming is: write once, debug forever, write again, debug forever again, ad-naseum. Switch platforms, and repeat. I've been doing this for 32 years, and the experience hasn't improved much over that time.

Neither has made me want to give up native solutions.

Java + Netbeans has been such a good experience for me that I cringe whenever I think about doing something natively. Whether it's Windows* (which is so especially cringe-worthy, there is no exaggeration in any language, human, computer, or alien that can adequately convey it) or Linux, programming in Java is several orders of magnitude more pleasant.

My Java/Swing software runs on both Linux and Windows with no additional effort. By far, the largest pain in the ass in distributing my Java programs is dealing with the brain disease that is Java's minimum and maximum memory usage. This exists to reign in applet memory issues, and is completely and utterly retarded for desktop software. Aside from that, write once, run anywhere has been an apt description of my process.

Native programming has exactly two benefits over Java:

1) Raw speed. For speed critical apps, native programs usually win by significant margins. However, most programs are not bound by speed requirements. Most programs spend most of their time waiting. And Java can wait just as fast as a native program. And for *most* application needs, the speed difference is negligible.

2) Special needs. Java supports the intersection of the capabilities of all the platforms it supports. Things like scanning, though, are not standardized across platforms to the point that Sun/Oracle want to support it. Most of these things, though, are addressable far more easily than Oracle would like to admit. So most of the time, it's not a significant issue.

* KDE comes close, though, as the enormous number of hoops that must be jumped through to get even a simple KDE development environment in place is quite unpleasant.

Re:Java

[AmiMoJo]

Sometimes less is better though. Take web apps, the refusal by other browsers to adopt batshit stuff like ActiveX, or one major vendor dropping support for some technology that is used to spy on users, benefits everyone.

Even more interesting is that people will happily trade usability for convenience. A lot of web apps are shitty, they break if you use the back button, the UI is entirely custom and ignores all guidelines, but since the barrier to entry is low (no need to install anything or wait) people use them.

Re: Javascript

[Anonymous Coward]

No he asked for a way to do all software executable on all platforms. And that's Java.

And he also asked what happens when all software use it. Well a lot of software do. However a lot of them is then compiled to native code that doesn't follow the "compile once run everywhere" design goal. But looking at Java software that exists and is runnable on any platform that supports Java we do have businesses that run some of their software on a Java only platform.

What we see on Java only platforms is that the operating system becomes a replaceable components. And so does hardware to a greater degree as native applications often has limited hardware support. I can't install FreeBSD on a Raspberry Pi and expect all FreeBSD software to work. But i can install Java and expect Java applications to work. Do if Raspberry Pi has power enough to run my applications i can just use it. And I can test with different operating systems and see what is best for my application.

So what we can already see is that Java applications gravitate away from windows into Unix-likes. People run it on Linux, FreeBSD, Solaris, various IBM mainframe operating systems. And even on Java processors. Then on top of that people use x86, AMD64, Sparc, power, ARM and a number of other otherwise incompatible processor types. What people use depends on what's best for their applications.

So yes if this was extended to other applications such as games and Photoshop we would see a rapid decline in Windows usage and a rise in practically everything else.

But the hardware market would be more profoundly changed. We would see ARM, SPARC and POWER desktop computers and workstations. That would put serious pressure on Intel and AMD especially when it comes to the expensive high end Xeon and Opteron products. We would see more competition and a rapid decline in processor pricing. Just like we have seen on other markets that already lack vendor lock in.

On the enterprise server market we haven't really seen much price decline but that's because the target audience isn't very price sensitive. But we have seen a more rapid growth in performance per processor and as such a decline in the price/performance ratio.

What about the security implications?

[apraetor]

Diversity decreases the threat profile, you don't want every device having an identical attack surface. Think of humanity; a virus which is potentially lethal to one person may not even give another person a cold, even in the absence of immunity due to previous exposure -- this is thanks to genetic diversity. If every human was genetically identical then we could easily be wiped out by a single well-evolved virus (maybe not too well-evolved if it exterminates the host..).

Re:The problem...

[Eravnrekaree]

The problems you describe can either be solved by the cross platform compatability library either emulating features on its own, or by applications adapting to absense of a feature by using an alternative or living without the feature when it is not available on an OS. Preferably the first alternative. Provided a basic level of functionality, anything can be implemented at the library/app layer. For instance, if you have a 24 bit video array buffer, you can implement any 3D operation in software, even though all you an give to the OS is bitmap data. It may not be perfect, it may be slow, but it can be done and its better than nothing.

There is an issue with cross platform libraries keeping up with applications needs so that apps are not tempted to include OS specific code. The library should meet the needs of the application rather than vice versa. App developers if they need an OS feature, instead of putting an OS specific call in thousands of places in apps, should just add a compatability layer once to the cross platform library, this way when they move to a new OS, they only need to update one peice code rather than thousands.

You mention web standards. For some while, they were indeed very weak, which was their own fault. Browsers dragged their feet on providing features but at the same time they provided horrible plugin models for OS level plugins. Basiclaly the browsers were saying, we dont provide the feature you need and dont care, but please write an OS dependant plugin using NSAPI so your web page can only be viewed on Windows. Thank you. Mozilla was guilty of that as any. I think it would be much preferable as an alternative to have provided a canvas to web apps in the browser to which vector and bitmap primatives could be drawn with javascript, rather than unleash a flood of low level plugins which had bad OS dependant code. Yes, eventually this is what ended up happening. I think we also have to accept 3D APIs in the browser to stave off OS dependant plugins adn third party apps.

Re:Java

[squiggleslash]

Multiple reasons:

1. As your follow-up sentence implies, many people have no idea what Java is or how it's supposed to be used - witness the confusion that comes up in every Slashdot article mentioning Java where people are convinced it's an alternative to Flash.

2. The language itself is extremely bureaucratic, which puts off many developers. Ease of use is critical in getting a language mass adoption.

3. It bundled a single language, and VM, together, coupling it with a small set of libraries designed for different environments. The reliance on a single language means developers support or do not support it based upon their view of the language, not the underlying platform. .NET has done a much better job here, and I think it's only people's mistrust of Microsoft that's holding the latter back. .NET is certainly most people's first choice for developing on Windows.

(3.1. To be clear, .NET has done a better job on creating an environment not dependent upon the whims of developers. .NET's failure to standardize a cross platform UI framework prevents that from being a complete rival to Java when it comes to being a cross platform application distribution system. That said, cross platform UIs... we're still waiting on someone to create a real, context-sensitive, cross platform UI framework in any platform, and no, QT isn't it.)