 | 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.
In computing, a device driver is a computer program that operates or controls a particular type of device that is attached to a computer or automaton. A driver provides a software interface to hardware devices, enabling operating systems and other computer programs to access hardware functions without needing to know precise details about the hardware being used.
The X Window System is a windowing system for bitmap displays, common on Unix-like operating systems.
NeWS is a discontinued windowing system developed by Sun Microsystems in the mid-1980s. Originally known as "SunDew", its primary authors were James Gosling and David S. H. Rosenthal. The NeWS interpreter was based on PostScript extending it to allow interaction and multiple "contexts" to support windows. Like PostScript, NeWS could be used as a complete programming language, but unlike PostScript, NeWS could be used to make complete interactive programs with mouse support and a GUI.
GNUstep is a free software implementation of the Cocoa Objective-C frameworks, widget toolkit, and application development tools for Unix-like operating systems and Microsoft Windows. It is part of the GNU Project.
The Windows API, informally WinAPI, is Microsoft's core set of application programming interfaces (APIs) available in the Microsoft Windows operating systems. The name Windows API collectively refers to several different platform implementations that are often referred to by their own names ; see the versions section. Almost all Windows programs interact with the Windows API. On the Windows NT line of operating systems, a small number use the Native API.
In computing, a windowing system is software 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.
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 graphical user interfaces (GUIs). Like GUIs, they may use the entire screen area and accept mouse and other inputs. They may also use color and often structure the display using special graphical characters such as ┌ and ╣, referred to in Unicode as the "box drawing" set. 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 display server stewarded by the X.Org Foundation.
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.
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 protocol. Few applications use Xlib directly; rather, they employ other libraries that use Xlib functions to provide widget toolkits:
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, they use 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.
Desktop Window Manager is the window manager in Windows Vista, Windows 7, Windows 8, Windows 10, and Windows 11 that enables the use of hardware acceleration to render the graphical user interface of Windows.
XCB is a library implementing the client-side of the X11 display server protocol. XCB is written in the C programming language and distributed under the MIT License. The project was started in 2001 by Bart Massey and aims to replace Xlib.
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 event loop is also sometimes referred to as the message dispatcher, message loop, message pump, or run loop.
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.
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).