Introducción (22/May/04)
Bueno,
primero lo primero, mi nombre es Mauricio Henriquez y escribo este articulo
desde Puerto Montt, Chile. Debo decir que es el primero que escribo para la
página del Guille y creo que ya era hora de devolver algo útil al sitio Web
del cual tantas cosas he aprendido, por lo que de ante mano espero estar a la
altura de todos lo demás artículos que se encuentran en este sitio. Este
articulo esta dirigido a todos aquellos, que como yo, están muy interesados en
el mundo de Linux, pero que por cosas del destino han realizado todo o gran
parte de su trabajo como desarrolladores en ambiente Windows y mas
específicamente con VB, si, aunque cueste creerlo, parece que el “santo grial”
de ejecutar aplicaciones Windows escritas C# o VB .NET en Linux, esta tan solo
un poco mas allá que a la “vuelta de la esquina”.
Si bien el Guille en otras
secciones a descrito de forma amena el funcionamiento y lo que es el
“Framework .NET” de Microsoft, creo que es importante, antes de comenzar el
articulo, aclarar ciertos conceptos mas bien “técnicos” que nos serán de gran
ayuda para entender que es y que podemos hacer realmente con el proyecto
“Mono” tanto en Windows como en Linux (créanme que hasta que no comprendí
realmente esto no estaba seguro de que es lo que estaba
haciendo).
Lo primero que se debe aclarar,
es que el proyecto “Mono” (http://www.go-mono.org) no es la migración de .NET
o del “Framework .NET” a Linux, sino mas bien una NUEVA implementación del
“CLI” propuesto por Microsoft a la ECMA.
Entonces, que es el CLI? Bueno,
el “CLI” o “Common Language Infrastructure” (o “Infraestructura Común para
Lenguajes”) es el alma y corazón de lo que Microsoft llama “Framework .NET”
(cada empresa le puede colocar el nombre que encuentre mas “marketero”) y es
algo similar a la maquina virtual de Java, claro que mas cercana a la maquina
en donde se ejecuta realmente el código, es decir, no tan “virtual” como la de
Java. Este “CLI”, no es un invento de Microsoft, es un trabajo conjunto
realizado por la “ECMA” o “European Computer Manufacturers Association” (o
“Asociación de Manufactureros de Computadoras Europeos”,
http://www.ecma-international.org/) y
sus demás integrantes, este organismo es uno de los mas importantes a nivel
internacional respecto a estándares de computación y lenguajes de
programación, ellos en conjunto con todos sus miembros (entre los cuales esta
por supuesto Microsoft) definieron hace algún tiempo lo que un “CLI” y un ECMAScript, debieran ser. Pero estos
“CLI” o “ECMAScript” no son nada tangible en si, si no mas bien un conjunto de
especificaciones que debieran cumplirse para poder denominarse “CLI” o
“ECMAScript” según sea el caso, y resulta que estos “CLI” y “ECMAScript” son
“POR NATURALEZA” estandarizaciones inter-plataformas o “Cross-Plataform”, lo
que se traduce en que cualquier implementación de cualquiera de ambos debiera
poder tener su implementación en otra plataforma distinta a la original y sin
embargo los programas hechos en una, ejecutarse en la
otra.
Y resulta que todo esto no es
tan reciente, una de las primeras implementaciones del ECMASCript es el
“JavaScript” (implementado por la empresa “Sun Microsystems”, entienden ahora
porque digo que cada quien le pone el nombre que mas le agrada, el nombre
oficial de ECMAScript es “ECMA 262 e ISO/IEC16262”, no tan llamativos verdad
:-) y por eso es que el “JavaScript” puede ser ejecutado en distintas
plataformas con el único requisito de tener las librerías o “plug-ins”
necesarios. Pues bien, resulta entonces que Microsoft entrego su “CLI”, su
compilador C# (también estandarizado por la ECMA) y su ECMAScript a la ECMA
para obtener lo que se podría denominar como una “certificación” de sus
implementaciones, por lo cual el “Framework .NET” por definición ya es
multiplataforma, lo cual no quiere decir que Microsoft este obligado o
interesado en transformar su implementación para que funcione en otra
plataforma distinta a Windows, aunque eso no es tan exacto, ya que Microsoft
ya libero las especificaciones de “su” implementación del “CLI” y del
compilador de C# para ser utilizado en la plataforma “FreeBSD”, un buen
articulo respecto a esto ultimo lo pueden encontrar en
http://www.ondotnet.com/pub/a/dotnet/2001/06/27/dotnet.html.
Pues bien, el hecho de que el
“CLI” de Microsoft este sujeto a estandarización genera dos impactos, el
primero es que cualquier otra empresa puede construir lenguajes de
programación que utilicen este “CLI” (el caso mas practico lo encontramos en
la compañía “Borland” con su producto “Delphi 8 para .NET”, y algunos otros
lenguajes que se están anunciando en el horizonte como “COBOL .NET”, si
“COBOL” y algunos otros) y el segundo, y tal vez mayor impacto, es el de que
cualquier otra empresa podría realizar su propia implementación del “CLI”
(basándose en el de Microsoft y siguiendo las especificaciones de la ECMA),
con lo cual cualquier aplicación generada por cualquier implementación del
“CLI” podría ejecutarse en la otra. Aquí es donde entra en juego la empresa
“Novell” y su organización para proyectos “OpenSource” “Ximian”, la cual se ha
lanzado en la tarea de realizar su propia implementación del “CLI”, pero en
este caso en dos versiones, una para Windows y la otra para Linux, esto es lo
que finalmente conocemos como el proyecto “Mono”, entonces como vemos, “Mono”
es mucho mas que una “portación” del “Famework .NET” a Linux, sino que tal vez
sea incluso un “CLI” mucho mas potente y multiplataforma que el propuesto por
Microsoft, aunque la idea no es competir por quien tiene un mejor “CLI”, sino
mas bien complementarse mutuamente para potenciarse el uno al otro y abrirse
paso entre la gran brecha que separa a ambas plataformas.
Dicho todo este bla, bla…..manos
a la obra.
Instalando el Mono y
todo lo necesario en Windows
(22/May/04)
Partiré esta sección por el lado
de Windows ya que a pesar de que el proyecto “Mono” nació pensando en “Linux”,
es menos frustrante su instalación en Windows, y además podemos ver resultados
más pronto, lo que nos dará fuerzas para emprender la compilación e
instalación de todo lo necesario en Linux.
Lo primero que debemos hacer es
por supuesto bajar el “Mono” que se encuentra en su versión “BETA1” desde el
sito oficial en http://www.go-mono.org,
en la sección de descargas (http://www.go-mono.org/download.html),
encontraremos el “BETA1”, en su versión “Windows installer” con el link “Mono
Setup”, el cual nos descargara el archivo “mono-Beta1-win32-2.exe” de
aproximadamente 12Mb, una vez hecho esto, también debemos bajarnos el
“GtkSharp” (ya hablaremos de el mas tarde) desde
http://sourceforge.net/project/showfiles.php?group_id=40240,
bajando el archivo “gtk-sharp-0.18-win32-setup.zip” de aproximadamente 5Mb y
finalmente el “GLADE” (también hablaremos de el mas tarde) y todo lo que este
necesita en un solo instalador en
http://gladewin32.sourceforge.net/ en el link “gtk+
win32 all in one installer 2.4-rc6 (.exe, 7.73M)”, de
aproximadamente 7MB. Una vez tengamos todo esto en nuestras maquinas daremos
paso a la instalación.
La verdad es
que respecto a la instalación es poco lo que debemos decir, como toda
instalación en Windows, esta se realiza de forma bastante automática, primero
ejecutamos el “mono-Beta1-win32-2.exe” el cual
nos instalara toda la implementación y librarías básicas del “Mono”,
personalmente lo instale en “Archivos de Programa” tal como el me sugirió,
creando la carpeta “Mono-0.91” (correspondiente al BETA1). Luego instalamos el
“gtk-sharp-0.18-win32-setup.zip”, para esto, lo descomprimimos e instalamos
como de costumbre, teniendo en cuenta solo que en una parte de la instalación
nos preguntara por el directorio donde se encuentra “Mono” para que el
instalador agregue las librerías GtkSharp correspondientes al directorio de
librerías de “Mono”, para esto solo basta indicarle el directorio “raiz” de la
instalación de “Mono”, en mi caso “C:\Archivos de Programa\Mono-0.91”.
Finalmente instalamos el “gtk-win32-aio-2.4-rc6.exe”, en mi caso en
“C:\Archivos de Programa\Archivos Comunes\”, lo que crea la carpeta “GTK”
dentro de este directorio.
Finalmente debemos agregar una
ruta o “path” dentro de nuestras variables globales, para que el sistema sepa
donde encontrar ciertas librerias de “mono”, en Windows XP esto se realiza
haciendo “click” derecho sobe “Mi PC”, luego al menú propiedades, nos vamos a
la tablilla de “Opciones avanzadas” y luego en la parte de abajo a “Variables
de entorno”, en el primer recuadro de esta ventana veremos una primera columna
llamada “Variable”, y luego una llamada “Valor”, en la columna “Variable”
buscamos y seleccionamos la que dice “path” y luego presionamos el botón
“Modificar”, nos aparecerá una nueva ventana de dialogo que nos mostrara los
valores, separados por “;”, que posee la variable “path”, Debemos entonces
agregar “;C:\Archivos de programa\Mono-0.91\lib\” (sin la comillas), al final
del contenido del cuadro de texto “Valor de variable:”, teniendo cuidado de no
modificar nada mas.
Para el caso de otras versiones
de Windows, esto se hace de forma similar, pero en estos momentos no recuerdo
exactamente como…
Luego de esto deberemos
reiniciar nuestra maquina…
Primera mezcla, un
poco de VB .NET y otro poco de librerías graficas “Gtk” (26/May/04)
Creo que es mejor (por sanidad
mental) aclarar la problemática de las librerías graficas desde un comienzo y
así entender mejor el “porque” de estas y porque DEBEMOS
usarlas.
Resulta que en Windows, cuando
consideramos una aplicación, la consideramos inmediatamente con una interfaz
grafica de usuario o GUI (por sus siglas en ingles), esto es normal en
ambiente Windows ya que no es posible concebir al mismo “Windows” sin interfaz
grafica, mas aun, todos sabemos que si nuestro Windows no logra arrancar su
interfaz grafica inicial o “Escritorio” estamos bastante perdidos. En el caso
de Linux, el paradigma de la programación se plantea de una forma diferente,
puesto que el sistema operativo puede o no tener interfaz grafica, es que los
programas se construyen separados de sus GUI’s correspondientes, y por lo
tanto si alguien quiere hacer algo “grafico” (ventana, botones, etc.)
necesitara obligadamente alguna librería grafica que se adapte al lenguaje de
programación que se va a utilizar. En otras palabras Windows no tiene (por que
no las necesita) librerías graficas ya que los elementos necesarios para
construirlas están incorporados dentro de la misma API de Windows, y por lo
tanto las ventanas, botones, etc., son proveído por estas llamadas a la API y
no por alguna librería en particular. Tal como mencionábamos, el caso de Linux
es distinto, este incorpora distintas librerías graficas y por lo mismo
existen diversos “ambientes de escritorio” para este sistema operativo, dentro
de los cuales, los mas famosos son “KDE” que utiliza las librerías graficas
“Qt” y “GNOME” que utiliza las librarías graficas “Gtk” (en versiones mas
recientes de Linux, esto es mas exactamente GNOME2 con
Gtk+).
Entonces resulta que el proyecto
“Mono” se vio ante el problema de cómo fabricar las interfases graficas de
forma que fuesen compatibles con ambas plataformas, y la solución provino
desde dos direcciones:
La primera fue la de tratar las
“Ventana de Windows” de forma normal; las ventanas de Windows en .NET son
implementadas en la clase “System.Windows.Forms”, la cual nos provee de los
Formularios, TextBox, Button, etc., pero el problema es que esta clase, mas
bien, encapsula todas las llamadas a la API de Windows necesarias para la
creación de ventanas, lo cual por supuesto es incompatible con Linux,
principalmente por el uso de llamadas a P/Invoke, por lo tanto para que estas
ventanas funcionen en Linux, “Mono” trabaja mediante la clase “System.Drawing”
y alguna librerías “Wine”, mas información respecto a esta problemática la
puedes encontrar en
http://www.go-mono.org/winforms.html.
Las librerías “Wine”, desde hace
algún tiempo ya están permitiendo ejecutar aplicaciones Windows normales, no
Framework, como Office, IExplorer, Kazaa y otras en ambiente Linux, pero en
este caso se utilizan solo para “renderizar” o dibujar la ventana cuando se
hace uso de las “Windows.Forms” en Linux, el resto de la ejecución de la
aplicación la sigue manejando “Mono”. Para un tema de “Integración Visual”,
“Mono” esta trabajando con “Wine” para que la ventana adquiera el tema de
escritorio utilizado actualmente, de esta forma la aplicación no parecerá
“emulada” y parecerá una aplicación “GNOME” o “KDE” normal. Ya veremos mas
adelante una pequeña aplicación con “Windows.Forms” y VB .NET ejecutándose en
Linux.
Por otro lado, el proyecto
“Mono” tenia la oportunidad de introducir un nuevo enlace entre los lenguajes
.NET y “Mono” a otras librerías graficas que ya fuesen Cross-Plataform como lo
son las “Gtk”, que existen en versiones para Linux, Windows, IRIX, Solaris,
etc., por esto se creo el “Gtk#” o ”GtkSharp” para enlazar estas liberarías
graficas a lenguajes como C# y VB .NET.
Entonces demos paso a nuestra
primera aplicación con “Gtk” y VB .NET:
En este caso, utilizaremos el VS
.NET y el compilador de Basic que este nos provee, ya que el compilador para
Basic de “Mono” todavía esta en versión “alpha” y todavía tendremos muchos
problemas al compilar con este en Windows, de todas formas lo que hagamos será
compatible con Linux, e incluso lo copilaremos en esa
plataforma.
Abrimos el
VS .NET y creamos un nuevo proyecto VB .NET “Vacío”, a este le agregamos un
nuevo elemento “Module” al que le pondremos el nombre de “Modulo_Inicio”,
agregamos “Referencias” a “System.dll” y “System.Data.dll”, además para lo que
corresponde a “Mono” debemos agregar “Referencias” a “atk-sharp” ,
“glib-sharp” y “gtk-sharp”, todas estas librerías las encontramos en
“C:\Archivos de Programa\Mono-0.91\lib”, el “Modulo_Inicio” contendrá el
siguiente código:
Imports
System
Imports
Gtk
Imports
GtkSharp
Module
Modulo_Inicio
Dim Ventana
As Gtk.Window
Dim Boton
As Gtk.Button
Sub main()
Gtk.Application.Init()
'Crea nuestros GTK Widgets o (controles)
Ventana =
New
Window("Hola Gtk#")
'Se utiliza este metodo, "late binding",
para enlazar manejadores de
eventos, ya que la
'clausula "WithEvents" todavia presenta problemas al compilador basic de Mono
AddHandler
Ventana.Destroyed, AddressOf
Ventana_Destroyed
Boton =
New Button("Apretame")
AddHandler
Boton.Clicked, AddressOf
Boton_Clicked
'Se construye el contenido de la ventana
y se despliega
Ventana.Add(Boton)
Ventana.ShowAll()
'Se inicia la ejecucion de la aplicación
Gtk.Application.Run()
End
Sub
'Maneja el cierre de la ventana y el fin de la
aplicación
Private
Sub Ventana_Destroyed(ByVal
o As
Object,
ByVal args
As
System.EventArgs)
Application.Quit()
End
Sub
'Maneja el evento "Clicked" del "Widget" "Boton"
y muestra un pequeño mensaje
Private
Sub Boton_Clicked(ByVal
sender As
Object,
ByVal e
As System.EventArgs)
Boton.Label = "Hola Mundo con VB .NET y Gtk#"
End
Sub
End
Module
Y si
hemos hecho todo bien, cuando ejecutemos la aplicación tendremos nuestra
primera ventana construida con Gtk# y VB .NET compatible 100% con Linux, seria
algo así como esto:
Básicamente el código no
requiere de demasiados comentarios, esencialmente creamos una “Ventana” y un
“Boton” mediante controles “Gtk”, en “Gtk” los controles son llamados “Widgets”,
(gtk-sharp.dll y las otras librerías harán los enlaces necesarios entre el
“Gtk” y nuestro lenguaje), a estos les agregamos manejadores de eventos
mediante el método de “late binding” (o “Enlace tardío”) con la palabra clave
“AddHandler”, también podríamos haber declarado estos “Windgets” con la
palabra reservada “WithEvents” y luego agregar un “Handler” al final del
nombre del procedimiento (como se hace con los controles Windows.Forms), pero
esta cláusula todavía se esta implementando en el compilador de Basic de
“Mono”, por lo cual esto nos habría funcionado solo en Windows, de la forma en
que esta planteado en el ejemplo, esta funciona tanto si lo compilamos en
Windows como en Linux.
Para los mas “puristas”
de la OOP, se puede meter todo el contenido del “Sub Main” dentro de una clase
y solo haber declarado una instancia de esta dentro del “Sub Main”, esto
también es soportado actualmente por el compilador de Basic en “Mono”, pero
por claridad del código se manejo de esta forma.
Bueno, si entendimos lo
que acabamos de hacer, lo que viene se ira por el chorro de fácil…nuestra
siguiente mezcla añadirá un toque de “GLADE” a nuestra aplicación.
El código de ejemplo: buho1_Gtk_Prueba1.zip (3.33 KB)
Llega el .NET a
Linux!!!