Windows Vista 交互式服务编程

  

Windows Vista 对快速用户切换，用户账户权限，以及服务程序所运行的会话空间都作了很大的改动，致使一些原本可以工作的程序不再能够正常工作了，我们不得不进行一些改进以跟上 Vista 的步伐。

我们的软件在Windows NT/2000/XP/Vista 系统中安装了一个系统服务，这个服务负责以 SYSTEM 权限启动我们的主程序。我们的主程序启动后会在系统托盘添加一个图标，点击此图标可以弹出控制菜单，通过这个菜单也可以激活配置程序首选项的对话框。在 Windows NT/2000/XP 下我们的程序都可以正常工作。哦不，当 XP 具备了快速用户切换功能的时候我们的问题已经出现了。XP 启动后我们以用户 A 登录，我们的图标出现在系统托盘，一切工作都正常，可当我们使用快速用户切换，切换到用户B后（用户A此时也是已登录状态，并没有注销），虽然用户B已经是本地控制台会话(Session 属性为 Console)但我们的图标已经无法出现了，自然菜单和对话框更无从谈起了。我们的程序是和本机控制台桌面相关的，这种情况无疑是个缺陷。再来看一下在 Vista 平台是怎么样吧，系统启动后以用户A登录，我们的图标更本就没有出现，查看进程管理器中的进程列表发现我们的程序已经启动了，当我们从远端检查我们的服务，发现已经正常工作，尝试远程登录我们的服务，Vista 会在本机控制台弹出一个消息框，提示有交互式服务消息，是否查看这个消息，点击立刻查看发现切换到另外一个桌面去了。

于是开始分析这种情况发生的原因。在 Windows NT/2000 中系统服务进程和本机控制台交互式登录的用户都运行于Session0 中，默认用户桌面运行于 WinSta0 窗口站，所以我们的程序由服务程序启动时依然是和本机用户处于同一个Session中，即使在某些情况下出现不能弹出对话框或者无法添加系统托盘图标的情况也只需要修改一下进程桌面到 WinSta0/Default 就可以了（可以参考 MSDN 中 OpenInputDesktop, SetThreadDesktop 等API的说明）。

XP为我们带来了快速用户切换，也让我们所采用的软件架构问题浮现出来。当我们快速切换到用户B的时候，用户A仍然在会话中(Session0)，而用户B则处于新启动的会话中(Session1或者其他)，此时服务程序和本机控制台程序就不在处于同一会话了，OpenInputDesktop,SetThreadDesktop 等API的工作范围仅限于本Session，用户A没有退出，Session0也依然存在但是已经是 Disconnected 状态，当进程所处的Session是 Disconnected 状态的时候调用 OpenInputDesktop 会返回错误“无效的API”。进程及线程所属的Session 是由他们的Token 结构中的 TokenSessionId 决定的（参见MSDN中SetTokenInformation 和 TOKEN_INFORMATION_CLASS的说明），我尝试以微软提供的相关API修改运行中的进程和线程的TokenSessionId 信息从而达到修改桌面环境的目的，到目前还没有成功过（或许可以尝试参考RootKit 技术，不过即使修改成功到底能不能实现我们的需求也不确定）。我们的进程无法跨越Session的界限，自然无法与当前活动的另外一个Session中的桌面交互了， L 。

Vista中又是如何的一番景象呢？处于安全方面及其他因素的考虑，Vista以及将所有的服务程序置于Session0中，而为本机第一个交互登录的用户创建了Session1，快速切换到用户B后则是 Session2，无论是本机登录的用户，快速切换后的用户，还是远程桌面登录的用户再也没有谁和服务进程处于同一个Session中了，我们的程序还运行在Session0中，自然我们的托盘图标是没有用户能看到了。事实上这个图标还是可以出现的。Session0因为不是一个交互式会话所以没有象其他用户环境初始化的时候一样启动Explorer程序，但是我们开始可以手工启动他，在Session0中启动 Explorer 后任务栏出现后我们还是看到了我们的图标（具体启动Explorer的方法我们不在此文中讨论），菜单、对话框也可以使用。

既然我们的程序必须运行在Session0而我们又没有办法把我们的图标、对话框一下子就抛到隔壁Session的用户桌面上去，只能想其他的办法了。微软也不提倡我们这种服务程序直接提供GUI与用户直接交互的方式，而他们建议使用C/S架构，Client/Server之间用Socket/Pipe/RPC等方式通讯，这样我们只要把Client整个进程放到用户Session去和用户交互，然后将配置信息等内容通过上述途径传递给Server，服务端在作出相应的响应即可。

把GUI分离出来并不是那么困难，然后在以前直接调用的地方加上一个通过Pipe通讯的接口，这样GUI(Client)的运行就可以灵活的掌握了。

最初我想把用户界面程序放到 Startup（启动）中随用户登录自动启动。这样当用户A和B都登录后将有两个用户界面程序在运行，而我们的服务只是和当前活动的控制台登录用户交互，所以这样并不符合需求。

接下来我们需要看看如何判定当前的活动Session是哪个，然后如何在这个活动Session中启动我们的用户界面程序了。

微软从XP/2003开始为我们提供了一套Windows Terminal Service 的相关API，这些API都以WTS开头（请安装MSDN2005以查阅相关说明），要获得活动Session也不止一个途径，最简单的就是直接使用

DWORD WTSGetActiveConsoleSessionId(void);

来获得活动Session Id 。要在程序中使用这些API需要最新的Platform SDK（如果你正在使用Visual Studio 2005那么它已经具备了相关头文件和库文件可以直接使用了），如果你在使用VC++ 6.0 你也没有或者不打算安装最新的SDK那么你可以直接使用LoadLibrary() 装载wtsapi32.dll然后使用GetProcAddress()获得相关函数的地址以调用它们。我们获得了活动SessionId后就可以使用

BOOL