MiniGUl-Threads 和 MiniGUl-Lite 的选择

---

引言

自MiniGUI 从1998年底推出以来,越来越多的人开始选择MiniGUI在Linux上开发实时嵌入式系统。MiniGUI 系统也逐渐成熟，并在各种嵌入式系统中扮演了重要的角色。为了帮助嵌入式软件开发人员使用MiniGUI编写出更好的应用程序﹐我们将撰写一系列文章讲解基于Linux和 MiniGUI 的嵌入式系统软件开发，并冠名"基于Linux和 MiniGUI 的嵌入式系统软件开发指南"。该系列文章将讲述如何在基于Linux的系统上利用MiniGUI开发具有图形用户界面支持的嵌入式系统软件,其内容不仅仅限于MiniGUI的编程,还会涉及到一些Linux下嵌入式系统软件开发的技巧。系列文章的初步规划如下:
①如何针对特定项目选择 MiniGUI-Threads 和 MiniGUI-Lite
②理解消息循环和窗口过程
③对话框和控件编程
④使用GDI函数
⑤MiniGUI_和 Linux系统调用
⑥MiniGUI-Lite与进程间通讯
⑦将MiniGUI及应角程序彦植到特定平台
⑧利用autoconf接口编写跨平台代码
⑨如何调试MiniGUI应用程序
本文是该系列文章的第一篇，将讲述如何针对具体项目选择使用MiniGUI-Threads或者MiniGUI-Lite 版本，并比较不同版本对系统软件结构的影响。

---

一、MiniGUI-Threads和 MiniGUI-Lite 的区别

大家都知道，我们可以将 MiniGUI编译成两个截然不同的版本，一个是
MiniGUI-Threads，一个是 MiniGUI-Lite。这两个版本适用于不同的应用需求。在选择到底使用MiniGUI-Threads 还是 MiniGUI-Lite 之前，我们首先需要了解这两个版本之间的区别。

MiniGUI-Threads 是 MiniGUI的最初版本。MiniGUI最初为一个工业控制系统开发的，该系统功能单一，但却需要非常高的实时性，因此考虑将MiniGUI开发成一个基于多线程的图形用户界面支持系统。因为在传统的UNIX/Linux系统上，典型的GUI系统(比如X)采用传统的基于UNIX套接字的客户/服务器系统结构。在这种体系结构下，客户建立窗口、绘制等等都要通过套接字传递到服务器，由服务器完成实质工作。这样，系统非常依赖于UNIX套接字通讯。而大家都知道，UNIX套接字的数据传递，要经过内核，然后再传递到另外一个程序。这样，大量的数据在客户/内核/服务器之间传递，从而增加了系统负荷，也占用了许多系统资源。这对许多嵌入式系统，尤其是实时性要求非常高的系统来说，是不可接受的。

为了解决这个问题，MiniGUI首先采用了线程机制（类似Windows CE)，所有的应用程序都运行在同一个地址空间，这样，大大提高了程序之间的通讯效率，并且特别适合于实时性要求非常高的系统。这就是MiniGUI-Threads。基于MiniGUI-Threads的程序，可以具有多个线程，每个线程有不同的功能和任务，并且可以建立各自的窗口，不同的线程之间，可以通过 MiniGUI提供的消息传递机制进行事件传送和同步。

但显然,这种基于线程的结构也导致了系统整体的脆弱――如果某个线程因为非法的数据访问而终止运行，则整个进程都将受到影响。不过，这种体系结构对实时控制系统等时间关键的系统来讲，还是非常适合的。
为了解决 MiniGUI-Threads版本因为线程而引入的一些问题，同时也为了让MiniGUI 更加适合于嵌入式系统，我们决定开发一个 MiniGUI-Lite 版本。这个版本的开发目的是:
①保持与原先MiniGUI版本在源代码级99%以上的兼容
②不再使用线程库。
③可以同时运行多个基于MiniGUI-Lite 的应用程序，即多个进程，并且提供前后台进程的切换。

显然，要同时满足上述三个目的，如果采用传统的C/S结构对MiniGUI-Threads进行改造，应该不难实现。但前面提到的传统C/S结构的缺陷却无法避免。经过对PDA等嵌入式系统的分析，我们发现，某些PDA产品具有运行多个任务的能力，但同一时刻在屏幕上进行绘制的程序，一般不会超过两个。因此，只要确保将这两个进程的绘制相互隔离，就不需要采用复杂的C/S结构处理多个进程窗口之间的互相剪切。也就是说，在这种产品中，如果采用基于传统C/S结构的多窗口系统，实际是一种浪费。

有了上述认识，我们对MiniGUI-Threads进行了如下简化设计:
①每个进程维护自己的主窗口Z序,同一进程创建的主窗口之间互相剪切。
也就是说，除这个进程只有一个线程，只有一个消息循环之外，它与原有的MiniGUI版本之间没有任何区别。每个进程在进行屏幕绘制时，不需要考虑其他进程。
②建立一个简单的客户/服务器体系，但确保最小化进程间的数据复制功能。因此，在服务器和客户之间传递的数据仅限于输入设备的输入数据，以及客户和服务器之间的某些请求和响应数据。
③有一个服务器进程(mginit),它负责初始化一些输入设备﹐并且通过UNIXDomain套接字将输入设备的消息发送到前台的MiniGUI-Lite 客户进程。
服务器和客户被分别限定在屏幕的某两个不相交矩形内进行绘制,同一时刻，只能有一个客户及服务器进行屏幕绘制。其他客户可继续运行，但屏幕输入被屏蔽。服务器可以利用API接口将某个客户切换到前台。同时，服务器和客户之间采用信号和 System V信号量进行同步。
④服务器还采用System V IPC机制提供一些资源的共享，包括位图、图标、鼠标、字体等等，以便减少实际内存的消耗。

从传统C/S窗口系统的角度看，MiniGUI-Lite 的这种设计，无法处理达到完整的多窗口支持，这的确是一个结构设计上的不足和缺陷。不过，这实际是
MiniGUI-Lite 不同于其他窗口系统的一个特征。因为处理每个进程之间的互相剪切问题，将导致客户和服务器之间的通讯量大大增加，但实际上在许多嵌入式系统当中这种处理是没有必要的。在类似PDA 的嵌入式系统中，往往各个程序启动后，就独占屏幕进行绘制输出，其他程序根本就没有必要知道它现在的窗口被别的进程剪切了，因为它根本就没有机会输出到屏幕上。所以，在MiniGUI-Lite当中，当一个进程成为最顶层程序时，服务器会保证其输出正常，而当有新的程序成为最顶层程序时，服务器也会保证其他程序不能输出到屏幕上。但这些进程依然在正常执行着，不过，服务器只向最顶层的程序发送外部事件消息。

表1给出了MiniGUI-Threads和 MiniGUI-Lite的区别。从表中总结的区别看来，MiniGUI-Threads适合于功能单一、实时性要求很高的系统，比如工业控制系统;而 MiniGUI-Lite 适合于功能丰富、结构复杂、显示屏幕较小的系统，比如PDA等信息产品。

表1 MiniGUI-Threads和 MiniGUI-Lite 的区别
除上表中列出的不同之外，MiniGUI-Threads和 MiniGUI-Lite 的 API是一致的。

二、MiniGUI-Threads 的典型应用和软件架构

本文介绍的基于 MiniGUI-Threads 典型应用是一个计算机数字控制(CNC)系统。这个系统是由清华大学基于 RT-Linux建立的机床控制系统。该系统使用
MiniGUI-Threads作为图形用户界面支持系统。图1是该CNC系统的用户界面。

图⒉是该系统的架构。在用户层，该系统有三个线程，一个作为GUI主线程存在，另一个作为监视线程监视系统的工作状态，并在该线程建立的窗口上输出状态信息，第三个线程是工作线程，该线程执行加工指令，并通过RT-Linux的实时FIFO和系统的实时模块进行通讯。

三、MiniGUI-Lite 的典型应用和软件架构

这里介绍的典型应用是一个基于MiniGUI-Lite 的 PDA。该PDA 由国内某公司基于Linux开发，其上可以运行各种PIM程序、浏览器以及各种游戏程序。图3是该PDA 的用户界面。

该系统中的所有应用程序都以 Linux进程的形式执行，mginit（即
MiniGUI-Lite)提供了输入法支持和应用程序管理功能。当应用程序之间需要通讯时,可以通过 MiniGUI-Lite 所提供的request/response接口实现。图4是该系统的架构。

总结

本文讲解了MiniGUI-Threads和 MiniGUI-Lite 之间的区别，并举例说明了基于这两个不同版本的不同软件架构。嵌入式程序开发人员必须明白这两个版本之间的区别，并针对具体应用恰当选择使用哪个版本。