一種準確控制外部程序的方法
2023-10-31 00:37:32 2
專利名稱：一種準確控制外部程序的方法
技術領域：
本發明涉及計算機軟體技術，特別是涉及在Unix，Linux下方便快捷地準確控制外部程序的方法。
背景技術：
在現實中經常會出現一個程序控制另一個程序的需求。比如windows下的遙控器應用軟體。控制程序接收遙控器的紅外信號，將其轉換為相應的控制信息，然後再控制其它的外部程序。這樣的過程很象一種通訊機制，也是一種進程間通訊機制。那麼要如何實現這一點呢？在windows下有多種實現方法。以下是一些常用的方法。
1、共享在硬碟上建立一個文件，一個應用程式往該文件裡寫數據(可以不關閉文件，但必須刷新緩衝區)，另一個應用程式以共享方式打開這個文件並讀取其中的內容，這便是最簡單的一種數據交換方式。對於網絡用戶而言，只要兩臺終端上安裝的都是Win311 For Workgroup或Windows 95(或NT)，則只要設置一下目錄共享，映射成網絡驅動器，同樣可以簡單地實現數據交換。但它的缺點也是顯而易見的只能採取輪詢的方式獲得最新數據，因此效率低下，網絡映射的驅動器絕對不能變動或取消，可靠性差，所以這是一種「低級」的通訊方式。
2、DDE每個Windows程式設計師都不會對DDE(動態數據交換)感到陌生，它是最早的基於Windows的數據交換方法，有三種方式可供選擇冷連接、溫連接和熱連接。一般都是由客戶端向伺服器端發出連接申請，並且必須指明伺服器端的名字和標題。在連接建立後，數據可以雙向流動。典型的例子如抓圖軟體SnagIt，它提供了DDE接口，能夠讓其它應用程式來控制它。DDE是完全向後兼容的，從16位平臺轉到32位，原始碼幾乎不用修改。
DDE還有網絡功能。使用過Win311 For Workgroup的人大概都還記得，它自帶一個非常吸引人的小程序「Chat」，能使兩臺計算機通過網絡實時交談，這在當時幾乎是一項創舉。可是很少有人知道「Chat」使用的實際上是一種特殊的DDE，即NetDDE。它的基本工作原理仍然是DDE，但它能使一臺計算機向在同一個網絡中的另一臺終端發消息，而不像普通DDE只能局限在同一臺機器上。與其它的數據交換方式相比，DDE已不夠先進，而且Microsoft也不再積極支持DDE，所以它的前景不被看好。
3、WM_COPYDATAWindows消息WM_COPYDATA功能強大，知之者卻甚少。它的確切定義是一個應用程式向另一個應用程式傳遞數據時所發出的消息。眾所周知，Windows在很大程度上依賴於消息機制，那麼為什麼不把數據放在消息中一起發送出去呢？這樣，只要調用SendMessage，以對方窗體的句柄作為第一個參數，以含有指向實際數據的指針結構的地址作為第二個參數，就可以把整個數據塊當作消息發向另一個應用程式。也許有的程式設計師會說，一個自定義的消息同樣可以完成這樣的工作。他只說對了一半，自定義消息的確可以發送到其它的應用程式上去，但其原始數據所在的內存區只有在發送過程中才是合法的，若在其它模塊中存取該內存區就會導致「AccessViolation」。而使用WM_COPYDATA則不存在這個問題，因為Windows本身會替你處理這一切。深入鑽研下去，就會發現它其實是先創建了一個文件映射的對象，將發送方的原始數據先拷貝至映射文件，然後再在接收方對這個映射文件打開一個「視圖」。WM_COPYDATA的不足之處在於必須要有一個窗體來接收消息和數據，缺乏靈活性，數據在使用之前先得拷貝到一個映射文件，造成資源浪費。
4、NetBIOS
從20世紀80年代開始，NetBIOS就是開發Client/Server類程序的標準接口。而當時其它的解決方案幾乎都是從UNIX系統上發展而來的。當然，對於今天的用戶而言，NetBIOS已不是唯一的選擇，他們可以從各種方案中擇優選取。在Windows 95和NT平臺上，可以通過API函數Netbios來調用NetBIOS功能。
NetBIOS兼容以下幾種低層協議NetBEUI協議(NBF)、NWLinkNetBIOS(NWNBlink)、NetBIOS over TCP/IP(NetBT)。NetBIOS的優點是速度較快，缺點是可靠性較差。
5、標準的Sockets和WinSockSockets是15年前在UNIX系統上提出來的，一開始主要是用於本地通訊，但很快就應用在Client/Server體系上了。它的內核很簡單你可以將一個Socket看作是一個雙向的節點，一個應用程式可以通過它先與另一個程序建立連接(建立在一個雙方都認可的端上，以便於區分同時運行的幾個通訊線程)，然後就可以彼此交換數據了。微軟公司在其基礎上創建了WinSock，專門用於Windows接口，與Socket完全兼容。近年來基於TCP/IP協議的網絡大行其道，Socket也隨之獲得了更加廣泛的應用。
如今，Sockets已在Internet上獲得了最廣泛的應用，主要是因為它的可移植性好Socket應用程式無論在任何平臺間都能互相進行通訊(不管是PC機還是Macintosh，也不管是Windows平臺還是UNIX平臺)。而最新推出的WinSock2.0，已不僅僅只基於TCP/IP協議，還可基於其它幾種傳輸協議(如IPX)。Socket的缺陷是它工作在通訊的低層，所以實現起來較為複雜(如果是Win95或NT平臺，則不存在這個問題，微軟公司提供了相應的控制項)。但是，如果要在多個平臺間互相通訊，則Socket是不二之選。
6、Mailslot和PipeMailslot和Pipe有很多相同點，即都是高層的、基於內存的通訊系統。Mailslot由Server端創建，代碼如下myMailslot＝CreateMailslot(pSlotName，0，MAILSLOT_WAIT_FOREVER，NULL)；然後，Client端就可以像打開文件一樣打開這個Mailslot，再通過API函數WriteFile來將數據寫入到消息隊列中。
與此相類似，Pipe也是由Server端創建的，代碼如下pipe＝CreateNamedPipe(pPipeName，PIPE_ACCESS_DUPLEX，PIPE_TYPE_MESSAGE|PIPE_READMODE_MESSAGE|PIPE_WAIT，PIPE_UNLIMITED_INSTANCES，BUFSIZE，BUFSIZE，20000，NULL)；接著，Client端就可以通過一般的文件API讀寫數據，代碼如下pipe＝CreateFile(pPipeName，GENERIC_READ|GENERIC_WRITE，0，NULL，OPEN_EXISTING，0，NULL)；success＝WriteFile(pipe，pMessage，strlen(pMessage)+1， bytesWritten，NULL)；Pipe分兩種，即命名Pipe和匿名Pipe。匿名Pipe是以句柄而不是以名字來進行標識的，因而也就限制了它只能在同一臺機器上通訊，而不能應用於網絡。命名Pipe則提供了以名字來進行標識，所以能在網絡上的其它任何地方打開它。需要注意的是命名Pipe只能在Win NT而不是Win 95上創建(即Server端)，Client端則可以是任意平臺。
Pipe既可以單向通訊也可以雙向通訊，Mailslot則只能單向通訊。Client端可以發送消息給mailslot，但不能接收消息；如果你想要接收消息，則只能創建一個新的mailslot。但mailslot有一個很大的優點它支持數據廣播。也就是說，若Client端發送一條消息，則整個網絡中的同名對象都能收到。這是因為mailslot的名字的作用域只是在本臺機器上，所以可在不同機器上創建同名的mailslot，當Client端發來消息時則每一臺機上的mailslot都得到了該消息的一份拷貝，並在本機上作出相應的反應。Mailslot的最大缺陷是不可靠，因為它的數據是以數據報格式來傳送的，網絡錯誤或負荷過重都會導致數據丟失。
Pipe雖然較為可靠，但它不能廣播。所以，如果不需要進行廣播，則Pipe是更好的選擇。選擇Mailslot，則要對此後遇到的麻煩有充分的準備。
7、多剪貼板(Clipboard)Windows的剪貼板的出現就是為了實現應用程式間的互相數據交換。Windows提供了一系列的API函數來讓應用程式安全地打開剪貼板，讀寫其中的數據。
剪貼板的缺陷也是顯而易見的當有新的數據放在剪貼板上時，則先前的數據就會被衝掉，而在Windows中用到剪貼板的時候又實在太多了，所以這種方式用於程序間的通訊顯然不夠安全。
8、COM和DCOM公共對象模式(COM)是一種協議，它建立了一個軟體模塊同另一個軟體模塊之間的連接，然後將其描述出來。當這種連接建立起來之後，則兩個模塊之間就可以通過稱為「接口」的機制來進行通訊。COM可以用不同的語言(VB、VC、Delphi)進行編制，又能被其它語言編寫的程序所使用，並且不用理睬通訊雙方實際所處的位置(是在同一臺機上，還是在同一個網絡上的不同機上)。事實上，Internet上有大量的COM控制項可供人們下載使用，其中有相當一部分就是用於應用程式間的相互通訊(甚至是Internet程序間的通訊)，硬碟上能夠看到的大量的。ocx文件其實就是一種COM。
COM對象為外部調用提供了一個標準的界面，COM Client通過創建COMserver的一個實例獲得指針，轉向所需的函數定義處並執行相應的程序。講得通俗一點，也就是先正確定義好COM對象的屬性(Property)，再執行相應的方法(Method)。
DCOM(分布式公共對象模式)是COM在網絡上的一種擴展，它通過把分布式對象間的通訊變成一個實體來實現通訊。
COM如今被微軟公司大力提倡，最著名的有OLE、ActiveX、DirectX和Win95、WinNT的外殼。由於微軟公司目前在軟體業處於霸主地位，所以COM很有可能成為將來的業界標準，其前途也較為看好。但COM的龐大也會使一些經驗豐富的程式設計師望而卻步，他們寧可自己多寫一些代碼以使整個程序更為簡潔、有效而不願使用COM。
以上這些通訊方式都可以用來實現進程間的相互控制。但是都有一定的局限性。比如拿wi ndows消息傳送來舉例，為了說明這種方法，先來了解一下Windows消息驅動的工作機制。Windows的驅動方式是事件驅動，就是不由事件的順序來控制，而是由事件的發生來控制，所有的事件都是無序的，作為一個程式設計師，在編寫程序時，並不知道用戶先按哪個按紐，也不知道程序先觸發哪個消息。程式設計師的任務就是對正在開發的應用程式要發出或要接收的消息進行排序和管理。事件驅動程序設計是密切圍繞消息的產生與處理而展開的，一條消息是關於發生的事件的消息。就是說當你按下界面中的一個按鈕，選擇一個菜單，選擇一個列表的時候都是向windows發出了一個消息，windows會把這個消息正確分配給相應的窗口函數。那麼如果要達到控制其它程序的目的，只要能模擬出控制操作相應的消息即可。但是這樣的做法的缺點是，對於每一個外部程序的控制必須先了解他的消息ID，雖然可以通過一些消息截獲的工具軟體獲得這一信息ID，但還是很麻煩，因為消息ID對於用戶是不可見的。這個問題造成程序很難做得通用。
發明內容
本發明要解決的技術問題是提出一種準確控制外部程序的方法，實現在Unix，Linux下方便快捷地控制外部程序。
本發明的實現方法如下步驟一、由控制程序的一個實例進程一，創建一個管道；步驟二、進程一用Linux的fork函數創建一個子進程進程二；這個子進程會獲得進程一的數據空間，堆和棧的複製品；步驟三、在進程一和進程二之間創建兩個這樣的共享管道，以實現兩個進程間的雙向數據讀寫；步驟四、根據數據流的方向，分別關閉所述兩個進程共享管道的讀端或寫端，僅保留一個讀端和寫端；步驟五、將進程二的讀寫端連接到標準輸入輸出設備上；步驟六、加載需要控制的外部程序到子進程上，以實現控制程序對外部程序的完全控制。
採用本發明，能在Unix，Linux下方便快捷的實現控制外部程序。就可以大量的復用目前已有的程序，提高代碼復用性，節省開發時間，而不用重新編寫，節省了大量的開發成本；由於使用的是久經考驗的程序，提高系統的可靠性。
圖1是本發明所述方法實現向外部程序發送命令的流程；圖2是本發明所述方法實現從外部程序讀出輸出結果的流程；圖3是管道的示意圖；圖4是創建子進程後的管道；圖5是從父進程到子進程的管道；圖6是從子進程到父進程的管道。
具體實施例方式
Unix，Linux下實現進程間通訊的方法主要有以下幾種，管道、消息隊列、信號量和共享存儲。由於管道是極少數可以在幾乎所有的Unix，Linux下都支持的通訊方式，所以用這種方法實現移植性很好。因此本發明採用管道來達到控制的目的。
本發明所述方法的基本步驟如下所述首先，控制程序的一個實例進程一創建一個管道。
進程一用Linux的fork函數創建一個子進程進程二，由於這個子進程會獲得其父進程即進程一的數據空間，堆和棧的複製品，但管道本身不會被複製，因此這個子進程就可以和父進程進程一共享同一個管道。這個管道在每一個進程處都有一個讀端和寫端。根據數據流的方向分別關閉這兩個進程共享管道的讀端或寫端。
僅留下一個讀端和寫端。這樣數據就可以從一個進程中的寫端流向另一個進程的讀端。當需要向子進程寫數據的時候就關閉父進程的讀端和子進程的寫端。反之需要從子進程讀數據的時候就關閉父進程的寫端和子進程的讀端。
在父進程和子進程之間創建兩個這樣的共享管道，就可以實現兩個進程間的雙向數據讀寫。
連接子進程這邊的讀寫端到標準輸入輸出設備上，那麼父進程流向子進程的數據在子進程看來就象從鍵盤輸入的一樣，而子進程輸出到標準輸出設備(一般是屏幕)的數據，父進程可以完全的從管道的讀端獲取。
加載需要控制的外部程序到子進程上，就可以實現控制程序對外部程序的完全控制。
以下結合附圖以及實施例進一步說明本發明的基本思想。
如圖1所示，這是本發明所述方法的一個具體實施例，可以實現控制程序向外部程序發送命令。
第一步，創建父進程的一個管道；第二步，創建一個子進程，子進程會共享父進程的管道；第三步，關閉子進程的寫管道；第四步，將子進程的讀管道連接到標準輸入，利用這個子進程加載要控制的外部程序；第五步，關閉父進程的讀管道；第六步，從父進程的寫管道寫入命令，對於子進程程序來說就和接收鍵盤輸入一樣，從而實現控制外部程序的目的。
如圖2所示，這是本發明所述方法的另一個具體實施例，可以實現控制外部程序，即從外部程序讀出輸出結果。具體步驟如下第一步，創建一個管道；第二步，創建一個子進程，子進程會共享父進程的管道；第三步，關閉子進程的讀管道；第四步，將子進程的寫管道連接到標準輸出，利用這個子進程執行要控制的外部程序；第五步，關閉父進程的寫管道；第六步，從父進程的讀管道讀入外部程序的輸出，父進程可以根據輸出來改變發送的命令流，從而實現控制外部程序的目的。
圖3是管道的示意圖，本發明中關於Linux下管道的實質其實是駐留在內核中的在內部表示的一個合法索引節點，並且不在任何物理文件系統的範圍之內。對管道的讀寫其實就是對內核中這個節點的讀寫，利用這個特性，就可以實現控制外部程序。
圖4是創建子進程後的管道；可以看出，子進程會共享父進程創建的管道，每一個進程都分別有一個該管道的讀埠和一個寫埠。
圖5是從父進程到子進程的管道；如果關閉父進程對於這個管道的讀埠和子進程對於這個管道的寫埠，就可以形成數據只能從父進程流向子進程的管道。再把子進程的標準輸入埠連接到這個管道在子進程那邊的讀埠，那麼從父埠寫入的數據就如同從鍵盤向子進程輸入數據一樣，從而實現模擬鍵盤對子進程的控制。
圖6是從子進程到父進程的管道。如果關閉父進程對於這個管道的寫埠和子進程對於這個管道的讀埠。就可以形成數據只能從子進程流向父進程的管道。再把子進程的標準輸出埠連接到這個管道在子進程那邊的寫埠，那麼從子進程輸出到屏幕的數據就可以完全的從父進程的讀埠讀出，從而使父進程可以得到子進程的所有輸出反饋。
最後所應說明的是以上實施例僅用以說明而非限制本發明的技術方案，儘管參照上述實施例對本發明進行了詳細說明，本領域的普通技術人員應當理解依然可以對本發明進行修改或者等同替換，而不脫離本發明的精神和範圍的任何修改或局部替換，其均應涵蓋在本發明的權利要求範圍當中。
權利要求
1.一種準確控制外部程序的方法，其特徵在於，包括如下步驟步驟一、由控制程序的一個實例進程一，創建一個管道；步驟二、進程一創建一個子進程進程二；步驟三、在進程一和進程二之間創建兩個這樣的共享管道，以實現兩個進程間的雙向數據讀寫；步驟四、根據數據流的方向，分別關閉所述兩個進程共享管道的讀端或寫端，僅保留一個讀端和寫端；步驟五、將進程二的讀寫端連接到標準輸入輸出設備上；步驟六、加載需要控制的外部程序到子進程上，以實現控制程序對外部程序的完全控制。
2.根據權利要求1所述的準確控制外部程序的方法，其特徵在於，向外部程序發送命令時，所述步驟四中包括關閉子進程的寫管道；將子進程的讀管道連接到標準輸入，利用這個子進程加載要控制的外部程序；關閉父進程的讀管道；從父進程的寫管道寫入命令。
3.根據權利要求1所述的準確控制外部程序的方法，其特徵在於，從外部程序讀出輸出結果時，所述步驟四中包括關閉子進程的讀管道；將子進程的寫管道連接到標準輸出，利用這個子進程執行要控制的外部程序；關閉父進程的寫管道；從父進程的讀管道讀入外部程序的輸出。
4.根據權利要求1、2、3之一所述的準確控制外部程序的方法，其特徵在於，所述步驟二中進程一用Linux的fork函數創建一個子進程進程二；所述子進程獲得進程一的數據空間，堆和棧的複製品。
5.根據權利要求1、2、3之一所述的準確控制外部程序的方法，其特徵在於，所述管道為駐留在內核中的在內部表示的一個合法索引節點。
全文摘要
本發明公開了一種準確控制外部程序的方法，包括如下步驟步驟一、由控制程序的一個實例進程一，創建一個管道；步驟二、進程一創建一個子進程進程二；步驟三、在進程一和進程二之間創建兩個這樣的共享管道，以實現兩個進程間的雙向數據讀寫；步驟四、根據數據流的方向，分別關閉所述兩個進程共享管道的讀端或寫端，僅保留一個讀端和寫端；步驟五、將進程二的讀寫端連接到標準輸入輸出設備上；步驟六、加載需要控制的外部程序到子進程上，以實現控制程序對外部程序的完全控制。採用本發明，能在Unix，Linux下方便快捷的實現控制外部程序，就可以大量的復用目前已有的程序，提高代碼復用性，節省開發時間，而不用重新編寫,節省了大量的開發成本。
文檔編號G06F9/52GK1516010SQ0310000
公開日2004年7月28日 申請日期2003年1月2日 優先權日2003年1月2日
發明者邵蘇毅, 陸寬, 柯妍 申請人:聯想(北京)有限公司