Disculpa, pero ya no te entendí. Si el código tiene que ser multiplataforma para que funcione con tu aplicación entonces le estás dejando las mismas responsabilidades al programador de trabajar para cada sistema operativo en vez de que tu aplicación la adapte, que es lo que desde un principio se dijo que debía hacer. ¿O entonces cuál es la ventaja de tu aplicación? Es decir que mi aplicación de Windows que use el registro no va poder funcionar en linux ni con tu aplicación a menos que yo mismo le escriba el código?

Disculpa, pero este tipo de cosas son las que desde un principio se estuvieron discutiendo. 

me parece que tiene un problema y es la privacidad , no me gusta la idea de que para ejecutar algo se deba pasar antes por la nube .

Eso si, es totalmente distinto a lo expuesto al comienzo pero tienes toda la razón y es muy factible y tienes toda la razón de que pueda ser algo simple.

Por ejemplo, creamos un código, llamemoslo c$ que su sintaxis sea perfectamente la misma que java, ahora digamos que lo vamos a compilar, entonces el compilador toma todas las instrucciones del código y lo compila para código máquina embebiendo todas las librerías en formato .h necesarias para que funcione bién, este debería ser capaz de generar por lo menos 4 binarios: un exe (windows), un binario de gnu/linux, un binario para unix (mac) y otro para bsd.

Solo entonces no dependería de una maquina virtual porque el compilador debería ser el encargado de interpretar linea por linea el código y saber generar las mismas instrucciones en código máquina para cada plataforma ahorrando el traspaso de librerías, mv, etc.

Por ejemplo:


Al compilarlo debería generar un archivo binario para windows que haga uso de la librería strings.h para windows, al generar uno para linux que haga uso de strings.h para linux y así para cada sistema donde cada archivo .h o .cpp contenga la equivalencia en su sistema operativo y lo compile y genere los 4 ejecutables, cosa que cuando llames al de windows a traves del cmd este diga "hola" y al llevar el binario de linux a ese sistema y ejecutarlo desde el bash también diga "hola".

Las rutas de directorios deberían llamarse igual que en java: /a/b/c, donde / equivale a c: y para entrar a d: podría ser por ejemplo: disk://d/a/b/c, entrará al disco d de windows al directorio a/b/c, y cuando se ejecute en linux entrará al disco montado con nombre "d" y si no existe dará una excepción.

Como se ve, es 100% posible, tendrá sus ventajas y desventajas, no las conozco pero la idea no es mala, talves algo que en java pese 100kb termine pesando 50mb pero ya no necesitará de la maquina virtual que pesa al rededor de 500mb en total y al ser ejecutado en tiempo real su velocidad sería mucho mayor.

Yo no he dicho que fuese del todo imposible, pero es evidente que, si fuese rentable, las empresas lo habrían desarrollado, crees que una empresa que genere versiones para Linux + Mac + Windows no se lo habrá planteado? Imaginate, el coste de desarrollar eso, de ser posible, es mas caro que el que una empresa estima en portar TODOS sus productos (por ejemplo Adobe con la suite creative, microsoft con office.... etc etc)

Eso es una maldita locura, osea, pretendes hacer un ejecutable con ejecutables de todos los SO? vamos, un porgrama como Photoshop, que te carga 600 MB de ram tranquilamente, que me compro, exabytes de RAM?

1) Si el código es multiplataforma (p.e: ANSI C), mi único trabajo, es recompilarlo, osea, los escasos 2 segundos que puede perder una persona en escribir gcc en una linea de comando.

2) Si el programa no es multiplitaforma vas a fastidiarte.

3) hay cientos de lenguajes, algunos no estan en windows, otros no estarán en linux, otros no estarán en free bsd, otros no estarán en HP-UX, otros no estarán en solaris, otros no estarán en red hat... ( te vas dando cuenta también de la cantidad de sistemas operativos que hay? )

4) De que te vale tener un cluster de servidores con distintos so? osea, yo hago mi programa en windows, lo voy a hacer en C#, y tirando de .net, no C# básico. Como compilas eso para HP-UX? o para FreeBSD?  no puedes hacer la piedra rossetta de los lenguajes y hacer un interprete que acepte de todo a C. El tamaño del servidor sería BRUTAL, y los costes totalmente desproporcionados. Esto teniendo en cuenta, que pudieses compilar de un sistema a otro... (que en el 99% de los casos NO SE PUEDE)

Está bien dejar volar la imaginación y tener ideas, pero un poco de rigor , por favor, que no todo es ponerse a hacer código

EDIT: También tienes que , no todos los lenguajes serían compatibles entre sí, probablemente, como dices que programas en C++ , estarás acostumbrado al paradigma orietnado a objetos, te invito a que veas el paradigma funcional, o el paradigma orientado a aspectos, para que veas que hacer lo mismo en objetos/imperativo es MUY TEDIOSO