Foro de elhacker.net

Verdad que es molesto tener que recompilar programas echos en Windows en 20 sistemas más o creados en Linux recompilarlos en Windows, Mac, etc.

Pues se me a ocurrido una idea para que aportemos entre los que quieran realizar el proyecto un formato universal.

Imaginaros. Tenemos un programa .exe. Pues lo cogemos y lo convertimos al formato .universal o como queramos llamarlo con el programa que creemos.

Ese programa será el encargado de convertir el archivo a eses formatos y de ejecutarlos.

Sería un gran aporte para la comunidad Open Source y un gran alivio y tiempo para muchos usuarios y desarrolladores.

¿Qué os parece?  

OJO! ;)

Ehm, pues a mi parecer sería mucho trabajo, no crees? :xD

La verdad no sé que tanto implique.
Te refieres a una conversión de un programa plataforma n a programa plataforma n-1 o programa plataforma n+1?

Hay que tener en cuenta la cantidad de sistemas operativos, aunque supongamos que iniciamos con 3, windows, mac y linux, ahora sus versiones y después su arquitectura, además de tomar en cuenta el lenguaje de programación con que fue creado.
SO x Ver. x Arq.

No sé la idea no suena nada mal, que se pueda realizar es diferentes.

Todos los programas fueron creados a su manera porque por varias razones, las dos principales es por necesidad y la segunda sería por su plataforma en que se instalaría.

Por cierto me diste una idea para otro proyecto xD

Saludos.

OmarHack, es una muy buena idea; de hecho es tan buena que ya se ha intentado hacer antes pero sin los resultados esperados. Te explico:

JAVA compila con ese formato universal al que tú te refieres, que es un código de bytes que representa operaciones del procesador y los datos que procesará el mismo. Sin embargo hay un problema al hacer esto y es que lógicamente necesitas de un intérprete de esas órdenes que es la máquina virtual de JAVA.
Microsoft fue un paso más allá con el .NET Framework y su compilador JIT (Just In Time) que compila el "código universal" según el procesador y el sistema operativo de la computadora en cuestión, de esta manera se elimina el intérprete (o parte de él) en tiempo de ejecución.

Ahora dime, ¿vas a hacer una máquina virtual desde cero para cada sistema operativo y procesador que se te ocurra? ¿De verdad tienes tantos conocimientos en programación como para intentar hacer al menos la mitad de este proyecto? ¿Ya te has puesto a pensar en el trabajo de adaptar las APIs entre cada sistema operativo o crearlas desde cero en caso de que alguna no exista?

No quiero decirte que no lo hagas, pero de verdad me parece mucho para tan poco, es decir, para mí realmente basta con recompilar para otro sistema operativo y dar a elegir entre dos o más enlaces de descarga.  :huh:

Disculpa, pero hay que ser realistas. Un saludo y suerte si lo piensas hacer.  ;D

se me ocurre la siguente idea :

la extension universal lo abre un interprete
2 el interprete ya conoce el so donde se esta ejecutando
3. el interprete busca en el archivo .universal la version correspondiente a su SO
4.lo descarga
5. lo instala.

suena bastante viable y no es para nada complicado de hacer incluso si los archivos .universal se hacen de forma estandar(usando xml por ejemplo) los interpretes pueden ser programados por quien desee hasta se podrian hacer extensiones de navegador etc.

extiendo un poco mi idea , supongamos que ese interprete trae un compilador como gcc y otro metodo de instalacion que consista en que  dependiendo el so se compile con x o y opcion "claro el interprete deberia facilitar el reconocimiento del so" y en este caso eberia permitir el manejo de instalar librerias como por ejemplo qt o etc

PD: tengan en cuanta que los virus se reproducirian indistintamente el so

Quizás fallaron por plantearse la solución de esa manera pero seguro que hay muchas más.
Imagínate que quieres abrir un exe en Linux.
Tienes varias opciones. Las primera creo que es la que se ha tomado hasta ahora por esas empresas que mencionas.
·Emular Windows


¿Pero que pasa con las miles de opciones restantes que podrían dar resultado?
Se me ocurren unas cuantas pensándolo fríamente en un par de minutos.

·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.

¿Por qué no empezar este proyecto nosotros? Si es viable seguro que se unirían muchos desarrolladores profesionales de distribuciones Linux. Al fin y al cabo esto le quitará mercado a Windows y a Mac y le dará mucho más poder al software libre.

Lo que tu dices daryo también es una opción muy buena. Seguro que hay miles de opciones más, solo hay que estudiarlas, elegir la mejor y ponernos a ello.

di dos opciones :P jeje

Lo sé, pero veo las 2 como una sola opción.

Creo que es más fácil desarrollar algo así que ir haciendo copias de todos los programas útiles que se vayan creando para Windows y Mac como se lleva haciendo desde siempre en Linux.

bueno a ver que opinan los demas  ;D

Por supuesto, sería MEJOR, pro no es más FÁCIL. Yo veo demasiado complicado por el hecho de que no estamos hablando de desarrollar muchas aplicaciones independiente para un núcleo ya establecido (como indicas que ha ido creciendo linux), sino que hablamos de cientos o miles de programadores trabajando en el mismo código sin una verdadera coordinación, cada uno escribiendo según su visión del proyecto y (en el peor de los casos, pero seguramente) a su conveniencia.

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

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

Veamos:

• 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.

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).

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 :)

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?  :rolleyes:

¿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!

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.

No, en realidad mil líneas de código no me parecen mucho, por eso lo puse.  :xD 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.

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.

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  ::)

En el ejemplo que puse está claro que el código tiene que ser multiplataforma, si no no tiene sentido.

¿Entonces la humanidad ya no puede hacer nada más ni crear nada nuevo, porque si no se ha hecho ya es por que es "imposible"?
Estoy seguro de que se puede hacer, si no es así será de otra forma, pero que se puede hacer lo tengo clarísimo, aún que se tenga que unir en un solo sistema todos los que existen. Pero posible, es. Otra cosa es que encontremos la manera de que sea viable crearlo.

Un saludo.

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.  :(

Lo estoy dividiendo en dos proyectos, uno sería el de un servicio que compilara tu código multiplataforma para todos los sistemas que le indiques para no tener que instalar Mac, Linux... y todas las herramientas de desarrollo y compiladores que se necesitan.

Te pongo un ejemplo, si yo solo tengo Windows y hago un programa que va a servir para Linux y Mac, que el programa me devuelva el ejecutable para ambos sistemas sin tener que tenerlos yo instalados ni todas las herramientas necesarias para la compilación. El ahorro de tiempo es importante y el programa tiene salida y se podría conseguir.

Y después está el otro, para el cual se podría decir que aún no tenemos una idea viable y para la que abrí explícitamente el tema. Que sería que se pudieran usar todos los programas en cualquiera sistema o alguna alternativa similar. Yo sigo pensando en como, seguro que se me ocurre algo.

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 .

Nadie ha dicho que los binarios tengan que pasar por donde se centran todas las miradas (en la cloud). Aun de ser así, el canal de comunicación estaría cifrado por métodos criptográficos actualmente seguros.

Saludos!

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.

Y después de hacer eso incluso se podría hacer un quinto binario. Sería un binario con el formato que le pongamos y en el irán los cuatro binarios. Los cuatro con un índice para cada sistema. Así el binario final será ejecutado en el sistema que corresponda y por lo tanto funcionará en todas las plataformas. En el caso de que el programa genere o use archivos externos, estos archivos se compartirían por los cuatro binarios embebidos en el quinto. Sería algo así:

"Comprimimos" los cuatro binarios en un formato .universal agregándole índices:
Programa de Windows:
Archivo .exe ya compilado.
Programa de Linux:
Archivo .Deb ya compilado
Programa de Mac:
...........
Programa de FreeBSD:
...........

Así al ejecutar el programa en Windows buscará por el índice el .exe
En linux el .deb, etc.

Un ejemplo:

Imaginaros, todos los binarios se encargan de crear un .txt con números de teléfono dentro para más tarde acceder a ellos desde al mismo programa.

Pues los cuatro binarios usarán el mismo archivo.txt

Así cambiarás los datos del archivo y los leerás desde cualquier de esos cuatro sistemas. Esto hará al programa independiente de cualquier sistema y se podrán trabajar con los mismos datos desde cualquier sistema.

Llevado a programas más complejos; con el mismo código tendrías un solo binario portable entre sistemas.

Esto implicaría que el código del programa fuera multiplataforma, pero estoy seguro de que millones de usuarios considerarían útil poder usar el mismo programa sin alterar en todas las plataformas. Te ahorraría descargar el mismo programa para los cuatro sistemas e importar la configuración y los datos constantemente entre todos ellos, actualizarlos todos cada uno con sus distintas versiones. Problemas entre usuarios por las distintas versiones de los programas, etc.

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 mismo estaba pensando digo cuales deben ser las capacidades del servidor para compilar cientos o miles de aplicaciones? y ademas pongamole unos cuantos gigas a algunas  de estas aplicaciones.

cuantos servidores se necesitarian para esto?

no se que tan practico seria la verdad

si me equivoco en algo me gustaria que me lo dijeran  ;D

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

@Oblivi0n: estoy de acuerdo contigo. Si el código no es multiplataforma entonces solo podrá ser recompilado para cada familia de SO asociada al SO donde fue compilado el código.

El precio de los costes sería enorme teniendo que cubrir entre otros el coste de procesamiento y el mantenimiento del cluster de servidores. Además habría que crear un lenguaje intermedio en la máquina donde se envía el binario para ser recompilado en cada plataforma para poder llevar todo los juegos de instrucciones a uno común el C.

La idea viable podría ser la de recompilar para todas las familias y arquitecturas relacionadas con el SO donde fue compilado el código. Pero eso queda al alcance de cualquiera.

Saludos!

en resumen aunque es posible es  mas practico generar versiones para diferentes SO que es lo que se ha estado haciendo durante años.

A ver... qué dificulta la portabilidad de un ejecutable? Yo veo dos causas:

1. Los distintos procesadores tienen diferentes juegos de instrucciones y opcodes.

2. Los ejecutables están en un formato de ejecutable propio de un sistema determinado, y llaman a las APIs de ese sistema determinado.

La primera dificultad se puede salvar desde la creación de los lenguajes de alto nivel, en los que un compilador traduce el código al lenguaje ensamblador del procesador en cuestión (sin tener en cuenta los lenguajes interpretados).

La segunda dificultad hay que explorarla un poco más. Dividamos los ejecutables en dos grupos, a saber:

1. Los que usan el formato PE y llaman a las APIs de Windows.

2. Los que usan el formato ELF y llaman a las APIs de POSIX, y posiblemente, a otras específicas del sistema.

Bien, ahora supongamos que queremos un programa que, dado un ejecutable, lo convierta en uno equivalente del otro grupo.

Mi aproximación mental:

 Se crean dos librerías, una que implemente las APIs de POSIX, las syscalls de Linux, BSD, etc... en Windows, y otra que implemente las APIs de Windows en Linux y otros sistemas.

 El programa debe, además, cambiar el formato de ejecutable. Esto se presenta muy costoso, pero se puede extraer el código ensamblador y los datos de un ejecutable y construir un ejecutable válido para el otro sistema a partir de esos datos, añadiendo headers y demás.

 Supongamos que ya hemos hecho lo anterior. Ahora tenemos un ejecutable de Windows que queremos portar a Linux, y lo pasamos por el hipotético programa descrito más arriba. Nos queda un ejecutable ELF con el código ensamblador y los datos del programa original, que llama a APIs de Windows. Sólo queda volverlo a enlazar con nuestras hipotéticas librerías, que implementan todas las APIs de Windows en Linux, y relocalizar los símbolos de los propios datos del ejecutable.

Parece enorme, no?

es un proyecto muy bestia (muy grande) es demasiado complejo simplemente

WINE es un intento de traducir las llamadas WIN32  a POSIX, el resultado es inestabilidad, falta de una buena parte de las funciones... etc etc...

¿ Quieres un programa multiplataforma ? JAVA.

Yo pienso que lo ven como una amenaza para sus productos de pago. ¿Piensas que adobe y muchas empresas más no tienen chanchullos con los de los softwares privativos para sacar más tajada y no desarrollar para software libre?

Estas empresas son eso, empresas. Su única motivación es el dinero. Se basan en el modelo de exclusividad con sistemas privativos para que estes le den parte del pastel. Así todos ganan. Los usuarios con conocimientos que se quedan en sistemas privativos es por su software. La empresa encargada de gestionar los sistemas privativos se encarga de hacer contratos de exclusividad con compañías productoras de software de calidad. Así por ejemplo Adobe desarrolla sus "mejores" productos para sistemas privativos. Y hace otros de menos calidad para sistemas libres. Los usuarios que desconozcan este dato y usen el software de adobe verán que va mejor en Windows que Linux, lo cual hará que piensen que Windows es mejor, cuando en realidad lo que es mejor es el software de Adobe de Windows.

Esto se lleva haciendo desde siempre, Windows gana adeptos y Adobe gana una prima por su "buen labor" que será superior al posible beneficio que pueda sacar "exponiendo" la total calidad de sus productos en otro sistema.

Quitando esto todo simplemente podría no habérseles ocurrido, como a mi no se me ocurrirán millones de ideas que a otra persona sí.



Si tiene éxito con 4 anuncios mal puestos en el cliente o en la web oficial tienes para mantener todos los servidores necesarios. Cuantos más usuarios usen el servicio más servidores harán falta y a la vez cuantos mas usuarios usen el servicio más presupuesto se generará para obtener más servidores y mantenerlos.

Necesitaría un buen procesador y que los programas se compilaran por hilos y no secuencialmente.

Si dices que se necesitaría al principio para el proyecto, un servidor normalito vale mientras no se compilen proyectos muy grandes y a la vez.

Si tiene éxito se substentaría solo e incluso se podría mantener "por la marca". Es decir alguien que quiera darle fama a su software y ponga la marca que creemos en su producto para que el mercado lo acepte.

Pos si no se entiende, alguien crea un coche, pero su marca al no ser conocida no se vende, pues paga a Audi para que lo comercialicen con la marca Audi. Esto generará ingresos a ambos, y Audi no moverá ni un dedo.

Claro que esto lo comento porque veo que muchos estáis inseguros de que lo único que se generará con este proyecto son perdidas. Aún es muy pronto para esto todo pero si el software tiene un mínimo de éxito como veis se mantendría solo y podría producir ingresos sin tener que spamear a nadie.

La inversión inicial para el proyecto sería un servidor, tiempo y ganas de desarrollar.

El servidor mismo lo pongo yo. Si se ve que el proyecto va alcanzando éxito pues se van mejorando los códigos y añadiendo más servidores.
 
Así empiezan todas las grandes empresas, de cero.

Yo creo que el proyecto puede tener una oportunidad en el mercado y además como software libre.  



La verdad es que parece muchísimo trabajo, hay que seguir buscando alternativas, y de no encontrar una si decidimos hacerlo como acabas de mencionar habría que hacer equivalencias entre librerías que generen el mismo resultado. Eso llevaría un enorme trabajo y no creo que sea para nada viable así que habría que seguir buscando alternativas hasta dar con una razonable.

Y en muchos casos funciona. Hay que replanteárselo de otra forma. Porque seg uro que la hay.

Con C++ también puedes hacer un programa multiplataforma. Por eso no habría problema ya que se puede con muchísimos lenguajes.

@OmarHack

1) Wine funciona, precisamente, EN LA MINORIA DE LOS CASOS.

2) Creo que no eres consciente de lo que costaría mantener un servidor así. estamos hablando de MILES de €

3) No es solo el coste del servidor, es el volumen de trabajo que llevaría, esBRUTAL, y probablemente (y no lo digo en coña), un esfuerzo muy superior al de hacer un sistema operativo.

4) Me parece genial que apoyes el software libre, pero no os volváis un fanático, en muchas ocasiones si algo funciona peor en Linux, es porque el modo de hacerlo igual que en windows es mucho mas complicado.

Si hay programas de software privativo que no existen para Linux, no es para que pienses " Ohhhh windows es la leche ", no, es porque no merece la pena gastarse los cientos de miles de dolares que cuesta producir un software de calidad, para un 0.5% de los usuarios. Así de simple.

Creo que deberías informarte muy bien acerca de lo que es desarrollar software a un nivel profesional, antes hablabas de mil lineas como algo reseñable.... yo ayer escribí 6000 lineas en C solo para una tontería, el kernel de linux va por las 15.000.000 de lineas, y realizaría menos funciones aún que lo que tu propones, para que te hagas una idea.

Para los que han señalado el inconmensurable trabajo que conllevaría mi idea:

 Precisamente eso es lo que quería señalar. Porque en el post originalmente se pretendía convertir ejecutables.

Saludos.

¿Y el servidor miles porqué? Al principio del proyecto y sin presupuesto con un servidor de andar por casa valdría. Si lo usuarios del proyecto van aumentando se van generando ingresos. El proyecto es sostenible aún que cueste millones, que para empezar no costará ni un duro. Como ya dije, si el coste del servidor se tasa en 50 euros al mes, pues habrá que poner poner publicidad que genere más de 50 euros al mes. Si se tasa en 1000, pues mil. Así de simple.

Lo único que hace el software en principio es mandar un texto a un compilador por sockets y recoger un ejecutable de una carpeta.  Si eso conlleva más código que un sistema malo...

Si te refieres al proyecto de convertir los ejecutables ya propusimos ideas y estamos a la espera de más, que ya dijimos que no eran viables.

Estamos hablando de 2 cosas distintas. La que propuso kub0x, y que comentamos algunos detalles WHK y yo y la de transformar los ejecutables.

¿Entonces qué pasó siempre con el proyecto? ¿Ya se está realizando?

Es que vais mezclando, me acabo de leer casi todos los post y unos hablais de convertir un mismo codigo a cualquier plataforma, creando librerias que pasen las apis de windows a linux y viceversa y tal.... (mas o menos lo que querias hacer en tu post original) que cualquier programa pueda ser usado en cualquier otro S.O.

Y luego lo otro, mandar un codigo por sockets y que este sea multiplataforma, sino tampoco funcionara, y hay en maquinas virtuales te compile el codigo, y luego te envie los ejecutables....
Eso es muy factible...
Pero no creo que a la gente le guste mucho enviar sus codigos para que se los compilen en varios S.O....

Imagina que uso windows... creo mi codigo multiplataforma, y tambien lo quiero para linux... para enviarlo a una aplicacion desconocida y que me lo compile  y me devuelva el ejecutable....
Al final, tardas menos creandote una maquina virtual tu mismo y compilandolo......
No sé no le veo tanto "futuro"  XDD

Lo de que en un mismo ejecutable se pudiera ejecutar en todos los S.O y arquitecturas pues si.... pero eso como ya te han dicho es inviable....

Lo de los sockets... lo más práctico que veo ahi, es la cantidad de cosas que se pueden aprender.