En informática , Nano-X es un sistema de ventanas que tiene suficientes funciones para usarse en una PC , un sistema integrado [1] [2] o una PDA . [3] [4] Es un proyecto de código abierto destinado a llevar las características de los entornos gráficos de ventanas modernos a dispositivos y plataformas más pequeños. El proyecto pasó a llamarse Microwindows debido a amenazas legales de Microsoft con respecto a la marca Windows .
El sistema Nano- X Window es extremadamente portátil y está completamente escrito en C. Se ha adaptado a las CPU Intel de 16, 32 y 64 bits, al Broadcom BCM2837 ARM Cortex-A53 , así como a los chips MIPS R4000 (NEC Vr41xx) StrongARM y PowerPC que se encuentran en computadoras portátiles y de bolsillo.
El sistema Nano-X Window actualmente se ejecuta en sistemas Linux con soporte de framebuffer del kernel o usando un controlador X11 que permite que las aplicaciones Microwindows se ejecuten en la parte superior del escritorio X Window . Este controlador emula todos los modos de paleta y color verdadero de Microwindows para que se pueda obtener una vista previa de una aplicación utilizando las características de visualización del sistema de destino directamente en la pantalla del escritorio, independientemente de las características de la pantalla del escritorio. Además, ha sido portado a Windows , Emscripten , Android (basado en la biblioteca Allegro ) y MS-DOS . Los controladores de pantalla de Microwindows se han escrito basándose en las bibliotecas SDL1 y SDL2 más las bibliotecas Allegro y SVGAlib . También hay un controlador VESA y VGA de 16 colores y 4 planos.
Microwindows es esencialmente un diseño en capas que permite usar o reescribir diferentes capas para satisfacer las necesidades de la implementación. [5] En el nivel más bajo, los controladores de pantalla , mouse / touchpad y teclado brindan acceso a la pantalla real y a otro hardware de entrada del usuario. En el nivel medio, se implementa un motor de gráficos portátil que brinda soporte para dibujos de líneas, rellenos de áreas, polígonos, recortes y modelos de color. En el nivel superior se implementan tres API que brindan acceso al programador de aplicaciones gráficas. Actualmente, Microwindows admite las API Xlib, Nano-X y Windows Win32 / WinCE GDI . Estas API proporcionan una estrecha compatibilidad con los sistemas Win32 y X Window , aunque con una funcionalidad reducida. Estas API permiten que los programas se transfieran fácilmente desde otros sistemas.
Las interfaces del controlador de dispositivo están definidas en dispositivo.h. Una implementación determinada de Microwindows vinculará al menos un controlador de pantalla, mouse y teclado al sistema. Las rutinas de nivel medio en el núcleo del motor de gráficos independiente del dispositivo llaman al controlador del dispositivo directamente para realizar las operaciones específicas del hardware. Esta configuración permite agregar diversos dispositivos de hardware al sistema Microwindows sin afectar la forma en que funciona todo el sistema.
Actualmente, Microwindows admite tres interfaces de programación de aplicaciones (API) diferentes. Este conjunto de rutinas maneja la actividad cliente - servidor , actividades del administrador de ventanas como dibujar barras de título, cerrar cuadros, etc., así como también manejar las solicitudes de salida de gráficos del programador. Estas API se ejecutan sobre las rutinas principales del motor de gráficos y los controladores de dispositivos.
La API de NX11 es compatible con la API de X Window . Se basa en la API Nano-X y proporciona funciones Xlib utilizando las funciones disponibles en la API Nano-X. Se puede compilar como una biblioteca separada o junto con la biblioteca Nano-X como una biblioteca única llamada libPX11. En total proporciona 180 funciones Xlib y resguardos para funciones adicionales no implementadas.
Basada en la API NX11, la biblioteca de interfaz gráfica de usuario FLTK se puede utilizar para proporcionar una GUI para programas de aplicación. La distribución Nanolinux utiliza la API NX11 y FLTK para implementar un sistema operativo Linux utilizando 19 MB de espacio en disco.
La API Nano-X sigue el modelo del servidor mini-x escrito inicialmente por David Bell, que fue una reimplementación de X en el sistema operativo MINIX . Sigue vagamente la API Xlib del sistema X Window, pero todos los nombres son GrXXX() en lugar de X...(). El modelo básico de cualquier API sobre Microwindows es inicializar los controladores de pantalla, teclado y mouse, luego colgar en un bucle select() esperando un evento. Cuando ocurre un evento, si es un evento del sistema como actividad del teclado o del mouse, entonces esta información se pasa al programa de usuario convertida en un evento de exposición, mensaje de pintura, etc. Si es un usuario que solicita una operación gráfica, entonces los parámetros se decodifican y se pasan a la rutina del motor GdXXX adecuada. Tenga en cuenta que el concepto de ventana versus operaciones de gráficos sin formato se maneja en este nivel de API. Es decir, la API define los conceptos de qué es una ventana, cuáles son los sistemas de coordenadas, etc., y luego todas las coordenadas se convierten en "coordenadas de pantalla" y se pasan a las rutinas centrales del motor GdXXX para hacer el trabajo real. Este nivel también define gráficos o contextos de visualización y pasa esa información, incluida la información de recorte, a las rutinas centrales del motor.
La API que intenta ser compatible con el estándar Microsoft Win32 y WinCE GDI es la API de Microwindows. [6] Actualmente, existe soporte para la mayoría de las rutinas de dibujo y recorte de gráficos, así como para el dibujo automático de la barra de título de la ventana y el arrastre de ventanas para moverlas. La API de Microwindows se basa en mensajes y permite escribir programas sin tener en cuenta las posibles políticas de gestión de ventanas implementadas por el sistema. La API de Microwindows actualmente no es cliente/servidor.
El mecanismo de comunicación fundamental en la API de Microwindows es el mensaje. Un mensaje consta de un número de mensaje conocido y dos parámetros, conocidos como wParam y lParam. Los mensajes se almacenan en la cola de mensajes de una aplicación y se recuperan mediante la función GetMessage. La aplicación se bloquea mientras espera un mensaje. Hay mensajes que corresponden a eventos de hardware, como WM_CHAR para la entrada del teclado o WM_LBUTTONDOWN para presionar el botón del mouse. Además, se envían los eventos que señalan la creación y destrucción de ventanas WM_CREATE y WM_DESTROY. En la mayoría de los casos, un mensaje está asociado con una ventana, identificada como HWND. Después de recuperar el mensaje, la aplicación envía el mensaje al procedimiento de manejo de la ventana asociada mediante DispatchMessage. Cuando se crea una clase de ventana, se especifica su procedimiento de manejo de mensajes asociado, para que el sistema sepa dónde enviar el mensaje.
La arquitectura de paso de mensajes permite que la API central administre muchas funciones del sistema enviando mensajes sobre todo tipo de eventos, como creación de ventanas, necesidad de pintar, movimiento, etc. De forma predeterminada, la función de manejo de ventanas asociada obtiene un "primer paso" en el mensaje y luego llama a la función DefWindowProc, que maneja las acciones predeterminadas para todos los mensajes. De esta manera, todas las ventanas pueden comportarse de la misma manera cuando se arrastran, etc., a menos que el usuario las anule específicamente. Las principales políticas de gestión de ventanas se pueden redefinir simplemente volviendo a implementar DefWindowProc, en lugar de realizar cambios en todo el sistema.
La unidad básica de organización de la pantalla en la API de Microwindows es la ventana. Windows describe un área de la pantalla para dibujar, así como un "procedimiento de ventana" asociado para manejar mensajes destinados a esta ventana. Los programadores de aplicaciones pueden crear ventanas a partir de clases predefinidas, como botones, cuadros de edición y similares, o definir sus propias clases de ventanas. En ambos casos, el método de creación y comunicación con las ventanas sigue siendo exactamente el mismo.
El origen de Nano-X está en NanoGUI. NanoGUI fue creado por Alex Holden tomando el servidor mini-X de David Bell y las modificaciones de Alan Cox y agregando redes cliente/servidor. Luego, Gregory Haerr se interesó en el proyecto NanoGUI y comenzó a realizar importantes mejoras y modificaciones en NanoGUI. Alrededor de la versión 0.5, Gregory Haerr agregó soporte para múltiples API y comenzó a distribuir Microwindows. En Microwindows 0.84, se incorporaron todos los cambios anteriores de NanoGUI y desde entonces ha sido la distribución combinada NanoGUI/Microwindows. En enero de 2005, el sistema cambió su nombre a Nano-X Window System. Debido a que Nano-X sigue vagamente la API Xlib del sistema X Window, se desarrolló una interfaz adicional llamada NXlib, que proporciona una API compatible con Xlib basada en Nano-X.