Introduction to Microwindows Programming
In the fast-changing world of embedded, handheld and wireless devices, there are many hardware and software design changes taking place. Many devices now feature 32-bit microprocessors from Intel, MIPS and Motorola, as well as larger LCD graphical displays. In order to leverage the significant results gained in the desktop arena the last ten years, many developers are turning to desktop-like operating systems with these new embedded designs. One of the most promising emerging developments is running Linux in these environments, for a couple of good reasons: Linux on embedded systems brings with it the entire power of desktop computing, along with many solutions already available. Linux, being open source, allows any aspect of the solution to be fully understood and then customized for a particular application.
The Microwindows Project is an open-source project aimed at bringing the features of modern graphical windowing environments to smaller devices and platforms running Linux. Designed as a replacement for the X Window System, Microwindows provides similar functionality using much less RAM and file storage space: from 100K to 600K. The architecture allows for ease in adding different display, mouse, touchscreen and keyboard devices. Starting with Linux version 2.2, the kernel contains code to allow user applications to access graphical display memory as a frame buffer, which ends up being a memory-mapped region in a user process space that, when written to, controls the display appearance. This allows graphics applications to be written without necessitating knowledge of the underlying graphics hardware or using the X Window System. This is the way that Microwindows typically runs on embedded systems.
Microwindows fully supports the new Linux kernel frame buffer architecture and currently has support for 1, 2, 4, 8, 16, 24 and 32 bits per pixel displays, with support for palettized and truecolor display color implementations, as well as grayscale. When programming applications, all colors are specified in the portable RGB format, and the system uses routines to convert to the nearest available color or shade of gray for monochromatic systems. Although Microwindows fully supports Linux, its internal, portable architecture is based on a relatively simple screen device interface and can run on many different RTOSes as well as bare hardware. This is beneficial: graphics programming by the customer can be shared between projects and even run on different targets with different RTOSes, without having to rewrite the graphics side of the application.
The Microwindows system supports host platform emulation of the target platform graphically. That is, Microwindows applications for Linux can be developed and prototyped on the desktop, then run and tested without having to cross-compile and run on the target platform. This is accomplished using Microwindows' X screen driver, rather than the frame buffer driver, where the target application is run on the desktop host and displayed within an X window. The driver can be told to emulate exactly the target platform's display in terms of bits per pixel and color depth. Thus, even though the desktop system is 24-bit color, it can display a 2bpp grayscale for previewing the target application. Since both the host and target are running Linux, almost all operating system services are available on the desktop host.
Microwindows was designed as an attempt to bring applications to market quickly with minimum effort. In order to accomplish this, I felt that designing yet another graphics applications programming interface (API) would steepen the learning curve, thus discouraging interest and increasing time-to-market. Microwindows implements two popular graphics programming interfaces: the Microsoft Windows Win32/WinCE graphics display interface (GDI), used by all Windows CE and Win32 applications, and an Xlib-like interface, known as Nano-X, used at the lowest level by all Linux X widget sets. This allows the extremely large pool of Windows programming talent to be used in developing the graphical side of the application, as well as being familiar to the core group of Linux graphics programmers used to working with X.
In this article we'll build a sample application using the Nano-X API and discuss the issues associated with lower-level Nano-X programming. The Nano-X API allows applications to be built using a client/server protocol over a network or local UNIX domain socket. This allows several applications, running on the embedded device or a remote host, to connect to the Microwindows server for display. In this way, Nano-X programs operate much like clients using the X Window System. The Nano-X API is similar to X's Xlib library, being quite low-level and concerned mostly with creating and destroying windows and basic graphics drawing functions. Because Microwindows was designed to be small, many options can be set using a configuration file supplied with the source package. I'll cover some of these options so that we can first build a working Nano-X server.
|SUSE Linux Enterprise High Availability Extension||Mar 29, 2017|
|Hybrid Cloud Storage Delivers Performance and Value||Mar 29, 2017|
|smbclient Security for Windows Printing and File Transfer||Mar 28, 2017|
|How to Calculate Flash Storage TCO||Mar 27, 2017|
|Non-Linux FOSS: Don't Drink the Apple Kool-Aid; Brew Your Own!||Mar 27, 2017|
|Three EU Industries That Need HPC Now||Mar 25, 2017|
- smbclient Security for Windows Printing and File Transfer
- SUSE Linux Enterprise High Availability Extension
- Hybrid Cloud Storage Delivers Performance and Value
- Non-Linux FOSS: Don't Drink the Apple Kool-Aid; Brew Your Own!
- Returning Values from Bash Functions
- How to Calculate Flash Storage TCO
- Preseeding Full Disk Encryption
- Two Ways GDPR Will Change Your Data Storage Solution
- Chemistry on the Desktop
- Hodge Podge