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

[kub0x]

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

[daryo]

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

[0xDani]

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?

[daryo]

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

[Oblivi0n]

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.

[OmarHack]

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)

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

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  

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.  

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?

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.

[OmarHack]

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.

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.

[Oblivi0n]

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

[0xDani]

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.

[OmarHack]

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

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