Get best of the week

OS "Sivelkiriya": un ejemplo de construcción de un programa

Hola Habr

Esta publicación continúa el ciclo de publicaciones sobre el proyecto Sivelkiriya OS. El primer artículo del ciclo dio una descripción general del concepto, el segundo explicó por qué era necesario y de qué forma el producto podía ver la luz, el tercero describió las soluciones arquitectónicas, y el cuarto respondió la pregunta de cómo coordinar las acciones de los desarrolladores de sistemas operativos y Software en este modelo. Este artículo mostrará un ejemplo de división de un programa simple en módulos para adaptarlo a las realidades del nuevo sistema operativo.

Considere un ejemplo clásico: un programa que le permite abrir un archivo que contiene una imagen de mapa de bits y verlo en la pantalla. La imagen se puede escalar, y si su tamaño en la escala actual excede el tamaño de la pantalla, desplácese.

En los sistemas operativos modernos, este problema a menudo se resuelve mediante una aplicación con una arquitectura cerrada, es decir, una que contiene todo el código requerido o utiliza componentes de terceros por iniciativa propia. El punto clave es que no puede usar parte de la aplicación, puede iniciarla como está o usar otra solución.

Para comprender cómo se resuelve este problema en el marco del sistema operativo Sivelkiriya, primero tendrá que mirar "bajo el capó" de este programa y comprender qué hace y con qué conceptos funciona. Las siguientes son las entidades que surgen durante la operación del programa.

  1. La ubicación de la imagen.En el caso clásico, se describe por la ruta al archivo en el disco. Con una consideración un poco más amplia, las direcciones en la red local o en Internet también entran en esta categoría. Sin embargo, esto no agota todas las posibilidades: la imagen se puede ubicar en la RAM, en la salida de algún programa (por ejemplo, un procesador de fotos o un procesador de gráficos), en una página web, en un chat o mensaje de correo electrónico, dentro de un archivo o documento de oficina. A pesar de que técnicamente todas estas opciones son diferentes entre sí y requieren un procesamiento diferente, desde el punto de vista del usuario, todas tienen un propósito: indican dónde se encuentra la imagen que desea ver. Crear una interfaz que le permita elegir entre tantas opciones es una tarea no trivial, pero conceptualmente no hay obstáculos para este enfoque.Además: no hay ninguna razón por la cual el usuario no debería tener la oportunidad de ver la imagen ubicada en cualquiera de las ubicaciones anteriores.
  2. , . , , , .
  3. . , , jpeg gif. : jpeg .gif, gif . , , , , web-.
  4. , ( ) .
  5. . , tiff, . — , gif — .
  6. .
  7. : , , , .
  8. .
  9. ( ) , .
  10. ( ), .

Dentro del sistema operativo Sivelkiriya, cada una de las entidades enumeradas anteriormente se describe mediante una determinada interfaz de datos. Dicha representación permite su uso en muchos contextos fuera del modelo original (que se discutirá más adelante).

Cada interfaz es implementada por algún objeto, que es creado por algún módulo. El código de los métodos del objeto se ejecuta dentro del marco del módulo que lo generó. Al mismo tiempo, es incorrecto hablar sobre el lanzamiento de módulos como aplicaciones separadas, ya que no tienen sus propios hilos ni memoria fuera de los objetos creados por ellos. Si necesita almacenar un estado que va más allá de trabajar con una sola imagen, se almacena en un objeto separado, cuyo acceso se lleva a cabo de acuerdo con las reglas generales, a través de la interfaz de objetos del sistema operativo.

La estructura de los módulos involucrados en el trabajo de este programa puede verse así:

  1. El primer módulo define el comportamiento de un objeto que implementa la interfaz "Ubicación del objeto" (una imagen es un caso especial de un objeto). En particular, determina cómo acceder a los bytes desde una ubicación determinada. Sin embargo, puede usar módulos que brinden acceso directo al disco o soporte de red, dependiendo de la ubicación física del objeto.
  2. El segundo módulo proporciona acceso directo a los bytes de la imagen. Además, proporciona pistas sobre el posible tipo de contenido basado en el método de almacenamiento (extensión de archivo, encabezados de servidor web, etc.).
  3. El tercer módulo, utilizando sugerencias sobre el tipo de contenido y el acceso a su representación de bytes, determina el tipo real de contenido (formato de archivo de imagen).
  4. , ( , , ) ( ) . , : , . — : jpeg .
  5. , , , , . — — , , .
  6. , . , . — , , , , , , , .

Por supuesto, además de los módulos descritos, el programa puede participar en módulos que proporcionan características adicionales: registro, representación de componentes de ventana, comentarios de audio, etc.

Es fácil ver que dicha estructura hace que la reutilización de la funcionalidad implementada sea lo más simple posible. Por lo tanto, instalar un nuevo códec en el sistema significa que este tipo de imagen se admitirá automáticamente en todos los contextos y en todos los programas. Los diferentes programadores pueden escribir diferentes módulos y en diferentes lenguajes, sin embargo, en el marco de este modelo de interacción, estas diferencias no son significativas. Se puede usar un mismo códec tanto para cargar imágenes en una pantalla en esta interfaz como para representarlas en un programa de mensajería, navegador, visor de directorio, etc.

El soporte para nuevos casos de uso se realiza principalmente. Por ejemplo, agregar varias interfaces adicionales le permite admitir acciones como moverse a las imágenes siguientes y anteriores (independientemente de su ubicación y cómo acceder a ellas) o aplicar filtros. La introducción de un cliente ligero tampoco es un problema: como el sistema operativo controla el paso de datos y llamadas a través de los bordes del módulo, es posible transferir operaciones costosas (por ejemplo, decodificar el contenido de un archivo y escalar una imagen) a otra máquina.

Dado que los prototipos de todos los módulos descritos anteriormente son conocidos por el sistema operativo, conoce sus necesidades desde el punto de vista del sistema y puede actuar en consecuencia. Por ejemplo, la operación de escalado de imágenes se puede realizar en un hilo separado para que el trabajo con imágenes grandes no bloquee la interfaz en las computadoras de gama baja. Además, dado que los módulos no hacen suposiciones sobre los subprocesos en los que se ejecutan, son posibles optimizaciones adicionales: por ejemplo, el subproceso de la interfaz de usuario puede separarse del subproceso responsable de la computación (en este caso, el escalado), solo si este último No tuve tiempo para terminar el trabajo dentro de un período de tiempo predeterminado, y con una reescala rápida, dibujar la imagen a una nueva escala se puede iniciar en una secuencia adicional incluso antescomo un hilo dedicado a la representación, que ya no necesita completarse, logrará procesar la señal hasta su finalización. Dado que el sistema operativo tiene información sobre todos los subprocesos en ejecución, sobre la carga y las capacidades reales de los procesadores de la computadora, los datos de optimización pueden ser más efectivos que los que el autor de una aplicación separada puede hacer en base a suposiciones sobre su entorno de ejecución.

La cuestión de cómo los módulos que conjuntamente brindan una solución a un problema aplicado se vinculan entre sí se puede resolver de varias maneras. Por ejemplo, es obvio que la elección de un módulo que lee bytes de un archivo del disco está determinada por el sistema de archivos de esta sección, y en todos los casos de acceso a la misma sección, se utilizará el mismo módulo. Es probable que el módulo responsable de determinar el formato de imagen se instale a nivel del sistema y se use en todos los contextos. Una excepción pueden ser los casos en que un módulo falla: en este caso, el sistema operativo puede buscar otro módulo instalado que coincida con este prototipo, y si existe, intente usarlo con los mismos datos de entrada. De este modo,el error puede procesarse sin la intervención del usuario, y los datos sobre él se recopilan y, si lo permiten las políticas de seguridad de esta máquina, se pasan a los desarrolladores del módulo del problema junto con la información relacionada necesaria. Si un módulo a menudo tiene problemas, el sistema operativo puede decidir excluirlo de la cadena de búsqueda o disminuir su prioridad en él.

En otros casos, la elección del módulo puede ser definida por el usuario y almacenada en la configuración. Por lo tanto, diferentes módulos de escalado de imágenes pueden proporcionar diferentes estilos de representación (parámetros de suavizado al alejar o difuminar los bordes de píxeles cuando aumenta). Dependiendo del contexto, el usuario puede necesitar un enfoque diferente (bordes de píxeles nítidos para un posicionamiento preciso o borrosos para la comodidad visual).

Los métodos para iniciar los módulos también pueden variar. Por ejemplo, el módulo responsable de representar la ventana del visor de imágenes puede ser llamado por el módulo responsable de representar el escritorio (haciendo clic en el archivo gráfico en el escritorio), o por el módulo que muestra el menú de inicio del programa. Después de comenzar, el módulo de ventana carga los módulos que necesita para completar la tarea actual.

Esta descripción es solo una demostración de la posibilidad fundamental de implementar dicho esquema de interacción y no puede considerarse como una instrucción completa para escribir un visor de imágenes, un sistema operativo y / o módulos para él.

Los artículos anteriores de la serie están disponibles aquí: uno , dos , tres , cuatro. El texto completo, como antes, está disponible en el sitio web del proyecto .

More articles:


All Articles