La Gaceta de Linux ...¡ haciendo a Linux un poco más divertido !

¡El Escritorio sí Importa!: Una guía de las tecnologías Windows para usuarios de Linux

Por Jimmy O'Regan

Traducción al español por Hugo Cabrera Castro
el día 4 de Abril de 2005, para La Gaceta de Linux

Una pregunta razonable, y que no dejará de ser hecha (¡no importa qué tan bien explique esto!), es: “¿Por qué los usuarios de Linux deben leer acerca de tecnologías de Windows?"

La respuesta principal es: porque mucho del desarrollo en Linux es influenciado por Windows. Windows es la plataforma mas común en la actualidad; la mayoría de nuevos usuarios de Linux vienen de Windows, pero mas importante aún, muchos son nuevos desarrolladores.

Ahora, no significa que sugiera que las tecnologías presentadas aquí se originaran en Windows, o que los equivalentes disponibles en Linux estén limitadas a simplemente seguir la versión de Windows. En muchos casos, especialmente en el escritorio, se pueden argumentar que las tecnologías Linux son mejores, aunque en otros casos, peores.

La principal motivación detrás de escribir esto es tener un documento que apuntar cuando se escriba sobre temas de escritorio. Ya he comparado DCOP con Automatización OLE, Tom Brown también ha hecho esta comparación. Ya que muchos artículos sobre temas de escritorio son escritos con intención de introducir a anteriores usuarios de Windows a Linux, siento que es útil tener un glosario de clases para apuntarlas.

También siento que no sería dañino introducir a usuarios experimentados de Linux a los conceptos de Windows, para ayudar mejor a aquellos que intentarían ayudar a los nuevos usuarios, y ayudarlos a entender porque algún software está diseñado de esa forma. Por ejemplo, la mayoría de tipos de Linux descartan Visual Basic, sin entender por qué Visual Basic es útil para los desarrolladores de Windows.

Una nota acerca de Wine

La mayoría de la gente conoce Wine, aunque sea vagamente. Wine es una implementación de la API de Windows, con un cargador para binarios de Windows. Usando Wine, muchas aplicaciones de Windows pueden ser ejecutadas en Linux; y muchos proyectos open source para Windows pueden ser compilados usando Winelib.

Un problema con Wine es que no puede ser usado como una biblioteca regular de Unix, porque tiene que ser compatible binario con Windows para funcionar. Debido a esto, no puedes vincular con Wine para obtener un cargador DLL sencillo. Se está trabajando en esta área: Mono está usando Wine para desarrollar su implementación de Formas .Net de Windows, y Ardour.

Otro problema mayor es que la API de Windows contiene varias modificaciones para soportar la compatibilidad con versiones anteriores. Después que comencé a escribir esto, Slashdot envió este articulo, que me provee con una forma de explicar por qué Wine tiene tan difícil el implementar la API de Windows:

Escuché acerca de esto de uno de los desarrolladores del exitoso juego SimCity, quien me dijo que había un error crítico en su aplicación: usaba memoria justo después de liberarla, un no-no serio que ocurría para trabajar bien en DOS pero no funcionaría bajo Windows donde la memoria que es liberada es arrebatada por otra aplicación que se esté ejecutando. Los examinadores en el equipo de Windows estaban yendo a través de varias aplicaciones populares, probándolas para asegurarse que trabajaban bien, pero SimCity siguió fallando. Ellos reportaron esto a los desarrolladores de Windows, quienes desensamblaron SimCity, lo pasaron en un depurador, encontraron el error y agregaron código especial que verificaba si SimCity se estaba ejecutando, y si era así, ejecutaba un distribuidor de memoria en un modo especial en el que podía seguir utilizando memoria después de liberarla.

Otro problema es que gran parte de Windows está indocumentada. Del articulo citado arriba, fui guiado al weblog de Raymond Chen, uno de los desarrolladores de Windows, donde encontré esta cita de otro desarrollador de Windows, que explica por que: “La razón por la que no podemos publicar las estructuras es que hacerlo nos excluye de cambiarlas PARA SIEMPRE. Quiero decir PARA SIEMPRE.” (Esta página tiene mas comentarios sobre esto, aunque la historia principal es muy divertida, considerando que mucha gente podría ser perdonada por pensar que esto es lo que Microsoft hace).

Integración de Lenguajes

Una de las razones detrás del diseño de Windows es la meta de la integración de lenguajes. La mayoría de las tecnologías en Windows parecen haber sido escritas para Visual Basic, pero fueron hechas parte del sistema operativo para que otros lenguajes pudieran tomar ventaja de ellas. Esto coloca una carga extra en los desarrolladores de lenguajes que usan estos lenguajes.

En Windows, un desarrollador puede entrar a un objeto COM tan fácilmente desde Python como lo pueden hacer desde C++ o Visual Basic. En Linux, hay varios aros que saltar primero. Un programador de Perl o Python que quiere usar una biblioteca C debe encontrar primero un envoltorio para su lenguaje; si no hay ninguno disponible, debe escribir uno por su cuenta. Un programador de C que quiera entrar a una biblioteca C++ debe escribir una biblioteca envoltorio en C++, que expone las funciones que pueden ser llamadas desde C.

Hay equivalentes disponibles; los módulos Inline de Perl permiten a los programadores de Perl incrustar otros lenguajes dentro del código Perl. Esto permite el reuso de bibliotecas, no importa en que lenguaje estén escritas, pero también requiere que seas capaz de escribir lo suficiente en otro lenguaje para entrar a la funciones que quieres.

El uso que GNOME hace de CORBA permite la integración de lenguajes en un nivel similar al presente en Windows, especialmente con los vínculos de Perl y Python, pero desafortunadamente estos vinieron muy tarde. Como sea, es posible acceder por completo a cualquier objeto CORBA en GNOME, y escribir servidores CORBA, en ambos Perl y Python, pero CORBA ha sido descartado del todo de GNOME como un mecanismo para llamar funciones. Ximian ha enfocado su atención en Mono como un medio de lograr su integración, mientras que otros desarrolladores esta viendo a D-BUS.

OpenOffice.org y Mozilla han obtenido el tipo de framework que permite el mismo nivel de integración de lenguajes que Windows. Aunque esto no es sorprendente, ya que ambos UNO y XPCOM tienen diseños basados en el de COM.

Compatibilidad

De mucha más importancia es la compatibilidad entre los diversos aspectos de Windows. En Linux, aunque hay equivalentes disponibles para cada parte individual de Windows, estas vienen de diferentes proyectos, y varias de estas partes son incompatibles.

Hay tres colecciones de software de oficina para Linux; OpenOffice, Koffice y GNOME Office. Debido a que los componentes son incompatibles, si uso Kword, no puedo usar Gnumeric para mis ilustraciones de ventas incrustadas. Tengo que usar Kspread. Si uso OOCalc, no puedo tener un dibujo Dia incrustado.

Como mencioné, KDE, GNOME, OpenOffice y Mozilla tienen diferentes sistemas de componentes. Ahora, la situación no es tan mala como pudiera haber sido, ya que la gente buena en Sun ha escrito software para permitir que OpenOffice sea usado como un componente Bonobo, como un plugin de Netscape y acceder a componentes XPCOM, los cuales usan para varios propósitos; y KDE tiene una tecnología llamada XParts que permite a los componentes que no son KDE ser incrustados como KParts (aunque no sin una pequeña modificación – solamente Mozilla es soportado, aunque hay también el proyecto Cuckooo para usar OOo como una KPart), así como QtGtk, que permite a las aplicaciones Gtk usar diálogos Qt – el software usando esta tecnología podría, por ejemplo, desplegar el diálogo de archivo de KDE, que permite a los IOSlaves de KDE funcionar dentro de la aplicación GNOME (Ars Technica tiene una visión general de las tecnologías de KDE). Aquí también hay un plugin Bonobo para Mozilla.

Existen otros problemas de compatibilidad; pero estos están siendo abordados, debido principalmente al trabajo de freedesktop.org. Gtk-Qt es un ejemplo de esto en acción; unifica los temas de Gtk y Qt, así los usuarios pueden tener una vista común en su escritorio.

Visual Basic

Ahora, cuando digo Visual Basic, quiero decir el tipo de programación orientada a objetos que VB permite, el cual puede aplicar fácilmente a Delphi o a cualquier otro lenguaje de programación disponible para Windows. Pero VB es el lenguaje más popular en Windows, por eso lo uso para los propósitos de este artículo.

Hay varias razones detrás de la popularidad de Visual Basic: diseño gráfico GUI, sintaxis simple, fácil acceso a objetos COM y fácil acceso a DLLs escritas en C. Diseñadores de GUI están disponibles para Linux: ahí están Glade para GNOME, QtDesigner para KDE, etc. La sintaxis simple tampoco es un problema: Python tiene al menos el mismo nivel de simplicidad.

Eso deja el acceso a componentes y bibliotecas. El acceso a bibliotecas no es mucho problema, ya que para las bibliotecas más comunes, es solo cuestión de tiempo antes de que alguien escriba un envoltorio. El acceso a componentes, como se mencionó antes, es posible, pero tu elección es limitada.

Para un programador en VB, es una tarea común usar Internet Explorer para obtener algunas gráficas de un sitio web, usar Excel para ejecutar cálculos en ellas, insertarlos en una base de datos Access, enviarlas por correo electrónico con Outlook, etc. Es igual de fácil obtener esas gráficas de Mozilla, usar Lotus 123 para cálculos, etc. (Aunque debo anotar que en realidad, la mayoría de la gente no querrá usar componentes des otras suites de escritorio/oficina).

Por el lado positivo, ¡hay tecnologías como Sash XB ahí afuera!

.Net

.Net es el bebé más nuevo de Microsoft. Los lenguajes .Net apuntan al CLR, o Common Language Runtime, que es como el runtime de Java, pero con extensiones para soportar varios lenguajes. Los programas escritos en un lenguaje .Net puede entrar en bibliotecas escritas en otros a través del CLR.

.Net, especialmente cuando es considerado con C#, es visto por muchos como la reacción de Microsoft a perder la demanda que Sun puso en su contra después que hicieron cambios incompatibles a Java. Sin embargo, .Net es también una extensión al ambiente de programación COM + VB que Microsoft ya tenía. Provee una biblioteca de clases con todas las diferentes facilidades de la API Windows/COM, que el equipo Mono está haciendo un gran esfuerzo para implementarla.

Hay dos cosas muy importantes acerca de .Net desde un punto de vista de Linux; primero, que hay dos proyectos que ayudan a implementarlo: Mono y DotGNU Portable .Net; segundo, que Microsoft está diseñando una API completamente nueva, para que esos proyectos tengan menos captura que hacer que con el proyecto Wine.

Además, si quieres tener una máquina virtual incrustable que soporte varios lenguajes, y lo más probable es que tendrá una gran y variada biblioteca de clases, puedes seguir siempre el progreso de Parrot, que está siendo todavía diseñado, pero albergará Perl 6 y (una versión de) Python cuando quede finalizado.

Las tecnologías

DDE

DDE, o Dynamic Data Exchange (Intercambio de Datos Dinámicos), es un protocolo que permite a las aplicaciones de Windows intercambiar datos. Los datos son intercambiados en la forma de pequeños mensajes, que contienen o un pequeño elemento de datos o un apuntador a la ubicación en memoria donde están estos datos disponibles.

DDE esta depreciado.

OLE

OLE significa Object Linking and Embedding (Vinculado e Incrustado de Objetos). OLE fue pensado originalmente para complementar DDE, y para proveer un método simple para vincular archivos, para que, por ejemplo una hoja de cálculo vinculada desde un procesador de palabras pudiera tener las últimas gráficas; e incrustar la aplicación, y entonces el usuario pudiera ser capaz de editar la hoja de cálculo sin salir del procesador de palabras.

En Linux, KDE tiene KParts, mientras GNOME tiene Bonobo. Bonobo es muy similar al diseño de Windows, ya que usa interfases CORBA que son muy parecidas a las interfases usadas en Windows. Sin embargo, Kparts es una tecnología mucho más sencilla. Una KPart es una biblioteca compartida escrita en C++ que implementa una interfaz. Esta biblioteca está acompañada por un archivo XML que describe los elementos del menú que provee la KPart. Esto permite un incrustado similar, con un framework mucho menos complicado. Las KParts usan DCOP para comunicarse con las demás.

VBX

VBX, o Visual Basic eXtensions, también llamadas “controles personalizados”, fueron introducidos como una forma de extender a Visual Basic. Incluidos en el incrustado de OLE, los controles personalizados fueron pensados como una manera de permitir el reuso de componentes. Los controles podían ser agregados a la forma (el “lienzo” del diseñador de GUI de VB) de un programa, donde proveían elementos GUI personalizados, con sus propiedades y métodos propios. Por ejemplo, un programador en VB que quiera desplegar una imagen incluiría un control de image, configurando la propiedad correcta para proveer la localización de la imagen.

VBX es una tecnología obsoleta.

Automatización OLE

Automatización OLE es un conjunto de interfases COM usado para presentar funciones en un objeto ActiveX, u otro programa, en una manera estándar. La automatización también provee un sistema como la reflexión de Java. Esto es usado en VB, por ejemplo, para proveer el completado de código.

A pesar de la afirmación de Eric Raymond de que "La mayoría de los programas no pueden tener ningún script. Los programas dependen de métodos de llamada remota de procedimientos (remote procedure call (RPC)) frágiles y complejos para comunicarse con los demás”, los programas mas grandes proveen interfases OLE. (Ve DCOM para encontrar acerca de la parte RPC)

OCX/ActiveX

OCX, o OLE Control eXtensions, fue una versión extensión de VBX diseñado para las versiones de 32 bits de Windows. VBX fue una idea popular, y Delphi de Borland fue capaz de usarlos. Esto, quizá, convenció Microsoft de que la idea resultaría útil en sus otros lenguajes, así que hicieron OCXs una parte de Windows.

OCX fue después remarcada como ActiveX, aunque este término fue posteriormente usado para referirse a COM y otras tecnologías relacionadas, cuando Microsoft extendió el Internet Explorer para actuar como un contenedor OCX, como una reacción a las applets de Java y plugins de Netscape. Los componentes ActiveX podían ser ejecutados sobre demanda, como las applets, pero también podían ser instalados, como plugins. Microsoft no prestó tanta atención a la seguridad como lo hizo Sun, aunque, y después de la mala publicidad que recibió la seguridad de ActiveX, pocos los usaron como algo diferente que los plugins.

Reaktivate es una extensión de KDE que usa Wine para permitir los controles ActiveX en Konqueror. Hay un plugin ActiveX para Mozilla, pero como este es un plugin para Windows, necesitarás tener el plugin Crossover (y nota que este ya no se vende por separado de Crossover Office), o instalar la versión para Windows de Mozilla usando Wine. (El proyecto Wine eventualmente desea usar el código Mozilla, pero como el código actual está escrito usando ATL, esto envolvería una gran reescritura).

Para equivalentes, ve OLE, aunque es valioso notar que con Mozilla, ahora es posible escribir ActiveX como componentes en Java.

Active Script

Active Script es una tecnología OLE que permite a los lenguajes de scripts ser usados en cualquier aplicación “host”. Esto fue (probablemente) un resultado del trabajo realizado para agregar Javascript a Internet Explorer en adición a ASP. Los lenguajes Active Script pueden entrar a cualquier función expuesta en Automatización.

El resultado es, por ejemplo, Perl en ASP y Python en páginas web.

OpenOffice.org tiene una tecnología similar. Mono y Parrot probablemente agregarán esto en una base más amplia.

COM/DCOM

COM, o Component Object Model, es una extensión a OLE que también se tomó en OCX, basado en una versión modificada de DCE/RPC. Previamente, las interfases de objetos eran especificadas usando ODL (Object Description Language); con COM, estas fueron especificadas usando DCE IDL, con una sintaxis extendida. DCOM significa "Distributed COM". La única diferencia real aquí es que cuando se entra a un objeto en la misma máquina, se accede a él en la misma forma que una clase de C++, pero si el objeto esta en otra máquina, se usa el mecanismo RPC.

En territorio de Linux, Samba implementa mucho de DCOM. Actualmente están trabajando en facilitar la escritura de programas que usen la infraestructura Samba para entrar a objetos DCOM. Hay mucho trabajo en Wine que apunta a lograr que RPC funcione.

DCOP está basado en libICE de X, y Bonobo está basado en CORBA, así que ambos KDE y GNOME son tan transparentes en redes como Windows cuando se trata de entrar a objetos remotos.

ASP

ASP, Active Server Pages, es una forma basada en Active Script de generar páginas web.

Ha habido varios intentos de clonar ASP para Linux. Sun Java System Active Server Pages (anteriormente SunONE ASP, anteriormente Chilisoft ASP) es posiblemente el más conocido, aunque es un producto propietario.

De intentos open source, hay Arrowhead ASP, una implementación Java, que requiere que todos los objetos se reimplementen en Java (aunque si Wine se vuelve utilizable como una biblioteca, Jawin podría eliminar este requerimiento); ASP2PHP, que convierte ASP (VBscript) a PHP; y ASP.NET en Mono.

ADO

ADO, Active Data Objects, es una interfase basada en Automatización para bases de datos, similar a DBI de Perl. ADO está basada en OLE DB, un framework anterior dirigido a programadores de sistemas. OLE DB es poco usada, ya que es una API de bajo nivel muy complicada, aunque los programadores que deseen proveer acceso a una nueva base de datos debe escribir primero una “Proveedor OLE DB” (para continuar con la comparación con Perl, esto es similar a un módulo DBD) antes de que los programadores en ADO puedan usar la base de datos.

GNOME DB de GNOME es una biblioteca influenciada por ADO, que se parece lo suficiente para que Mono lo use para implementar su versión de ADO.NET. KDE, a través de la biblioteca Qt en el que está basado, también tiene un conjunto de bibliotecas para entrar a bases de datos.

J/Direct

Valiendo una breve mención, J/Direct es la extensión para Java que Sun demandó a Microsoft. J/Direct proveyó sintaxis extra para comentarios Javadoc que especificaban como una función DLL u objeto COM iba a ser accesada, así como un conjunto de atributos para clases Java compiladas.

Esta tecnología es obsoleta ahora, pero vive en J# para .Net de Microsoft. Portable .Net provee un compilador Java, aunque no acepta J/Direct ni extensiones J#; como tampoco lo hace IKVM, una VM de Java VM para .Net que viene con Mono.

 



[BIO]Jimmy ha estado usando computadoras desde la tierna edad de siete años, cuando su padre heredó una Amstrad PCW8256. Después de breves coqueteos con una Atari ST y numerosas versiones de DOS y Windows, Jimmy fue introducido a Linux en 1998 y no ha volteado hacia atrás.

Jimmy tiene un hijo, un experto en tecnología de siete años llamado Mark. En el tiempo libre disfruta fuera de su círculo del Infierno personal, trabajando en una fábrica, le gusta tocar la guitarra y editar Wikipedia.

Copyright © 2004, Jimmy O'Regan. Publicado bajo la Open Publication license

Publicado en la Edición 104 de Linux Gazette, Julio 2004