Glue layers can greatly simplify the porting of applications from one software environment to another. The concept of a “glue layer” becomes especially practical when there is a large body of already-debugged application software, and it's not desireable to recode that software to a new, different programming interface.

This is especially common with graphical applications because, once painstakenly coded, no one wants to reinvest the effort to overcome all the “off-by-one” problems and other issues associated with graphical systems interfaces. In addition, a well-designed large body of software — including graphical “stacks” which include framebuffer code, windowing systems, widget sets, and applications software — needs to use layered software techniques in order to achieve code and component independence.

Because the Microwindows Project is very well architected by splitting it's own functionality into well defined, separate components, it is fairly easy to write a glue layer that allows a major component of Microwindows to talk with a new or unknown programming interface. Microwindows components include:

• Top layer — the API emulation layer; implements the publicly available graphics programming interface that is normally used.
  
• Middle layer — the drawing engine; performs all the drawing and clipping but is unconcerned with the “window” abstraction that the top layer handles.
  
• Bottom layer — the screen/touch panel/keyboard driver layer; handles all device-dependent interfacing, as the top two levels are device-independent, and highly portable.

(Note: more information on the Microwindows architecture appears here. Also, refer to the references provided at the conclusion of this article.)

The one-day port

I created a glue layer in the process of porting a large embedded java vendor's JVM and graphics interface to Microwindows. As it turns out, their code base was extremely portable, and only required the blitting function of a graphics system. All clipping, text output and drawing was handled through blitting. (This was a java environment targeted towards very small devices, and all applications were written using mostly pictures being drawn, like the new LCD screens used in cars that look like “analog” heater and A/C controls and control the car's conditioning systems.)

I decided that grafting a glue layer right on top of the device-dependent screen layer was the quickest and best choice of getting fast access to all of Microwindow's pre-built framebuffer routines for Linux, but without any overhead of the drawing engine or the Win32 api. In a matter of a single day I had Microwindows running the Java applications. Needless to say, the vendor was very impressed!

Since I was using the portable Microwindows screen driver interface to glue to, I was able to develop this modification on top of a desktop Linux system running X Windows, even though the target system was to be an embedded PowerPC SBC running framebuffer! After the glue layer was completed and tested on the desktop, we simply switched screen drivers from X to the framebuffer driver — and the same glue code allowed the Java application to run without modification on the target embedded device.

I would never have been able to complete this in one day if using the X Window system, because of it's enormous size (my X sources unpacked are 136 megabytes!), as well as because the X server is still tightly packed for performance reasons.

Golfing with Microwindows

Another possibility is gluing onto the upper side of Microwindows. For instance, an embedded SBC board vendor had a customer that wanted to move from Windows CE to Linux, and Microwindows is the only graphical windowing system available on that vendor's StrongARM platform for Linux. The customer, a golf cart manufacturer, had an application already written which used a simple API very similar to SVGAlib.

The SVGAlib library is a simple library that assists with drawing lines, rectangles, and fill-boxes. That's about all it does. (Its claim to fame, however, is that it does it extremely fast, by talking around the framebuffer directly to the VGA chip).

So one of the SBC vendor's technical people built a glue layer that resembled SVGAlib on the top, to work with the prebuilt application, and that talked directly to the Microwindows engine layer, skipping the Xlib and Win32 APIs. The resulting glue layer was extremely thin, since the Microwindows engine already draws rectangles and fills. This job took about two days, with the happy result that the vendor managed to sell the customer 6000 SBCs, along with displays!

Now, when you drive around in a golf cart, you may be keeping score with a Linux application written for Microwindows. Isn't it amazing how much money companies are willing to spend, just to get certain key messages and images behind important eyeballs?

Gluing widgets

Finally, glue layers can also be applied at the widget set layer, above Microwindows. For instance, the YOPY PDA that's been announced uses the [somewhat obsolete] W windowing system.

What makes this interesting, is that there is a small suite of applications programs available, including a very small [non-conformant] browser. The browser talks to the Wt (W Toolkit) API, which turns out to be very simple. We have been thinking about writing a glue layer to convert calls to Wt into calls to Microwindows APIs, so that those applications can run on a superior graphical system unmodifed.

And beyond . . .

Needless to say, the same techniques can be used to efficiently and rapidly port graphical application programs from pSOS or Wind River environments to embedded Linux.

Related stories:
Microwindows: a Graphical Windowing system for Embedded Linux
Linux + Microwindows: challenger to WinCE
Enabling embedded Linux graphical applications
The Microwindows and NanoGUI Projects
Display connectivity solution for embedded Linux devices

Do you have questions or comments on this article? talkback here

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.