多例输入设备控制方法技术

一个可执行的应用程序，该程序实现为一个允许多个应用程序和一个单一的输入设备进行通信的进程。上述这些通过将该输入设备控制程序作为一个进程载入存储器来实现。因此这个可执行程序是一个允许多个应用程序和同一个输入设备接口的服务器。该多例输入设备控制可执行程序响应任何一应用程序的请求，如同输入设备正在为该调用应用程序打开一样。每个应用程序可以和该输入设备实例通信，而不会中断其它正在和同一输入设备通信的应用程序。（*该技术在2020年保护过期，可自由使用*）

【技术实现步骤摘要】

本专利技术涉及摄像机，更具体地说，涉及摄像机与应用程序的接口。以往，当一个应用程序连接到一部摄像机时，其他的程序将被禁止使用这部摄像机。当一个应用程序试图和一部摄像机通信时，它将调用相应的驱动程序文件或动态连接库(DLL，*.dll)文件。通常，一个动态连接库提供一个或多个特殊的函数，一个应用程序通过和该动态连接库(DLL)建立连接来访问这些函数。动态连接库也可以同时包括数据。一些动态连接库也提供有操作系统(如视窗操作系统)，它们可以用于任何操作系统应用程序。其它的动态连接库专门为特殊的应用程序编写，他们和应用程序一起被调入系统(如一个视频控制应用程序)，当一个视频控制应用程序请求连接到一部摄像机时，相应的驱动程序便检查以确保没有其它的应用程序已经打开了该驱动程序文件(*.dll)，如果没有，该驱动程序将打开相应的驱动程序文件。当打开后，通过这个打开的摄像机驱动程序文件，这里便存在了一个在摄像机和相应的应用程序之间的单线程的连接。如附图说明图1所示。如图1中所描述的，驱动程序文件14被驱动程序12打开，驱动程序12被调用应用程序10调用，同时，驱动程序文件14被载入调用应用程序的存储器空间中。由于摄像机驱动程序文件14已经被该应用程序10打开，下一个企图访问该摄像机的应用程序将被禁止访问。这是因为摄像机驱动程序文件已经被调入了第一个应用程序的存储器中，将无法被其它的调用应用程序访问。因此，每一个可能调用一个摄像机的应用程序必须考虑该摄像机已经被其它的应用程序使用的可能性。所以，这样的应用程序将被阻断，因为需要首先检查确定是否其它的首先被执行的应用程序已经连接到了该摄像机，如果其它的首先被执行的应用程序已经连接到了该摄像机，第2个调用应用程序必须有允许它和已经连接到摄像机的应用程序商议摄像机共享的例程。但是，这种共享是单实例的，这意味着在摄像机和第2个应用程序的连接可以被建立之前，摄像机和第1个应用程序之间的连接将不得不被中断(即，第1个应用程序将不得不被终止或者摄像机被关闭)。所有权，优先权，其它相关的安全问题以及适当的错误处理必须通过两个竞争的应用程序间的通信来解决。目前，甚至没用应用程序试图去解决上述任意一个问题，因此，如果一个调用应用程序和摄像机之间的连接不能被建立，异常的应用程序错误被操作系统解决，操作系统发送更加不清楚、不可理解的错误消息，使得最终的用户仅仅被通知一个正确的连接无法被建立。应用程序的大小，适用性和可用性在一直不断地增加，应用程序的发展趋势也已经由向单一的巨大的应用程序发展转变为向由许多小子程序组成的应用程序发展。这种模块化的方法集中了许多优点，如使后续的调整和配置变得很容易。此外，操作系统的供应商同样已经采用了这样的模块化的方法，并提供了许多标准的子程序和对象来处理应用类的功能。如队列化文件到打印机中，载入并运行打印机动态连接库文件来打印文件。这些动态连接库文件本身也是对象或子程序。为了使由不同的高级语言编写的对象和小子程序之间允许相互操作，操作系统的供应商已经开发了可执行程序的模型，这些模型可以在二进制级别上相互兼容。微软公司开发的组件对象模型(COM)便是这样一个二进制码模型。COM使程序员可以开发可以被任何和COM兼容的应用程序访问的对象。尽管将大的单一的应用程序转化为一组小的子程序和对象可以获得很多好处，但这些好处必须和由于需要额外的程序支持这样的子程序和对象之间的进程通信而增加的负担相平衡。除了在实用性和复杂性上的发展，多元的应用程序正在从单一主机上移植到多主机的异构网络环境中。因此，我们也已经听说了这样的单独的应用程序，它由许多由不同高级语言编写的子程序组成，其中每一个子程序位于一台分立的计算机上，而所有这些计算机通过一个网络被连接到一起。在这样的实现中，对高效的网内的和网间的和进程间的通信需求成为了一个新的问题，从程序员编写应用程序的主要任务中分离出来。程序员不得不处理由于将应用程序组件分布到网络中带来的通信问题。再一次，操作系统的供应商们已经意识到了这个挑战和这种潜在的转移，并且以不同的方式致力于它的解决。微软公司已经通过开发分布式组件对象模型(DCOM)扩展了COM的功能。DCOM是COM的一个扩展，用来支持通过网络的对象的分布。除了作为COM的一个扩展，DCOM提供了一个接口用来处理网络通信的细节问题，以便使开发人员将精力集中于他们的主要工作——专用应用程序的开发上，DCOM被设计用来满足企业对分布组件结构的需求。例如，一家公司可能希望建造并采用一个客户订单登记程序，该程序涉及几种不同的功能，如税务计算，客户信用卡核实，货物清单管理，保证说明更新，和订单登记。使用DCOM，该应用程序可以由5个分立的组件建立，运行于一个服务器上，可以通过浏览器进行访问。该程序中的位于不同计算机上的每一个组件访问一个不同的数据库。程序员可以专心于应用程序的开发，而DCOM来处理关于该应用程序的分立组件之间的进程间通信方面的问题。例如，DCOM将处理组件通信和合适的队列的集成，以及在一台服务器上的组件应用程序和基于超文本链接语言(HTML)的因特网应用程序的结合。本专利技术结合了一个可执行程序的特性和对多个应用程序共享单一的输入设备(如摄像机)的需要。一个输入设备如摄像机是一个外部设备，它在响应一个来自应用程序的调用时被打开并一直保持打开状态。本专利技术提供了一个可执行程序，它被实现为一个允许多个应用程序和单一的输入设备通信的进程。通过建立一个虚拟的通向物理输入设备的接口(一个实例)，和将该输入设备控制可执行文件载入一个进程中，上述的专利技术可以被实现。一个实例是一个实际的使用和因此导致的调入存储器的实体的一份拷贝的虚拟建立。该可执行程序进程作为一个服务器，允许多个应用程序和相同的输入设备实现接口。该多例输入设备控制(MIIDC)可执行程序响应每一个应用程序的请求，就好像输入设备正在为该调用应用程序打开一样。这样每一个应用程序就可以和该输入设备实例进行通信。而不必中断其它正在和同样的输入设备进行通信的应用程序。在一个实现中，这个(MIIDC)可执行程序可以是一个DCOM对象。DCOM也可以作为一个允许多个应用程序和单一的输入设备进行通信的接口。这个DCOM接口处理所有的接口操作，例如载入，执行缓冲，卸载以及调用该可执行程序。在基于DCOM的实现中，这个MIIDC对象本身就是一个DCOM服务器，该MIIDC程序在一个体现为可执行服务器的DCOM对象中，通过连接到一个输入设备开始工作。随后，该MIIDC变成了一个体现为可执行程序的DCOM对象，这意味着该MIIDC是一个进程——像任何其他的操作系统(O/S)进程一样——可以被许多应用程序共享。通过将一个输入设备访问程序放入到一个分立的可执行进程中，这个输入设备便可以被多个应用程序所共享。在应用程序看来，这个DCOM接口好像正在仅仅为调用该DCOM对象的应用程序打开，但这时，这里只有一个输入设备的实例。MIIDC被实现以便于对于每一个实际的输入设备，DCOM服务器建立单一的输入设备实例并且连接到该输入设备。当一个应用程序和输入设备控件一一这是一个可执行的DCOM服务器——连接后，该DCOM服务器建立一个MIIDC实例(和一个接本文档来自技高网...

【技术保护点】
一个允许多个客户应用程序同时和单一的输入设备进行通信的输入设备控制程序，其中，所说的输入设备控制程序被作为一个进程载入，所有后续的应用程序呼叫该进程以和所说的这个单一的输入设备建立通信。

【技术特征摘要】
...

【专利技术属性】
技术研发人员：蒂莫西D迪克曼，阿龙D斯坦立奇，
申请(专利权)人：罗技电子股份有限公司，
类型：发明
国别省市：US[美国]