Windows服務編寫原理及探討【2】

（二）對服務的深入討論之上 　　上一章其實只是概括性的介紹，下面開始才是真正的細節所在。在進入點函數裡面要完成ServiceMain的初始化，準確點說是初始化一個SERVICE_TABLE_ENTRY結構數組，這個結構記錄了這個服務程式裡面所包含的所有服務的名稱和服務的進入點函數，下面是一個SERVICE_TABLE_ENTRY的例子： SERVICE_TABLE_ENTRY service_table_entry[] = {   { "MyFTPd" , FtpdMain },   { "MyHttpd", Httpserv},   { NULL, NULL }, }; 　　第一個成員代表格服務的名字，第二個成員是ServiceMain回呼函數的地址，上面的服務程式因為擁有兩個服務，所以有三個SERVICE_TABLE_ENTRY元素，前兩個用於服務，最後的NULL指明數組的結束。 　　接下來這個數組的地址被傳遞到StartServiceCtrlDispatcher函數： BOOL StartServiceCtrlDispatcher( LPSERVICE_TABLE_ENTRY lpServiceStartTable ) 　　這個Win32函數表明可執行檔的進程怎樣通知SCM包含在這個進程中的服務。就像上一章中講的那樣，StartServiceCtrlDispatcher為每一個傳遞到它的數組中的非空元素產生一個新的線程，每一個進程開始執行由數組元素中的lpServiceStartTable指明的ServiceMain函數。 　　SCM啟動一個服務程式之後，它會等待該程式的主線程去調StartServiceCtrlDispatcher。如果那個函數在兩分鐘內沒有被調用，SCM將會認為這個服務有問題，並調用TerminateProcess去殺死這個進程。這就要求你的主線程要儘可能快的調用StartServiceCtrlDispatcher。 　　StartServiceCtrlDispatcher函數則並不立即返回，相反它會駐留在一個迴圈內。當在該迴圈內時，StartServiceCtrlDispatcher懸掛起自己，等待下面兩個事件中的一個發生。第一，如果SCM要去送一個控制通知給運行在這個進程內一個服務的時候，這個線程就會啟用。當控制通知到達後，線程啟用並調用相應服務的CtrlHandler函數。CtrlHandler函數處理這個服務控制通知，並返回到StartServiceCtrlDispatcher。StartServiceCtrlDispatcher迴圈回去後再一次懸掛自己。 　　第二，如果服務線程中的一個服務中止，這個線程也將啟用。在這種情況下，該進程將運行在它裡面的服務數減一。如果服務數為零，StartServiceCtrlDispatcher就會返回到進入點函數，以便能夠執行任何與進程有關的清除工作並結束進程。如果還有服務在運行，哪怕只是一個服務，StartServiceCtrlDispatcher也會繼續迴圈下去，繼續等待其它的控制通知或者剩下的服務線程中止。 　　上面的內容是關於進入點函數的，下面的內容則是關於ServiceMain函數的。還記得以前講過的ServiceMain函數的的原型嗎。但實際上一個ServiceMain函數通常忽略傳遞給它的兩個參數，因為服務一般不怎麼傳遞參數。設定一個服務最好的方法就是設定註冊表，一般服務在 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServiceServiceNameParameters 子鍵下存放自己的設定，這裡的ServiceName是服務的名字。事實上，可能要寫一個客戶應用程式去進行服務的背景設定，這個客戶應用程式將這些資訊存在註冊表中，以便服務讀取。當一個外部應用程式已經改變了某個正在運行中的服務的設定資料的時候，這個服務能夠用RegNotifyChangeKeyValue函數去接受一個通知，這樣就允許服務快速的重新設定自己。 　　前面講到StartServiceCtrlDispatcher為每一個傳遞到它的數組中的非空元素產生一個新的線程。接下來，一個ServiceMain要做些什麼呢。MSDN裡面的原文是這樣說的：The ServiceMain function should immediately call the RegisterServiceCtrlHandler function to specify a Handler function to handle control requests. Next, it should call the SetServiceStatus function to send status information to the service control manager. 為什麼呢。因為發出啟動服務要求之後，如果在一定時間之內無法完成服務的初始化，SCM會認為服務的啟動已經失敗了，這個時間的長度在Win NT 4.0中是80秒，Win2000中不詳... 　　基於上面的理由，ServiceMain要迅速完成自身工作，首先是必不可少的兩項工作，第一項是調用RegisterServiceCtrlHandler函數去通知SCM它的CtrlHandler回呼函數的地址： SERVICE_STATUS_HANDLE RegisterServiceCtrlHandler( LPCTSTR lpServiceName, //服務的名字 LPHANDLER_FUNCTION lpHandlerProc //CtrlHandler函數地址 )  　　第一個參數指明你正在建立的CtrlHandler是為哪一個服務所用，第二個參數是CtrlHandler函數的地址。lpServiceName必須和在SERVICE_TABLE_ENTRY裡面被初始化的服務的名字相匹配。RegisterServiceCtrlHandler返回一個SERVICE_STATUS_HANDLE，這是一個32位的控制代碼。SCM用它來唯一確定這個服務。當這個服務需要把它當時的狀態報表給SCM的時候，就必須把這個控制代碼傳給需要它的Win32函數。注意：這個控制代碼和其他大多數的控制代碼不同，你無需關閉它。 　　SCM要求ServiceMain函數的線程在一秒鐘內調用RegisterServiceCtrlHandler函數，否則SCM會認為服務已經失敗。但在這種情況下，SCM不會終止服務，不過在NT 4中將無法啟動這個服務，同時會返回一個不正確的錯誤資訊，這一點在Windows 2000中得到了修正。 　　在RegisterServiceCtrlHandler函數返回後，ServiceMain線程要立即告訴SCM服務正在繼續初始化。具體的方法是通過調用SetServiceStatus函數傳遞SERVICE_STATUS資料結構。 BOOL SetServiceStatus( SERVICE_STATUS_HANDLE hService, //服務的控制代碼 SERVICE_STATUS lpServiceStatus //SERVICE_STATUS結構的地址 )  　　這個函數要求傳遞給它指明服務的控制代碼(剛剛通過調用RegisterServiceCtrlHandler得到)，和一個初始化的SERVICE_STATUS結構的地址： typedef struct _SERVICE_STATUS { DWORD dwServiceType;  DWORD dwCurrentState;  DWORD dwControlsAccepted;  DWORD dwWin32ExitCode;  DWORD dwServiceSpecificExitCode;  DWORD dwCheckPoint;  DWORD dwWaitHint;  } SERVICE_STATUS, *LPSERVICE_STATUS; 　　SERVICE_STATUS結構含有七個成員，它們反映服務的現行狀態。所有這些成員必須在這個結構被傳遞到SetServiceStatus之前正確的設定。 　　成員dwServiceType指明服務可執行檔的類型。如果你的可執行檔中只有一個單獨的服務，就把這個成員設定成SERVICE_WIN32_OWN_PROCESS；如果擁有多個服務的話，就設定成SERVICE_WIN32_SHARE_PROCESS。除了這兩個標誌之外，如果你的服務需要和案頭發生互動(當然不推薦這樣做)，就要用“OR”運算子附加上SERVICE_INTERACTIVE_PROCESS。這個成員的值在你的服務的生存期內絕對不應該改變。 　　成員dwCurrentState是這個結構中最重要的成員，它將告訴SCM你的服務的現行狀態。為了報表服務仍在初始化，應該把這個成員設定成SERVICE_START_PENDING。在以後具體講述CtrlHandler函數的時候具體解釋其它可能的值。 　　成員dwControlsAccepted指明服務願意接受什麼樣的控制通知。如果你允許一個SCP去暫停/繼續服務，就把它設成SERVICE_ACCEPT_PAUSE_CONTINUE。很多服務不支援暫停或繼續，就必須自己決定在服務中它是否可用。如果你允許一個SCP去停止服務，就要設定它為SERVICE_ACCEPT_STOP。如果服務要在作業系統關閉的時候得到通知，設定它為SERVICE_ACCEPT_SHUTDOWN可以收到預期的結果。這些標誌可以用“OR”運算子組合。 　　成員dwWin32ExitCode和dwServiceSpecificExitCode是允許服務報告錯誤的關鍵，如果希望服務去報告一個Win32錯誤碼(預定義在WinError.h中)，它就設定dwWin32ExitCode為需要的代碼。一個服務也可以報告它本身特有的、沒有映射到一個預定義的Win32錯誤碼中的錯誤。為了這一點，要把dwWin32ExitCode設定為ERROR_SERVICE_SPECIFIC_ERROR，然後還要設定成員dwServiceSpecificExitCode為服務特有的錯誤碼。當服務運行正常，沒有錯誤可以報告的時候，就設定成員dwWin32ExitCode為NO_ERROR。 　　最後的兩個成員dwCheckPoint和dwWaitHint是一個服務用來報告它當前的事件進展情況的。當成員dwCurrentState被設定成SERVICE_START_PENDING的時候，應該把dwCheckPoint設成0，dwWaitHint設成一個經過多次嘗試後確定比較合適的數，這樣服務才能高效運行。一旦服務被完全初始化，就應該重新初始化SERVICE_STATUS結構的成員，更改dwCurrentState為SERVICE_RUNNING，然後把dwCheckPoint和dwWaitHint都改為0。 　　dwCheckPoint成員的存在對使用者是有益的，它允許一個服務報告它處於進程的哪一步。每一次調用SetServiceStatus時，可以增加它到一個能指明服務已經執行到哪一步的數字，它可以協助使用者決定多長時間報告一次服務的進展情況。如果決定要報表服務的初始化進程的每一步，就應該設定dwWaitHint為你認為到達下一步所需的毫秒數，而不是服務完成它的進程所需的毫秒數。 　　在服務的所有初始化都完成之後，服務調用SetServiceStatus指明SERVICE_RUNNING，在那一刻服務已經開始運行。通常一個服務是把自己放在一個迴圈之中來啟動並執行。在迴圈的內部這個服務進程懸掛自己，等待指明它下一步是應該暫停、繼續或停止之類的網路請求或通知。當一個請求到達的時候，服務線程啟用並處理這個請求，然後再迴圈回去等待下一個請求/通知。 　　如果一個服務由於一個通知而啟用，它會先處理這個通知，除非這個服務得到的是停止或關閉的通知。如果真的是停止或關閉的通知，服務線程將退出迴圈，執行必要的清除操作，然後從這個線程返回。當ServiceMain線程返回並中止時，引起在StartServiceCtrlDispatcher內睡眠的線程啟用，並像在前面解釋過的那樣，減少它啟動並執行服務的計數。