操作系统“ Sivelkiriya”:构建程序的示例

哈Ha

这篇文章继续了有关Sivelkiriya OS项目的出版物发行周期。周期的第一篇文章对概念进行了一般性描述,第二篇解释了为什么需要使用该概念,以及产品以何种形式可以看到光线,第三篇描述了体系结构解决方案,第四篇回答了如何协调OS开发人员和开发人员的行动的问题。此模型中的软件。本文将展示一个示例,该示例将一个简单的程序拆分为多个模块,以使其适应新OS的实际情况。

考虑一个经典的示例:一个程序,该程序可让您打开包含位图图像的文件并在屏幕上查看。可以缩放图像,如果其当前尺寸超出屏幕尺寸,请滚动。

在现代操作系统中,此问题通常由具有封闭体系结构的应用程序解决,即该应用程序本身包含所有必需的代码,或者仅主动使用第三方组件。关键是您不能使用应用程序的一部分-您可以按原样启动它,也可以使用其他解决方案。

为了了解如何在Sivelkiriya OS的框架内解决此任务,您首先必须看一下该程序的“内幕”,并了解它的作用和作用原理。以下是程序运行期间出现的实体。

  1. 图像的位置。在经典情况下,它是通过磁盘上文件的路径来描述的。经过更广泛的考虑,本地网络或Internet上的地址也属于此类。但是,这并不能穷尽所有可能性:图像可以位于RAM中,某些程序(例如照片处理器或图形渲染器)的输出中,网页上,聊天或电子邮件中,档案或办公室文档中。尽管事实上所有这些选项在技术上都互不相同并且需要不同的处理,但从用户的角度来看,它们全都用于一个目的:它们指示他要查看的图像位于何处。创建一个允许您在众多选项中进行选择的界面是一项艰巨的任务,但是从概念上讲,这种方法没有任何障碍。而且:没有理由不使用户没有机会查看位于上述任何位置的图像。
  2. 代表存储图像的字节序列。访问该序列的方法将由存储方法确定,但是,从读取这些字节以在屏幕上显示图像的算法的角度来看,差异几乎没有。
  3. 图像文件格式。流行的格式例如是jpeg和gif。最终格式由文件的内容决定:如果jpeg文件被错误地保存为扩展名.gif,则将其解释为gif或完全拒绝对其进行处理的尝试将是短视的。同时,例如,可以通过分析Web服务器发送的文件扩展名或标头来获得有关预期格式的提示。
  4. , ( ) .
  5. . , tiff, . — , gif — .
  6. .
  7. : , , , .
  8. .
  9. ( ) , .
  10. ( ), .

在Sivelkiriya OS中,上面列出的每个实体都是由某个数据接口描述的。这样的表示允许它们在原始模型之外的许多上下文中使用(稍后将进行讨论)。

每个接口由某个对象实现,该对象由某个模块创建。对象方法的代码在生成它的模块的框架内执行。同时,将模块作为单独的应用程序启动是不正确的,因为它们既没有自己的线程,也没有由它们创建的对象之外的内存。如果您需要存储的状态超出了处理单个映像的范围,则可以将其存储在单独的对象中,并根据一般规则通过OS对象接口对其进行访问。

该程序的工作涉及的模块结构可能如下所示:

  1. 第一个模块定义实现“对象位置”接口的对象的行为(图像是对象的特例)。特别是,它确定如何从给定位置访问字节。但是,他可以使用提供直接访问磁盘或网络支持的模块,具体取决于对象的物理位置。
  2. 第二个模块提供对图像字节的直接访问。此外,它根据存储方法(文件扩展名,Web服务器头等)提供有关内容可能类型的提示。
  3. 第三个模块使用有关内容类型的提示和对其字节表示形式的访问来确定内容的实际类型(图像文件格式)。
  4. , ( , , ) ( ) . , : , . — : jpeg .
  5. , , , , . — — , , .
  6. , . , . — , , , , , , , .

当然,除了所描述的模块之外,该程序还可以参与提供附加功能的模块:日志记录,窗口组件的呈现,声音反馈等。

显而易见,这种结构使重用已实现的功能尽可能简单。因此,在系统中安装新的编解码器意味着将在所有上下文和所有程序中自动支持此类图像。不同的模块可以由不同的程序员以不同的语言编写,但是,在此交互模型的框架中,这些差异并不重要。一个和相同的编解码器既可以用于在该界面中将图像加载到屏幕上,又可以在消息传递程序,浏览器,目录查看器等中呈现它们。

对新用例的支持基本进行。例如,添加一些其他界面可以使您支持诸如移至下一个和上一个图像(无论其位置和访问方式如何)或应用过滤器之类的操作。瘦客户端的引入也不是问题:由于数据和通过模块边界的调用是由操作系统控制的,因此可以将昂贵的操作(例如,解码文件的内容和缩放图像)转移到另一台机器上。

由于上述所有模块的原型对于操作系统都是已知的,因此它从系统角度了解它们的需求,并可以采取相应的措施。例如,可以在单独的线程中执行图像缩放操作,以使处理大图像不会阻塞低端计算机上的界面。此外,由于模块不对执行模块的线程做任何假设,因此可以进行其他优化:例如,用户界面线程可以与负责计算(在这种情况下为缩放)的线程分开,只有后者我没有时间在预定的时间内完成工作,并且通过快速重新缩放,甚至可以在其他流中开始以新比例绘制图像。作为一个正在进行渲染的线程,它不再需要完成,它将设法处理信号以完成操作。由于操作系统具有有关所有正在运行的线程的信息,有关计算机处理器的负载和实际功能的信息,因此优化数据可能比单独应用程序的作者根据其执行环境的假设所能提供的数据更有效。

可以以多种方式解决将共同为一个已解决问题提供解决方案的模块链接在一起的问题。例如,很明显,从磁盘上读取文件字节的模块的选择由该部分的文件系统确定,并且在所有访问同一部分的情况下,都将使用相同的模块。负责确定图像格式的模块很可能会安装在系统级别并在所有上下文中使用。当模块发生故障时,可能是一个例外:在这种情况下,操作系统可以搜索与该原型匹配的另一个已安装模块,如果存在,则尝试将其与相同的输入数据一起使用。通过这种方式,错误可以在没有用户干预的情况下进行处理,并且有关错误的数据将被收集,并且如果本机的安全策略允许,则将错误连同必要的相关信息一起传递给问题模块的开发人员。如果某个模块经常出现问题,则操作系统可能决定将其从搜索链中排除,或降低其优先级。

在其他情况下,模块的选择可以由用户定义并存储在配置中。因此,不同的图像缩放模块可以提供不同的渲染样式(缩小时的抗锯齿参数或增加时的像素边界模糊)。取决于上下文,用户可能需要不同的方法(为精确定位而使用清晰的像素边框,为视觉舒适而使用模糊的边框)。

启动模块的方法也可能有所不同。例如,负责渲染图像查看器窗口的模块可以由负责渲染桌面的模块(通过单击桌面上的图形文件)或显示程序启动菜单的模块调用。启动后,窗口模块将加载完成当前任务所需的模块。

此描述仅是实现这种交互方案的基本可能性的说明,不能视为编写图像查看器,操作系统和/或模块的完整说明。

该系列中的先前文章可在此处找到:与以前一样,全文可在项目网站上找到

All Articles