An Interview with Greg Haerr on the Past, Present and Future of Microwindows
Greg Haerr is CEO of Century Software and founder of the Microwindows Project, a GUI/windowing solution for embedded systems and devices. In this interview, Haerr relates how he came to be working with embedded Linux, explains why he created Microwindows, offers a brief comparison between Microwindows and alternative embedded GUIs, contemplates the future of Microwindows and offers his perspective on open source.
Rick: When were you first exposed to Linux, and what led you to begin developing GUI/windowing software for Linux?
Greg: My involvement with Linux goes back to 1993, to one of the first 386 distributions, Yggadrisil. I remember that this distribution came with a boot floppy and a CD, which was new for the time. On bootup, the system ran the UMSDOS file system, which allowed Linux to run on top of the MS-DOS system's free space, and then proceeded to run the X Windows System, display a login prompt and play the theme to Star Trek. The display would switch between three graphics resolutions when you hit the Alt-Plus key...Linux has always shown from the start its extreme adaptability to differing hardware environments and its ability to take maximal advantage of that hardware with minimal user reconfiguration.
I've been programming for over 25 years, long before I became a businessman. Although I've followed Linux for seven years, it's only been during the last two years that I've contributed heavily to important projects. It's definitely been worth it.
Rick: To date, the greatest popularity of Linux has been in the area of web servers and Internet infrastructure systems. Why do you feel Linux is a good choice for embedded systems?
Greg: Why run Linux on embedded devices? In my estimation, there are at least four compelling reasons that show that Linux will continue to grow extremely rapidly in the next decade. First, the 32-bit microprocessor has finally come down in price and power requirements, and up in speed so that it can be used very cost effectively in the embedded devices desired today, including handheld computers, webpad-like devices and devices running flat-panel displays. And Linux nearly from the start has been a multiple-architecture operating system, which already supported these advanced RISC processors. So the convergence of Linux and embedded is quite natural.
Secondly, and especially in the graphical area in which I'm focused, software developers and systems architects want to leverage the tremendous success that has occurred on the desktop to more portable devices. There's no need to reinvent the wheel when so many applications that have propelled the desktop forward can now be used to enable wireless handheld computing.
Finally, Linux, being royalty-free and open source, allows the manufacturers to control their costs during the development phase, while sharing inventions and algorithms allows the best implementations to be deployed, which is a win-win for producers and consumers alike.
Rick: How does Linux compare to the “traditional” operating systems that have been used in the embedded market? That is, OSes like VxWorks, pSOS, VRTX, etc.
Greg: One of the key advantages Linux has over other choices comes in the development cycle: developers run exactly the same operating system on their desktop as they deploy on the target embedded device. This means that they are as completely familiar with the features and capabilities of the target device as they are of the desktop. For instance, in Century Software's new Microwindows operating environment and development toolkit for the Compaq iPAQ, we can completely simulate the target device graphical screen layout on the desktop host environment, thus allowing the applications to be built and tested while the hardware is also being developed.
Of course there are other advantages too, especially for those customers that already have a considerable investment in UNIX, whether it be from Sun, DEC, HP or IBM. And that is if you've got applications that you've developed for the UNIX environment and want to take advantage of the newly available capabilities of handheld and wireless technology, it's unbelievably more simple to deploy those UNIX applications on Linux than it is to try to run them on say, Windows CE. And of course since the majority of web servers are already running Linux, it's natural to build client-side applications using the Linux operating system.
Rick: What made you begin developing Microwindows? What did you have in mind when you started the project—what were your goals?
Greg: Well, I designed the Microwindows windowing environment initially for fun, since I have a love of small systems doing big things. However, this quickly turned into a project where user interest drove me to implement features found only on more advanced systems, but in a small space, without having to be ultimately general. For instance, Microwindows supports anti-aliased text, TrueType and Adobe Type 1 fonts and alpha blending, all of which X is just getting around to support.
Microwindows, when compared to X and including all the libraries, is still an order of magnitude smaller than X. But there is work being performed to bring the size of the X Window System down to a sub-megabyte. However, the complexity difference between Microwindows and X will always be great. In embedded-systems designs, there is always the issue of taking maximum advantage of the hardware, since that is what the appliance is being built for in the first place. So when you've got to interface to the hardware for graphics acceleration or when adding a strange touchpad device, it's an order of magnitude simpler implementing this for Microwindows rather than X. And Microwindows' Nano-X protocol is very similar to X, except that it's got a much simpler color model, which makes applications easier to design.
Rick: What other alternatives are you aware of that, shall we say, compete with Microwindows in terms of GUI support for embedded systems and devices?
Greg: I would say that there's probably three competitors in this space, that is, when you're talking about the technology creators. In addition to TrollTech, there's the PocketLinux folks with the Java implementation. Although Century, TrollTech and Transvirtual could be seen as competing, actually each solution is really a different approach to bringing applications to market, and each has its strong points that are well suited in a particular area. For instance, Transvirtual's PocketLinux is a nice Java implementation that runs on framebuffer and implements a small but complete set of applets, which is great if you're running Java. But it won't run any non-java application, so it's not well suited for general-purpose work. TrollTech's Qt/Embedded is in a similar situation but works for a large desktop Linux audience. The Qt/Embedded Project is, along with the entire Qt class library, a fantastic implementation of a very Windows-look-and-feel applications framework that will port with very little, if any, modifications to an embedded device with a framebuffer. However, Qt/Embedded won't run any non-Qt applications. It's also a lot of source code and is considerably complicated.
The Microwindows operating environment is the fastest of the lot and is well suited for general applications development, where it can't be relied on that all the applications will require a certain look-and-feel, widget set or Java implementation. This general environment is well suited for platforms where a large third-party contribution is desirable, such as devices made for the general public or where different technologies must be applied together without restricting the language or APIs used for development.
Rick: Another important requirement in embedded Linux systems with graphical interfaces is the browser. You've started a browser project too—ViewML. What other alternatives are there, and how do they compare with ViewML?
Greg: Of course I'm partial to ViewML, which is the open-source embedded browser created by Century Software. ViewML runs in 800K ROM and 2.1MB RAM, and so it works very well with small devices. But it's quite limited in what you can do, given its small footprint. Recently, a group in Australia ported the full Mozilla browser to Microwindows, and it actually works. So depending on the requirements, people now have both a small footprint as well as a fully featured browser available. Opera gets very high marks for HTML compatibility, and they have an unreleased Microwindows version as well.
With our Microwindows operating environment product, we've been focusing on getting ViewML working well and running fast enough to run on the small PDAs as well as the larger faster ones. In this way, our product comes with a browser that can be used on any device, and we can always upgrade to Mozilla if the customer has enough RAM.
Rick: What were some of the challenges you faced in developing ViewML, and how did you overcome them? What were some of the design tradeoffs that you needed to make?
Greg: Size constraints were the biggest issue, as was the business of making sure that the browser displayed the pages correctly. Since we didn't want to write a browser from scratch, falling prey to the many other browsers that just can't display pages correctly, we selected the KDE Project's kfm KHTML widget. We selected this HTML display widget with two priorities: first, it displayed pages almost perfectly, and second, it was small and well written. The ViewML Project then proceeded to implement an embedded browser without changing a single line of code in the KHTML widget, thus guaranteeing we couldn't screw it up too badly. We wrote a QTÝFLTK class conversion layer, which allowed us to implement all the user interface and widget controls in less than 100K, and the result was ViewML. Most of the work so far has been on finalizing the implementation of this conversion layer. The other consideration was making sure the browser speed is fast enough for everyday users, and we're still working on TrueType font display enhancements in this area.
Rick: In retrospect, what has it been like leading an open-source project?
Greg: The Microwindows Project wouldn't be what it is today without the generous contribution of some very important technologies, like the scalable font support, countless debugging on a wide variety of systems and considerable discussion on the mailing list. I must say I've had a heck of a lot of fun being its leader. The Open Source community has had a very positive effect by testing my implementations and others' contributions almost immediately after release. Believe me, if it doesn't work, I'll hear about it.
Rick: Unlike Linux, Microwindows isn't released under the GNU General Public License (GPL). Could you comment on the Microwindows license?
Greg: The early Microwindows contributors and I decided to license Microwindows as MPL, which is a looser license than GPL. This means that Microwindows can be used in projects under NDA or where driver source cannot be made available. Although this is contrary to open-source purists, I'm more of a pragmatist, and my real mission is enabling the growth of the embedded industry with graphical applications. In order to do this, you have to have a system that many people can use, and the license should be as generous as possible.
Rick: What new Microwindows features or enhancements are planned for development over the coming year or so?
Greg: Well, we're going to be producing our freely available binary distribution of the Microwindows operating environment for a lot more PDAs that are on the market or are soon to come to market. This will leverage all developers' interest in Microwindows and allow their applications to run on more platforms.
Another very exciting area will be our inroads into the webpad arena. I've got an architecture designed that will allow developers and users to run the same graphical-applications binaries across a large array of flat-panel-enabled devices, which hopefully will enable the continued fast growth we've been seeing in this embedded space. The applications can take a different look and feel depending on whether the device screen is 240x320 or 800x600, as well as 2-D, 3-D and TV-looking controls being implemented by the toolkits.
Rick: Thank you very much!
[Look for Greg's series of articles on Microwindows in our sister publication Embedded Linux Journal in the January/February 2001 issue.]
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Weechat, Irssi's Little Brother
- Tech Tip: Really Simple HTTP Server with Python
- Poul-Henning Kamp: welcome to
40 min 11 sec ago
- This has already been done
41 min 11 sec ago
- Reply to comment | Linux Journal
1 hour 26 min ago
- Welcome to 1998
2 hours 14 min ago
- notifier shortcomings
2 hours 38 min ago
4 hours 15 min ago
- Android User
4 hours 17 min ago
- Reply to comment | Linux Journal
6 hours 10 min ago
8 hours 59 min ago
- This is a good post. This
14 hours 12 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?