Se me ha ocurrido una idea muy interesante. Igual la podemos desarrollar.

[daryo]

.................

no . obvio que tiene que a ver una forma de coordinacion y no hace falta tanta gente como dices programandolo , al menos con mi idea si se usan librerias como qt(multiplataforma) donde cambiarian cosas pequeñas como las rutas no es algo tan descabellado

la cosa es que compilar cada aplicacion seria algo lento y se deberia estar dispuesto a mostrar el codigo o parte de este

[0xDani]

Sin ánimo de ofensa, creo que la única posibilidad realista que he leído en este topic es la aportada por @daryo.

Veamos:

·Que el exe se envíe a un servidor Windows y este inspeccionando los cambios que ha realizado el ejecutable en su sistema devuelva un programa compilado para linux que altere Linux de la misma manera. Es decir, un programa con las mismas condiciones y similar al original. (Demasiado complejo para realizarse pero totalmente posible aún que no viable.)

·Que se recojan todas las instrucciones que el programa realice en código máquina y que se cree un ejecutable. (Demasiado complejo)

Y la última y la mas viable que se me ocurre de momento.
·Recrear en Linux el sistema que abre los exes en Windows.

Si se consiguiese hacer esta última simplemente habría que substituir algunos cambios que se realicen en Windows para Linux. Imaginaros el ejemplo de un programa que abra el disco local C: y copie un archivo dentro. Pues solo habría que indicarle al programa que creemos que sin el programa intenta acceder a la ruta C: pues que en Linux se copie el archivo en Raiz o en donde sea, en vez de en C. Llevaría trabajo, cierto. Podemos ser muchísimos en el proyecto, aún más cierto aún. La mayoría de distribuciones Linux han sido creadas por millones de desarrolladores.

• 1^a forma:
  
  Tú mismo has señalado la complejidad de este método, date cuenta de lo difícil que sería que tu programa crease otro programa en base a los cambios que el programa que se quiere portar a Linux ha hecho en el equipo. Y no te olvides de que los cambios que un programa haga en un equipo dependen de una serie de condiciones, cómo emular todo eso?
  
  
• 2^a forma:
  
  Esa no sería tan difícil, conociendo el formato de ejecutable de ambos sistemas, el problema estaría en los cambios de arquitectura y en que el programa resultante quedaría llamando a APIs que no existen en el otro sistema.
  
  Se podría crear una librería que recreara todas las funciones de la API de Windows en Linux, y relocalizar los símbolos del ejecutable para enlazar con esta librería. Cuántas funciones API tiene Windows?
  
  
• 3^a forma:
   
    El loader de Windows? Ok, pero Linux ya tiene un loader, sólo que trabaja con el formato ELF en vez de con el PE. Supón que cargas un ejecutable PE en memoria, tal cómo lo haría el loader de Windows, en Linux. De qué te sirve, si el programa sigue teniendo referencias indefinidas a APIs que no existen en Linux?
  
  En fin, ahí te dejo mi crítica para que te vayas haciendo una idea más realista, y te des cuenta de todo lo que implica lo que quieres hacer.
  
  Saludos.

[WHK]

El problema es el mismo de siempre, los nucleos de linux, unix y windows son distintos, por lo tanto es imposible ejecutar algo en ambos lados con el mismo código sin ser interpretado.

Por esto se crearon los lenguajes interpretados en el cual el interpretador es el encargado de ejecutar todas las funciones utilizadas en el script o binario.

Por ejemplo: perl, php, python, ruby, pascal, java, etc.

El gran problema de .Net es que no funciona en otros sistemas que no sean windows si lo compilas directamente a .exe, mono interpreta pero ya pierde toda lógica, por eso java es mucho mas potente ya que el objetivo de un lenguaje interpretado es la multi plataforma sin mayor esfuerzo donde tu aplicación pueda tener exactamente el mismo rendimiento, ventajas y funcionalidad en ambos sistemas, con .net no puedes utilizar todo su poder en sistemas libres porque dependerias de las dependencias de Windows en muchas ocasiones, en cambio java todos los sistemas funcionan por igual.

Volviendo al tema, no es mala idea pero el desgaste de trabajo es enorme y requiere de mucho conocimiento a nivel de ensamblador a menos que quieras usar las apis de cada sistema operativo (doble trabajo).

[kub0x]

Llamadme iluso pero...

Máquinas que corran SO de todo tipo alojadas en un espacio cualquiera a las que se les envía el código del ejecutable, librería o componente a compilar. Solo habría que crear un canal de comunicación con dichas Máquinas Virtuales y que éstas sean capaces de reconocer y generar el ejecutable compilado para su propia plataforma. Esto actualmente es factible (y me atrevo a decir hasta que es sencillo) si lo comparás con los métodos expuestos aquí.

Te libras de intérpretes y máquinas virtuales que lo único que hacen es crear dependencia. Sólamente habría un escenario, y sería el de una serie de Máquinas 'on the cloud' que reciben binarios y los parámetros de la compilación.

Ya para ahorrar costes se podría alojar en una máquina SO de todo tipo en forma de Máquina Virtual, y que éstas sean capaces de comunicarse entre si mismas (mediante carpetas/espacios compartidos).

Saludos

[El Benjo]

Eso que comenta kub0x es cierto, es muy factible, y desde hace años se viene haciendo en las aplicaciones Web con JAVA cuando se ejecuta un applet y con .NET con las aplicaciones clickonce y XBAP, las cuales son multiplataforma, envían este código intermedio y los compilan o interpretan en el cliente. Pero volvemos a lo mismo, eso sigue siendo recompilación e interpretación.

Ahora, yo estoy totalmente en contra de decir que algo no es posible y si alguien quiere seguirlo intentando de acuerdo, pero la pregunta sigue siendo ¿quién le va poner el cascabel al gato?  

¿De verdad alguno de los que dicen que no sólo es posible sino que no requiere mucho trabajo y no es tan complicado, va ponerse a escribir las primeras 1000 líneas de código para dicha idea? Y lo pregunto con todo respeto.

[kub0x]

¿De verdad alguno de los que dicen que no sólo es posible sino que no requiere mucho trabajo y no es tan complicado, va ponerse a escribir las primeras 1000 líneas de código para dicha idea? Y lo pregunto con todo respeto.

Bueno, si algo he dicho, es que el concepto es sencillo, pero no he mencionado que no requiera trabajo. Si alguien está interesado en que esta idea se haga realidad, pues ya sabe, aquí me tiene dispuesto a todo.

Saludos!

[OmarHack]

Lo que comenta kub0x si parece muy buena idea. Está claro que todo lo bueno lleva su trabajo. Se habrán creado miles de programas por gente con menos nivel del que hay aquí y con más código del que posiblemente ocupe el programa. 1000 lineas de código parece mucho pero no te creas. yo mismo acabo de escribir 1000 lineas de código en 3 semanas y no es que tenga mucha experiencia en C++. Para muchos de vosotros no supondría ni una décima parte del esfuerzo que me ha llevado a mi, por eso estoy seguro de que si los más "veteranos" se unen podremos sacar el proyecto adelante.

Lo de que seamos muchos programadores no es para nada un problemas. Unos se pueden encargar de la interfaz, otros de sockets y comunicación de redes, otros de la estructura, otros de reclutar programadores. Lo que sea, cuantos más mejor. Si son 10 personas con sockets, pues se comunican entre ellos y dicen, pues me falta esto, pues yo lo sé hacer, lo hace y listo.

¿No os gustaría marcar un antes y un después en el software libre? Posible es.

[El Benjo]

No, en realidad mil líneas de código no me parecen mucho, por eso lo puse.  Y bueno, ya que los veo tan determinados en llevar a cabo el proyecto, en especial a usted OmarHack, que inició el hilo; me gustaría preguntar una cosa: ¿En qué punto del desarrollo de un ejecutable intervendrá finalmente esta aplicación? ¿Será en la compilación del código fuente (que veo poco práctico), o modificará los archivos ya compilados?

Mucha suerte con su proyecto.

[OmarHack]

Creo que como lo dice kub0x podría definirse como un servicio de compilación en linea, lo cual es una gran idea y serviría para desarrolladores que trabajen con lenguajes compilados y por supuesto que los códigos sean multiplataformas. Pones el código en el programa (que creemos) y te devuelve los archivos compilados para Windows, Mac, Linux, etc. Esto en realidad no parece tan complicado.
Usas un Ubuntu Server mismo (por decir uno), le metes VirtualBox con las máquinas de los sistemas y con los compiladores e ides y listo. Mirando un poco lo que habría que codear, sería lo siguiente:

·Habría que hacer la comunicación con el Ubuntu Server con sockets. Tanto para enviar el código como para recibir los binarios ya compilados.

· Una vez controlando el servidor remotamente el programa, comunicarse con las máquina virtuales. Sencillo haciéndolo por Red Local. Simplemente habría que encender las máquinas virtuales con el comando VBoxManage startvm y conectarse a una de ellas remotamente con una shell desde la que ejecutaremos el archivo recibido. Este archivo podríamos identificarlo por la ip durante un determinado periodo de tiempo. Una vez compilado el archivo lo mandaremos de vuelta a la Ip por el puerto que especifiquemos, o a nuestro programa cliente mediante sockets.

·Habría que hacer una interfaz gráfica con las distintas opciones. Como pueden ser elegir el tipo de compilación que deseemos.



Un ejemplo en más o menos pseudocódigo del programa. xD

Este ejemplo es para el compilar un archivo en lenguaje C++, podría hacerse una función y darle los parámetros para que trabajara con la extensión de cada lenguaje que queramos compilar, autodetectándolo o pidiendo que se especifique en el cliente.

Más o menos sería algo así:



Desde el programa cliente:

Conectar con servidor
Esperar datos de usuario
Si usuario a pedido compilación en windows
Conecta con máquina virtual windows.
Guarda la ip del usuario en una variable.
Envía el código con la siguiente identificación variableQueContieneLaIpDeUsuario.
Envía un código para saber que tipo de compilación se desea. 1 windows. 2 Linux.
Espera respuesta x tiempo.
Si llegó la respuesta
Guarda el programa compilado que te ha llegado.
Cierra conexión
Si no, inténtalo de nuevo.



Para el servidor algo así:

Si recibo datos del cliente:
Recojo la ip.
Creo una carpeta temporal para esa ip.

si es un .txt
lo cambio a .cpp

si ya es un cpp:
compruebo que tipo de compilación ha pedido el usuario mirando el código correspondiente.
si código de compilación es igual a 1

Comprueba que la máquina virtual de windows esté encendida, en caso contrario enciéndela

Si ahora esta encendida: abre un programa previamente creado, que se encuentre  en la máquina virtual (a través de la dirección local)
Entrégale el cpp.
Espera un .exe.
Mándalo de vuelta al cliente.
Espera más peticiones.

Si sigue sin encenderse vuelve a intentarlo.
Si sigue sin encenderse, devuelve un error.


Y por último para la máquina virtual:

Abre conexión.
Espera un cpp de la ip del servidor.
Compílalo.
busca el exe con el mismo nombre que el cpp.
Devuélveselo al servidor.
Cierra la conexión.
Cierra el programa.


Creo que sería un método rápido y eficaz para llevar a cabo lo que planteó kub0x.

Para correr directamente el programa en cualquier plataforma sin el código, hay que seguir pensando ideas que puedan funcionar, las de ahora llevan demasiado trabajo para el resultado que se pueda obtener. Pero seguro que sacamos alguna idea buena.

[Oblivi0n]

Si no se ha hecho ya es por que es "imposible"

Es decir, windows hace unas cosas, Linux hace otras, y encima, lo que hacen igual, internamente lo hacen de manera diferente.

Ya no es solo el hecho de querer compilar para distintos SO, es compilar para distintas arquitecturas. Aún poniendo ese ejemplo que dices de el servidor / maquina virtual. Si tu tienes un código para Windows, lo mas probable es que no haya versión posible para Linux, u otro SO diferente.

Podría ser posible si todos los SO's implementasen el standart POSIX, pero no es asi