b/s比c/s有一个非常大的优势在于升级简单，升级有限的服务器就ok了，而c/s模式则是每台客户机都需要升级，版本一致比较难控制，所以在线升级就成了很重要的问题。
当时研究这个的时候存在的问题是，公司所有的产品的在线升级是VB写的加上几个VC写的com组件，每个产品需要就修改部分源代码，然后编译出一个自己产品用的，然后可能一台电脑上安装了几款我们公司的产品，也有好几个升级进程，相互影响。还有如果不是管理员权限，安装补丁包就会不能写注册表之类的，有一些问题。
研究了下谷歌的一个在线升级项目，开源的，叫omaha，链接http://omaha.googlecode.com/svn/wiki/OmahaOverview.html，然后看了一下介绍，尝试编译google update开源项目:omaha。
附几个资料链接：
http://code.google.com/p/omaha/wiki/DeveloperSetupGuide
https://code.google.com/p/omaha/source/browse/
https://code.google.com/p/omaha/wiki/HammerOptions
http://omaha.googlecode.com/svn/wiki/cup.html
这里用到了很多ATL和WTL的技术，编译器最好是VS2008,之前试过2010，没能成功，构造脚本python写的，只能尝试重建一个虚拟机，搭建如下构造环境：
一通折腾之后，还排除了一些编译错误，构造出来之后，发现效果并不好，支持断点续传，但好像没有本地版本检测，都是全新下载安装，代码量大到让人叹气，这么一个几千行代码就能完成的功能，几百个头文件和cpp文件也是醉了，不过代码确实写得很规范，敢公开代码肯定是有自信的，只能扒了扒怎么提升进程权限，因为文档有限，研究别人代码在没文档的情况太痛苦，所以还是自己写吧。
其实主要流程是考虑：
1.由每个产品都调用这个在线升级的exe，由它自己来控制只有一个进程在运行，这在技术上并不困难。
2.建立一个补丁包的命名机制，由它来控制版本，什么补丁安装，什么补丁不安装，大版本和小版本怎么安装之类的。
3.安全机制，服务器上的文件经过校验才会被安装，防止服务器被黑或是管理员操作失误，把一些不该安装的程序推送给了用户。
4.补丁包下载了之后，检测该补丁包对应的产品是否在运行，如果在运行，则需要停止其运行，因为安装一些在运行的程序的补丁，它的一些文件被占用可能导致安装失败。
5.权限问题，由于我们习惯了XP的admin权限，当处于非admin或是win7下时，有些函数难以实现我们需要的功能。
6.实现断点续传功能，先技术尝试一下，这个简单。
代码就不贴了，大概5000行的样子，如果当时用正则表达式，而不是拼凑字符串，代码量应该会少很多。
有空再详细写写。