Why can't we create programs cross-platforms these days?

Question

Hi guys,

I just wonder, if all compilers in any language transform the code into the only language "talked" in the computer guts (Machine Code - zeros and ones), why is it so hard to pass .NET windows application into a Mac application?

Shouldn't someone come with a brilliant idea (I have no brilliant ideas since I got married 3 years ago!) and have a ... I don't know ... a machine code framework so, instead of the compiler converting to machine code, it would convert to that framework, that will be installed in any platform (SuSE, fsb, Ubuntu, AIX, SCO, OS X, Windows 9x, Vista, 7, etc., etc.).

I wonder why can't we do things this easy, these days...

Any thoughts?

Answer 1

We can do that, see Java for an example. Whether Microsoft will do it is another question. They maintain a competitive advantage for Windows by not doing it.

Other examples are Perl and Python to name just two. It's not enough to just have a language, you need to have libraries to make the programmers life easier. Java, Python and Perl seem to have achieved this relatively well and I'm sure Microsoft has the brainpower to do the same for .NET. But the question remains: why would they?

Stepping away from bytecode-type VMs, you also have things like VMWare, Virtual PC and so on which can run code on a hardware-level virtual processor. Some of these need the same processor under the covers, others (like VirtualBox and Bochs, I believe) run a virtual processor on top of a different processor.

What I haven't really seen is seamless integration between the host and virtual environments. VMWare's drag-n-drop between the two is okay but it would be so much better to be able to host an SPARC environment on top of x86 and basically have the SPARC apps look exactly like the x86 ones (similar to how Cygwin's X-windows-based apps just look like regular Windows windows.

Answer 2

Microsoft has only implemented .NET on Windows. Therefore, to have .NET applications run on other platforms, a new implementation is necessary. Mono is taking steps to make this possible. The current version runs most .NET 2.0 assemblies and supports many of the Windows-specific interfaces.

As to the rest of your question: Reimplementing all of the APIs that everyone else uses is hard, and existing projects are incomplete. Wine supports most Windows applications, but only just. GNUstep implements most of the OpenStep specification and has some compatibility to Mac OS's Cocoa API, but it's painfully incomplete and will be for a long time.

If everyone used one standard API, perhaps it would be different. But, frankly, all the APIs that exist suck in some way.

Answer 3

In fact, it's already done. To a certain extent at least.

One of the efforts is called Java, which is a cross-platform language. Java compiler compiles source to something called "bytecode", which is nothing more than a machine-independent "assembly language". That "executable" is later executed by the Java Virtual Machine (JVM), which is the part that differs from platform to platform (that is, Windows JVM is obviously different from MacOS JVM).

However, cross-platform apps are not that simple. It's relatively simple to write a basic VM that would execute some kind of abstract bytecode for every possible platform. But the language itself is practically nothing if it lacks a rich class library. So implementing the said class library is a very hard thing for various reasons.

Answer 4

Well you kind of can with Silverlight. As to whether Silverlight moves out of the browser and into native apps, that's a political decision from Microsoft, rather than a technical issue. The Mono guys have also done work on getting .net to build iPhone binaries, so it's no doubt going to get more cross platform in the future.

Adobe Air, Java and other such things also make cross platform client side apps - hell, you can even do cross platform in C++ if you really want to :-)

Answer 5

The problem is always that you would get a sub-par application.

If an application needs to work on all platforms then you end up with a GUI that fits no one platform correctly, and an application that misses expected functionality on the platform i.e. functionality that only exists on one platform - on OS X you would expect integration with all the latest features, and the smae goes for Windows and *nix

The closest you can get I guess is to have the core functionality cross platform, and then build the GUI and any additional platform-specific features on top.

Answer 6

As others already mentioned, it is possible (especially JVM-based languages and Python), and many people do create cross-platform apps. What astonishes me is the number of people who stick with platform-dependent frameworks. Apparently they have been marketed better.

These things have more to do with political than with technical issues. In practice the most demanding technical issues with cross-platform development arise from low-level hardware communication (drivers to specific devices etc.) but typical apps don't need to communicate with hardware directly anyway.

Answer 7

This issue is deeper than most people are laying out, Java is still not really platform independent as it won't run on all x86 or x64 OSs, you still need a VM to run ontop of the OS. It isn't even close to what you propose as you still need an OS dependent runtime to execute the 'independent' bytecode.

The problem comes with the fact that most executables are overlaying the OS and using it as a kind of framework. As soon as you place some kind of OS dependent code into your application, you screw your chances of making it independent. Disc IO, network IO, Graphical UI, getting system information, any of these things will impact how and why your code can't be independent.

There is also the problem of what an executable is, on windows you have PE whereas on most linux OSs you have ELF. These have different structures and different loading styles. How they are loaded and executed is up to the OS and not a matter for the executable.

You can see the difference between the two formats in this image (taken from here:

Basically the problem comes that there is no standard for the way in which executable/binary files are structured and loaded into a computer. Then, atop of that is the framework and functionality of the OS. It's a far more complex problem but one that isn't going to be solved as long as companies want to have OS specific functionality.

Answer 8

Applications depend on the operation system to provide services.

You might create an application with minimal dependency on the OS. But even if (with some serious Fu, Magic and handwaving) you make it run on "every computer", it's not what we want.

Script and Script-like languages (like Python and Perl as mentioned) go that way: they use minimal features of the OS, and build everything they provide on top of it. That's great for command line applications because all you need (more or less) is reading and writing files and the user console.

Rich applications today need much more services though, they need to "run on the OS" rather than "on the CPU" alone: we expect them to integrate wih the OS, The UI should look native, you want to use the clipboard, the "open file" dialog should provide all the features the other open file dialogs provide.

An environment like Java tries to provide that in a portable way by using a higher level of abstraction: there are windows and widgets and all the beautiful things. But that has some problems of its own:

First, you always have to balance between "Virtualization Platform consistency" (i.e. the application works the same no matter where you run it) and "Host platform consistency" (i.e. the application works like a native application).

You could try to put away completely with the "native stuff" to avoid that problem, but then you aim for the intersection of functionality that all platforms provide. You run on Apple? Do away with the second mouse button. etc. Also your abstraction platform will always limp behind innovations on the host platforms.

---

The gist of it is that there's no silver bullet: there is always a compromise you have to make. There are different compromises successful at the market.

Answer 9

why it is so hard to pass .NET windows application into a Mac application?

.NET is meant as a framework for programmers to build windows programs. the full implementation of .NET (as done by MS) is only available for windows. There seems to be not much hope, that this will change.

For better cross platform support you might want to take a look at other languages, like Java [1]:

Java applications are typically compiled to bytecode that can run on any Java virtual machine (JVM)

... which is very similar to what python does [2]:

CPython compiles the Python program into intermediate bytecode, which is then executed by the virtual machine.

and even though .NET does the same thing [3]:

Also part of the .NET Framework, this runtime environment is known as the Common Language Runtime (CLR). The CLR provides the appearance of an application virtual machine

the problem is that the "virtual machine" - as defined and built by MS - simply is only available on windows:

.NET in its complete form is only available on Windows platforms