统一的类厂实现 
    扩展的接口描述语言 为 ezCOM 服务器中新功能的实现提供了方便，如脚本语言调用构件对象函数等。 

    和欣操作系统的基本系统服务均使用 ezCOM 技术包装，而且在核心态与用户态统一系统服务的接口，这一点显然不同于以往的许多操作系统。以往的多数操作系统提供两份功能相似的系统服务接口，其中一份给内核模块使用，另一份给用户态模块使用。和欣系统的这一特性使得编写既能运行于核内又能运行于核外的功能模块成为可能。 

    图 2 展示了和欣操作系统中 ezCOM 技术的运行机制。当用户程序调用一个构件时，系统便根据构件的元数据创建一个代理构件，用户程序通过代理构件实现对构件对象的访问。图中虚线框中的部分是系统自动生成的构件运行环境。系统通过对代理构件的管理实现 ezCOM 的种种特性。
 
    6 构件化驱动程序设计 

    自从关于微内核和整体内核的争论开始以来，双方的支持者都在不同的程度上对各自的体系结构进行了改造，但矛盾依然存在。下面提出的基于和欣操作系统的构件化驱动程序模型将尝试解决这一矛盾，确切地说解决途径是在微内核系统和整体内核系统之间寻求一种折衷方案。 

    构件化驱动程序设计方案是使用 ezCOM 构件技术封装驱动程序，每个驱动程序都是一个模块化非常强的构件。这些构件由 DLL 的形式承载，一个 DLL 中可以封装一个或多个驱动程序构件。使用 ezCOM 构件技术封装驱动程序使得驱动程序可继承 ezCOM 的大部分优点，而且也给驱动程序带来了新的特性。构件化驱动程序可以建立符合设备功能和用户理解的接口，这一点不同于类 UINX 系统， UINX 系统的驱动程序都是以文件的接口形式体现。 

    由 ezCOM 技术封装的驱动程序根据功能区分将提供两组接口，一组为系统功能接口；另一组为用户使用接口。系统功能接口是用于从系统角度管理设备驱动程序，完成设备驱动的配置、初始化和启动终止等功能。用户使用接口是用户程序（驱动程序的客户端程序）使用，通过这些接口用户程序可以访问改程序驱动的硬件设备，实现和硬件设备的信息交换。 

    构建设备驱动程序的代码只会使用内核提供的基本系统服务或由这些基本系统服务构建的服务模块，基于这一原则构建的设备驱动程序可以灵活地选择运行环境。具体地说，设备驱动程序可以动态配置到以下几种环境中运行： 1. 在系统内核中运行驱动程序； 2. 在用户进程内运行驱动程序； 3. 在内核外地进程外服务模块运行驱动程序。和欣操作系统的统一系统服务接口和 ezCOM 技术提供的灵活的跨边界构件运行机制保证了构件化设备驱动程序的以上三种运行方式。在图 1 中也可以看到这一点。 

    通过动态配置驱动程序的运行环境，和欣操作系统能够在多种系统性能之间进行选择。如果某一个驱动程序经过长期测试具有很强的稳定性或是系统追求高效率时，可以让驱动程序在核内运行，这时驱动程序调用系统服务就无需再通过 IPC （ inter-process communication ）陷入到内核中，而只需完成一个普通的函数调用过程，这样 IPC 和线程切换耗去的时间都会节省下来，自然效率会大大提高。但是在效率得到提升的同时，系统的稳定性却降低了，由于驱动程序运行在系统内核中，驱动程序的崩溃会对内核造成很严重的影响，甚至会导致内核的崩溃。为了得到较高的稳定性，可以让驱动程序运行于内核外，也就是让驱动程序以后两种方式来运行。 

    驱动程序的后两种运行方式的区别在于是否运行于客户端程序进程内，如果驱动程序只被某个应用使用，则完全可以让其运行在用户进程内，这样用户程序和驱动程序的交互无需通过 IPC ，但是驱动程序的崩溃会影响应用程序。如果驱动程序运行于内核外的进程外服务模块中，虽然效率会受损失，但由于客户端程序和驱动程序运行在不同的地址空间，当然作为客户端的用户程序会更稳定。 

    应当说明的是，驱动程序在上面三种方式下运行，并不需要改变驱动程序的源代码。而客户端程序如果不是特别声明要求驱动程序的运行方式，在驱动程序运行方式发生改变时，客户端程序也不需要修改，这时驱动程序的运行方式是由作为第三方的配置来决定的。 

    和欣操作系统的灵活内核技术和 ezCOM 技术使得构造具有上述的构件化驱动程序成为可能，其实这种模式同样适用于不涉及硬件的服务构件。和欣系统的内核和符合这种模式的服务构件组建起来的系统可以根据具体需要在多种性能之间进行选择，从而部分有效地解决整体内核和微内核之间的矛盾。