🚀 go-pugleaf

On Thu, 09 Oct 1997 21:14:29 +0100, "Chano G�mez" <chano@ran.es>
wrote:

>> Seg�n esa regla de tres, por ejemplo los archivos con extensi�n .pas
>> son ejecutables puesto que Turbo Pascal los transforma en c�digo
>> objeto,  los linka y los ejecuta, y estos tres pasos son trasparentes
>> al usuario. Si lo miras as� hasta los archivos con extensi�n DOC se
>> les puede llamar ejecutables por que el interprete llamado word
>> ejecuta macros.
>
>Sabes que hay diferencias sustanciales entre el caso de un .class y el caso
>de un .pas.

Claro que lo s�, te lo acabo de decir en el texto que has quoteado, lo
que me extra�a es que tu sabi�ndolo perfectamente metas en el mismo
saco a todo lo que acaba ejecut�ndose.

>Imagina que tienes un programa para Mac antiguo (680x0). Hablo de un
>programa normal, compilado. Esto no me negar�s que se corresponde con lo que
>entendemos por un .exe. Imagina ahora que tienes un PowerMac e intentas
>ejecutarlo. El sistema operativo coge el fichero, lo carga en memoria y
>"traga" con �l. Incluso parte del sistema operativo de los Macintosh est�
>escrito en c�digo 680x0, y se ejecuta en modo de emulaci�n. No ya los
>programas, sino el propio sistema operativo. �Me vas a decir que esas partes
>del sistema operativo son equivalentes a un archivo .pas?

No conozco MacOs como para opinar, pero no me des la vuelta a la
tortilla, yo no he dicho que un .pas se parezca a nada, simplemente
estaba exagerando tu postura.

>Un .pas es c�digo fuente de alto nivel. El bytecode de Java es c�digo
>m�quina. Lo que pasa es que t� y yo tenemos la "mala suerte" de no disponer
>de un chip Java. Pero eso no cambia la condici�n del archivo.
>Coge un .exe para x86. Ll�valo a un ordenador con procesador Alpha, sistema
>operativo NT e interprete FX!32. Ver�s si se ejecuta... y ver�s qu� rapido.
>�El hecho de copiarlo en un diskette y moverlo de m�quina ha cambiado el
>hecho de que sea ejecutable o no?

Coge ese mismo .exe y llevalo a un Amiga...Puede que haya alg�n caso
en el que un .exe trague en dos plataformas, pero no es lo m�s
frecuente, Java y sus .class s� y es otra de las enoooormes
diferencias. Por eso te dec�a lo del int�rprete ajeno al SO.
S� podr�a programar un interprete .exe para cada plataforma  pero
hasta que no llegue es lo que hay.

>Otro ejemplo: �Es un programa en Visual Basic un .exe "normal"? Cualquiera
>dir�a que s�. Pues bien, VB tambi�n es c�digo interpretado, conceptualmente
>similar al bytecode de Java, por lo menos hasta la versi�n 4.
>
>Otro ejemplo m�s (y termino): Un programa en Java convertido en .exe por
>medio del SDK de Microsoft, �es un .exe normal? Parece que si lo ejecutas
>desde la l�nea de comandos, la cosa funciona... Y te puedo asegurar que el
>contenido de ese archivo es bytecode Java en un 100%, si le quitas la
>cabecera.

Eso no es cierto, SDK te crea un EXE que con ayuda de unas DLLs, en
las cuales est� incluida la m�quina virtual Java, interpreta el
bytecode contenido en los  .CLASS
Para que el programa funcione en otra plataforma sin la m�quina Java
de MS, tienes que incluir todo el lote EXEs,  DLLs y CLASS.  Es un exe
normal, puro y duro, sin un gramo de bytecode.

>> >�Cu�l es, entonces, la diferencia "funcional" entre un CLASS y un
>> >EXE?
>>
>> �Funcional? ninguna, los dos acaban ejecut�ndose, pero un .CLASS
>> necesita un interprete ajeno al SO.
>
>Entonces un .bat es m�s parecido a un .exe que un .class. Porque parece que
>no hace falta nada "externo" al S.O. para ejecutarlo...

Yo pienso que es m�s parecido, pero la comparaci�n entre los tres me
parece tan remota..

>Lo de que sea ajeno al sistema operativo o no me parece carente de
>importancia. Ser�a un argumento m�s s�lido el decir que un .class necesita
>otro software mientras que un .exe no. Y tampoco eso es cierto, porque un
>.exe necesita las llamadas del S.O., de la BIOS, etc. Y todo eso es
>software.

Pero es que el bytecode Java contenido en los .class n� siquiera llama
a la BIOS como lo hace un .exe. La MV Java tiene distintos registros,
distinta pila, los punteros a los registros (as� como estos) son solo
de 32 bits, areas de memoria solo para la cons/destr. de objetos.
Sabes que el bytecode Java trabaja con est� arquitectura y no con la
que lo hace el c�digo m�quina de los exes.  

>Adem�s... �qu� pertenece al sistema operativo y qu� no? �Lo que venga en el
>CD de Windows 95?
>En cualquier caso, el interprete ya no ser� ajeno al S.O. dentro de un par
>de meses.

Explic�me esto.

>> >Y eso de que una DLL no tenga nada que ver con la POO...
>> >�Es que un programa C++ formado a base de DLL no es lo bastante
>> >OO?
>>
>> Una DLL es un conjunto de m�todos y variables y lo �nico que puedes
>> hacer con ellos es llamarlos desde un programa para que hagan algo
>> concreto o que se llamen entre s�, no est�n dise�adas para POO, no
>> puedes hacer que una DLL herede m�todos o variables de otra DLL o
>> definir una interface .DLL o hacer una .DLL abstracta en fin que solo
>> se parecen a un .CLASS en que son un conjunto de m�todos y variables.
>
>Una DLL es un mont�n de c�digo (olv�date de s� es OO o no lo �s: el c�digo
>m�quina no tiene color, ni nacionalidad, ni ideolog�a pol�tica) que se carga
>en memoria en tiempo de ejecuci�n. Y un .class tambi�n. Creo que confundes
>lo que ves t�, como programador de Java, con el funcionamiento real del
>entorno de ejecuci�n (la parte que no ves y que se encarga de gestionar los
>objetos, la herencia, el enlace din�mico de m�todos virtuales, etc...)
>
>La herencia, el polimorfismo, y todo lo que t� entiendes por POO "NO" est�
>en la DLL ni est� en el CLASS. Est� en el entorno de ejecuci�n (el de C++ o
>el de Java). Tanto la DLL como el CLASS es c�digo totalmente muerto, sin
>ninguna de las caracter�sticas que le asumismos a la POO.

No puedo asegurar esto, porque nunca me ha dado por destripar el
bytecode de un .class pero si yo tengo dos archivos a.class y b.class,
y b es una clase hija de a, por sentido com�n en el bytecode de
b.class deber� estar representado que b es una clase hija de a (a no
ser que la m�quina virtual tenga poderes de adivinaci�n). No te puedo
asegurar esto, me voy a informar. Lo que si es seguro es que un
archivo DLL no puede hacer esto desde el mismo c�digo. Te doy la raz�n
en que programando y d�ndole vueltas puedes conseguir programar al
objeto hasta con Cobol.

>Por cierto: todo lo que dices m�s arriba de que no puedes hacer que una DLL
>herede de otra, que no puedes hacer interfaces, que no puedes hacer m�todos
>abstractos.... en fin todo eso: pues es falso.
>
>Haz una DLL llamada A con 10 m�todos. Haz una DLL B con 15 m�todos. Haz que
>los 10 primeros m�todos de la DLL B llamen a los de la DLL A. Ya tienes
>herencia. Y as� todo lo dem�s.

Hombre, yo no llamar�a precisamente herencia a eso, estas llamando a
una DLL desde otra. Prueba a llamar a un m�todo perteneciente a la DLL
A llamando a la DLL B y te dir� que no le encuentra. Quiero decir que
los m�todos de la DLL  A perteneceran solo a la DLL A, sustituye DLLs
por .class y los m�todos de A ser�n comunes a ambas.

>Java no es orientado a objeto por hecho de que sea interpretado o por alguna
>otra raz�n m�gica. Es orientado a objeto porque el entorno de ejecuci�n se
>encarga de ello.

Te repito lo de antes, es cierto que puedes programar al objeto hasta
con Basic, pero por eso no dices que Basic est� orientado al objeto. 

Un saludo.