为了帮助更多软件开发人员理解 minigui編辑框及其编程同时帮助更多的自由软件开发人员加入 minigui编辑框 的开发，我们将撰写一系列文章介绍minigui编辑框的体系结构本文是系列文章嘚第一篇，将在整体上对minigui编辑框的体系结构作一介绍其中主要包括：线程的基本概念；基于 POSIX Thread 的微客户/服务器结构；用来同步微客户/服务器动作的关键数据结构?D?D消息队列；面向对象技术在
minigui编辑框 中的应用等等。最后文章展望了我们计划在 minigui编辑框 2.0 版开发中采用的体系结構。
到目前为止minigui编辑框 的最新发布版本是 0.9.96。我们将 0.9.xx系列版本定位为 minigui编辑框 1.0 版本的预览版在 0.9.xx版本足够稳定时，我们将发布 minigui编辑框 1.0版本哃时，目前的代码不会再进行重大调整在 minigui编辑框 1.0版本发布之后，我们将立即着手开发 minigui编辑框
2.0版本该版本预期将在体系结构上进行重大調整。为了吸引更多的自由软件程序员加入minigui编辑框 2.0 的开发也为了更好地帮助 minigui编辑框程序员进行程序开发，我们将撰写一系列的文章介绍 minigui編辑框 1.0版本的体系结构重点分析其中的一些缺点以及需要在 2.0版本当中进行优化和改造的地方。介绍体系结构的文章计划如下：
- 体系结构概览（本文）将在整体上对 minigui编辑框 1.0的体系结构进行介绍。重点包括：线程的基本概念；多线程的微客户/服务器体系、多线程通讯的关键數据结构?D?D消息队列；面向对象技术在minigui编辑框 中的应用等等
- minigui编辑框 的多窗口管理。将介绍 minigui编辑框的多窗口机制以及相关的窗口类技术其中涉及到窗口剪切处理和 Z序，消息传递控件类设计和输入法模块设计等等。
- minigui编辑框 的图形设备管理重点介绍 minigui编辑框是如何处理窗ロ绘制的。其中主要包括图形上下文的概念坐标映射，图形上下文的局部、全局和有效剪切域的概念等等
- 图形抽象层和输入抽象层。圖形抽象层（GAL）和输入抽象层（IAL）大大提高了minigui编辑框的可移植性并将底层图形设备和上层接口分离开来。这里将重点介绍minigui编辑框 的 GAL 和 IAL 接ロ并以 EP7211等嵌入式系统为例，说明如何将 minigui编辑框 移植到新的嵌入式平台上
- 多字体和多字符集支持。minigui编辑框采用逻辑字体实现多字体和多芓符集处理这一技术成功应用了面向对象技术，通过单一的逻辑接口可以实现对各种字符集以及各种字体的支持。
minigui编辑框 是一个基于線程的窗口系统为了理解 minigui编辑框的体系结构，我们有必要首先对线程作一番了解
线程通常被定义为一个进程中代码的不同执行路线。吔就是说一个进程中，可以有多个不同的代码路线在同时执行例如，常见的字处理程序中主线程处理用户输入，而其他并行运行的線程在必要时可在后台保存用户的文档我们也可以说线程是“轻量级进程”。在Linux
中每个进程由五个基本的部分组成：代码、数据、栈、文件I/O和信号表。因此系统对进程的处理要花费更多的开支，尤其在进行进程调度和任务切换时从这个意义上，我们可以将一般的进程理解为重量级进程在重量级进程之间，如果需要共享信息一般只能采用管道或者共享内存的方式实现。如果重量级进程通过fork() 派生了孓进程则父子进程之间只有代码是共享的。
而我们这里提到的线程则通过共享一些基本部分而减轻了部分系统开支。通过共享这些基夲组成部分可以大大提高任务切换效率，同时数据的共享也不再困难?D?D因为几乎所有的东西都可以共享
从实现方式上划分，线程有兩种类型：“用户级线程”和“内核级线程”
用户线程指不需要内核支持而在用户程序中实现的线程，这种线程甚至在象DOS这样的操作系統中也可实现但线程的调度需要用户程序完成，这有些类似Windows
3.x的协作式多任务另外一种则需要内核的参与，由内核完成线程的调度这兩种模型各有其好处和缺点。用户线程不需要额外的内核开支但是当一个线程因I/O而处于等待状态时，整个进程就会被调度程序切换为等待状态其他线程得不到运行的机会；而内核线程则没有各个限制，但却占用了更多的系统开支
Linux 支持内核级的多线程，同时也可以从 Internet 仩下载一些Linux
上的用户级的线程库。Linux的内核线程和其他操作系统的内核实现不同前者更好一些。大多数操作系统单独定义线程从而增加叻内核和调度程序的复杂性；而Linux则将线程定义为“执行上下文”，它实际只是进程的另外一个执行上下文而已这样，Linux内核只需区分进程只需要一个进程/线程数组，而调度程序仍然是进程的调度程序Linux的 clone 系统调用可用来建立新的线程。
POSIX 标准定义了线程操作的 C 语言接口我們可以将 POSIX线程的接口划分如下：
- 线程的建立和销毁。用来创建线程取消线程，制造线程取消点等等
- 互斥量操作接口。提供基本的共享對象互斥访问机制
- 信号量操作接口。提供基本的基于信号量的同步机制不能与 System VIPC 机制的信号量相混淆。
- 条件量操作接口提供基本的基於条件量的同步机制。尽管信号量和条件量均可以划分为同步机制但条件量比信号量更为灵活一些，比如可以进行广播设置等待超时等等。但条件量的操作比较复杂
- 信号操作接口。处理线程间的信号发送和线程信号掩码
- 其他。包括线程局部存储、一次性函数等等
目前，Linux 上兼容 POSIX 的线程库称为 LinuxThreads它已经作为glibc 的一部分而发布。这些函数的名称均以 pthread_开头（信号量操作函数以 sem_ 开头）
为了对线程有一些感性認识，我们在这里举两个例子
第一个例子在进入 main () 函数之后，调用 pthread_create函数建立了另一个线程pthread_create的参数主要有两个，一个是新线程的入口函数（thread_entry）另一个是传递给入口函数的参数（data），而新线程的标识符通过引用参数返回（new_thread）见清单1。
清单 1 新线程的创建
main () 函数在建立了新线程の后调用 pthread_join函数等待新线程执行结束。pthread_join 类似进程级的 wait系统调用当所等待的线程执行结束之后，该函数返回利用 pthread_join可用来实现一些简单的線程同步。注意在上面的例子中我们忽略了函数调用返回值的错误检查。
第二个例子是利用信号量进行同步的两个线程这里所使用的唎子利用信号量解决了经典的“生产者/消费者”问题（清单2）。我们首先解释信号量的基本概念
信号量的概念由 E. W. Dijkstra 于 1965年首次提出。信号量實际是一个整数进程（也可以是线程）在信号量上的操作分两种，一种称为DOWN而另外一种称为 UP。DOWN 操作的结果是让信号量的值减 1UP操作的結果是让信号量的值加1。在进行实际的操作之前进程首先检查信号量的当前值，如果当前值大于0则可以执行 DOWN
操作，否则进程休眠等待其他进程在该信号量上的UP 操作，因为其他进程的 UP 操作将让信号量的值增加从而它的 DOWN操作可以成功完成。某信号量在经过某个进程的成功操作之后其他休眠在该信号量上的进程就有可能成功完成自己的操作，这时系统负责检查休眠进程是否可以完成自己的操作。
为了悝解信号量我们想象某机票定购系统。最初旅客在定票时一般有足够的票数可以满足定票量。当剩余的机票数为1而某个旅客现在需偠定两张票时，就无法满足该顾客的需求这时售票小姐让这个旅客留下他的电话号码，如果其他人退票就可以优先让这个旅客定票。洳果最终有人退票则售票小姐打电话通知上述要定两张票的旅客，这时该旅客就能够定到自己的票。
我们可以将旅客看成是进程而萣票可看成是信号量上的 DOWN操作，退票可看成是信号量上的 UP操作而信号量的初始值为机票总数，售票小姐则相当于操作系统的信号量管理器由她（操作系统）决定旅客（进程）能不能完成操作，并且在新的条件成熟时负责通知（唤醒）登记的（休眠的）旅客（进程）。
茬操作系统中信号量的最简单形式是一个整数，多个进程可检查并设置信号量的值这种检查并设置操作是不可被中断的，也称为“原孓”操作检查并设置操作的结果是信号量的当前值和设置值相加的结果，该设置值可以是正值也可以是负值。根据检查和设置操作的結果进行操作的进程可能会进入休眠状态，而当其他进程完成自己的检查并设置操作后由系统检查前一个休眠进程是否可以在新信号量值的条件下完成相应的检查和设置操作。这样通过信号量，就可以协调多个进程的操作
信号量可用来实现所谓的“关键段”。关键段指同一时刻只能有一个进程执行其中代码的代码段也可用信号量解决经典的“生产者/消费者”问题，“生产者/消费者”问题和上述的萣票问题类似这一问题可以描述如下：
两个进程共享一个公共的、固定大小的缓冲区。其中的一个进程即生产者，向缓冲区放入信息另外一个进程，即消费者从缓冲区中取走信息（该问题也可以一般化为m 个生产者和
n个消费者）。当生产者向缓冲区放入信息时如果緩冲区是满的，则生产者进入休眠而当消费者从缓冲区中拿走信息后，可唤醒生产者；当消费者从缓冲区中取信息时如果缓冲区为空，则消费者进入休眠而当生产者向缓冲区写入信息后，可唤醒消费者
清单 2 中的例子实际是“生产者/消费者”问题的线程版本。
清单 2 利鼡信号量解决“生产者/消费者”问题
/* 在缓冲区中保存一个整数 */
/* 从缓冲区读取并删除数据 */
/* 测试程序: 一个线程插入 1 到 10000 的整数另一个线程读取並打印。*/
/* 建立生产者和消费者线程*/
/* 等待生产者和消费者结束。 */
在清单 2中程序首先建立了两个线程分别扮演生产者和消费者的角色。生產者负责将1 到 1000的整数写入缓冲区而消费者负责从同一个缓冲区中读取并删除由生产者写入的整数。因为生产者和消费者是两个同时运行嘚线程并且要使用同一个缓冲区进行数据交换，因此必须利用一种机制进行同步清单2 中的程序就利用信号量实现了同步。
起初程序初始化了两个信号量（init()函数）分别表示可读取的元素数目（sem_read）和可写入的空位个数（sem_write），并分别初始化为0 和缓冲区大小减1在生产者调用 put() 函数写入时，它首先对sem_write 进行DOWN 操作（即 sem_wait调用）看是否能够写入，如果此时 sem_write 信号量的值大于零则sem_wait
可以立即返回，否则生产者将在该 sem_write信号量仩等待生产者在将数据写入之后，在 sem_read 信号量上进行 UP操作（即sem_post调用）此时如果有消费者等待在 sem_read信号量上，则可以被系统唤醒而继续运行消费者线程的操作恰恰相反，该线程调用get() 函数时首先在 sem_read 上进行 DOWN操作，当读取数据并删除之后在 sem_write
信号量上进行 UP 操作。
通过上面的两个唎子读者可以对线程之间的互操作有一个大概了解。如果读者对System V IPC机制比较熟悉的话也可以作一番比较。可以看到多线程的最大好处昰，除堆栈之外几乎所有的数据均是共享的，因此线程间的通讯效率最高；但最大坏处是因为共享所有数据，从而非常容易导致线程の间互相破坏数据
minigui编辑框 1.0 版本采用了多线程机制，也就是说minigui编辑框 以及运行在minigui编辑框之上的所有应用程序均运行在同一个地址空间之內。比起其他基于进程的GUI 系统来说虽然缺少了地址保护，但运行效率却是最高的
3.1 多线程的分层设计
从整体结构上看，minigui编辑框 是分层设計的层次结构见图1。在最底层GAL 和 IAL提供底层图形接口以及鼠标和键盘的驱动；中间层是 minigui编辑框的核心层，其中包括了窗口系统必不可少嘚各个模块；最顶层是API即编程接口。
minigui编辑框本身运行在多线程模式下它的许多模块都以单独的线程运行，同时minigui编辑框还利用线程来支持多窗口。从本质上讲每个线程有一个消息队列，消息队列是实现线程数据交换和同步的关键数据接口一个线程向消息队列中发送消息，而另一个线程从这个消息队列中获取消息同一个线程中创建的窗口可共享同一个消息队列。利用消息队列和多线程之间的同步机淛可以实现下面要讲到的微客户/服务器机制。
多线程有其一定的好处但不方便的是不同的线程共享了同一个地址空间，因此客户线程可能会破坏系统服务器线程的数据，但有一个重要的优势是由于共享地址空间，线程之间就没有额外的数据复制开销
由于 minigui编辑框是媔向嵌入式或实时控制系统的，因此这种应用环境下的应用程序往往具有单一的功能，从而使得采用多线程而非多进程模式实现图形界媔有了一定的实际意义也更加符合minigui编辑框 之“mini”的特色。
3.2 微客户/服务器结构
在多线程环境中与多进程间的通讯机制类似，线程之间也囿交互和同步的需求比如，用来管理窗口的线程维持全局的窗口列表而其他线程不能直接修改这些全局的数据结构，而必须依据“先來先服务”的原则依次处理每个线程的请求，这就是一般性的客户/服务器模式minigui编辑框利用线程之间的同步操作实现了客户线程和服务器线程之间的微客户/服务器机制，之所以这样命名是因为客户和服务器是同一进程中的不同线程。
微客户/服务器机制的核心实现主要集Φ在消息队列数据结构上比如，minigui编辑框中的 desktop 微服务器管理窗口的创建和销毁当一个线程要求 desktop微服务器建立一个窗口时，该线程首先在 desktop嘚消息队列中放置一条消息然后进入休眠状态而等待 desktop处理这一请求，当
desktop处理完成当前任务之后或正处于休眠状态时，它可以立即处理這一请求请求处理完成时，desktop将唤醒等待的线程并返回一个处理结果。
当 minigui编辑框 在初始化全局数据结构以及各个模块之后minigui编辑框要启動几个重要的微服务器，它们分别完成不同的系统任务：
- desktop 用于管理 minigui编辑框窗口中的所有主窗口包括建立、销毁、显示、隐藏、修改Z-order、获嘚输入焦点等等。
- parsor 线程用来从IAL中收集鼠标和键盘事件并将收集到的事件转换为消息而邮寄给 desktop服务器。
- timer 线程用来触发定时器事件该线程啟动时首先设置 Linux定时器，然后等待 desktop 线程的结束即处于休眠状态。当接收到SIGALRM 信号时该线程处理该信号并向 desktop服务器发送定时器消息。当 desktop 接收到定时器消息时desktop会查看当前窗口的定时器列表，如果某个定时器过期则会向该定时器所属的窗口发送定时器消息。
4多线程通讯的关鍵数据结构――消息队列
4.1 消息和消息循环
在任何 GUI系统中均有事件或消息驱动的概念。在minigui编辑框中我们使用消息驱动作为应用程序的创建构架。
在消息驱动的应用程序中计算机外设发生的事件，例如键盘键的敲击、鼠标键的按击等都由支持系统收集，将其以事先的约萣格式翻译为特定的消息应用程序一般包含有自己的消息队列，系统将消息发送到应用程序的消息队列中应用程序可以建立一个循环，在这个循环中读取消息并处理消息直到特定的消息传来为止。这样的循环称为消息循环一般地，消息由代表消息的一个整型数和消息的附加参数组成
应用程序一般要提供一个处理消息的标准函数。在消息循环中系统可以调用此函数，应用程序在此函数中处理相应嘚消息
图 2 是一个消息驱动的应用程序的简单构架示意。
图 2 消息驱动的应用程序的简单构架
minigui编辑框支持如下几种消息的传递机制这些机淛为多线程环境下的窗口间通讯提供了基本途径：
- 通过 PostMessage发送。消息发送到消息队列后立即返回这种发送方式称为“邮寄”消息。如果消息队列中的邮寄消息缓冲区已满则该函数返回错误值。
- 通过 PostSyncMessage发送该函数用来向不同于调用该函数的线程消息队列邮寄消息，并且只有該消息被处理之后该函数才能返回，因此这种消息称为“同步消息”
- 通过 SendMessage发送。该函数可以向任意一个窗口发送消息消息处理完成の后，该函数返回如果目标窗口所在线程和调用线程是同一个线程，该函数直接调用窗口过程如果处于不同的线程，则利用 PostSyncMessage 函数发送哃步消息
- 通过 SendNotifyMessage发送。该函数向指定的窗口发送通知消息将消息放入消息队列后立即返回。由于这种消息和邮寄消息不同是不允许丢夨的，因此系统以链表的形式处理这种消息。
- 通过 SendAsyncMessage发送利用该函数发送的消息称为“异步消息”，系统直接调用目标窗口的窗口过程
读者可以联系我们在第1节中给出的“生产者/消费者”问题而想到一个简单的消息队列的实现，该消息队列可以简单地设计为一个类似清單2 的循环队列但是，GUI系统中的消息队列并不能是一个简单的循环队列它还要注意到如下一些问题：
- 消息一般附带有相关的数据，这些數据对各种消息具有不同的含义在多窗口环境，尤其是多进程环境下消息数据的有效传递非常重要。
-
消息作为窗口间进行数据交换的┅种方式要提供多种传递机制。某些情况下发送消息的窗口要等到这个消息处理完成之后，知道处理的结果之后才能继续执行；而有些情况下发送消息的窗口只是简单地向接收消息的窗口通知某些事件的发生，一般发送出消息之后就返回后一种情况类似于邮寄信件，所以通常称为邮寄消息更有一种较为复杂的情况，就是等待一个可能长时间无法被处理的消息时发送的消息的窗口设置一个超时值，以便能够在消息得不到及时处理的情况下能够恢复执行
- 某些特殊消息的处理也需要注意，比如定时器当某个定时器的频率很高，而處理这个定时器的窗口的反应速度又很慢这时如果采用邮寄消息或者发送消息的方式，线性的循环队列最终就会塞满
- 最后一个问题是消息优先级的问题。一般情况下要考虑优先处理鼠标或键盘的输入消息，其次才是重绘和定时器等消息
- 特殊消息的处理。由于窗口重繪消息的特殊性（通常比较花费时间）只有当程序将其他消息处理之后，才会处理重绘消息并且只有存在窗口的无效区域的时候，才會通知程序处理窗口的重绘
鉴于以上要特殊考虑的问题，minigui编辑框 中的消息队列要比清单 2中的循环队列复杂参见清单 3。
可以看出在 minigui编輯框的消息队列定义中，只有邮寄消息的定义类似清单 2中的线性循环队列上面提到，通知消息类似邮寄消息但该消息是不允许丢失的，因此该消息通过链表形式实现。PMSG结构的定义也很简单：
用于同步消息传递的数据结构为SYNCMSG该结构在消息队列中也形成了一个链表，但該结构本身稍微复杂一些：
可以看到该结构中有一个信号量，该信号量就是用来通知同步消息的发送线程的当接收并处理同步消息的線程处理该消息之后，将在retval 成员中存放处理结果然后通过 sem_handle信号量唤醒同步消息的发送线程。
在上述消息队列结构的定义中还有两个分別用来实现互斥访问和同步的成员，即互斥锁lock 和信号量 wait互斥锁 lock用来实现不同线程对消息队列的互斥访问，比如在获取邮寄消息时的操作洳下：
信号量 wait用来同步消息循环一般来说，一个线程在建立窗口之后要进入消息循环持续地从消息队列中获取消息（通过GetMessage()函数）。当消息队列中没有任何消息时该线程将进入休眠状态，而当其他线程将消息邮寄或发送到该消息队列之后将通过信号量wait 唤醒该线程：
在 minigui編辑框的消息队列结构中，第一个成员是消息队列的状态字该状态字通过标志位表示如下状态：
- 消息队列中是否有邮寄消息；
- 消息队列Φ是否有通知消息；
- 消息队列中是否有同步消息；
- 消息队列中是否有退出消息；
- 消息队列中是否有重绘消息；
- 消息队列中是否有定时器消息。
通过这些标志GetMessage()可判断是否需要检查邮寄消息队列、通知消息链表和同步消息链表等等。同时利用这些标志还可以处理上面提到的┅些特殊消息。这里以定时器为例进行说明
在 minigui编辑框中，一个创建了窗口的线程一般拥有一个消息队列使用该消息队列所有窗口，包括子窗口在内一共可以建立8个定时器。这些定时器是否到期体现在消息队列的状态字上?D?D状态字的最低8 位分别用来表示这 8个定时器昰否到期。消息队列中同时还有三个成员：
其中 TimerMask 表示当前有效的定时器每位表示一个定时器；TimerID表示这 8 个定时器的标识符（整数）；而 TimerOwner则表示定时器的所有者（窗口句柄）。这种定时器的实现方法类似
Linux内核中的信号实现定时器是否有效以及是否到期均由二进制字节的一个位来表示。当GetMessage检查这些标志时发现有某个定时器到期才会获得一个定时器消息也就是说，定时器消息是不排队的这样就解决了排队时鈳能塞满消息队列的问题。
5 面向对象技术在 minigui编辑框中的应用
minigui编辑框中的每个控件都属于某种子窗口类是对应子窗口类的实例。这类似于媔向对象技术中类和对象的关系图3 给出了 minigui编辑框 中控件和控件类之间的关系。
图 3 控件类和控件之间的关系
每个控件的消息实际都是有该控件所属控件类的回调函数处理的从而可以让每个属于统一控件类的控件均保持有相同的用户界面和处理行为。
但是如果我们在调用某个控件类的回调函数之前，首先调用自己定义的某个回调函数的话我们就可以让该控件重载控件类的某些处理行为，从而让该控件一方面继承控件类的大部分处理行为另一方面又具有自己的特殊行为。这实际就是面向对象中的继承和派生比如，一般的编辑框会接收所有的键盘输入当我们希望自己的编辑框只接收数字时，就可以用这种办法屏蔽非数字的字符输入
IAL）的概念。抽象层的概念类似Linux内核虛拟文件系统的概念它定义了一组不依赖于任何特殊硬件的抽象接口，所有顶层的图形操作和输入处理都建立在抽象接口之上而用于實现这一抽象接口的底层代码称为“图形引擎”或“输入引擎”，类似操作系统中的驱动程序这实际是一种面向对象的程序结构。利用GAL 囷 IALminigui编辑框 可以在许多图形引擎上运行，比如 SVGALib
和LibGGI并且可以非常方便地将 minigui编辑框 移植到其他 POSIX系统上，只需要根据我们的抽象层接口实现新嘚图形引擎即可目前，我们已经编写了基于SVGALib 和 LibGGI 的图形引擎利用 LibGGI， minigui编辑框应用程序可以运行在 X Window上将大大方便应用程序的调试。我们目湔正在进行 minigui编辑框私有图形引擎的设计开发通过
minigui编辑框的私有图形引擎，我们可以最大程度地针对窗口系统对图形引擎进行优化最终提高系统的图形性能和效率。
GAL 和 IAL 的结构是一样的我们这里只拿 GAL作为实例说明面向对象技术的运用，参见图 4
系统维护一个已注册图形引擎数组，保存每个图形引擎数据结构的指针系统利用一个指针保存当前使用的图形引擎。一般而言系统中至少有两个图形引擎，一个昰“哑”图形引擎不进行任何实际的图形输出；一个是实际要使用的图形引擎，比如LibGGI
或者SVGALib每个图形引擎的数据结构定义了该图形引擎嘚一些信息，比如标识符、属性等更重要的是，它实现了GAL所定义的各个接口包括初始化和终止、图形上下文管理、画点处理函数、画線处理函数、矩形框填充函数、调色板函数等等。
如果在某个实际项目中所使用的图形硬件比较特殊现有的图形引擎均不支持。这时峩们就可以安照GAL 所定义的接口实现自己的图形引擎，并指定 minigui编辑框使用这种私有的图形引擎即可这种软件技术实际就是面向对象多态性嘚具体体现。
利用 GAL 和 IAL大大提高了 minigui编辑框的可移植性，并且使得程序的开发和调试变得更加容易我们可以在 XWindow 上开发和调试自己的 minigui编辑框 程序，通过重新编译就可以让minigui编辑框 应用程序运行在特殊的嵌入式硬件平台上
5.3 字符集和字体支持
在成功引入 GAL 和
IAL之后，我们又在处理字体囷字符集的模块当中引入了逻辑字体的概念逻辑字体是minigui编辑框用来处理文本（包括文本输出和文本分析）的顶层接口。逻辑字体接口将各种不同的字体（比如宋体、黑体和揩体）和字体格式（比如等宽字体、变宽字体等光栅字体和TrueType等矢量字体）以及各种不同字符集（ISO-8859、GB2312、Big5、UNICODE等）综合了起来，从而可以通过统一的接口显示不同字符集的不同字体的文本并且还可以分析各种字符集文本的组成，比如字符、單词等在多字体和多字符集的支持中，我们也采用了面向对象的软件技术使得添加新的字体支持和新的字符集支持非常方便。目前minigui編辑框能够支持各种光栅字体和
相对 GAL 和 IAL 而言，minigui编辑框中的字符集和字体支持更加复杂涉及到的内容也较多。前面提到我们通过逻辑字體这一接口，实现了文字输出和文本分析两个功能实际这两个功能是相互关联的。在进行文本输出时尤其在处理多字节字符集，比如GB2312 戓者 Big5时首先要对文本进行分析，以便判断是否是一个属于该字符集的双字节字符
图 5 给出了逻辑字体、设备字体以及字符集之间的关系。
图 5 逻辑字体以及相关数据结构
尽管 minigui编辑框采用多线程机制实现了一个小巧、高效的窗口系统但有很多理由希望minigui编辑框能够采用多进程機制实现（尽管多进程机制可能带来通讯上的额外开支）：
- 良好的地址保护。窗口本身的崩溃不会影响 minigui编辑框的运行而目前的多线程机淛无法提供地址保护。
- 信号处理上的问题在多线程程序中，所有的多线程共享同一个信号处理方式包括是否忽略、是否捕获等等。这對某些大型软件是很难接受的
- 多线程程序对程序员要求较高。在编写多线程程序时通常要考虑到函数的“线程安全”问题，即函数是否是可重入的因此，我们通常不能使用全局或者静态变量
鉴于上述需求，我们将在接下来的 minigui编辑框 2.0开发中进行一些体系结构上的调整，其中最为重要的就是采用进程机制替代线程机制
