Microwindows

Microwindows Architecture

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.