[ATARI] Librerías dinámicas

[Luis Manuel Asensio Royo]

Buenas,

¡Hala Jesús!, veo que hoy has dado rienda suelta a tu vena literaria... ;-D
Bromas aparte, habrás estado un buen rato escribiendo todos los mensajes... :-D

En fin, voy directamente al tema, pero en un único mensaje, sino puedo pasarme 
mucho tiempo con ello, y precisamente no es lo que más me sobra... :-(

Mi idea de lo que se debería de implementar como librería dinámica se ajusta 
al ejemplo que has dado Jesús sobre el formato JPEG, un tipo de ejecutable 
especializado en una tarea concreta, que además no hay razón alguna para estar 
integrado en el sistema operativo, al estilo de los módulos del núcleo del Linux.

El tema de APIs de cosas más concretas como OpenGL o librería matemática, en 
el caso del primero se debería tratar como con el GDOS, un tipo de archivo que 
él mismo es una capa de sistema, que cuando se necesite se carga durante el 
arranque y queda residente.

En el caso de una librería matemática se debería estudiar si es realmente 
necesaria una precisión tan elevada teniendo en cuenta a qué tipo de usuarios 
se destina el sistema. Si son usuarios normales y corrientes, o incluso PYMES, 
en mi modesta opinión creo que tiene poco sentido, porque con la precisión que 
tienen los coprrcesadores matemáticos ya es suficiente. Pero aun en el caso de 
que fueran necesario, se tendría que tener en cuenta cuántas aplicaciones la 
necesitan, y qué necesitan de ésta librería, porque no creo que un programa 
las necesite todas.

Estoy totalmente en desacuerdo en tener varias versiones de la misma librería, 
lo considero redundante e innecesario, máxime si se tratan de librerías 
especializadas en una tarea concreta. Pongo por ejemplo el Linux, más 
concretamente la distribución Debian. Acabo de examinar el directorio /lib, y 
solamente he encontrado una librería por API o tarea diferente, lo demás son 
enlaces simbólicos a dichas librerías, lo cual evita la redundancia y el 
despilfarro de espacio y tiempo.

Estoy de acuerdo en que el sistema sea el único que gestione el mantenimiento 
y uso de las librerías, impidiendo si es necesario que programadores 
'avispados' intenten usarlas por otras vías no deseables, para evitar lo que 
sucede en otros sistemas como el windows y el linux. El sistema del Amiga me 
parece interesante de estudiar...

Se ha hablado de actualizar el sistema operativo. Se habla de la ventaja de 
tener el sistema en disco, yo lo veo una desventaja, Si se te corrompe el 
disco o se avería, ya puedes prepararte para empezar de nuevo la instalación 
del sistema entero, aparte de las aplicaciones, como pasa con el windows y el 
linux. La idea del Milan me parece la más idónea. El sistema está en una 
FlashROM, por ello SIEMPRE esta presente y disponible, pase lo que pase, y al 
ser una FlashROM, si hay un error en el sistema y parece una nueva versión que 
la corrige, la grabas en la FlashROM y listo. Ësto es útil cuando se tiene un 
sistema pequeño y eficiente, como siempre lo ha sido el TOS. Los sistema que 
se cargan de disco al final acaban convirtiéndose en armatostes que necesitan 
megas y megas de disco, y yo no quiero eso en un sistema Atari, lo rechazo de 
plano.

Me niego rotundamente a que el TOS acabe siendo un 'conjunto de librerías', da 
igual donde se metan, porque se que al final acabaría como otros sistemas, 
convirtiéndose en una locura. El ejemplo del VDI no es válido en absoluto, ya 
que es una parte fundamental del sistema TOS, la usa constantemente no sólo 
para dibujar en pantalla todos los menus, ventanas y cajas de diálogo, sino 
también gestión de periféricos como el teclado, ratón y pantalla. Si se quiere 
actualizar el VDI, se hace como siempre, una capa completa del VDI que se 
carga durante el arranque y queda residente en memoria, porque tiene que estar 
SIEMPRE presente y lista para su uso. Si al final el número de cambios es 
elevado y por ello genera una nueva versión del sistema, como está en FlashROM 
se actualiza y listo.

El sistema 'SONAME' del Linux me parece interesante, pero veo que no todo el 
mundo la usa, sino no existirían los problemas que tenemos a la hora de 
instalar una aplicación que no viene con la distribución de Linux. Es por ello 
que insisto tantas veces en que la gestión, carga y llamada de librerías se 
única y exclusivamente a través del sistema, impidiendo cualquier otra vía. 
Ésto es independiente de si el programador pone o no el número de la versión 
de la librería en el nombre del archivo, ya que ésta información ha de estar 
en una cabecera que cargará el sistema para que esté disponible a cualquier 
programa que quiera conocerla.

A diferencia de la gestión de menús, en cuanto a la gestión de ventanas, yo 
también echo de menos funciones que faciliten la labor de presentar y manejar 
los datos que ponemos en su interior, y no tener que estar 'reinventado' lo 
mismo todas las veces, y lo mismo con la cajas de diálogo, y también en el 
tema de los atajos de teclado, no sólo para menús sino también para las cajas 
de diálogo se debería definir un sistema estándar. Si hubieran incluído en el 
AES funciones y servicios para la gestión de cajas de diálogo y ventanas nos 
hubieran facilitado a todos mucho la labor de desarrollar programas GEM. Si se 
está desarrollando una nueva versión del TOS, o el que sea, espero que tengan 
en cuenta éste detalle...

En fin, éste es mi punto de vista sobre librerías dinámicas. Se puede estar o 
o de acuerdo, ya sea en todo o en parte, con lo que expreso en éste mensaje, 
pero es éso, mi punto de vista sobre lo que me gustaría que se implementase en 
un futuro sistema Atari y que no acabe como otros sistemas, con problemas de 
una u otra índole sobre cómo se implementa aquello o ésto.

Bueno, me dejo de rollos, no quiero dormir a nadie, y tampoco quiero excederme 
  y dejar seguir dando rienda suelta mi vena literaria... X-DD
Ya seguiremos disertando sobre éste y otros temas en la lista con el tiempo.
-- 
  |||   Saludos | Salutations | Greetings
_/|\_  Luis Manuel Asensio Royo

"Oh Dios! Nunca subestimes el poder de las cosas estupidas en grandes cantidades"
Sam 'Serious' Stone (The Second Encounter)