AmigaOS

AmigaOS

Captura de pantalla de AmigaOS 4.1
Revelador	Commodore International , Hyperion Entertainment
Escrito en	Lenguaje ensamblador , BCPL , C
Familia de sistemas operativos	Amiga
Estado de funcionamiento	Actual
Modelo fuente	Código cerrado
Lanzamiento inicial	23 de julio de 1985 ; hace 39 años ( 23 de julio de 1985 )
Último lanzamiento	4.1 Edición final Actualización 2 / 12 de enero de 2021 ; hace 3 años ( 12 de enero de 2021 )
Plataformas	M68K : versiones 1.0 a 3.9 PowerPC : versiones 4.0 a 4.1
Tipo de kernel	Micronúcleo
Interfaz de usuario predeterminada	Gráfica ( Banco de trabajo )
Licencia	Propiedad
Sitio web oficial	www.amigaos.net

AmigaOS es una familia de sistemas operativos nativos propietarios de los ordenadores personales Amiga y AmigaOne . Fue desarrollado inicialmente por Commodore International y presentado con el lanzamiento del primer Amiga, el Amiga 1000 , en 1985. Las primeras versiones de AmigaOS requerían la serie Motorola 68000 de microprocesadores de 16 y 32 bits . Las versiones posteriores, tras la desaparición de Commodore, fueron desarrolladas por Haage & Partner (AmigaOS 3.5 y 3.9) y luego por Hyperion Entertainment (AmigaOS 4.0-4.1). Se requiere un microprocesador PowerPC para la versión más reciente, AmigaOS 4 .

AmigaOS es un sistema operativo monousuario basado en un núcleo multitarea preventivo , llamado Exec . ^[1] Incluye una abstracción del hardware de Amiga, un sistema operativo de disco llamado AmigaDOS , una API de sistema de ventanas llamada Intuition y un entorno de escritorio ^[2] y un administrador de archivos llamado Workbench .

La propiedad intelectual de Amiga está fragmentada entre Amiga Inc. , Cloanto y Hyperion Entertainment . Los derechos de autor de las obras creadas hasta 1993 son propiedad de Cloanto. ^{[3] [4]} En 2001, Amiga Inc. contrató el desarrollo de AmigaOS 4 a Hyperion Entertainment, y en 2009 le otorgaron a Hyperion una licencia exclusiva, perpetua y mundial para AmigaOS 3.1 con el fin de desarrollar y comercializar AmigaOS 4 y versiones posteriores. ^{[5] [ necesita actualización ]}

AmigaOS es un sistema operativo monousuario basado en un núcleo multitarea preventivo , llamado Exec . AmigaOS proporciona una abstracción del hardware de Amiga, un sistema operativo de disco llamado AmigaDOS, una API de sistema de ventanas llamada Intuition y un administrador de archivos de escritorio llamado Workbench .

También se integra en el sistema una interfaz de línea de comandos (CLI), llamada AmigaShell, aunque también está basada completamente en ventanas. Los componentes CLI y Workbench comparten los mismos privilegios. Cabe destacar que AmigaOS carece de cualquier protección de memoria incorporada .

AmigaOS está formado por dos partes, a saber, un componente de firmware llamado Kickstart y una parte de software normalmente denominada Workbench . Hasta AmigaOS 3.1, las versiones correspondientes de Kickstart y Workbench normalmente se lanzaban juntas. Sin embargo, desde AmigaOS 3.5, el primer lanzamiento después de la desaparición de Commodore, solo se ha actualizado el componente de software y el papel de Kickstart se ha reducido un poco. Las actualizaciones de firmware aún se pueden aplicar mediante parches en el arranque del sistema. Eso fue hasta 2018, cuando Hyperion Entertainment (titular de la licencia de AmigaOS 3.1) lanzó AmigaOS 3.1.4 con una ROM Kickstart actualizada para acompañarlo.

Kickstart es el firmware de arranque , que normalmente se almacena en la ROM . Kickstart contiene el código necesario para arrancar el hardware estándar de Amiga y muchos de los componentes principales de AmigaOS. La función de Kickstart es comparable a la BIOS más el núcleo del sistema operativo principal en los IBM PC compatibles . Sin embargo, Kickstart proporciona más funcionalidad disponible en el momento del arranque de lo que normalmente se esperaría en una PC, por ejemplo, el entorno de ventanas completo.

Kickstart contiene muchas partes fundamentales del sistema operativo de Amiga, como Exec , Intuition , el núcleo de AmigaDOS y la funcionalidad para inicializar hardware de expansión compatible con Autoconfig . Las versiones posteriores de Kickstart contenían controladores para controladores IDE y SCSI , puertos de tarjetas PC y otro hardware integrado.

Al iniciar o reiniciar el sistema, Kickstart realiza una serie de comprobaciones de diagnóstico y del sistema y, a continuación, inicializa el chipset de Amiga y algunos componentes básicos del sistema operativo. A continuación, examina los dispositivos de arranque conectados e intenta arrancar desde el que tenga la prioridad de arranque más alta. Si no hay ningún dispositivo de arranque presente, se mostrará una pantalla en la que se le pedirá al usuario que inserte un disco de arranque, normalmente un disquete.

Al iniciarse, Kickstart intenta arrancar desde un dispositivo de arranque (normalmente, un disquete o una unidad de disco duro). En el caso de un disquete, el sistema lee los dos primeros sectores del disco (el bootblock ) y ejecuta las instrucciones de arranque almacenadas allí. Normalmente, este código devuelve el control al SO (invocando AmigaDOS y la GUI) y utilizando el disco como volumen de arranque del sistema. Cualquier disco de este tipo, independientemente del resto del contenido del disco, se denominaba "disco de arranque" o "disco de arranque". Se podía añadir un bootblock a un disco en blanco mediante el uso del installcomando . Algunos juegos y demostraciones en disquete utilizaban bootblocks personalizados, lo que les permitía hacerse cargo de la secuencia de arranque y gestionar el hardware del Amiga sin AmigaOS.

El bootblock se convirtió en un objetivo obvio para los creadores de virus . Algunos juegos o demostraciones que utilizaban un bootblock personalizado no funcionaban si se infectaban con un virus bootblock, ya que el código del virus reemplazaba al original. El primero de estos virus fue el virus SCA . Los intentos de antivirus incluían bootblocks personalizados. Estos bootblocks modificados anunciaban la presencia del verificador de virus mientras revisaban el sistema en busca de signos reveladores de virus residentes en la memoria y luego devolvían el control al sistema. Desafortunadamente, estos no se podían utilizar en discos que ya dependían de un bootblock personalizado, pero alertaban a los usuarios sobre posibles problemas. Varios de ellos también se replicaban en otros discos, convirtiéndose en poco más que virus por derecho propio. ^{[ cita requerida ]}

El Macintosh debería haber tenido multitarea. No puedo enfatizar lo suficiente la gran contribución que hace al elegante diseño del software del sistema. El Amiga tiene un excelente sistema multitarea y creo que tendrá el doble de vida útil que el Macintosh gracias a él.

—  Adam Brooks Webber, el programador responsable de trasladar TrueBASIC a Amiga y Macintosh, Byte , septiembre de 1986 ^[6]

Exec es el núcleo multitarea de AmigaOS. Exec proporciona funcionalidad para multitarea, asignación de memoria, manejo de interrupciones y manejo de bibliotecas compartidas dinámicas . Actúa como un programador para las tareas que se ejecutan en el sistema, proporcionando multitarea preventiva con programación round-robin priorizada. Exec también proporciona acceso a otras bibliotecas y comunicación entre procesos de alto nivel mediante el paso de mensajes . Otros microkernels comparables han tenido problemas de rendimiento debido a la necesidad de copiar mensajes entre espacios de direcciones. Dado que Amiga solo tiene un espacio de direcciones, el paso de mensajes de Exec es bastante eficiente. ^{[7] [8]}

AmigaDOS proporciona la parte del sistema operativo de disco de AmigaOS. Esto incluye sistemas de archivos , manipulación de archivos y directorios, la interfaz de línea de comandos , redirección de archivos, ventanas de consola, etc. Sus interfaces ofrecen funciones como redirección de comandos , canalización , creación de scripts con primitivas de programación estructurada y un sistema de variables globales y locales .

En AmigaOS 1.x, la parte de AmigaDOS se basaba en TRIPOS , que está escrito en BCPL . La interacción con él desde otros lenguajes resultó una tarea difícil y propensa a errores, y la adaptación de TRIPOS no fue muy eficiente.

A partir de AmigaOS 2.x, AmigaDOS fue reescrito en C y Ensamblador , conservando la compatibilidad del programa BCPL 1.x, e incorporó partes del Proyecto de recursos AmigaDOS de terceros , ^[9] que ya había escrito reemplazos para muchas de las utilidades e interfaces BCPL.

ARP también proporcionó uno de los primeros solicitantes de archivos estandarizados para Amiga e introdujo el uso de funciones comodín ( globbing ) más amigables al estilo UNIX en los parámetros de la línea de comandos. Otras innovaciones fueron una mejora en el rango de formatos de fecha aceptados por los comandos y la posibilidad de hacer que un comando sea residente, de modo que solo necesite cargarse en la memoria una vez y permanezca en la memoria para reducir el costo de carga en usos posteriores.

En AmigaOS 4.0 , el DOS abandonó por completo el legado BCPL y, a partir de AmigaOS 4.1 , se ha reescrito con soporte completo de 64 bits .

Las extensiones de archivo se utilizan a menudo en AmigaOS, pero no son obligatorias y no son manejadas específicamente por el DOS, siendo en cambio solo una parte convencional de los nombres de archivo. Los programas ejecutables se reconocen usando un número mágico .

El sistema de ventanas nativo de Amiga se llama Intuition , que maneja la entrada del teclado y el mouse y la representación de pantallas, ventanas y widgets .

Antes de AmigaOS 2.0, no había una apariencia estandarizada , los desarrolladores de aplicaciones tenían que escribir sus propios widgets no estándar. Commodore agregó la biblioteca GadTools y BOOPSI en AmigaOS 2.0, las cuales proporcionaban widgets estandarizados. Commodore también publicó la Guía de estilo de interfaz de usuario de Amiga , que explicaba cómo se debían diseñar las aplicaciones para lograr coherencia. Stefan Stuntz creó una popular biblioteca de widgets de terceros, basada en BOOPSI, llamada Magic User Interface o MUI. MorphOS usa MUI como su kit de herramientas oficial, mientras que AROS usa un clon de MUI llamado Zune . AmigaOS 3.5 agregó otro conjunto de widgets, ReAction , también basado en BOOPSI.

Una característica inusual de AmigaOS es el uso de múltiples pantallas mostradas en la misma pantalla. Cada pantalla puede tener una resolución de video o profundidad de color diferente. AmigaOS 2.0 agregó soporte para pantallas públicas , lo que permite que las aplicaciones abran ventanas en las pantallas de otras aplicaciones. Antes de AmigaOS 2.0, solo se compartía la pantalla Workbench. ^[10] Un widget en la esquina superior derecha de cada pantalla permite alternar entre pantallas. Las pantallas se pueden superponer arrastrándolas hacia arriba o hacia abajo por sus barras de título. AmigaOS 4 introdujo pantallas que se pueden arrastrar en cualquier dirección.

Workbench es el administrador de archivos gráfico nativo y el entorno de escritorio de AmigaOS. Aunque el término Workbench se usó originalmente para referirse a todo el sistema operativo, con el lanzamiento de AmigaOS 3.1, el sistema operativo pasó a llamarse AmigaOS y, posteriormente, Workbench se refiere solo al administrador de escritorio. Como sugiere el nombre, se utiliza la metáfora de un banco de trabajo , en lugar de la de un escritorio; los directorios se representan como cajones , los archivos ejecutables son herramientas , los archivos de datos son proyectos y los widgets de la GUI son gadgets . En muchos otros aspectos, la interfaz se parece a Mac OS , con el escritorio principal mostrando íconos de discos insertados y particiones del disco duro, y una sola barra de menú en la parte superior de cada pantalla. A diferencia del mouse Macintosh disponible en ese momento, el mouse estándar de Amiga tiene dos botones: el botón derecho del mouse opera los menús desplegables, con un mecanismo de "soltar para seleccionar".

Hasta el lanzamiento de la versión 3, AmigaOS solo admitía de forma nativa el chipset gráfico nativo de Amiga , a través de graphics.library , que proporciona una API para primitivas geométricas , operaciones con gráficos rasterizados y manejo de sprites. Como esta API podía obviarse, algunos desarrolladores optaron por evitar la funcionalidad del SO para renderizar y programar directamente el hardware subyacente para obtener ganancias en eficiencia.

Las tarjetas gráficas de terceros fueron inicialmente compatibles a través de soluciones no oficiales propietarias. Una solución posterior en la que AmigaOS podía soportar directamente cualquier sistema gráfico se denominó gráficos retargetables (RTG). ^[11] Con AmigaOS 3.5, algunos sistemas RTG se incluyeron con el sistema operativo, lo que permitió el uso de tarjetas de hardware comunes distintas de los chipsets nativos de Amiga. Los principales sistemas RTG son CyberGraphX , Picasso 96 y EGS . También están disponibles algunas bibliotecas de gráficos vectoriales, como Cairo y Anti-Grain Geometry . Los sistemas modernos pueden utilizar el motor SDL (simple DirectMedia Layer) multiplataforma para juegos y otros programas multimedia.

El Amiga no tenía ninguna capacidad gráfica 3D incorporada , por lo que no tenía una API de gráficos 3D estándar . Más tarde, los fabricantes de tarjetas gráficas y los desarrolladores externos proporcionaron sus propios estándares, que incluían MiniGL , Warp3D , Storm Mesa ( agl.library ) y CyberGL.

El Amiga se lanzó en un momento en el que había poco apoyo para las bibliotecas de gráficos 3D para mejorar las GUI de escritorio y las capacidades de renderizado de las computadoras. Sin embargo, el Amiga se convirtió en una de las primeras plataformas de desarrollo 3D generalizadas. VideoScape 3D fue uno de los primeros sistemas de renderizado y animación 3D, y Silver/ TurboSilver fue uno de los primeros programas 3D de trazado de rayos. Luego, Amiga se jactó de muchas aplicaciones influyentes en el software 3D, como Imagine , Cinema 4D de maxon , Realsoft 3D , VistaPro , Aladdin 4D y Lightwave de NewTek (usado para renderizar películas y programas de televisión como Babylon 5 ).

Asimismo, si bien el Amiga es conocido por su capacidad para sincronizar video fácilmente, no tiene una interfaz de captura de video incorporada . El Amiga admitía una gran cantidad de interfaces de terceros para captura de video de fabricantes estadounidenses y europeos. Existían soluciones de hardware internas y externas, llamadas frame-capturadores, para capturar fotogramas de vídeo individuales o secuencias de ellos, entre ellos: Newtronic Videon, Newtek DigiView, ^{[12] el} búfer de fotogramas externo de 24 bits de Graffiti , el Digilab, el Videocruncher, Firecracker 24, Vidi Amiga 12, Vidi Amiga de 24 bits y 24RT (tiempo real), Newtek Video Toaster , GVP Impact Vision IV24, MacroSystem VLab Motion y VLab PAR, DPS PAR (Personal Animation Recorder), VHI (Video Hardware Interface) de IOSPIRIT GmbH, DVE-10, etc. Algunas soluciones eran complementos de hardware para tarjetas gráficas Amiga como el módulo Merlin XCalibur o el módulo DV construido para el clon de Amiga Draco de la firma alemana Macrosystem. Las modernas tarjetas de expansión de TV con bus PCI y sus interfaces de captura son compatibles con tv.library de Elbox Computer y tvcard.library de Guido Mersmann.

Siguiendo las tendencias modernas en la evolución de las interfaces gráficas, AmigaOS 4.1 utiliza el motor de composición de imágenes Porter-Duff acelerado por hardware 3D .

Antes de la versión 3.5, AmigaOS solo admitía oficialmente el chip de sonido nativo de Amiga , a través de audio.device . Esto facilita la reproducción de muestras de sonido en cuatro canales de sonido PCM de 8 bits controlados por DMA . El único formato de muestra de hardware compatible es el complemento a dos lineal con signo de 8 bits .

El soporte para tarjetas de audio de terceros dependía del proveedor, hasta la creación y adopción de AHI ^[13] como estándar de facto. AHI ofrece una funcionalidad mejorada, como la reproducción de audio sin interrupciones desde un dispositivo de audio seleccionado por el usuario, una funcionalidad estandarizada para la grabación de audio y rutinas de mezcla de software eficientes para combinar múltiples canales de sonido, superando así el límite de hardware de cuatro canales del chipset original de Amiga. AHI se puede instalar por separado en AmigaOS v2.0 y posteriores. ^[14]

El propio AmigaOS no admitía MIDI hasta la versión 3.1, cuando la biblioteca camd.library de Roger Dannenberg se adaptó como API MIDI estándar. La versión de Commodore de camd.library también incluía un controlador integrado para el puerto serie. La versión posterior de código abierto de camd.library de Kjetil Matheussen no proporcionaba un controlador integrado para el puerto serie, sino un controlador externo.

AmigaOS fue uno de los primeros sistemas operativos en incorporar síntesis de voz con software desarrollado por SoftVoice, Inc., que permitía la conversión de texto a voz del inglés americano . ^[15] Este tenía tres componentes principales: narrator.device , que modula los fonemas utilizados en inglés americano , translate.library , que traduce texto en inglés a fonemas en inglés americano utilizando un conjunto de reglas, y un controlador SPEAK: de alto nivel , que permite a los usuarios de la línea de comandos redirigir la salida de texto a voz. Una utilidad llamada Say se incluyó con el sistema operativo, que permitía la síntesis de texto a voz con cierto control de los parámetros de voz y habla. También se incluyó una demostración con ejemplos de programación de AmigaBASIC . La síntesis de voz se utilizó ocasionalmente en programas de terceros, particularmente software educativo. Por ejemplo, los procesadores de texto Prowrite y Excellence! podían leer documentos utilizando el sintetizador. Estos componentes de síntesis de voz permanecieron prácticamente sin cambios en versiones posteriores del sistema operativo y Commodore finalmente eliminó el soporte de síntesis de voz a partir de AmigaOS 2.1 en adelante debido a restricciones de licencia. ^[16]

A pesar de la limitación del inglés americano en cuanto a los fonemas del dispositivo narrator.device , Francesco Devitt desarrolló una versión no oficial con síntesis de voz multilingüe. Para ello, utilizó una versión mejorada de translate.library , que podía traducir varios idiomas a fonemas, a partir de un conjunto de reglas para cada idioma. ^[17]

AmigaOS tiene un disco RAM de tamaño dinámico , que se redimensiona automáticamente para acomodar su contenido. A partir de AmigaOS 2.x, los archivos de configuración del sistema operativo se cargaban en el disco RAM al iniciarse, lo que aceleraba enormemente el uso del sistema operativo. Se podían copiar otros archivos al disco RAM como cualquier dispositivo estándar para una rápida modificación y recuperación. También a partir de AmigaOS 2.x, el disco RAM admitía la notificación de cambios de archivos, que se usaba principalmente para monitorear los archivos de configuración en busca de cambios.

A partir de AmigaOS 1.3, ^[18] también hay un disco RAM recuperable de capacidad fija, que funciona como un disco RAM estándar pero puede mantener su contenido en un reinicio suave. Se lo suele llamar disco RAD por su nombre de dispositivo predeterminado, y se puede usar como un disco de arranque (con sector de arranque). Anteriormente, se introdujo un disco RAM recuperable, comúnmente llamado ASDG RRD o VD0 , en 1987; ^[19] al principio, estaba limitado a los productos de memoria de expansión ASDG. Más tarde, el ASDG RRD se agregó a la serie Fred Fish de software gratuito, shareware y de dominio público (discos 58 ^[20] y 241 ^[21] ).

AmigaOS es compatible con el lenguaje Rexx , llamado ARexx (abreviatura de "Amiga Rexx"), y es un lenguaje de script que permite la creación de scripts completos para el sistema operativo, similar a AppleScript ; scripts dentro de la aplicación, similar a VBA en Microsoft Office ; así como comunicación entre programas. Tener un único lenguaje de scripts para cualquier aplicación en el sistema operativo es beneficioso para los usuarios, en lugar de tener que aprender un nuevo lenguaje para cada aplicación.

Los programas pueden escuchar mensajes de cadena en un "puerto ARexx". Estos mensajes pueden ser interpretados por el programa de manera similar a como lo haría un usuario al presionar botones. Por ejemplo, un script ARexx ejecutado en un programa de correo electrónico podría guardar el correo electrónico que se muestra actualmente, invocar un programa externo que podría extraer y procesar información y luego invocar un programa de visualización. Esto permite que las aplicaciones controlen otras aplicaciones enviando datos de ida y vuelta directamente con controladores de memoria, en lugar de guardar archivos en el disco y luego volver a cargarlos.

Desde AmigaOS 4, el lenguaje Python está incluido en el sistema operativo.

John C. Dvorak afirmó en 1996:

El AmigaOS "sigue siendo uno de los grandes sistemas operativos de los últimos 20 años, incorporando un núcleo pequeño y tremendas capacidades multitarea como las que se han desarrollado recientemente en OS/2 y Windows NT . La mayor diferencia es que el AmigaOS podía funcionar completamente y realizar múltiples tareas en tan sólo 250 K de espacio de direcciones. Incluso hoy, el SO tiene un tamaño de sólo 1 MB. Y hasta el día de hoy, hay muy poco que un SO que acapara la memoria y carga CD-ROM pueda hacer que el Amiga no pueda. Código ajustado: no hay nada como eso.
He tenido un Amiga durante quizás una década. Es el equipo más confiable que he tenido. ¡Es asombroso! Se puede entender fácilmente por qué hay tantos fanáticos que se preguntan por qué son los únicos que aman esta cosa. El Amiga continúa inspirando una comunidad vibrante -aunque de culto-, no muy diferente a la que tienes con Linux, el clon de Unix". ^[22]

AmigaOS proporciona un conjunto modular de funciones del sistema a través de bibliotecas compartidas cargadas dinámicamente , ya sea almacenadas como un archivo en el disco con una .libraryextensión de nombre de archivo " ", o almacenadas en el firmware Kickstart. Se accede a todas las funciones de la biblioteca a través de una tabla de salto indirecto , que es un desplazamiento negativo al puntero base de la biblioteca. De esa manera, cada función de la biblioteca puede ser parcheada o enganchada en tiempo de ejecución, incluso si la biblioteca está almacenada en ROM. La biblioteca principal de AmigaOS es exec.library ( Exec ), que proporciona una interfaz a las funciones del microkernel de Amiga .

Los controladores de dispositivos también son bibliotecas, pero implementan una interfaz estandarizada. Las aplicaciones no suelen llamar a los dispositivos directamente como bibliotecas, sino que utilizan las funciones de E/S exec.library para acceder a ellos indirectamente. Al igual que las bibliotecas, los dispositivos son archivos en el disco (con la .deviceextensión " ") o almacenados en la ROM Kickstart.

La parte de nivel superior de la gestión de dispositivos y recursos está controlada por los manejadores , que no son bibliotecas, sino tareas , y se comunican mediante el paso de mensajes. Un tipo de manejador es un manejador de sistema de archivos . El AmigaOS puede hacer uso de cualquier sistema de archivos para el que se haya escrito un manejador, una posibilidad que ha sido explotada por programas como CrossDOS y por algunos sistemas de archivos "alternativos" a los estándares OFS y FFS . Estos sistemas de archivos permiten agregar nuevas características como el registro en diario o los privilegios de archivo , que no se encuentran en el sistema operativo estándar. Los manejadores generalmente exponen un nombre de dispositivo al DOS , que se puede usar para acceder al periférico (si lo hay) asociado con el manejador. Como ejemplo de estos conceptos está el manejador SPEAK: que podría hacer que el texto se redirija a voz hablada, a través del sistema de síntesis de voz.

Los nombres de dispositivos son cadenas que no distinguen entre mayúsculas y minúsculas (mayúsculas por convención) seguidas de dos puntos . Después de los dos puntos se puede agregar un especificador , que proporciona al controlador información adicional sobre qué se está accediendo y cómo . En el caso de un sistema de archivos, el especificador generalmente consiste en una ruta a un archivo en el sistema de archivos; para otros controladores, los especificadores generalmente establecen características del canal de entrada/salida deseado (para el controlador de puerto serie SER :, por ejemplo, el especificador contendrá velocidad de bits , bits de inicio y detención , etc.). Los sistemas de archivos exponen los nombres de las unidades como sus nombres de dispositivo. Por ejemplo, DF0: de manera predeterminada se refiere a la primera unidad de disquete del sistema. En muchos sistemas, DH0: se usa para referirse al primer disco duro. Los sistemas de archivos también exponen nombres de volúmenes , siguiendo la misma sintaxis que los nombres de dispositivos: estos identifican el medio específico en la unidad administrada por el sistema de archivos. Si DF0: contiene un disco llamado "Workbench", entonces Workbench: será un nombre de volumen que se puede usar para acceder a los archivos en DF0 :. Si uno quisiera acceder a un archivo llamado "Bar" ubicado en el directorio "Foo" del disco con nombre "Work" en la unidad DF0: , uno podría escribir " DF0:Foo/Bar" o " Work:Foo/Bar". Sin embargo, estos no son completamente equivalentes, ya que cuando se utiliza la última forma, el sistema sabe que el volumen deseado es "Work" y no cualquier volumen en DF0: . Por lo tanto, siempre que se acceda a un archivo solicitado en "Work" sin que el volumen "Work" esté presente en ninguna unidad, dirá algo como: Please insert volume Work in any drive.

Los programas a menudo necesitan acceder a archivos sin conocer su ubicación física (ya sea la unidad o el volumen): solo conocen la "ruta lógica" del archivo, es decir, si el archivo es una biblioteca, un archivo de documentación, una traducción de los mensajes del programa, etc. Esto se soluciona en AmigaOS mediante el uso de asignaciones . Una asignación sigue, nuevamente, la misma sintaxis que un nombre de dispositivo; sin embargo, ya apunta a un directorio dentro del sistema de archivos. El lugar al que apunta una asignación puede ser cambiado en cualquier momento por el usuario (este comportamiento es similar, pero no obstante distinto, del substcomando en MS-DOS , por ejemplo). Las asignaciones también eran convenientes porque una asignación lógica podía apuntar a más de una ubicación física diferente al mismo tiempo, lo que permitía que el contenido de una asignación se expandiera lógicamente, mientras se mantenía una organización física separada. Las asignaciones estándar que generalmente están presentes en un sistema AmigaOS incluyen:

• SYS: , que apunta al directorio raíz de la unidad de arranque.
• C:, que apunta a un directorio que contiene comandos de shell. En el momento del arranque, es SYS:C, si existe; de ​​lo contrario, es SYS:. La ruta de comandos predeterminada es C: y el directorio de trabajo actual, por lo que colocar los ejecutables en C: permite ejecutarlos simplemente escribiendo su nombre.
• DEVS: , que apunta a un directorio que contiene los dispositivos del sistema. En el momento del arranque, es SYS:Devs si existe ese directorio, de lo contrario es SYS:.
• L: , que apunta a un directorio que contiene los controladores y sistemas de archivos de AmigaDOS. En el momento del arranque, es SYS:L si existe; de ​​lo contrario, L: no se crea automáticamente.
• LIBS: , que apunta a un directorio que contiene las bibliotecas del sistema. En el momento del arranque, es SYS:Libs si existe ese directorio, de lo contrario es SYS:.
• S: , que apunta a un directorio con scripts, incluido el startup-sequenceque se ejecuta automáticamente en el momento del arranque, si existe. En el momento del arranque, es SYS:S si existe; de ​​lo contrario, S: no se crea automáticamente.
• T: , que apunta a una carpeta temporal .
• PROGDIR: , una asignación especial que siempre apunta al directorio que contiene el ejecutable que se está ejecutando actualmente. Por ejemplo, si un usuario ejecuta "SYS:Tools/Multiview" y "SYS:System/Format", PROGDIR: apunta a SYS:Tools para Multiview y, al mismo tiempo, a SYS:System para el comando Format. Esta función se introdujo en Workbench 2.0.

AmigaOS 4 introdujo un nuevo sistema para asignar RAM y desfragmentarla "sobre la marcha" durante las inactividades del sistema. Se basa en el método de asignación de bloques y también hay un paginador de memoria que arbitra la memoria de paginación y permite el intercambio de grandes porciones de RAM física en dispositivos de almacenamiento masivo como una especie de memoria virtual . ^{[23] [24]} La paginación cooperativa finalmente se implementó en AmigaOS 4.1 .

Desde la introducción de AmigaOS en 1985, ha habido cuatro versiones principales y varias revisiones menores. Hasta la versión 3.1 del sistema operativo de Amiga, Commodore utilizaba Workbench para referirse a todo el sistema operativo de Amiga. Como consecuencia, Workbench se utilizaba comúnmente para referirse tanto al sistema operativo como al componente de gestión de archivos. Para los usuarios finales, Workbench era a menudo sinónimo de AmigaOS. A partir de la versión 3.5, el sistema operativo pasó a llamarse "AmigaOS" y las versiones anteriores a la 3.5 también se denominaron retroactivamente "AmigaOS" (en lugar de Workbench). Posteriormente, "Workbench" se refiere únicamente al gestor de archivos gráfico nativo.

Desde su inicio, Workbench ofreció una interfaz altamente personalizable. El usuario podía cambiar el aspecto de los iconos del programa reemplazándolos por otros más nuevos con diferentes combinaciones de colores. Los usuarios también podían tomar una "instantánea" de los iconos y ventanas para que estos permanecieran en el escritorio en las coordenadas elegidas por el usuario y las ventanas se abrieran en el tamaño deseado.

AmigaOS 1.0 fue lanzado con el primer Amiga, el Amiga 1000 , en 1985. Las versiones 1.x de AmigaOS usaban por defecto un esquema de colores azul y naranja, diseñado para dar un alto contraste incluso en las peores pantallas de televisión (los colores pueden ser cambiados por el usuario). La versión 1.1 consiste principalmente en correcciones de errores y, al igual que la versión 1.0, fue distribuida solo para el Amiga 1000.

La pantalla era altamente personalizable para la época. El usuario era libre de crear y modificar los iconos del sistema y del usuario, que podían tener un tamaño y un diseño arbitrarios y podían tener dos estados de imagen para producir un efecto pseudoanimado cuando se seleccionaba. Los usuarios podían personalizar cuatro colores de pantalla y elegir entre dos resoluciones: 640×200 o 640×400 (entrelazado) en NTSC , o 640×256 o 640×512 en sistemas PAL . En revisiones posteriores, se podía ajustar el sobreescaneo del televisor o del monitor.

Varias funciones quedaron obsoletas en versiones posteriores. Por ejemplo, el indicador que mostraba el espacio libre en un sistema de archivos fue reemplazado por un porcentaje en AmigaOS 2.0 antes de ser restaurado en 3.5. El indicador de "ocupado" predeterminado (un globo de cómic que muestra "Zzz...") fue reemplazado por un cronómetro en versiones posteriores.

AmigaOS 2.0 fue lanzado con el lanzamiento del Amiga 3000 en 1990. Hasta AmigaOS 2.0 no había un estándar de diseño de apariencia unificado y los desarrolladores de aplicaciones tenían que escribir sus propios widgets (tanto botones como menús) si querían mejorar la ya escasa selección de widgets básicos estándar proporcionados por Intuition. Con AmigaOS 2.0 se creó gadtools.library , que proporcionaba conjuntos de widgets estándar. Se publicó la Guía de estilo de interfaz de usuario de Amiga , que explicaba cómo se debían diseñar las aplicaciones para lograr coherencia. Intuition se mejoró con BOOPSI (Basic Object Oriented Programming System for Intuition) que mejoró el sistema con una interfaz orientada a objetos para definir un sistema de clases en el que cada clase individualiza un solo widget o describe un evento de interfaz. Se puede utilizar para programar interfaces orientadas a objetos en Amiga en cualquier nivel.

AmigaOS 2.0 también agregó compatibilidad con pantallas públicas . En lugar de que la pantalla de AmigaOS sea la única pantalla que se pueda compartir, las aplicaciones pueden crear sus propias pantallas con nombre para compartirlas con otras aplicaciones.

AmigaOS 2.0 corrigió el problema de las aplicaciones que se conectaban directamente al flujo de eventos de entrada para capturar los movimientos del teclado y el ratón, lo que a veces bloqueaba todo el sistema. AmigaOS 2.0 proporcionó Commodities , una interfaz estándar para modificar o escanear eventos de entrada. Esto incluía un método estándar para especificar secuencias de teclas de "acceso rápido" globales y un registro de Commodities Exchange para que el usuario pudiera ver qué productos se estaban ejecutando.

AmigaOS 2.1 introdujo AmigaGuide , un esquema de marcado de hipertexto y navegador simple de solo texto , para proporcionar ayuda en línea dentro de las aplicaciones. También introdujo Installer , un programa de instalación de software estándar, impulsado por un lenguaje de programación similar a LISP .

AmigaOS 2.1 introdujo soporte para configuraciones regionales multilingües a través de locale.library y por primera vez AmigaOS fue traducido a diferentes idiomas. ^[16]

La versión 3.0 se envió originalmente con las computadoras Amiga 1200 y Amiga 4000. La versión 3.0 agregó soporte para tipos de datos, lo que permitió que cualquier aplicación que admitiera tipos de datos cargara cualquier formato de archivo compatible con los tipos de datos. Workbench podía cargar cualquier imagen de fondo en cualquier formato si el tipo de datos requerido estaba instalado. Se incluyó una pequeña aplicación llamada Multiview que podía abrir y mostrar cualquier archivo compatible. Sus capacidades estaban directamente relacionadas con los tipos de datos instalados en Devs:Datatypes. El sistema de hipertexto establecido de AmigaGuide ganó más usabilidad al usar enlaces de documentos que apuntaban a archivos multimedia, por ejemplo imágenes o sonidos, todos reconocidos por los tipos de datos.

El 29 de diciembre de 2015, el código fuente de AmigaOS 3.1 se filtró en línea; esto fue confirmado por el licenciatario, Hyperion Entertainment . ^{[25] [26]}

Aproximadamente seis años después del lanzamiento de AmigaOS 3.1, tras la desaparición de Commodore, se le concedió a Haage & Partner una licencia para actualizar AmigaOS, que se lanzó en 1999 como una actualización solo de software para sistemas existentes, que se ejecutaban al menos en un procesador 68(EC)020.

El aspecto y el funcionamiento de AmigaOS , aunque en gran medida sigue basándose en la versión 3.1 anterior, se revisaron un poco, con una interfaz de usuario mejorada basada en ReAction, una representación de iconos mejorada y soporte oficial para fondos de color verdadero . Estas versiones incluyeron soporte para mejoras de GUI de terceros existentes, como NewIcons , al integrar estos parches en el sistema. Las versiones 3.5 y 3.9 incluyeron un nuevo conjunto de 256 iconos de color y una opción de fondo de escritorio. Estos reemplazaron el esquema de color gris metálico 4/8 predeterminado utilizado en AmigaOS desde la versión 2.0 a la 3.1.

La versión 3.9 de AmigaOS fue desarrollada nuevamente por Haage&Partner y lanzada en 2000. Las principales mejoras fueron la introducción de una barra de inicio de programa llamada AmiDock, interfaces de usuario revisadas para la configuración del sistema y programas de utilidad mejorados.

En septiembre de 2018, Hyperion Entertainment lanzó AmigaOS 3.1.4, una actualización de software y hardware para todos los Amigas. En 2019, se lanzó AmigaOS 3.1.4.1 como una actualización de software de Amiga 3.1.4, principalmente como corrección de errores. ^{[ cita requerida ]}

Incluye muchas correcciones, moderniza varios componentes del sistema que se habían actualizado previamente en OS 3.9, introduce compatibilidad con discos duros más grandes (incluso durante el arranque), admite toda la línea de CPU Motorola 680x0 hasta (e incluyendo) la Motorola 68060, e incluye un Workbench modernizado con un nuevo conjunto de iconos opcional. A diferencia de AmigaOS 3.5 / 3.9, AmigaOS 3.1.4 aún admite la CPU Motorola 68000.

En mayo de 2021, Hyperion Entertainment lanzó AmigaOS 3.2, que incluye todas las características de la versión anterior (3.1.4.1) y agrega varias mejoras nuevas como soporte para ReAction GUI , administración de imágenes de archivos de disco de Amiga , sistema de ayuda y tipos de datos mejorados. ^[27] En diciembre de 2021, se lanzó una actualización llamada AmigaOS 3.2.1, con correcciones de errores y otras mejoras. Una segunda actualización, llamada AmigaOS 3.2.2, se lanzó en marzo de 2023 con más mejoras y correcciones de errores. ^[28]

Este nuevo AmigaOS, llamado AmigaOS 4.0, ha sido reescrito para que sea totalmente compatible con PowerPC . Inicialmente fue desarrollado en Cyberstorm PPC, ya que hacerlo independiente de los antiguos chipsets de Amiga no era trivial. ^[29] Desde la cuarta Actualización previa al lanzamiento para desarrolladores se adoptó una nueva técnica y las pantallas se pueden arrastrar en cualquier dirección. ^{[30] También es posible} arrastrar y soltar los íconos de Workbench entre diferentes pantallas.

También en AmigaOS 4.0 había una nueva versión de Amidock, fuentes TrueType / OpenType y un reproductor de películas con soporte para DivX y MPEG-4 .

En AmigaOS 4.1, se agregó una nueva función de preferencias de inicio que reemplazó al antiguo cajón WBStartup. Otras mejoras fueron un nuevo conjunto de íconos para complementar resoluciones de pantalla más altas, nuevos temas de ventana que incluyen sombras paralelas, una nueva versión de AmiDock con transparencia real, íconos escalables y AmigaOS con función de actualización automática. ^[31]

En octubre de 2022, el desarrollador de AmigaOS, Hyperion Entertainment, lanzó un SDK para AmigaOS 4.1. ^[32]

AROS Research Operating System (AROS) implementa la API de AmigaOS en un sistema operativo portátil de código abierto. Aunque no es compatible a nivel binario con AmigaOS (a menos que se ejecute en 68k), los usuarios han informado que es altamente compatible con el código fuente.

MorphOS es un sistema operativo nativo de PowerPC que también se ejecuta en algunos dispositivos Amiga. Implementa la API de AmigaOS y proporciona compatibilidad binaria con aplicaciones AmigaOS "compatibles con sistemas operativos" (es decir, aquellas aplicaciones que no acceden directamente a ningún hardware Amiga nativo heredado, como AmigaOS 4.x, a menos que se ejecuten en modelos Amiga reales).

pOS era un sistema operativo multiplataforma de código cerrado con compatibilidad a nivel de código fuente con el software Amiga existente. ^[33]

BeOS también cuenta con una estructura de tipos de datos centralizada similar a MacOS Easy Open después de que los antiguos desarrolladores de Amiga solicitaran a Be que adoptara el servicio de tipos de datos de Amiga. Permite que todo el sistema operativo reconozca todo tipo de archivos (texto, música, videos, documentos, etc.) con descriptores de archivos estándar . El sistema de tipos de datos proporciona a todo el sistema y a cualquier herramienta de productividad cargadores y guardadores estándar para estos archivos, sin la necesidad de integrar múltiples capacidades de carga de archivos en un solo programa. ^[34]

AtheOS se inspiró en AmigaOS y originalmente estaba destinado a ser un clon de AmigaOS. ^[35] Syllable es una bifurcación de AtheOS e incluye algunas cualidades similares a AmigaOS y BeOS .

FriendUP es un sistema operativo meta basado en la nube. Cuenta con muchos ex desarrolladores y empleados de Commodore y Amiga trabajando en el proyecto. El sistema operativo conserva varias características similares a las de AmigaOS, incluidos controladores DOS, listas de montaje, una CLI basada en TRIPOS y arrastre de pantalla. ^[36]

Por último, el sistema operativo del 3DO Interactive Multiplayer tenía un gran parecido con AmigaOS y fue desarrollado por RJ Mical , ^[37] el creador de la interfaz de usuario Intuition de Amiga. ^[38]

• Comparación de sistemas operativos

• Sitio web oficial