🚀 go-pugleaf

Cymoril sin patas <ceinalem@thegym.net> wrote:
> Eso es una "bobada", ya que lo que interesa de un programa es que se
> pueda compilar bajo distintas arquitecturas, no que un solo ejecutable
> valga para todos los S.O. y plataformas. Usar printf es lo m�s
> recomendable.
Bueno... Bobada no es. Si se pudiera hacer por las buenas ser�a muy interesante, ya que las compa�ias solo tendr�an que hacer un ejecutable y su 
aplicaci�n ya valdr�a para todo el mundo.
Ojal� fuese sencillo hacerlo.

>>Una soluci�n para no tener que reinventar la rueda es utilizar las
>>librer�as del propio nucleo de linux (por ejemplo, para poder utilizar
>>printk) que no utilizan las llamadas al sistema.
> Entonces pierdes la portabilidad. De todas maneras, seg�n strace,
> printf hace una llamada write, y eso es tirar de n�cleo. 
En efecto...

>>Otra cosa es el formato del ejecutable. Eso si que te impedir�a que un
>>mismo programa compilado se pueda ejecutar en cualquier SO, pero hay una
>>versi�n del Gcc que puede act�al como "cross-compiler", (no suele venir
>>en las distribuciones), o sea, que te permite generar ejecutables para
>>distintas arquitecturas.
> Eso es otra cosa. De todos modos, las diferencias DOS/UNIX son lo
> bastante grandes como para tener problemas (e.g. conio.h vs ncurses)
> O tiras de #ifdef y #ifndef y #elif y compa��a, con compilaci�n
> condificonal por un tubo, o tu dir�s.
Resulta muy facil emular una terminal Unix sobre DOS, ya que esta �ltima
permite un acceso directo. Lo contrario no es posible.
A traves de una terminal normal no es posible saber cuando se pulsa una tecla y 
cuando se suelta (en X si). Digamos que lo m�s que puedes hacer con la 
terminal es el equivalente a la BIOS para el teclado en el PC (INT 16h).

Hay que reconocer que lo de crear un ejecutable, independiente de SO es algo
muy tentador, y que d�ndole vueltas, he visto que SI es posible (pese a lo
que se pudiera pensar en un principio)
La cuesti�n es que ning�n SO iba a aceptar un nuevo estandar de ejecutable
(adem�s, en principio solo nos interesa Win9x,NT, Linux y quien sabe OS2 BeOS, etc)
Bueno... Si no lo quieren adoptar, es posible crear un "cargador" del nuevo
tipo de ejecutable para cada tipo de SO.
�Utilidad? Se me ocurren varias pero la primera que me viene a la mente son
JUEGOS.
Pensad en un StarCraft o Quake creados en este tipo de ejecutable. Los
programadores solo tendr�an que crear un ejecutable y todos los usuarios
contentos.
Bien, ahora... �como se puede hacer eso?
Pues igual que funciona el Wine... Pensad que bajo Linnux tambi�n se pueden
correr ejecutables Win32. Emulando los servicios del SO nativo.
Ahora, puesto que crear�amos un tipo de ejecutable nuevo, se podr�a 
tomar un punto neutral que aislase todas las dependencias de los distintos SOs
y proporcionase unos servicios estandar (para juegos), facilmente traducibles
a las distintas APIs especializadas de cada uno de los SOs.
�Formato de ejecutable?, como nos diese la gana.
Por ejemplo, un interfaz sencillote que permitir�a crear este tipo de 
aplicaciones. (simplemente como ejemplo)
El ejecutable se crea para la posici�n 100h (como los COM), sin l�mites
de 64K en este caso, claro (modo protegido). Para conseguir que cada SO vea
este c�digo igual, se aloja memoria para todo el ejecutable en alguna
posici�n de la memoria con permiso de ejecuci�n y se crea un segmento
con dicha base. Usando todos los registros de segmento apuntando a dicho 
segmento el ensamblador correr� igual en cualquier plataforma...
Ahora, hay que crear una manera estandar para que la aplicaci�n llame a los
servicios estandar.
Por ejemplo, en la posici�n 0 le pasamos un puntero lejano para que lo 
utilice para sus llamadas al sistema.
Algo parecido a lo que ocurre con el Kernel de Linux pero usando un CALL en vez
de INT, ya que este �ltimo resulta m�s dificil de interceptar en cada SO.

Si cre�semos este emulador/cargador, prepar�semos utilidades para que
las puedan crear con sus compiladores m�s habituales, y les convenci�semos
de que es una buena idea, podr�an aparecer juegos en Linux como churros.

Ellos instalan el juego con el cargador de Win... y nosotros usamos el de
Linux :)

Hacer esto en un caso de prueba es relativamente f�cil, pero una
aplicaci�n real necesita un API amplio. O sea, acceso directo a Video, audio
teclado, rat�n, gesti�n de redes, API 3D, acceso al sistemas de 
ficheros com�n, mecanismos para hablar con un SO espec�fico de manera 
controlada, gesti�n de prioridades, APIs para GUIs, etc. etc.

La cuesti�n es... �Alguien se atreve con ello?