Microwindows
In computing, Microwindows is a windowing system which is full featured enough to be used on a PC or a PDA. The Nano-X Window System is an Open Source project aimed at bringing the features of modern graphical windowing environments to smaller devices and platforms. The project was renamed to Nano-X Window System, due to legal threats from Microsoft regarding the Windows trademark.
Overview
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, with a planned first release as v0.91.
Technical
The Nano-X Window System is extremely portable, and completely written in C, although some routines have been recoded in assembly for speed. It has been ported to the Intel 16 and 32 bit CPUs, as well as MIPS R4000 (NEC Vr41xx) StrongARM and PowerPC chips found on popular handheld and pocket PCs. There have been rumors of an SH3 port as well.
The Nano-X Window System currently runs on 32-bit Linux systems with kernel framebuffer support, or through the popular SVGAlib library. In addition, it has been ported to 16-bit Linux ELKS, and real mode MS-DOS. Microwindows screen drivers for 1, 2, 4, 8, 16 and 32 bits-per-pixel have been written, as well as a VGA 16 color 4 planes driver.
Recently, an X11 driver was completed 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.
Architecture
Layered Design
Microwindows is essentially a layered design that allows different layers to be used or rewritten to suit the needs of the implementation. 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, various API's are implemented providing access to the graphics applications programmer. These APIs may or may not provide desktop and/or window look and feel. Currently, Microwindows supports the Windows Win32/WinCE GDI and Nano-X APIs. These APIs provide close compatibility with the Win32 and X Window systems, allowing programs to be ported from other systems easily.
Device Drivers
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.
Application programmer interfaces
Microwindows currently supports two 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. Both the APIs run on top of the core graphics engine routines and device drivers.
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.
Microwindows API
The Microwindows API tries to be compliant with the Microsoft Win32 and WinCE GDI standard. 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, and will be discussed in more detail in section 4.
Nano-X API
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...(). Currently, the Nano-X API is client/server, but does not have any provisions for automatic window dressings, title bars, or user window moves. There are several groups writing widget sets currently, which will provide such things. The user programs must also then write only to a specific widget set API, rather than using the Nano-X API directly, which means that only the functionality provided by the widget set will be upwardly available to the applications programmer. (Although this could be considerable, in the case that, say Gdk was ported.)
Microwindows API
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.
Window creation and destruction
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.