MAC Rationale vs Windows Rationale en el desarrollo

Todavía estoy leyendo temas generales sobre el
desarrollo en MAC, de hecho aún no he pasado de los manuales que describen las
tecnologías y los diferentes bloques en que se divide el desarrollo en MAC.

No obstante me ha surgido una curiosa
reflexión que quiero compartir con vosotros. Todavía no estoy muy seguro de que
sea completamente cierta, porque todavía no he profundizado en los conceptos
MAC y lo que he leído tiene más que ver con la publicidad del desarrollo en esta plataforma que otra cosa, pero
creo que tiene muchos visos de ser real como la vida misma.

Y lo más curioso de todo es que tiene mucho
que ver con el desarrollo Windows, y más cercanamente al de las tecnologías
.NET. Cuanto más leo sobre Cocoa, QuickTime (que no sólo es un programa sino una
tecnología), etc., más me parece estar leyendo sobre .NET, o más bien sobre la
forma en la que se publicita .NET.

Se habla de grandes grupos de tecnologías
orientadas a objetos, con grandes rendimientos y grandes facilidades ofrecidas
a los desarrolladores. Calcado uno de otro. Ahora habrá que ver la pura
realidad.

Del lado .NET ya lo tengo claro: mucho ruido y
pocas nueces, al menos para desarrollo de sistemas. Quiero creer que del lado
MAC no será igual, pero cualquiera sabe. Ya os iré diciendo.

***

Pero no, no es sobre eso sobre lo que os
quería hablar. Veamos por un lado la arquitectura lógica expresada por los
manuales de MAC, que creo es más real que la dicha por los de Windows.

Debajo del todo un ordenador de Apple hay un
Kernel BSD que no es otra cosa que una variante de UNIX igual que es Linux. Y
luego hay un sistema POSIX de toda la vida que de nuevo tiene que ver con el
mundo UNIX (que viene a ser como una serie de servicios que simplifican el
acceso al núcleo del sistema igual que una consola de comandos en Windows
permite trabajar con ficheros sin tener que tocarlo).

Aunque Apple lo ha llamado Darwin, no deja de
ser lo que es, y de hecho Apple publica
todo el código fuente
de ello. Al ser un estándar debe estar separado.
Realmente está separado.

Encima de eso hay una serie de capas, Cocoa,
Carbon, QuickTime. Más o menos. Pero lo que es cierto es que esos subsistemas
están completamente separados del núcleo o más bien encima de él.

En Windows creo que no es así. En su momento,
en las versiones NT originales sí que lo era (o al menos así se publicitaba).
Recordemos la capa HAL que podía ser para un montón de procesadores y luego el
sistema NT Executive nativo, que corría sobre dicha capa. Pero ahora, después
de la unificación con la plataforma 9x en lo que fue Windows XP dudo mucho que
siga siéndolo.

Porque ahora no hay soporte para ARM, ni para
SuperH, ni para PPC. Sólo Intel x86 y dando gracias. Me juego un gallifante a
que ahora está todo mezclado y revuelto (y de ahí los problemas de Microsoft
para volver a añadir soporte para ARM). Porque si no fuera así no se entendería
cómo puede funcionar el sistema de vídeo sobre Win32 accediendo al driver que
está en el núcleo (sí, ya sé, anillos, gateways
y todo eso, pero no voy por ahí)…

Bueno, quizás en esto me equivoque, pero si
alguien me explicara cómo el hecho de reproducir un vídeo dentro de un
navegador pueda generar una BSOD estando los sistemas separados, que me lo
diga. Porque me ha pasado. Y no una, sino varias veces. Putas ATI.

De todos modos luego veremos alguna razón más
de ello y quizás uno de los puntos más fuertes de por qué Microsoft está un
poco contra la espada y la pared.

***

Apple ya lo ha hecho al menos dos veces y lo
va a hacer una más. En x64 no va a haber Carbon, que es como se le llama al
subsistema que soporta programar en C y C++ de forma nativa. En x64 sólo vamos
a tener Cocoa (Objetive-C y Objetive-C++) y POSIX (que yo sepa). En su momento,
con el cambio de PPC a x86 repitió jugada, haciendo borrón y cuenta nueva y
forzando a muchas empresas de software a reescribir sus programas. Como cosa
curiosa os diré que Apple encargó a Adobe la creación de su iPhoto, iVideo y
demás programas de esa plataforma y Adobe los mandó a freír espárragos porque
estaban como locos rehaciendo sus propios programas. Creo que hubo otro cambio
rompedor más en los MAC pero ahora no recuerdo qué.

Bueno, el meollo del asunto está en que a
veces es conveniente hacer borrón y cuenta nueva. Hasta donde sé, el API de MAC
OS X y el de iOS es un API moderno, orientado a objetos y bastante potente. Ya
os diré si realmente es cierto cuando me enfangue las manos con ello.

***

Ahora volvamos a Windows. Aquellos que hayan
leído sobre el tema, sabrán lo que son los subsistemas.
Para los que no, una pequeña introducción.

Win32 es un subsistema. POSIX es un subsistema
(o lo era hasta que lo quitaron). De hecho, en las primeras versiones de NT
había hasta un subsistema OS/2.

Un subsistema es una API completa que sirve
para que las aplicaciones escritas para tal subsistema se ejecuten en él, sean
independientes del núcleo y no puedan afectarlo en ninguna manera. Ved la
siguiente imagen de la Wikipedia y fijaros arriba a la derecha.






















 http://en.wikipedia.org/wiki/File:Windows_2000_architecture.svg

Básicamente esa debería ser la arquitectura de
Windows. Fijaros también en lo que hemos hablado antes sobre el HAL y el
Executive.

¿Realmente Windows es así? Creo que no.
Teóricamente si cogéis un programa 100% compatible POSIX y lo ejecutáis en
Windows 2000, debería funcionar. ¿Lo hace? Pues no. En su momento lo probé y no
funcionaba. Tampoco lo hacía uno de OS/2 cuando ese subsistema estaba, todavía,
presente. No es que no funcionaran bien o hicieran alguna cosa rara, es que la
mayoría de veces simplemente no cargaban.

¿Ha visto alguno de vosotros un Windows NT
ejecutado en un ARM o en un SuperH? Yo no y no creo que funcionen. ¿Vais viendo
ya por dónde voy?

Con esto no quiero decir que nunca hayan
llegado a funcionar, lo que quiero decir es que yo al menos no lo conseguí en
su momento. En un MAC moderno podemos ejecutar prácticamente cualquier comando
típico UNIX, desde un “ls” hasta un “ps” pasando por un “dd” o lo que queramos.
Aparte de los que la propia Apple ha añadido, que hay unos cuantos.

De nuevo no me malinterpretéis, en ningún
momento estoy diciendo que un MAC sea mejor que un Windows por eso. Simplemente
estoy diciendo que en un MAC sí que están separadas y presentes las distintas
piezas, o al menos así lo creo. De nuevo el tiempo me lo dirá, y yo a vosotros.

***

Y ahora entramos de lleno en .NET. ¿Por qué
.NET no es un subsistema y sin embargo está construido sobre Win32, que no es
precisamente un API limpia y ordenadita sino más bien todo lo contrario? ¿Por
qué no aprovecha Microsoft la arquitectura de los subsistemas para hacer a .NET
miembro de derecho propio dentro de Windows y no un mero envoltorio que cada
vez se va pareciendo más a lo que envuelve, sobre todo en el tema de la guarrería?

Si ya .NET es algo grande en el aspecto del
rendimiento y funcionalidad (comparado con su contrapartida Java y a veces con
el propio Win32), ¿qué rendimiento no tendría si fuera un subsistema
independiente?

¿O es que toda la estructura arquitectónica de
Windows es una mentira como un castillo y no puede haber otros subsistemas
cooperando sobre el ejecutivo?

Me gustaría que alguien me aclarara todo esto,
porque sinceramente no lo entiendo. Yo tengo mi teoría, que no voy a exponer
aquí no sea que se me acuse de lo que creo no soy, y menos ahora que tengo mi calentón de fanboy…

 

2 comentarios sobre “MAC Rationale vs Windows Rationale en el desarrollo”

  1. HOLA. PRIMERO Q NADA TUS COMENTARIOS Y CRITAS SON MUY BUENOS.

    .NET QUE YO SEPA NO TRABAJA BAJO WIN32
    CMO LO HACIA VB6 ES ALGO INDEPENDIENTE
    DE ECHO YO LO VEO CMO LA PLATAFORMA JAVA NO SE QUE TAN CIERTO. Y DE ECHO HAN ECHO QUE .NET FUNCIONE EN LINUX Y SI TIENES TU PROYECTOS 100 % .NET PUEDES COMPÌLARLOS Y CORRERLOS CON EN MONO QUE ES UN PROYECTO QUE SE ENCARGA DE EJECUTAR LA PLATAFORMA DE .NET EN LINUX

    http://en.wikipedia.org/wiki/Mono_(software)

    LEE SOBRE ESTO NO SI YA LO AYAS LEIDO.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *