[ATARI] RE: Atari digest, Vol 1 #391 - 9 msgs

[Luis Manuel Asensio Royo]

Joaquin Ferrero wrote:

> Yo también, para pasar el rato...

X-)
y de paso animamos un poco la lista, que había demasiada 'tranquilidad'... :-D

> Bueno, pero si intentamos meter todas las librerias en un 'summun',
> alias API, entonces lo que nos sale es lo que ya teníamos en nuestros
> ataris: GEM, DOS, XBIOS, VDI, etc. etc.

Mi idea es combinar ambos sistemas, tener un S.O. con lo que necesita un 
usuario normal y corriente para comenzar a trabajar (o jugar), y los 'extra' 
en módulos o librerías que se carguen de manera dinámica. Esto no evita que 
algún programador piense que cierto módulo o librería dinámica no es lo 
suficientemente buena y diseñe la suya propia, ya sea para añadirla al sistema 
o reemplazar la ya existente, con lo cual tendríamos un problema similar a 
otros sistemas, pero si se trata de librerías que realizan tareas que no son 
propias de un S.O., entonces la integridad del sistema (lo más importante en 
mi opinión) se mantiene.

> ZX spectrum, es que los desarrolladores contaban con un escenario único
> en donde programar: la BIOS y la API del ordenador. Y se sabía que era
> el mismo para todos.

Cierto, y las librerías que se enlazaban a los programas normalmente no eran 
más que llamadas al sistema, algo que no se puede reemplazar por una librería, 
porque después de todo, también la tienes que llamar, y el código resultante 
es compacto y rápido. Si habia que actualizar, tenías dos caminos, o todo el 
sistema, o una capa entera, pero mantenías la compatibilidad ¡, sino al 100%, 
y en un % muy elelvado...

> Lo de las librerias dinámicas se hizo porque
> a) No todo estaba en la BIOS/API y/o había que modernizarla/corregir
> errores.
> b) No había espacio físico (RAM) para que todos los programas estuvieran
> compilados de forma estática.

Supongo que Atari, pensando en ésto precisamente ideó el protocolo XBRA, que 
te permitía interceptar cualquiera de los TRAP de llamada al sistema para, o 
ampliar sus funciones, o para mejorar las ya existentes, con lo que se 
mantiene una cierta coherencia...

> Pero lo que son estas ventajas, aparecen los inconvenientes:
> a) Si un programa necesita una librería nueva, no sólo hay que
> actualizar la librería, sino los programas que dependen de ella (lo
> vemos frecuentemente en linux).

¡Qué me vas a contar a mi!, yo al final paso de complicarme la vida, instalo 
lo que viene con la distribución, y lo que no, si tengo ganas de 'guerra' lo 
intento, sino lo dejo para una ocasión que no tenga nada mejor que hacer... :-(

> b) O mantenemos todas las versiones de la librería. Necesitamos llevar
> un registro de ellas (como en windows). Y si casca el registro, casca el
> sistema.

Cierto, para desgracia nuestra, pero en el caso del windows es peor, porque 
parte del sistema operativo está en librerías dinámicas, a lo que yo estoy 
rotundamente en contra, y ya sabemos lo que pasa cuando el registro o alguna/s 
librería/s dinámica/s se corrompen, se borran, o se 'actualizan' por otras sin 
  miramientos...

> Pero, ¿y la otra alternativa? ¿Cada vez que compile un programa en
> windows, tengo que meterle de forma estática todas las librerias que
> estoy utilizando?

Eso es una locura, acabarías con programas aún mucho más voluminosos de lo que 
ya son, ahora bien, sabrías con certeza que funciona, pero a qué precio...

> Es que la informática actual es muy complicada... :-)

Estoy de acuerdo contigo, se ha complicado en exceso. ¿Qué fué de aquello de 
que la soluciónmás sencilla es la mejor?. :-)

>>Feliz año nuevo.

Lo mismo digo. :-D
-- 
  |||   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)