windows編程中的session

windows編程中的session

  前兩天在折騰Vista下的服務啟動進程的問題，有了點體會，記下來，希望能幫到跟我遇到一樣問題的朋友。

  windows xp、vista中，服務程式都是運行在session0中，而後面的第1、2、...、N個使用者則分別運行在session1、session2、...、sessionN中。不同的session有不同的namespace，但是由於目前主流的使用者windows平台WinXP支援快速切換使用者，所以我們感覺不到這些差異。

  在XP中，用Sevice啟動的進程跟我們用目前使用者啟動的進程在編程上似乎沒什麼區別，用起來都一樣。  可是到了vista下，情況就不一樣了。vista新的安全機制對不同的session之間的限制做了加強。比如：

1.雙擊啟動DbgView（也就是讓DbgView.exe運行在目前使用者的session環境中），然後在session0下，你用OutputDebugString來輸出一串debug string，你會發現在DbgView沒有這條資訊。

  這個問題折騰了我好久：我在我的進程的main()的入口輸出了些debug提示資訊，可是在DbgView中始終看不到。開始我以為是不是我的服務程式啟動進程失敗，但是發現進程列表裡又的確存在這個進程。我又猜想是不是我的服務建立進程的主線程失敗。發現也不是這個問題。後來試探性的吧debug資訊全都寫到檔案裡，才發現這個問題。

 

2.一些互斥量，如Mutex的使用。

  像普通的檢測方法一樣，為了避免我的進程B(處在session1中)多次啟動，我使用了named mutex，然後再進程A（由我的服務啟動，所以運行在session0中）中檢測該mutex，發現始終檢查不到。但是我又專門寫了個小程式來檢測（雙擊運行，所以也是運行在session1中），卻總能檢測到。後來仔細讀了MSDN中關於“ Kernel Object Name Spaces”的資料，才明白：

  一些命名的核心對象，比如： events, semaphores, mutexes, waitable timers, file-mapping objects, job objects，都只是在自己的namespace裡唯一存在，不同的session因為namespace不同，所以會導致上面的現象。詳細的資訊可以參考MSDN中的CreateMutex資料中對參數lpName的說明。

  針對vista下，跨session的進程問題，可以參考這篇文章，對我協助頗大，感謝作者。

  另：為了方便，把MSDN中“ Kernel Object Name Spaces”的說明也貼上來：

Kernel Object Name Spaces
A Terminal Services server has multiple name spaces for the following named kernel objects: events, semaphores, mutexes, waitable timers, file-mapping objects, and job objects. There is a global name space used primarily by services such as client/server applications. In addition, each client session has a separate name space for these objects. Note that this differs from the standard Windows environment in which all processes and services share a single name space for these objects.

The separate client session name spaces enable multiple clients to run the same applications without interfering with each other. For processes started under a client session, the system uses the session name space by default. However, these processes can use the global name space by prepending the "Global/" prefix to the object name. For example, the following code creates an event object named CSAPP in the global name space:

CreateEvent( NULL, FALSE, FALSE, "Global//CSAPP" );

Service applications on a Terminal Services server use the global name space by default. Processes started under the server console session (session zero) also use the global name space by default. The global name space enables processes on multiple client sessions to communicate with a service application or with the console session. For example, a client/server application might use a mutex object for synchronization. The server component running as a service can create the mutex object in the global name space. Then the client component running as a process running under a client session can use the "Global/" prefix to open the mutex object.

Another use of the global name space is for applications that use named objects to detect that there is already an instance of the application running in the system across all sessions. This named object must be created or opened in the global name space instead of the per-session name space. Note that the more common case of running the application once per session is supported by default since the named object is created in a per session name space.

Client processes can also use the "Local/" prefix to explicitly create an object in their session name space.

The "Local", "Global" and "Session" prefixes are reserved for system use and should not be used as names for kernel objects. These keywords are case sensitive. On Windows 2000 without Terminal Services, these keywords are ignored. On earlier versions of the system, the functions for creating or opening these objects fail if you specify a name containing the backslash character (/).

Windows XP: Fast user switching is implemented using Terminal Services sessions. The first user to log on uses session 0, the next user to log on uses session 1, and so on. Kernel object names must follow the guidelines outlined for Terminal Services so that applications can support multiple users. For more information, see Fast User Switching.