 | The topic of this article may not meet Wikipedia's general notability guideline .(October 2018) |
 |
In computing, Nano-X is a windowing system which is full featured enough to be used on a PC, an embedded system [1] [2] or a PDA. [3] [4] It is an open source project aimed at bringing the features of modern graphical windowing environments to smaller devices and platforms. The project was renamed from Microwindows due to legal threats from Microsoft regarding the Windows trademark.
The Nano-X Window System is extremely portable, and completely written in C. It has been ported to the Intel 16, 32 and 64 bit CPUs, the Broadcom BCM2837 ARM Cortex-A53, as well as MIPS R4000 (NEC Vr41xx) StrongARM and PowerPC chips found on handheld and pocket PCs.
The Nano-X Window System currently runs on Linux systems with kernel framebuffer support, or using an X11 driver that allows Microwindows applications to be run on top of the X Window desktop. This driver emulates all of Microwindows' truecolor and palette modes so that an application can be previewed using the target system's display characteristics directly on the desktop display, regardless of the desktop display characteristics. In addition, it has been ported to Windows, Emscripten, Android (based on the Allegro library), and MS-DOS. Microwindows screen drivers have been written based on the SDL1 and SDL2 libraries plus the Allegro and SVGAlib libraries. There are also a VESA and a VGA 16 color 4 planes driver.
Microwindows is essentially a layered design that allows different layers to be used or rewritten to suit the needs of the implementation. [5] At the lowest level, screen, mouse/touchpad and keyboard drivers provide access to the actual display and other user-input hardware. At the mid level, a portable graphics engine is implemented, providing support for line draws, area fills, polygons, clipping and color models. At the upper level, three API's are implemented providing access to the graphics applications programmer. Currently, Microwindows supports the Xlib, Nano-X and Windows Win32/WinCE GDI APIs. These APIs provide close compatibility with the Win32 and X Window systems, however, with reduced functionality. These APIs allow programs to be ported from other systems easily.
The device driver interfaces are defined in device.h. A given implementation of Microwindows will link at least one screen, mouse and keyboard driver into the system. The mid level routines in the device-independent graphics engine core then call the device driver directly to perform the hardware-specific operations. This setup allows varying hardware devices to be added to the Microwindows system without affecting the way the entire system works.
Microwindows currently supports three different application programming interfaces (APIs). This set of routines handles client–server activity, window manager activities like drawing title bars, close boxes, etc., as well as handling the programmer's requests for graphics output. These APIs run on top of the core graphics engine routines and device drivers.
The NX11 API is compliant with the X Window API. It is based on the Nano-X API and provides Xlib functions using the functions available in the Nano-X API. It can be compiled as a separate library or together with Nano-X library as a single library called libPX11. In all it provides 180 Xlib functions and stubs for additional functions not implemented.
Based on the NX11 API the FLTK graphical user interface library can be used to provide a GUI for application programs. The Nanolinux distribution uses the NX11 API and FLTK to implement a Linux operating system using 19 MB of disk space.
The Nano-X API is modeled after the mini-x server written initially by David Bell, which was a reimplementation of X on the MINIX operating system. It loosely follows the X Window System Xlib API, but the names all being with GrXXX() rather than X...(). The basic model of any API on top of Microwindows is to initialize the screen, keyboard and mouse drivers, then hang in a select() loop waiting for an event. When an event occurs, if it is a system event like keyboard or mouse activity, then this information is passed to the user program converted to an expose event, paint message, etc. If it is a user requesting a graphics operation, then the parameters are decoded and passed to the appropriate GdXXX engine routine. Note that the concept of a window versus raw graphics operations is handled at this API level. That is, the API defines the concepts of what a window is, what the coordinate systems are, etc., and then the coordinates are all converted to "screen coordinates" and passed to the core GdXXX engine routines to do the real work. This level also defines graphics or display contexts and passes that information, including clipping information, to the core engine routines.
The API which tries to be compliant with the Microsoft Win32 and WinCE GDI standard is the Microwindows API. [6] Currently, there is support for most of the graphics drawing and clipping routines, as well as automatic window title bar drawing and dragging windows for movement. The Microwindows API is message-based, and allows programs to be written without regard to the eventual window management policies implemented by the system. The Microwindows API is not currently client/server.
The fundamental communications mechanism in the Microwindows API is the message. A message consists of a well-known message number, and two parameters, known as wParam and lParam. Messages are stored in an application's message-queue, and retrieved via the GetMessage function. The application blocks while waiting for a message. There are messages that correspond to hardware events, like WM_CHAR for keyboard input or WM_LBUTTONDOWN for mouse button down. In addition, events signaling window creation and destruction WM_CREATE and WM_DESTROY are sent. In most cases, a message is associated with a window, identified as an HWND. After retrieving the message, the application sends the message to the associated window's handling procedure using DispatchMessage. When a window class is created, its associated message handling procedure is specified, so the system knows where to send the message.
The message-passing architecture allows the core API to manage many system functions by sending messages on all sorts of events, like window creation, painting needed, moving, etc. By default, the associated window handling function gets a "first pass" at the message, and then calls the DefWindowProc function, which handles default actions for all the messages. In this way, all windows can behave the same way when dragged, etc., unless specifically overridden by the user. Major window management policies can be redefined by merely re-implementing DefWindowProc, rather than making changes throughout the system.
The basic unit of screen organization in Microwindows API is the window. Windows describe an area of the screen to draw onto, as well as an associate "window procedure" for handling messages destined for this window. Applications programmers can create windows from pre-defined classes, like buttons, edit boxes, and the like, or define their own window classes. In both cases, the method of creating and communicating with the windows remains exactly the same.
Nano-X's origin is with NanoGUI. NanoGUI was created by Alex Holden by taking David Bell's mini-X server and Alan Cox's modifications and adding client/server networking. Gregory Haerr then took interest in the NanoGUI project and began making extensive enhancements and modifications to NanoGUI. Around version 0.5, Gregory Haerr added support for multiple API's, and began distributing Microwindows. In Microwindows 0.84, all previous NanoGUI changes were incorporated and since then has been the combined NanoGUI/Microwindows distribution. In January 2005, the system changed its name to the Nano-X Window System. Because Nano-X just loosely follows the X Window System Xlib API, an additional interface was developed named NXlib, which provides an Xlib compatible API based on Nano-X.
The X Window System is a windowing system for bitmap displays, common on Unix-like operating systems.
The Windows API, informally WinAPI, is the foundational application programming interface (API) that allows a computer program to access the features of the Microsoft Windows operating system in which the program is running.
The Graphics Device Interface (GDI) is a legacy component of Microsoft Windows responsible for representing graphical objects and transmitting them to output devices such as monitors and printers. It was superseded by DirectDraw API and later Direct2D API. Windows apps use Windows API to interact with GDI, for such tasks as drawing lines and curves, rendering fonts, and handling palettes. The Windows USER subsystem uses GDI to render such UI elements as window frames and menus. Other systems have components that are similar to GDI; for example: Mac OS has QuickDraw, and Linux and Unix have X Window System core protocol.
In computing, a windowing system is a software suite that manages separately different parts of display screens. It is a type of graphical user interface (GUI) which implements the WIMP paradigm for a user interface.
freedesktop.org (fd.o), formerly X Desktop Group (XDG), is a project to work on interoperability and shared base technology for free-software desktop environments for the X Window System (X11) and Wayland on Linux and other Unix-like operating systems. Although freedesktop.org produces specifications for interoperability, it is not a formal standards body.
In computer science, message queues and mailboxes are software-engineering components typically used for inter-process communication (IPC), or for inter-thread communication within the same process. They use a queue for messaging – the passing of control or of content. Group communication systems provide similar kinds of functionality.
In computing, text-based user interfaces (TUI), is a retronym describing a type of user interface (UI) common as an early form of human–computer interaction, before the advent of bitmapped displays and modern conventional graphical user interfaces (GUIs). Like modern GUIs, they can use the entire screen area and may accept mouse and other inputs. They may also use color and often structure the display using box-drawing characters such as ┌ and ╣. The modern context of use is usually a terminal emulator.
X.Org Server is the free and open-source implementation of the X Window System (X11) display server stewarded by the X.Org Foundation.
Windows Console is the infrastructure for console applications in Microsoft Windows. An instance of a Windows Console has a screen buffer and an input buffer. It allows console apps to run inside a window or in hardware text mode. The user can switch between the two using the Alt+↵ Enter key combination. The text mode is unavailable in Windows Vista and later. Starting with Windows 10, however, a native full-screen mode is available.
In computing, the X Window System is a network-transparent windowing system for bitmap displays. This article details the protocols and technical structure of X11.
The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards. DRM exposes an API that user-space programs can use to send commands and data to the GPU and perform operations such as configuring the mode setting of the display. DRM was first developed as the kernel-space component of the X Server Direct Rendering Infrastructure, but since then it has been used by other graphic stack alternatives such as Wayland and standalone applications and libraries such as SDL2 and Kodi.
GDK is a library that acts as a wrapper around the low-level functions provided by the underlying windowing and graphics systems. GDK lies between the display server and the GTK library, handling basic rendering such as drawing primitives, raster graphics (bitmaps), cursors, fonts, as well as window events and drag-and-drop functionality.
Xlib is an X Window System protocol client library written in the C programming language. It contains functions for interacting with an X server. These functions allow programmers to write programs without knowing the details of the X protocol.
The architecture of Windows NT, a line of operating systems produced and sold by Microsoft, is a layered design that consists of two main components, user mode and kernel mode. It is a preemptive, reentrant multitasking operating system, which has been designed to work with uniprocessor and symmetrical multiprocessor (SMP)-based computers. To process input/output (I/O) requests, it uses packet-driven I/O, which utilizes I/O request packets (IRPs) and asynchronous I/O. Starting with Windows XP, Microsoft began making 64-bit versions of Windows available; before this, there were only 32-bit versions of these operating systems.
In computing, a tiling window manager is a window manager with an organization of the screen into mutually non-overlapping frames, as opposed to the more common approach of coordinate-based stacking of overlapping objects (windows) that tries to fully emulate the desktop metaphor.
In computer science, the event loop is a programming construct or design pattern that waits for and dispatches events or messages in a program. The event loop works by making a request to some internal or external "event provider", then calls the relevant event handler.
The Microsoft Windows operating system supports a form of shared libraries known as "dynamic-link libraries", which are code libraries that can be used by multiple processes while only one copy is loaded into memory. This article provides an overview of the core libraries that are included with every modern Windows installation, on top of which most Windows applications are built.
The Linux console is a system console internal to the Linux kernel. A system console is the device which receives all kernel messages and warnings and which allows logins in single user mode. The Linux console provides a way for the kernel and other processes to send text output to the user, and to receive text input from the user. The user typically enters text with a computer keyboard and reads the output text on a computer monitor. The Linux kernel supports virtual consoles – consoles that are logically separate, but which access the same physical keyboard and display. The Linux console are implemented by the VT subsystem of the Linux kernel, and do not rely on any user space software. This is in contrast to a terminal emulator, which is a user space process that emulates a terminal, and is typically used in a graphical display environment.
Longene is a Linux-based operating system kernel intended to be binary compatible with application software and device drivers made for Microsoft Windows and Linux. As of 1.0-rc2, it consists of a Linux kernel module implementing aspects of the Windows kernel and a modified Wine distribution designed to take advantage of the more native interface. Longene is written in the C programming language and is free and open source software. It is licensed under the terms of the GNU General Public License version 2 (GPLv2).