有{間}客栈

强烈抗议，IT168的编辑一点幽默感都没有，把我的文章修改的味同嚼蜡。

“快说，你是不是安装程序?”操作系统问。

　　“我不是啊，长官。我虽然长得像，但是我真的不是安装程序啊!”，一个应用程序扮出一副可怜相，胆胆怯怯的回答道。

　　“不是?那为什么你的程序名中含有Install?”，操作系统以怀疑的眼光盯着他，“所有程序名中含有Install的应用程序都是安装程序，都必须在执行的时候都向用户请求管理员权限!”

　　“是是是，长官!”应用程序心中暗喜，操作系统主动给我机会让我请求管理员权限，我求之不得呢，用户早就厌烦UAC了，肯定直接点击“YES”了事啊，有了管理员权限，我就可以为所欲为啦，偷偷修改个首页先，哈哈哈哈~~~

　　UAC又惹祸了

　 　随着Windows Vista引入UAC(User Access Control)机制，默认情况下，应用程序都运行在普通用户权限下。虽然微软出于良好的愿望而在Vista中引入UAC机制， 但是在Vista操作系统中，只要系统稍作改变，它就会频繁弹出对话框来寻求用户的许可，因此它成为了Vista中最受痛恨的一个功能。 虽然如此，Windows 7还是继承了这一机制并根据用户的反馈做了相应的改进。为了降低计算机系统的风险，UAC机制将执行应用程序的用户权限降低了，这就为那些在UAC机制出 现之前所设计的应用程序的执行带来了兼容性的麻烦。这些旧有应用程序通常都假设以管理员权限运行，在Windows 7上，因为UAC的存在，这一假设不成立了，最终导致应用程序无法正常运行。一些应用程序确实是需要管理员权限才可以正常运行的，尤其是安装程序，他们需 要向一些需要特殊权限的区域，比如“Program Files”或者是注册表的HKEY_LOCAL_MACHINE写入内容，这种情况它们会遇到访问拒绝的错误，或者是数据被UAC Virtualization重定向到其他位置而无法正确执行。

　　为了解决这个问题，“聪明”的雷德蒙程序员们想出了一个办法：安装程序 检测。从Windows Vista开始，当然也包括Windows 7，操作系统将采用一些启发式算法来判断应用程序是不是一个安装程序，也就是在执行的时候这个程序是否需要请求管理员权限，如果操作系统判断应用程序是一 个安装程序，就会让它在执行的时候向用户请求获取管理员权限以便让应用程序正确的执行。

　　操作系统是如何检测的?

　 　所有在Windows Vista之前开发的没有manifest(包括外部的和内部的)的32位应用程序都会进行这种启发式的安装程序检测。操作系统会假设这些应用程序是旧有 的，他们都需要进行安装程序检测以确定这些应用程序是否管理员权限才能正常运行。面对这样的应用程序，操作系统的启发式安装检测通常会通过以下这些途径来 判断一个32位应用程序是不是安装程序：

　　• 文件名包含关键字：”install”, “setup”和”update”等等。

　 　• 在版本资源的以下字段内包含关键字：厂商(Vendor)、公司名(CompanyName)、产品名(ProductName)、文件说明(File Description)、初始文件名(Original Filename)、内部文件名(Internal Name)、导出名(Export Name)。

　　• 在可执行文件的manifest内包含关键字。

　　• 在链接到可执行文件的特定StringTable中包含关键字。

　　• 在链接到可执行文件的资源文件数据包含关键属性。

　　• 可执行文件包含特定的字节序列。

　　如果找到了，操作系统会认为它需要管理员权限才可以正常运行。一个UAC保护盾的图标会覆盖在应用程序图标上，这就表示应用程序在启动的时候会请求管理员权限以便它可以正确执行。

　　图1 安装程序检测

阅读全文：Win7共舞：UAC惹祸 如何进行安装程序检测？

作为程序员，谁都希望自己的软件性能优异，运行如飞。但是当我们在看到自己开发的软件像蜗牛一样慢吞吞地运行，半天没有反应的时候，我们常常会有这样一些疑问：

　　“我的系统都在忙些什么?CPU在干啥?”

　　“为什么我的软件性能表现这么低下?”

　　“哪里才是软件的性能瓶颈?什么代码导致了软件的性能低下?”

　　“软件运行到了什么状态?”

　 　面对这些问题，程序员们都在想，要是有个软件仪表仪表，就像汽车的仪表盘一样，能够实时向我们报告系统和软件的运行状态就好了!现在，在Windows 7中，程序员们的这个梦想成为了现实。通过Windows 7所提供的Performance Counters，Event Tracing for Windows (ETW) ，Windows Management Instrumentation以及Windows Performance Toolkit，我们可以实时地获得系统和在其上运行的各种软件的性能状态信息，圆满地回答上面这些问题。利用这些丰富的状态信息，我们可以对应用程序进 行诊断调试，性能分析，找到性能瓶颈，从而对其进行性能调优，给蜗牛软件插上飞的翅膀。

　　图1  我不是蜗牛，我是飞牛

　　关于性能分析的这十八般武器各有所长，这里我们先介绍性能计数器。

　　Performance Counters(性能计数器)

　　当我们在开发一些对性能期望较高的软件的时候，简单高效的性能计数器对发现软件中的性能瓶颈是很有价值的。虽然我们可以自己实现简单的性能计数器，但是，使用Windows操作系统本身所提供的Performance Counters(性能计数器)，我们可以获得更多得天独厚的优势。

　 　性能监视，是Windows NT引入的一种系统功能。从Windows NT以后，Windows操作系统总是集成了各种性能监视工具，它提供有关操作系统当前运行状况的信息，针对各种性能对象提供了数百个性能计数器。性能对 象，就是被性能计数器监视的对象，我们通常比较关心的监视对象主要有Processor、Process、Memory、TCP/UDP/IP /ICMP、Physical Disk等。性能计数器通常提供操作系统、应用程序、服务、驱动程 序等的性能相关信息，以此来分析系统瓶颈和对系统及应用程序性能进行诊断和调优。除了针对操作系统本身，通过性能计数器机制，我们也可以在应用程序或者是 操作系统组件中向性能监视器(Performance Monitor)报告一些与性能有关的统计信息，以此来查看软件的性能信息，对其进行诊断和调优。

　 　在Windows 7中，微软对性能计数器做了进一步的改进和优化。例如，采用了新的2.0版本的核心模块API、采用XML定义、更加强大的性能、更高的可扩展性和鲁棒 性、增加了多个系统计时器等等。同时，为了方便系统管理员进行管理，还增加了PowerShell对计时器日志文件的处理功能等等，使得性能计数器的功能 大大增强。

阅读全文：VS与Win7共舞：性能计数器进行性能分析

本文解答了关于Silverlight的10个最常见的问题。从某种意义上讲，这两种技术是相互关联的：它们都是关于界面表现的技术，更进一步 的，Silverlight是基于WPF的，是它的一个子集。本文不仅从理论上介绍了这两种技术，同时还提供了一些小的例子供大家参考。

  上篇：为你解惑之WPF经典9问详解

  第1问：什么是依赖属性？

  依赖属性有这样一个显著的特性：依赖属性属于某个类，但是却可以在另外一个类中使用。我们来看看下面的代码：

  其中，高(Height)和宽(Width)是这个长方体对象的普通属性。但是，顶部(Canvas. Top)和左侧(Canvas. Left)就是依赖属性。因为它们都属于Canvas类。却被用来指定长方形在画布(Canvas)中的位置。

  第2问：XAML文件会在运行时被编译或者构建吗？

  通常，XAML文件会在XAML应用程序运行之前被编译。但是它也同样支持在运行时进行编译处理。当我们创建一个基于XAML的项目的时候，你会在项目的 obj\Debug文件夹下看到Visual Studio创建的以g.cs为扩展名的文件，对于每一个XAML文件，你会找到对应有一个g.cs文件。例如，如果我们项目中有一个Shiv.xaml 文件，你就会在obj\Debug文件夹下找到Shiv.g.cs文件。简单来讲，在运行时，你不会看到XAML文件。但是如果你想让XAML文件的加载 和解析在运行时完成，也是可以的。

  第3问：如何分离程序代码和XAML？

  分离程序代码和XAML是WPF最重要的一个特性之一。这样，软件的UI设计师可以独立地专注于软件的界面表现，而程序员则可以专注于软件的代码逻辑，而不用去管软件的表现是什么样的。

图1  程序代码和XAML的分离

  上面的代码片段展示了XAML文件和它背后的逻辑代码是如何分离又是如何联系的。为了将XAML文件和一个类联系起来，我们需要指定XAML的类属性 (x:Class)。通过定义一个方法的事件发送者和事件值，XAML对象的事件都可以连接到这个方法。在上面的代码中，你可以看到我们将 MyClickEvent方法连接到了一个按钮点击事件。

【内容导航】

• 第1页：什么是依赖属性
• 第2页：什么是Silverlight
• 第3页：Silverlight的架构是什么样的
• 第4页：创建一个的Silverlight应用程序
• 第5页：Silverlight开发的IDE环境

第0问：能否简单介绍一下本文的结构？

  本文解答了关于WPF的9个最常见的问题。从某种意义上讲，这两种技术是相互关联的：它们都是关于界面表现的技术，更进一步的，Silverlight是基于WPF的，是它的一个子集。不仅从理论上介绍了这两种技术，同时还提供了一些小的例子供大家参考。

  第1问：我们已经有了GDI、GDI+和DirectX，为什么我们还需要WPF呢？

图1 从User32到WPF的发展历程

  首先，让我们来回顾一下微软的各种界面显示技术：

  User32:它提供了最基本的Windows界面，包括按钮，编辑框和其他UI元素。但是，User32缺乏的是图形图像的绘制功能，无法对屏幕实现自定义的绘制。

  GDI (Graphics device interface):- 为了提供图形图像的绘制功能，微软在User32的基础上引入了GDI。GDI不仅提供了图形图像的绘制功能，同时还对硬件显示进行了更高层次的抽象。换 句话说，它将硬件的复杂性封装在了GDI API中，用户使用起来更加方便。

  GDI+:顾名思义，GDI+是作为GDI的扩展而被引入到Windows中的。它提供了很多GDI所没有的扩展功能，例如对JPG和PNG图像格式支 持，渐变阴影和抗锯齿等。无论是GDI还是GDI+，它们最大的局限就是不支持硬件加速，同时无法展现动画和3D图像。

  提示:所谓硬件加速，就是使用硬件来执行某些功能，以替代使用软件在CPU中执行的某些功能，因为直接使用硬件，这样可以显著地加快图形图像处理的速度。

  DirectX :正如我们在上面所分析的那样，GDI及其扩展GDI+的一个最大问题就是不支持硬件加速和动画。这对于游戏开发者来说，是无法接受的。为了解决这个问 题，微软开发了DirectX。DirectX能够很好的利用硬件加速，能够支持3D，全彩图像，流媒体等等，非常适合游戏工业等对图形图像处理要求比较 高的领域。

  WPF:微软已经有了这么多套关于显示技术的API，为什么还要多此一举，创建另外一套显示技术的API呢？通过对硬件加速的支持，DirectX已经有 了很多非常棒的特性。微软想利用支持硬件加速的DirectX技术来开发UI元素，比如文本框，按钮，网格等等，所以他们又在DirectX的基础上开发 了WPF。因为WPF是在DirectX的基础上实现的，所以你不仅可以利用WPF创建简单的UI元素，还可以更进一步，开发特殊的UI元素，例如网格 (Grid)，流文档(FlowDocument)和椭圆(Ellipse)等。

  更进一步地，你还可以利用WPF创建动画。如果你在寻找用于创建轻量级动画(不是游戏中所使用的那种复杂三维动画)的技术方案，WPF将是一个不错的选择。你可以使用被称为XAML的XML文件来表现WPF。 

图2 WPF和DirectX的关系

  简单的讲，WPF就是DirectX之上的一层包装。所以，我们可以这样定义WPF：

  WPF是一套用于简便地构建动态用户界面的类的集合。这些类包括了一套新的界面控件。其中有些控件跟旧有的UI元素是相似的，例如标签，文本框和按钮等， 而另外一些控件则是全新的，例如，网格(Grid)，流文档(FlowDocument)和椭圆(Ellipse)等。

【内容导航】

书接上回，在前面一篇文章中，我们结合Office Word 2007，以实例的形式介绍了如何在Visual Sutton  2010中进行文档级自定义项的开发，相信大家在其基础上都可以开发出自己的丰富多彩的Office应用。前面介绍的文档级自定义项是跟某个具体的文档相 关联的，如果我们需要Office程序具有某些扩展功能，那该怎么办呢？能不能开发跟文档无关，而针对Office程序适用的插件，帮助我们完成一些繁琐 的辅助工作？答案当然是肯定的。在这篇文章中，我们继续在Visual Studio 2010中进行Office开发的话题，介绍如何开发跟文档无关的应用程序级插件。

  在上一篇文章中我们已经介绍过，在Visual Studio 2010中，Office开发主要有三种类型，其中应用程序级插件就是本文将要介绍的主要内容。应用程序级插件包含一个与某个 Microsoft Office 应用程序相关联的程序集。通常，该插件随着所关联的应用程序的启动而运行。当然，用户也可以在关联应用程序已经在运行的时候动态地加载插件。我们所创建的 应用程序级插件中的功能可用于应用程序本身，而与所打开的文档无关。

  第一篇：详解VSTS与OFFICE的协同开发:WORD篇

  在本文中，我们以最常用的Outlook收发邮件为例，介绍应用程序级插件的开发流程。我们可以设想这样这个Office应用场景：我们是工作在一个比较 规范的组织中，我们在利于Outlook发送新邮件时，通常会有一些固定的格式，例如给主题加上标头，邮件正文末尾添加固定的联系方式等等。另外，对于某 些管理者，常常会收到一些固定格式的报表，例如每周销售报表等等。这些报表需要专门整理保持到特定的目录以备查看。

  为了系统安全，甚至可以自动运行杀毒软件进行扫描。这些都是我们在使用Outlook时的常见任务，虽然这些任务都可以通过Outlook的设置来实现，但是这里我们还是利于开发的方式，来看看如果利于应用程序级插件，更加灵活高效地完成这些功能。

  Outlook对象模型概述

  在利用Visual Studio 2010开发应用程序级插件之前，我们还是先来了解一下即将用到的Outlook对象模型。Outlook对象模型提供许多我们可以与之进行交互的类。若要有效地使用Outlook对象模型，我们应该熟悉以下这些最常用类：

  •Application 类
  Application 类表示 Outlook 应用程序，它是 Outlook 对象模型中最顶层的类。此类的一些最重要的成员包括：
  CreateItem 方法，该方法可用来创建新项，例如电子邮件、任务或约会等。
  Explorers 属性，该属性可用来访问在 Outlook 用户界面 (UI) 中显示文件夹内容的窗口。
  Inspectors 属性，该属性可用来访问显示单个项（如电子邮件或会议要求）内容的窗口。
  在我们所创建的应用程序级插件项目中，若要获得 Application 类的实例，可以使用 自动生成的ThisAddin 类的 Application 属性，这个属性就代表了Application类的一个实例。

【内容导航】

• 第1页：Outlook对象模型概述
• 第2页：创建应用程序级插件
• 第3页：AppointmentItem 类
• 第4页：创建应用程序级插件
• 第5页：创建自定义主题的新邮件
• 第6页：对邮件附件进行整理