图像形成设备、打包方法及程序 【技术领域】
本发明涉及一种图像形成设备，其提供关于图像形成的用户服务，诸如复印、打印、扫描、传真等。本发明尤其涉及一种图像形成设备，其可以吸收应用程序与应用程序所使用的服务之间的版本差异。
背景技术
近来，包括机柜中的打印机、复印机、传真机、扫描仪等的功能的图像形成设备(在下文中称为复合机)是众所周知的。复合机包括机柜中的显示部分、打印部分、图像拾取部分等。在复合机中，提供分别相应于打印机、复印机和传真机的3个软件，从而通过转换软件，使复合机分别起打印机、复印机、扫描仪和传真机的作用。
根据这种传统的复合机，运行应用程序，用于每个功能单元，诸如打印机、复印机、传真机和扫描仪，且每个应用程序有访问硬件资源的函数。这时，假设作为应用程序的基础的操作系统(OS)的版本与复合机中实际使用的OS版本相同。然而，例如，如果升级OS而使OS之间的版本不同，就会出现迄今为止应用程序曾使用的函数变得无法使用地情况，或者应用程序本身变得无法使用。
这样，根据传统的复合机，如果在复合机中升级OS，就要求把应用程序重新编译，从而在升级的OS上操作应用程序。
由于传统的复合机设有单独用于打印机、复印机、扫描仪和传真机的各个软件，所以，开发软件需要很多时间。因而，申请人已经开发出了一种图像形成设备(复合机)，该设备包括硬件资源、多个应用程序、以及包括设在应用程序和硬件资源之间的多种控制服务的平台。硬件资源用于显示部分、打印部分和图像拾取部分中的图像形成处理。应用程序执行打印机、复印机和传真机等的用户服务所固有的处理。平台包括多种控制服务，所述服务在执行用户服务时，进行至少两个应用程序所共同需要的硬件资源的管理、进行应用程序的执行控制、以及图像形成处理。
根据这种新的复合机，分离提供了应用程序和控制服务。这样，在运送复合机之后，用户或第三方供应商可以开发新的应用程序，以安装在复合机上。这样，可以提供多种功能。
由于新的复合机设有与应用程序分离的、用来提供至少两个应用程序所共同要求的服务的控制服务，所以，需要在开发应用程序时，为应用程序和多种控制服务之间的工序间通信编写源代码。
在开发新的应用程序时，需要准确地掌握由每个控制服务所提供的应用程序接口(API：包括函数和事件)，并根据预定的过程编写源代码。然而，如果因排除错误或添加函数等而重复升级API，则由于不清楚应用程序是遵照哪个API版本的，供应商就难以开发出应用程序来。这样，有可能难以开发出应用程序来。另外，有可能为控制服务所开发的应用程序所使用的API版本与复合机中实际使用的控制服务的API版本是不同的。如果在复合机上执行该应用程序，就会发生差错，且应用程序会影响复合机。
这是一个包括固定功能的传统复合机所没有的新问题。
另外，从程序的隐蔽性和系统安全性来看，把控制服务和应用程序之间的所有API都公开给诸如开发新应用程序的第三方供应商的第三方是不合适的。
【发明内容】
本发明的一个目的是提供一种图像形成设备，其中，即使由于控制服务的升级而在应用程序所使用的函数和控制服务中的相应函数之间出现差别，该应用程序也可以执行函数调用而不用重写应用程序的源代码。另外，本发明的一个目的是提供一种图像形成设备，其能隐藏由控制服务所发送的预定消息。
上述目的由图像形成设备来实现，该图像形成设备包括用于进行图像形成的处理的应用程序，和用于根据来自应用程序的函数调用来进行系统一侧的处理的控制服务，该图像形成设备包括：
打包(wrapping)部分，用于转换应用程序所调用的函数，并通过使用转换后的函数，进行控制服务的函数调用。
根据本发明，由于转换了从应用程序调用的函数，并把转换后的函数用于函数调用，所以，即使在应用程序所使用的函数与控制服务中的实际函数不同时，也可以从应用程序来执行函数调用，而不用重写应用程序的源程序。
上述目的也由以下图像形成设备来实现，其包括用于进行图像形成的处理的应用程序，和用于根据来自应用程序的函数调用来进行系统一侧的处理的控制服务，图像形成设备包括：
打包部分，用于从控制服务所发送的消息中选择要发送到应用程序的消息。
根据本发明，可以对第三方隐藏用于访问控制服务的接口。
【附图说明】
结合附图来阅读，从下文的详细描述中，本发明的其它目的、特点和优点将更明了，其中：
图1是根据本发明第一实施例的复合机的框图；
图2显示了根据本发明第一实施例的复合机100的硬件构成的实例；
图3显示了第一实施例的复合机100中VAS 140的构成，以及VAS 140、应用程序、控制服务层150和通用OS 121之间的关系；
图4是用来显示根据本发明的第一实施例，在HD 200中存储的打包信息文件201的实例的图；
图5显示了根据本发明第一实施例的版本管理表210的实例；
图6显示了一个流程图，该流程图显示了根据本发明第一实施例并在其中吸收了版本差异的打包过程；
图7显示了一个表格，其包括表示升级或未升级的信息以及根据本发明第一实施例的升级类型；
图8显示了根据本发明第一实施例，描述用于填充哑变量的VAS 140的实例；
图9是一个流程图，其显示了根据本发明第一实施例由VAS 140进行的打包过程；
图10是一个流程图，其显示了根据本发明第一实施例检查整个版本的过程；
图11是一个流程图，其显示了根据本发明第一实施例，逐函数地检查版本的过程；
图12是本发明第二实施例的复合机的框图；
图13是显示第二实施例的复合机800的VAS 841-848的构成，以及显示根据本发明的第二实施例的VAS 841-848、每个应用程序、控制服务层150与通用OS 121之间的关系的图；
图14A-14C显示了VAS的构成的实例。
【具体实施方式】
在下文中，描述实施例的图像形成设备。
(第一实施例)
图1是根据本发明第一实施例的图像形成设备(下文中称为复合机，图像形成设备也可以称为合成机、多功能机等)的框图。如图1所示，复合机100包括硬件资源和软件组110。硬件资源包括黑白激光打印机(B&W LP)101、彩色激光打印机102、和诸如扫描仪、传真机、硬盘、存储器(RAM、NV-RAM、ROM等)和网络接口的硬件资源103。软件组110包括平台120、应用程序130、和虚拟应用服务140(下文中称为VAS)。
VAS 140设在应用程序130和平台120之间。从应用程序的观点来看，VAS 140被认为是平台120中的服务层，而从服务层的观点来看，被认为是应用程序。另外，VAS 140作为应用程序的服务器进程来操作，和作为每个控制服务的客户端进程来操作。
VAS 140的第一基本性能是吸收由应用程序用来利用控制服务的性能的函数(可称为API)与控制服务所提供的相应函数之间的版本差异。通过使用该性能，即使有版本差异，应用程序也能执行函数调用而不对应用程序重新编译。另外，VAS可以通过选择来自控制服务的消息有意地隐藏平台120。上述性能可称为打包性能。
作为第二基本性能，VAS 140检测应用程序所使用的用于VAS 140的函数的版本与VAS 140中相应函数之间的版本差异，确定每个版本差异是否在VAS 140所支持的范围内。然后，VAS 140把确定结果发送到应用程序，使得应用程序能在应用程序实际操作之前，确定应用程序与VAS之间的版本是否彼此相符。该性能称为版本管理性能。
VAS程序可以存储在例如SD(安全数字)卡中，使得能从SD卡运行VAS程序。另外，可以从包括VAS程序的服务器安装或运行VAS程序。
平台120包括：控制服务，用于解释来自应用程序的处理请求，以发布对硬件资源的获取请求；系统资源管理器(SRM)123，用于管理一个或多个硬件资源和仲裁来自控制服务的获取请求；和通用OS 121。
控制服务包括多个服务模块，即，系统控制服务(SCS)122、引擎控制服务(ECS)124、存储控制服务(MCS)125、操作面板控制服务(OCS)126、传真控制服务(FCS)127、和网络控制服务(NCS)128。另外，平台120有应用程序接口(API)，该应用程序接口可通过使用预定的函数从应用程序130接收处理请求。
通用的OS 121是诸如UNIX的通用操作系统，能同时执行平台120的每一个软件和应用程序130，作为一个进程。
SRM 123的进程用来执行系统的控制和用SCS 122来执行资源的管理。SRM 123的进程对来自上层的使用硬件资源的请求进行仲裁和执行控制，所述硬件资源包括诸如扫描仪部分和打印机部分的引擎、存储器、HDD文件、主I/O(核心(Centronics)I/F、网络I/F IEEE 1394 I/F、RS232C I/F等)。
更具体地说，SRM 123确定所请求的硬件资源是否可用(是否其它请求未使用该资源)，且在所请求的硬件资源可用时，通知上层所请求的硬件资源可用。另外，SRM 123对来自上层的使用硬件资源的请求进行调度，并直接进行相应于请求的处理(例如，打印机引擎进行的纸件传送和图像形成、分配存储区域、文件生成等)。
SCS 122的进程进行应用程序管理、操作部分的控制、系统屏幕的显示、LED显示、资源管理、和中断应用程序控制。
ECS 124的进程控制硬件资源的引擎，所述硬件资源包括黑白激光打印机(B&W LP)101、彩色激光打印机(彩色LP)102、扫描仪、和传真机等。MCS 125的进程获得和释放图像存储的区域，使用硬盘设备(HDD)，并压缩和扩展图像数据。
FCS 127的进程提供API，该API用于通过使用PSTN/ISDN网络从系统控制器的每个应用层发送和接收传真，登记/引用由BKM(备份SRAM)所管理的各种传真数据、传真读取、传真接收和打印、以及混合的发送和接收。
NCS 128是提供通常用于需要网络I/O的应用程序的服务的进程。NCS128把通过协议从网络接收到的数据分发到相应的应用程序，并且在把数据发送到网络时起应用程序和网络之间的调解作用。更具体地说，NCS 128的过程包括诸如ftpd、httpd、1pd、snmpd、telnetd、smtpd的服务器端口监控程序(daemon)，和协议的客户端函数。
OCS 126的进程控制操作面板，操作面板是用来在操作员(用户)和机器的控制部分之间传送信息的装置。在本实施例的复合机100中，OCS 126包括OCS处理部分和OCS函数库部分。OCS处理部分从操作面板获得表示按键被按下的按键事件，把相应于按键事件的按键事件函数发送到SCS 122。OCS函数库登记绘图函数和用来控制操作面板的其它函数，其中绘图函数用于根据来自有控制权的应用程序或控制服务的请求把各种图像输出到操作面板上。在开发了应用程序时，OCS函数库中的函数与通过编译应用程序的源代码文件而产生的目标程序相链接，从而产生应用程序的可执行文件。
应用程序130包括：打印机应用程序111，其是用于有页面描述语言(PDL)和PCL和附录(PS)的打印机的应用程序；复印应用程序112；传真应用程序113，其是用于传真的应用程序；扫描仪应用程序114，其是用于扫描仪的应用程序；网络文件应用程序115；和过程检查应用程序116。在运行每个应用程序时，应用程序把具有其进程的进程ID的应用程序登记请求消息发送到VAS 140。接收应用程序登记请求消息的VAS 140为运行的应用程序进行登记处理。
在应用程序130的进程和控制服务的进程之间执行工序间通信，其中，调用函数、发送返回值、发送和接收消息。通过使用工序间通信，可实现用于图像形成处理的用户服务，诸如复印、打印、扫描和发送传真。
如上所述，第一实施例的复合机100包括多个应用程序130和多个控制服务，它们均作为进程来操作。在每个进程中，产生一个或多个线程，并行执行线程。控制服务为应用程序130提供公共服务。提供关于图像形成的用户服务，诸如复印、打印、扫描和发送传真，同时并行执行多个进程，并行执行线程，执行工序间通信。第三方供应商可以为复合机100开发应用程序117、118，并可以在复合机100中的控制服务层上在应用层中执行应用程序。图1显示了包括新应用程序117和118的实例。
在第一实施例的复合机中，虽然操作应用程序130的多个进程和控制服务的多个进程，但是，每个应用程序和控制服务可以是单独的进程。可以一个一个地添加或删除应用程序130中的应用程序。在第一实施例的复合机100中，除了VAS 140之外，可以采用动态链接库(DLL)。
图2显示了复合机100的硬件构成的实例。
复合机包括控制器160、操作面板175、传真控制单元(FCU)176、和引擎部分177，引擎部分177是硬件资源，诸如专门用于图像形成处理的打印机。控制器160包括CPU 161、系统存储器162、北桥(NB)163、南桥(SB)164、ASIC 166、局部存储器167、HDD 168、网络接口卡(NIC)169、SD卡槽170、USB装置171、IEEE 1394装置172和核心173。存储器162、167可以包括例如RAM和/或ROM。FCU 176和引擎部分177经PCI总线178与控制器中的ASIC 166相连接。CPU 161通过从RAM中读取，来执行安装在复合机100中的应用程序的程序和控制服务等。
图3显示了第一实施例的复合机100中VAS 140的构成，以及VAS 140、应用程序、控制服务层150和通用OS 121之间的关系。虽然图3显示了打印机应用程序111、复印应用程序112、新应用程序117和118作为应用程序130的实例，但是，可以以相同的方式提供其它应用程序。
在虚拟应用服务(VAS)140的进程中，分配器144、控制线程143、打包线程141、和版本管理线程142进行工作。
分配器144监控从应用程序和控制服务接收消息，根据收到的消息，把处理请求发送到控制线程143、打包线程141或版本管理线程142。在第一实施例的复合机100中，当分配器144在应用程序运行时接收应用程序登记请求消息的时候，分配器144把应用程序登记请求消息发送到控制线程143。
控制线程143在从分配器144接收应用程序登记请求消息时执行应用程序登记处理。在应用程序登记处理中，控制线程143在RAM 210中产生应用程序表，并把应用程序ID存储在应用程序登记表中，其中，应用程序ID是发送软件登记请求消息的应用程序的标识符。另外，控制线程143参考存储在HD 200中的打包信息文件201，检查是否为登记的应用程序存储了打包信息。
打包线程141的性能大致如下。
即使在升级控制服务(例如在相应的函数(API)中添加变量)之后不升级在应用程序一侧使用的用于控制服务的函数(API)，打包线程141也可以通过转换从应用程序调用的函数来吸收函数之间的差。
而且，打包线程141能通过参考打包信息文件201，选择从控制服务层150发送到应用程序的消息。因此，可以对第三方供应商隐藏能够大大影响复合机100的系统的接口，从而可以防止直接访问控制服务。这样，可以改善复合机的安全性，可以防止发生故障。
版本管理线程142从控制线程143接收处理请求。另外，版本管理线程142检测应用程序所使用的用于VAS 140的函数的版本和VAS 140中相应的实际函数的版本之间的差异。然后，版本管理线程142通过参考版本管理表211，确定版本差异是否在VAS 140能涵盖的范围之内。
图4是用来显示存储在HD 200中的打包信息文件201的实例的图。如图4所示，打包信息文件201是一个在其中为从控制服务层150发送到应用程序的消息(事件)设定不通知设定的信息文件。可以一个消息一个消息地设定不通知设定，从而对第三方隐藏能大大影响系统的接口。由于如图4所示为事件A和C设定了不通知设定，所以，不把事件发送到应用程序。对于事件B，由于没有设定不通知设定，所以，正常地把事件发送到应用程序。
图5显示了版本管理表210的实例。该表格可以包含在VAS 140的执行文件中，当执行VAS 140时，把该表格存储在例如RAM 210中。为了把表格包括在执行文件中，例如，将包括该表格的信息的包含文件包括在VAS 140的程序中，并编译该程序。另外，可以把该表格准备成文件，和把文件存储在复合机中，从而VAS 140能参考该文件。
如图5所示，版本管理表211包括VAS 140的整个版本号和VAS 140可以支持的应用程序的整个版本范围。例如，VAS 140能涵盖的范围是从当前VAS的版本到预定范围的老版本。
VAS 140的整个版本是指VAS 140所提供的一组函数的版本，应用程序的整个版本是应用程序使用的用于VAS 140的一组函数的版本。应用程序所使用的用于VAS 140的一组函数的版本与在开发应用程序时VAS 140中的那组函数的版本相同。
另外，如图5所示，版本管理表211包括，逐个函数的，VAS 140中的函数的版本和应用程序可以用于VAS 140的函数的版本范围。虽然VAS 140通过使用上述线程执行上述的性能，但是，VAS 140也可以用一个进程来代替多个线程，从而进行上述性能。
在下文中，描述通过复合机100的VAS 140的打包处理和版本管理。先描述打包处理。
图6显示了一个流程图，该流程图显示在其中吸收了版本差异的打包过程。如果在控制服务中升级函数，该函数会因版本不同而与应用程序一侧的相应函数不同。图6显示的过程用于吸收版本差异。
VAS 140有用于每个控制服务的每个函数的信息，表示是否已经升级了函数，如果升级了函数，就表示升级的类型。当产生VAS 140的程序时，该信息可被包括为如图7所示的表格。升级的类型可以是例如函数添加、函数分割、函数删除、函数改变、函数积分、变量添加、变量分割、变量删除等。
在步骤S601，VAS 140通过参考图7所示的信息，检查是否在控制服务中升级了相应于从应用程序调用的函数的函数。如果还没有升级函数，就在步骤S604执行常规处理。如果已经升级了函数，VAS 140就检查升级的类型是不是在步骤S602中的函数分割或变量添加。
如果升级的类型既不是函数分割也不是变量添加，则该类型就是函数删除、函数改变、函数积分等。这种情况下，在控制服务中不存在相应于从应用程序调用的函数的函数，所以无法执行该函数的处理。这样，VAS 140在步骤S605把NG发送到应用程序，并在步骤S606结束该过程。
在步骤S602，如果升级的类型是函数分割或变量添加，就增加控制服务中的函数数量或变量数量。这样，在步骤S603，为增加的函数或增加的变量填充哑函数或哑变量。然后，在步骤S604继续常规处理。图8显示了在其中填充哑变量的VAS描述的实例。如图8所示，把从应用程序接收请求的函数“API_for_Apli_No1(int arg1，int arg2)”转换为包括哑变量“dummy”的函数“API_fir_XCS_No1(arg1，arg2，dummy)”。
即使升级了在其中添加了函数的控制服务，也不改变现有函数。这样，虽然应用程序不能使用添加的函数，但是，该升级不影响应用程序。
下面，描述用来隐藏控制服务的预定的接口的过程。如果把来自控制服务的每个消息(例如事件)发送到应用程序，就可能直接访问大大影响复合机100的系统的控制服务，这对保持复合机的安全性和防止出现故障是不利的。为了解决这一问题，可以预先在打包信息文件201中设定不发送到应用程序的事件。可以以任何方式进行设定。例如，在复合机100之外产生打包信息文件201，然后可以把文件201存储在复合机100中。另外，VAS 140可以显示用来在文件201中设定信息的屏幕，也可以从屏幕设定信息。另外，该信息可以包括在VAS 140的执行文件中。
图9是显示VAS 140的打包过程的流程图。
当从控制服务向应用程序通知消息时，打包线程141在步骤S701参考打包信息文件201，并且打包线程141在步骤S702检查是否为该消息设定了不通知。如果为该消息设定了不通知，则在步骤S703不把该消息发送到应用程序。
如果对该消息的设定不包括在打包信息文件201中或者在步骤S701中没有设定不通知，则在步骤S704把该消息如常发送到应用程序。
如上所述，可以预先设定是否把一个事件发送到应用程序，有可能改善复合机的安全性并预先防止出现故障。另外，由于预定的接口需要公开给诸如开发新应用程序的第三方供应商的第三方，所以，能够选择要公开的接口是非常重要的。
下面，描述用于检查由应用程序所使用的用于VAS 140的函数(API)与VAS 140中的相应函数之间的版本差异的过程。如上所述，VAS 140可以吸收应用程序与控制服务之间的版本差异。然而，由于升级了VAS 140本身等等，所以，应用程序所使用的用于VAS 140的函数的版本可以与VAS 140中的相应函数的版本不同。在下面的方法中，VAS 140检查版本差异，如果VAS 140可以支持版本差异，则应用程序就可以继续常规处理。
对于每个函数来说，应用程序有用于VAS 140的整个版本信息和函数的多个版本。运行应用程序时，用工序间通信把版本信息发送到VAS 140。版本信息可以在产生程序时，被包括在应用程序的执行程序中。
可以在执行应用程序之前的任何时间执行版本检查。在本实施例中，虽然在登记应用程序时执行了版本检查，但是，执行版本检查的时间不限于此。例如，可以通过试验性的运行应用程序来执行版本检查。应用程序的试验性运行是运行只用来执行与VAS 140的工序间通信的应用程序，从而VAS 140能获得应用程序的信息。这种情况下，应用程序配置成可进行试验性运行。
在登记应用程序时，执行下面的处理。
当分配器144从运行的应用程序接收软件登记请求消息时，分配器144把应用程序登记请求消息和进程ID发送到控制线程143。当控制线程143从分配器144收到应用程序登记请求消息和进程ID时，控制线程143确定应用程序ID，用来识别应用程序，并把应用程序ID存储在RAM中的应用程序登记表中，以便进行应用程序登记。预先确定已有应用程序(例如复印应用程序112，打印机应用程序)的应用程序ID，且VAS在内部保留每个应用程序ID。对于第三方供应商等新开发的应用程序，在应用程序第一次运行登记时，确定应用程序ID。
下文中，描述在检查整个版本的情况下和为每个函数检查版本的情况下的版本检查过程。可以只在整个版本的差异不在VAS 140所能支持的范围内时，逐函数地执行版本检查，以代替对每种情况单独执行过程。
首先，参考图10，描述用于整个版本检查的过程。
当VAS 140在步骤S801接收对应用程序登记的请求时，VAS 140在步骤S802从应用程序获得应用程序的整个版本号。VAS 140把应用程序的整个版本号与版本管理表211中的版本支持范围进行比较，并在步骤S803确定应用程序的整个版本是否在支持范围内。例如，假设目前使用的VAS 140可以支持的版本范围为1.0-1.6。这种情况下，如果应用程序的整个版本在1.0-1.6的范围内，则VAS 140就确定整个版本在范围之内。这种情况下，在步骤S804把“OK”发送到应用程序，在步骤S805正确地登记应用程序，并在步骤S806，在复合机100中执行常规处理。如果VAS 140确定应用程序的整个版本在范围之外，则VAS 140就在步骤S807把“NG”发送到应用程序，且该过程在步骤S808结束。
下面，参考图11，描述逐函数地检查版本的程序。
以与图10相同的方式，可以在执行应用程序之前的任何时候执行版本检查。在本实施例中，在登记应用程序时执行版本检查。
当在步骤S901有对应用程序登记的请求时，VAS 140在步骤S902，从应用程序逐函数地获得应用程序所使用的用于VAS 140的函数的版本信息。然后，VAS 140参考版本管理表211。对于应用程序所使用的用于VAS 140的每个函数，VAS 140将应用程序所使用的函数的版本与相应于该函数的支持范围进行比较，从而使VAS 140在步骤S903确定函数的版本是否在支持范围之内。例如，如果应用程序所使用的函数是“2”和“3”，且如果函数的版本分别是“1.1”和“2.0”，则如图5所示，每个函数都在支持范围之内。
在图11所示的处理中，当VAS 140确定每个函数都在支持范围之内时，之后的过程与图10中的步骤S804-S806相同。当VAS确定至少有一个函数不在支持范围之内时，之后的过程与图10中的步骤S807-S808相同。当结果是NG时，VAS 140会在操作面板上显示支持范围之外的函数名。
如果在VAS 140中升级了应用程序不使用的函数，则改变了VAS 140的整个版本。这样，如果只进行整个版本检查，则存在由于整个版本差异而无法执行应用程序的情形。另一方面，如果对应用程序所使用的每个函数进行版本检查，VAS 140就能确定可以执行应用程序，而没有上述情况中的问题。另外，通过逐函数地检查，可以容易地指定VAS 140无法支持的函数。
如上所述，根据第一实施例的复合机100，VAS 140的打包线程141吸收了版本差异。这样，即使升级了控制服务，也不必重新编译应用程序。另外，VAS 140可以选择要从控制服务发送到应用程序的消息。这样，可以对第三方隐藏会大大影响复合机100的系统的接口。
另外，根据第一实施例的复合机100，VAS 140可以通过使用从应用程序获得的版本信息来检查函数的版本。因此，可以安全地执行应用程序。另外，根据第一实施例的复合机100，除VAS 140外可采用动态链接库(DLL)。在这种情况下，可以更有效地吸收应用程序和控制服务之间的版本差异，和可以隐藏接口。这样，可以更确切地隐藏所述接口。
(第二实施例)
第一实施例的复合机100包括一个用于所有应用程序的VAS。根据第二实施例的复合机，为每个应用程序运行多个VAS，其中，每个VAS进行版本管理和打包。
图12是第二实施例的复合机的框图。如图12所示，复合机800与第一实施例的复合机的不同之处在于为每个应用程序操作多个虚拟应用服务。
VAS 841-848进行打印机应用程序111、复印应用程序112、传真应用程序113、扫描仪应用程序114、网络文件应用程序115、和过程检查应用程序116、以及新应用程序117和118的版本管理和打包。
图13是显示第二实施例的复合机800的VAS 841-848的构成的图，还显示了VAS 841-848、每个应用程序、控制服务层150和通用OS 121之间的关系。虽然图13显示打印机应用程序111、复印应用程序112、新应用程序117和118作为应用程序，且以相应的VAS 841、842、847和848作为实例，但是，可以为其它应用程序采用相同的构成。
根据第二实施例的复合机800，与第一实施例的复合机100不同，如图13所示，VAS控制端口监控程序801在VAS和应用程序之间操作。VAS控制进程(端口监控程序)801从每个应用程序接收应用程序登记请求消息，以便进行应用程序登记。另外，VAS控制进程(端口监控程序)801产生请求应用程序登记的VAS 841-848的相应应用程序。另外，VAS控制过程(端口监控程序)801把指令发送到每个线程。
虚拟应用服务(VAS)的每个进程包括分配器144、打包线程141、和版本管理线程142。
分配器144监控来自应用程序和控制服务的消息，根据收到的消息把处理请求发送到打包线程141或版本管理线程142。在第二实施例的复合机800中，分配器144从VAS控制进程801接收具有应用程序的应用程序ID和进程ID的版本管理请求消息或打包请求消息。当分配器144接收版本管理请求消息时，分配器144把版本管理请求消息、应用程序ID、和进程ID发送到版本管理线程142。当分配器144接收打包请求消息时，分配器144把打包请求消息、应用程序ID、和进程ID发送到打包线程141。
每个版本管理线程142和打包线程141的性能与第一实施例中的那些相同。
根据第二实施例的复合机800，可以获得与第一实施例相同的效果。另外，根据第二实施例的复合机800，为每个应用程序运行VAS。这样，可以用相应的VAS并行进行多个应用程序的确定。因此，可以更有效地进行确定。另外，由于可以并行进行用于每个应用程序的版本管理和打包，所以，即使添加或改变了应用程序，也可以有效地进行版本管理和打包。
作为VAS的构成，也可以采用图14A-14C所示的构成。图14A显示了父VAS的子进程用于每个应用程序的情况，其中，父VAS没有屏幕控制权(没有用户界面)。图14B显示了父VAS有屏幕控制权的情况。图14C显示了通过使用线程为每个应用程序提供VAS的函数的情况。
如上所述，根据本发明，提供了一种图像形成设备，该图像形成设备包括用于进行图像形成的处理的应用程序，和用于根据来自应用程序的函数调用进行系统一侧的处理的控制服务，其中，图像形成设备包括打包部分，该打包部分用于转换由应用程序所调用的函数，和通过使用转换后的函数进行对控制服务的函数调用。
根据图像形成设备，由于转换了从应用程序调用的函数，并把转换后的函数用于函数调用，所以，即使在应用程序所使用的函数和控制服务中的实际函数不同时，也可以从应用程序进行函数调用而不重写应用程序的源程序。
在图像形成设备中，其中，如果由应用程序所使用的用于控制服务的函数与控制服务中的相应函数之间有版本差异，则打包部分转换函数。这样，例如，若升级了控制服务一侧的函数，并出现了版本差异，就转换应用程序所调用的函数。相应地，可以防止版本不符所致的故障。
在图像形成设备中，打包部分参考表示已经改变了控制服务中相应函数的版本的信息，确定是否有版本差异。这样，可以正确地确定是否有版本差异。
在图像形成设备中，其中，如果应用程序所使用的用于控制服务的函数和控制服务中的相应函数之间在函数号或变量的数量上有所不同，则打包部分通过添加至少一个哑函数或至少一个变量来转换函数。
通常，如果应用程序所使用的函数和控制服务中的相应函数之间在函数号或变量的数量上有所不同，则应用程序就无法进行函数调用。另一方面，根据本发明，通过在相应于增加的函数或增加的变量的位置添加哑函数或哑变量，应用程序可以执行函数调用。
另外，提供了一种包括打包部分的图像形成设备，所述打包部分用于在控制服务发送的消息中选择要发送到应用程序的消息。
根据本发明，可以对第三方隐藏用来访问控制服务的接口。
在图像形成设备中，打包部分参考表示不应发送到应用程序的预定消息的信息，选择消息。
根据该构成，由于打包部分参考表示不应发送到应用程序的预定消息的信息，所以，可以通过在信息中存储预期的消息，容易地选择必需的消息。
图像形成设备可以包括虚拟应用服务，该服务作为控制服务的客户进程来操作，以及作为应用程序的服务器进程来操作，其中，打包部分包括在虚拟应用服务中。
另外，图像形成设备可以包括：版本检查部分，用于确定应用程序所使用的用于虚拟应用服务的一组函数的版本是否在虚拟应用服务所能支持的预定范围内。这样，版本检查部分可以确定该组的版本是否在虚拟应用服务所支持的范围内。因而，例如通过在实际使用该应用程序之前进行确定，可以确定应用程序是否可以用在虚拟应用服务上，从而可以防止出现故障。
在上述图像形成设备中，版本检查部分从应用程序获得该组函数的版本，并通过参考包括预定范围的信息来确定该版本是否在预定的范围内。这样，可以容易地进行所述该版本是否在预定的范围之内的确定。
图像形成设备可以包括：版本检查部分，用于逐函数地确定由应用程序所使用用于虚拟应用服务的函数的版本是否在虚拟应用服务所能支持的预定的范围之内。因此，由于逐函数地检查了版本，所以，如果升级了应用程序不使用的函数，就可以正确地确定该升级没有影响应用程序的操作。另外，可以容易地指出在支持范围之外的函数。
在上述图像形成设备中，版本检查部分从应用程序获得函数的版本，通过参考包括预定范围的信息，确定该版本是否在预定的范围之内。这样，可以容易地执行确定。
本发明不限于具体公开的实施例，可以不背离本发明的范围而进行变化和修改。