En informática, Nano-X es un sistema de ventanas lo suficientemente completo como para ser utilizado en 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 de ventanas gráficos modernos a dispositivos y plataformas más pequeños. El proyecto se llamaba originalmente Microwindows, pero fue renombrado a Nano-X debido a amenazas legales de Microsoft con respecto a la marca comercial Windows.

El sistema de ventanas Nano-X es extremadamente portátil y está completamente escrito en C. Se ha trasladado a las CPU Intel de 16, 32 y 64 bits, Broadcom BCM2837 ARM Cortex-A53, así como MIPS R4000 (NEC Vr41xx) StrongARM y chips PowerPC encuentran en computadoras de mano y bolsillo.

El sistema de ventanas Nano-X se ejecuta actualmente en sistemas Linux con soporte de framebuffer o usando un controlador X11 que permite que las aplicaciones de Nano-X se ejecuten en la parte superior del escritorio de X Window. Este controlador emula todos los modos de paleta y profundidad de color de Nano-X para que una aplicación pueda obtener una vista previa 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. Además, se ha adaptado a Windows, Emscripten, Android (basado en la biblioteca Allegro) y MS-DOS. Los controladores de pantalla de Nano-X se han escrito basándose en las bibliotecas SDL más las bibliotecas Allegro y SVGALib. También hay un controlador VESA y VGA de 16 colores y 4 planos.

Nano-X es esencialmente un diseño en capas que permite usar o reescribir diferentes capas para adaptarse a las necesidades de la implementación.^[5]​ En el nivel más bajo, los controladores de pantalla, mouse/panel táctil y teclado brindan acceso a la pantalla real y otro hardware de entrada del usuario. En el nivel medio, se implementa un motor gráfico portátil, que brinda soporte para dibujos de líneas, rellenos de área, 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 . Sin embargo, estas API brindan una estrecha compatibilidad con los sistemas Win32 y X Window, con una funcionalidad reducida. Estas API permiten que los programas sean fácilmente portados desde otros sistemas.

Las interfaces del controlador de dispositivo se definen en device.h. Una implementación dada de Nano-X 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 independientes del dispositivo luego llaman al controlador del dispositivo directamente para realizar las operaciones específicas del hardware. Esta configuración permite que se agreguen diferentes dispositivos de hardware al sistema Nano-X sin afectar la forma en que funciona todo el sistema.

Nano-X admite actualmente tres interfaces de programación de aplicaciones (API) diferentes. Este conjunto de rutinas maneja la actividad cliente-servidor, las actividades del administrador de ventanas como dibujar barras de título, cerrar cuadros, etc., así como manejar las solicitudes del programador para la salida de gráficos. Estas API se ejecutan sobre las rutinas del motor de gráficos centrales y los controladores de dispositivo.

La API de NX11 cumple con las especificaciones de la API de X Window. Se basa en la API Nano-X y proporciona funciones Xlib usando las funciones disponibles en la API Nano-X. Se puede compilar como una biblioteca separada o junto con la biblioteca Nano-X como una sola biblioteca llamada libPX11. En total, proporciona 180 funciones Xlib y stubs para funciones adicionales no implementadas.

Basada en la API de 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 μClinux utiliza la API NX11 y FLTK para implementar un sistema operativo Linux utilizando 19 MB de espacio en disco.

El Nano-X AP 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 están con GrXXX()en lugar de X...(). El modelo básico de cualquier API en la parte superior de Nano-X 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 la actividad del teclado o del mouse, esta información se pasa al programa de usuario convertido 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 pasan a la rutina del motor GdXXX correspondiente. Tenga en cuenta que el concepto de una ventana frente a las operaciones de gráficos en bruto 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 del motor GdXXX central 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 del motor central.

La API que intenta cumplir con el estándar Microsoft Win32 y WinCE GDI es la API de Nano-X.^[6]​ Actualmente, hay soporte para la mayoría de las rutinas de dibujo y recorte de gráficos, así como el dibujo automático de la barra de título de la ventana y el arrastre de ventanas para movimiento. La API de Nano-X se basa en mensajes y permite que los programas se escriban sin tener en cuenta las eventuales políticas de gestión de ventanas implementadas por el sistema. Actualmente, API de Nano-X no es cliente-servidor.

El mecanismo de comunicación fundamental en la API de Nano-X 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 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 usando DispatchMessage. Cuando se crea una clase de ventana, se especifica su procedimiento de manejo de mensajes asociado, por lo que el sistema sabe 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, dibujado necesario, movimiento, etc. De forma predeterminada, la función de manejo de ventana 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 administración de ventanas se pueden redefinir simplemente reimplementando DefWindowProc, en lugar de realizar cambios en todo el sistema.

La unidad básica de organización de la pantalla en la API de Nano-X es la ventana. Las ventanas describen un área de la pantalla para dibujar, así como un "procedimiento de ventana" asociado para manejar los 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á con 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. Gregory Haerr luego se interesó en el proyecto NanoGUI y comenzó a realizar amplias 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 de 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.

• Sitio web oficia de Nano-X
• Nano-X en GitHub.