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.