Windows 10 中面向开发人员的新增功能








Windows 10 及新增的开发人员工具将提供新通用 Windows 平台支持的工具、功能和体验。在 Windows 10 上安装完工具和 SDK 后，你可以随时创建新的通用
 Windows 应用，或了解如何使用 Windows 上的现有应用代码。






针对 Windows 10 进行生成


凯文·盖洛提供系统的快速纲要以及直接支持新的 Windows 10 开发体验的工具更新。





通用 Windows 平台指南


了解通用 Windows 平台如何将自适应 UI 控件用于不同的设备类型，以及它如何使用运行 Windows 10 的所有设备上必须具有的通用 API 集。





Windows 10 上的游戏


了解玩家如何才能进行连接和玩游戏 - 玩家的游戏、好友和成就将在其所有 Windows 设备上保持一致。







本主题内容




自适应布局
XAML 功能
图形
网络



文本
工具
安全



Web
用户体验
应用模型



媒体
设备
系统服务












自适应布局



返回页首










适用于定制内容的多个视图



XAML 针对定义用于共享相同代码文件的定制视图（.xaml 文件）提供了新的支持。这使你可以更加方便地创建和保留已定制为特定设备系列或方案的不同视图。如果你的应用具有不同的 UI 内容、布局或导航模型（与对应的方案截然不同），应构建多个视图。例如，对于针对移动版应用的单手使用模式进行优化的导航菜单，你可以使用 Pivot；而对于针对桌面版应用的鼠标输入进行优化的导航菜单，你可以使用 SplitView。









StateTriggers



使用新的 VisualState.StateTriggers 功能，你可以基于窗口高度/宽度或者基于自定义触发器有条件地设置相关属性。之前，你必须在代码中处理
 Window SizeChanged 事件并调用 VisualStateManager.GotoState。









Setters



使用新的 VisualState.Setters 语法，你可以使用简化的标记定义 VisualStateManager 中的属性更改。之前，你必须使用情节提要并创建动画来应用属性更改，例如将 StackPanel 的方向从水平更改为垂直。在通用
 Windows 应用中，你可以使用以下更加简单的 Setter 语法：
<setter target="stackPanel1.Orientation" value="Vertical" />

















XAML 功能



返回页首










已编译的数据绑定 (x:Bind)



在通用 Windows 应用中，你可以使用基于编译器的新绑定机制，该机制可通过 x:Bind 属性进行启用。基于编译器的绑定将在编译时严格设置类型并进行处理，这将非常快速并且会在绑定类型不匹配时提供编译时错误。因为绑定已转换为编译的应用代码，所以你现在就可以调试绑定，方法是在 Visual Studio 中逐步执行代码以诊断特定的绑定问题。你还可以使用 x:Bind 绑定到某一方法，如下所示：
<textblock text="{x:Bind Customer.Address.ToString()}" />

对于典型的绑定方案，你可以使用 x:Bind 替代绑定，从而获得改进的性能和可维护性。









列表的声明性增量呈现 (x:Phase)



在通用 Windows 应用中，新的 x:Phase 属性允许你借助 XAML（而非代码）执行列表的增量呈现或阶段性呈现。当平移带有复杂项目的较长列表时，你的应用呈现项目的速度可能不足以跟上平移的速度，致使你的用户获得了一次槽糕的体验。阶段性呈现让你可以在某一列表项目中指定个别元素的呈现优先级，以便仅该列表项目中最重要的部分才能在快速平移方案中呈现。这将为你的用户提供一次较为顺畅的平移体验。

在 Windows 8.1 中，你可以处理 ContainerContentChanging 事件，并编写用于分阶段呈现列表项目的代码。在
 UWP 应用中，你可以使用 x:Phase 属性以声明方式完成阶段性呈现。通过将 x:Phase 与已编译的绑定 x:Bind 结合使用，你可以在数据模板中为每个绑定元素轻松指定呈现优先级。在进行平移时，呈现项目所需执行的操作是基于阶段按时间进行分片，这将支持增量项目呈现。









UI 元素的延迟加载 (x:DeferLoadingStrategy)



在通用 Windows 应用中，新的 x:DeferLoadingStrategy 指令允许你指定要延迟加载的用户界面部分，从而改进启动性能并减少应用的内存使用量。例如，如果你的应用 UI 中存在一个仅在输入错误数据时才显示的数据验证元素，则你可以根据需要延迟该元素的加载。随后，这些元素对象将不会在加载页面时创建，它们只会在发生数据错误或者需要添加到页面的可视树时才会进行创建。









SplitView



借助新的 SplitView 控件，你可以轻松显示和隐藏瞬态内容。该控件通常用于“汉堡包菜单”之类的顶级导航方案，其中导航内容处于隐藏状态，可按需滑入作为用户操作的结果。









RelativePanel



RelativePanel 是一种新型的布局面板，该面板允许你放置子对象并使其相互对齐或与父面板对齐。例如，你可以指定某些文本应始终置于该面板的左侧，并指定按钮应始终向下对齐文本。当创建没有明确的线性模式的用户模式但却要求使用 StackPanel 或 Grid时，可使用
 ReleativePanel。









CalendarView



借助 CalendarView 控件，可使用基于月份的自定义视图轻松查看和选择日期以及日期范围。CalendarView
 支持相关功能，例如可将最小日期、最大日期和截止日期限制在可选的日期范围内。你还可以设置自定义密度栏，这些密度栏可用于显示某一天的计划的一般“细节”。









CalendarDatePicker



CalendarDatePicker 是一个下拉式控件，该控件已针对从CalendarView 选取某个日期进行了优化，尤其是能够显示诸如星期几或丰富的日历信息等上下文信息。它类似于 DatePicker 控件，不过
 DatePicker 是针对选取一个已知日期（例如出生日期）进行优化的。









MediaTransportControls



借助新的 MediaTransportControls 类，可更轻松地自定义 MediaElement 的传输控件。在
 Windows 8.1 中，你可以启用 MediaElement 的内置传输控件，或通过调用 MediaElement 方法创建你自己的传输控件。现在，你可以使用 MediaTransportControls 的内置功能，并且仍然可以轻松地自定义其外观，以适合你的应用。









属性更改通知



在通用 Windows 应用中，你可以听 DependencyObjects 上的属性更改，即便是属性没有对应的更改事件也是如此。

通知的操作行为类似于事件，但实际上显示为回调。与事件处理程序一样，回调将提取一个发件人参数，但不会提取事件参数。而是，将仅传递属性标识符来指示是哪个属性。借助此信息，你的应用可以定义多个属性通知的单个处理程序。有关详细信息，请参阅 RegisterPropertyChangedCallback 和 UnregisterPropertyChangedCallback。









地图



已更新为提供 3D 鸟瞰图和街景视图的 MapControl 类。这些新功能和早期的映射功能现在可用于
 Universal Windows App。使用以下 API 将映射添加到你的应用：

Windows.UI.Xaml.Controls.Maps 命名空间
 - 显示地图
Windows.Services.Maps 命名空间
 - 查找位置和路线

若要立即开始在 Universal Windows App 中使用这些 API，请从必应地图开发人员中心请求一个密钥。有关详细信息，请参阅如何验证地图应用。同样作为
 Windows 10 中的新增功能，电脑用户和手机用户可以从“设置”应用下载脱机地图。当 Internet 访问不可用时，MapControl 可使用脱机地图（如果可用）来显示地图。









输入按钮映射



Windows.UI.Xaml.Input.KeyEventArgs 类具有新的 OriginalKey 属性以及对 Windows.System.VirtualKey 所做的相应更新，从而让你可以获取与键盘输入事件关联的原始且未映射的输入按钮。









墨迹书写



借助 InkCanvas 控件和基础 InkPresenter 类，现在可以更容易地使用采用
 C++、C# 或 Visual Basic 的 Windows 运行时应用中功能强大的墨迹功能。

InkCanvas 控件定义了一个用于绘制和呈现墨迹笔划的覆盖区域。此控件的功能（输入、处理和呈现）源自InkPresenter、InkStroke、InkRecognizers 和 InkSynchronizer 类。

重要提示这些类在使用 JavaScript 的 Windows 应用中不受支持。

















已更新的 XAML 功能



返回页首










CommandBar 和 AppBar 更新



CommandBar 和 AppBar 控件已针对跨设备系列的
 UWP 应用更新为具有一致的 API、行为和用户体验。

适用于通用 Windows 应用的 CommandBar 控件已得到了改进，从而可提供 AppBar 功能的超集，并且针对如何将其用于你的应用提供了更大的灵活性。对于 Windows 10 上所有新的通用 Windows 应用，应使用 CommandBar。在 Windows 8.1 的 CommandBar 中，你只能使用已实现 ICommandBarElement 的控件，如 AppBarButton。在通用
 Windows 应用中，除了 AppBarButtons 外，你现在还可以将自定义内容放入 CommandBar 中。

AppBar 控件已得到了更新，以便你可以更加轻松地将使用 AppBar 的 Windows 8.1 应用移动到通用 Windows 平台。AppBar 设计为可与全屏应用一起使用并且可通过边缘手势进行调用。针对诸如 Window 应用以及 Window 10 中缺少边缘手势等问题对控件帐户进行更新。

之前仅在 Windows Phone 上提供的隐藏 AppBar.ClosedDisplayMode 现在在所有设备系列上均受支持，从而让你可以在不同的命令提示级别之间选择。AppBar
 默认情况下显示最少内容的提示，以便在将你的 Windows 8.1 应用升级到通用 Windows 应用时能为你提供一致性，不过你将无法再依赖平台中的边缘手势支持。

新的 AppBar API： Closing、OnClosing、Opening、OnOpening、TemplateSettings

新的 CommandBar API： CommandBarOverflowPresenterStyle 和 CommandBarOverflowPresenter









GridView 更新



在 Windows 10 之前的版本中，默认的 GridView 布局方向在 Windows 上为水平方向，而在 Windows
 Phone 上为垂直方向。在 UWP 应用中，GridView 默认情况下针对所有设备系列使用垂直布局，以确保你能获得一致的默认体验。









AreStickyGroupHeadersEnabled 属性



当你在 ListView 或 GridView 中显示分组数据时，组标头将在列表滚动时保持可见状态。这对于大型数据集很重要，其中标头为用户正在查看的数据提供了上下文。不过，在每个组中仅具有少数几个元素时，你可能会希望标头随着项目滚动至屏幕外。你可以通过设置 ItemsStackPanel 和 ItemsWrapGrid 上的
 AreStickyGroupHeadersEnabled 属性控制此行为。









GroupHeaderContainerFromItemContainer 方法



当你在 ItemsControl 中显示分组数据时，你可以通过调用 GroupHeaderContainerFromItemContainer 方法，获取对该组父标头的引用。例如，如果用户要在某组中删除最后一项，你可以获取对该组标头的引用，并同时删除该项和组标头。









ChoosingGroupHeaderContainer 事件



借助 ListViewBase 上的新 ChoosingGroupHeaderContainer 事件，你可以在
 ListView 或 GridView 中设置组标头的状态。例如，你可以通过处理此事件，将组标头上的 AutomationProperties.Nameproperty 设置为借助辅助技术来标识该组。









ChoosingItemContainer 事件



借助 ListViewBase 上的新 ChoosingItemContainer 事件，你可以更好地控制 ListView 或 GridView 中的
 UI 虚拟化。将此事件与ContainerContentChanging 事件结合使用，以保持你自己的要根据需要利用的回收容器的队列。例如，如果数据源因需筛选而被重置，你可以通过快速将一组已创建的视觉对象
 (ItemContainers) 与其对应的数据匹配获取最佳性能。









列表滚动虚拟化



XAML ListView 和 GridView 控件中有一个新 ListViewBase.ChooseingItemContainer 事件，该事件可在数据集合中发生更改时改进控件的性能。

系统现在将当前项与焦点状态和选择状态保留在视图中，而不是执行该列表的完全重置，这将重新播放 Entrance 动画；视口中的新项和已删除的项将流畅地闪烁。一旦未破坏的容器中的数据集合发生变化，应用即可快速将所有“旧”项与其之前的容器匹配，并跳过容器生命周期替代方法的进一步处理。仅“新”项得到处理并与回收的容器或新容器相关联。









SelectRange 方法和 SelectedRanges 属性



在通用 Windows 应用中，借助 ListView 和 GridView 控件，你现在可以根据项目索引的范围（而非项目对象引用）选择相应项目。这对于描述项目选项而言是一种非常有效的方式，因为无需针对每个选定项目创建项目对象。有关详细信息，请参阅ListViewBase.SelectedRanges、ListViewBase.SelectRange 和 ListViewBase.DeselectRange。









新 ListViewItemPresenter API



ListView 和 GridView 使用项目表示器来提供默认的视觉对象，以供选择和着重显示。在
 UWP 应用中，ListViewItemPresenter 和GridViewItemPresenter 具有新的属性，以便你可以针对列表项目进一步自定义视觉对象。新增的属性为
 heckBoxBrush、CheckMode、FocusSecondaryBorderBrush、PointerOverForeground、PressedBackground 和 SelectedPressedBackground。









SemanticZoom 更新



对于跨所有设备系列的 UWP 应用，SemanticZoom 控件现在具有一致的行为。

在放大视图和缩小视图之间切换的默认操作是，点击放大视图上的组标头。这与 Windows Phone 8.1 上的此类行为相同，不过在 Windows 8.1 上有所变动，因为其中使用了收缩手势进行缩放。若要使用收缩手势更改视图，应在 SemanticZoom 的内部 ScrollViewer 上设置 ScrollViewer.ZoomMode="Enabled"。

对于通用 Windows 应用，缩小视图将替代放大视图，并且前者与所替换的视图的大小相同。这与 Windows 8.1 上的此类行为相同，不过在 Windows Phone 8.1 上有所变动，因为其中缩小视图会占用整个屏幕，并且会在其他所有内容的顶部呈现。









DatePicker 和 TimePicker 更新



对于跨所有设备系列的通用 Windows 应用，DatePicker 和 TimePicker 控件现在具有一个一致的实现。此外，它们在
 Windows 10 中有了新的外观。弹出部分现在可在所有设备上使用 DatePickerFlyout 和 TimePickerFlyout 控件。这与
 Windows Phone 8.1 上的此类行为相同，不过在 Windows 8.1 上有所变动，因为其中可使用 ComboBox 控件。通过使用浮出控件，你可以更轻松地创建自定义的日期和时间选取器。









新的 ScrollViewer API



ScrollViewer 具有新的 DirectManipulationStarted 和 DirectManipulationCompleted 事件，可在触摸平移开始和停止时通知应用。你可以处理这些事件，以通过这些用户操作调整
 UI。









MenuFlyout 更新



通用 Windows 应用提供了可更轻松地构建更好的上下文菜单的全新 API。新 MenuFlyout.ShowAt 方法可用于指定浮出控件相对于其他元素的出现位置。（并且，你的
 MenuFlyout 甚至可以覆盖应用窗口边界。） 若要创建层叠菜单，请使用新的 MenuFlyoutSubItem类。









ContentPresenter、Grid 和 StackPanel 的新边框属性



常用容器控件具有新的边框属性，可用于在其周围绘制边框，而无需向你的 XAML 添加额外的边框元素。ContentPresenter、Grid 和StackPanel 具有以下新属性：
 BorderBrush、BorderThickness、CornerRadius 和 Padding。









ContentPresenter 上的新文本 API



ContentPresenter 具有可更好地控制文本显示的新 API： LineHeight、LineStackingStrategy、MaxLines
 和 TextWrapping。









系统焦点视觉对象



XAML 控件的焦点视觉对象现在由系统创建，而不是在控件模版中被声明为 XAML 元素。移动设备通常不需要焦点视觉对象，让系统按需创建并管理它们可改进应用性能。如果你需要更好地控制焦点视觉对象，可以替换该系统行为并提供定义焦点视觉对象的自定义控件模板。有关详细信息，请参阅 UseSystemFocusVisuals 和 IsTemplateFocusTarget。









PasswordBox.PasswordRevealMode



在通用 Windows 应用中，PasswordRevealMode 属性将替换
 IsPasswordRevealButtonEnabled 属性，以跨设备系列提供一致的行为。

警告： 在 Windows 10 之前的版本中，密码显示按钮默认处于不显示状态；在通用 Windows 应用中，它默认处于显示状态。如果设备安全要求始终掩盖密码，请务必将 PasswordRevealMode 设置为 Hidden。









Control.IsTextScaleFactorEnabled



以前可在 Windows Phone 8.1 上使用的 IsTextScaleFactorEnabled 属性现在可用于所有设备系列上的通用
 Windows 应用。









AutoSuggestBox



Windows Phone 8.1 中的 AutoSuggestBox 控件现在可用于所有设备系列上的通用
 Windows 应用，你应使用它而不是 SearchBox。AutoSuggestBox 在用户键入时即提供建议，与各种输入类型相辅相成，如触摸、键盘和输入法编辑器。它还具有一些可使之更好地发挥搜索框作用的新成员：QueryIcon 属性和 QuerySubmitted 事件。









ContentDialog



Windows Phone 8.1 中的 ContentDialog 控件现在可用于所有设备系列上的通用 Windows
 应用。ContentDialog 可用于显示可在所有系列的设备上完美运行的自定义模式对话框。









Pivot



Windows Phone 8.1 中的 Pivot 控件现在可用于所有设备系列上的通用 Windows 应用。现在，你可以将相同的
 Pivot 控件用于你的移动和桌面设备应用。Pivot 基于屏幕大小和输入类型提供自适应行为。你可以设置 Pivot 控件的样式，以提供类似选项卡的行为，每个透视项中包含不同的信息视图。

















文本



返回页首










Windows 内核文本 API



新的 Windows.UI.Text.Core 命名空间具有一个客户端-服务器系统功能，该系统可将键盘输入处理集中到单个服务器。

你可以使用它来操作自定义文本输入控件的编辑缓冲区。通过应用和服务器之间的异步通信通道，文本输入服务器可确保你的文本输入控件及其本身的编辑缓冲区内容始终保持同步。









矢量图标



Glyphs 元素具有新的 IsColorFontEnabled 和 ColorFontPalleteIndex 属性，可支持彩色字体；现在，你可以使用字体文件呈现基于字体的图标。在将
 ColorFontPalleteIndex 用于调色板切换时，可使用不同的颜色组合呈现一个图标；例如，显示该图标的启用和禁用版本。









“输入法编辑器”窗口事件



用户有时通过“输入法编辑器”输入文本，该编辑器显示在窗口中文本输入框的正下方（通常用于东亚语言）。若要使你的应用 UI 与 IME 窗口相得益彰，你可以对 TextBox 和 RichEditBox 使用
 CandidateWindowBoundsChanged 事件和 DesiredCandidateWindowAlignment 属性。









文本撰写事件



TextBox 和 RichEditBox 具有以下新事件，可在使用“输入法编辑器”撰写文本时通知应用：
 TextCompositionStarted、TextCompositionEnded 和 TextCompositionChanged。你可以处理这些事件，以通过 IME 文本撰写进程调整应用代码。例如，你可以为东亚语言实现内联自动完成功能。









改进的双向文本处理



XAML 文本控件具有全新 API，可改进双向文本处理，从而针对各种输入语言生成更好的文本对齐方式和段落方向。

TextReadingOrder 属性的默认值已更改为 DetectFromContent，因此对检测读取顺序的支持在默认情况下处于启用状态。TextReadingOrder 属性也已添加到 PasswordBox、RichEditBox 和 TextBox。

若要选择从内容自动检测对齐方式，可以将文本控件的 TextAlignment 属性设置为新的 DetectFromContent 值。









文本呈现



在 Windows 10 中，在大多数情况下，现在 XAML 应用中的文本的呈现速度几乎是 Windows 8.1 的两倍。在大多数情况下，你的应用将受益于此改进而无需任何更改。除了更快的呈现速度以外，这些改进还使 XAML 应用的常规内存消耗减少了 5%。

















应用程序模型



返回页首










Cortana



通过语音命令扩展 Cortana 的基本功能，这些命令用于在外部应用程序中启动并执行一个单独操作。

通过集成应用的基本功能，并通过为用户提供中心入口点以便在无需直接打开应用的情况下完成大多数任务，Cortana 可以充当应用和用户之间的联络人。在大多数情况下，这可以为用户节省大量时间和精力。

了解如何将应用集成到 Cortana Canvas。如果你需要创意，可以参考通用
 Windows 应用设计基础知识中特定于 Cortana 的设计建议和 UX 指南。









文件资源管理器



新的 Windows.System.Launcher.LaunchFolderAsync 方法允许你启动文件资源管理器并显示所指定的文件夹的内容。









共享存储



新的 Windows.ApplicationModel.DataTransfer.SharedStorageAccessManager 类及其方法允许你与另一个应用共享文件，方法是当通过使用
 URI 激活启动另一个应用时，传递一个共享标记。目标应用通过兑换该令牌来获取由源应用共享的文件。









设置



通过将 ms-settings 协议与 LaunchUriAsync 方法结合使用，显示内置的设置页面��例如，以下代码可用于显示
 Wi-Fi 设置页面。
bool result = await Launcher.LaunchUriAsync(new Uri("ms-settings://network/wifi"));

有关可以显示的设置页面列表，请参阅如何使用 ms-settings 协议显示内置设置页面。









应用到应用的通信



通过 Windows 10 中新增的应用到应用的通信 API，Windows 应用程序（以及 Windows Web 应用程序）可以相互启动并交换数据和文件。

利用这些新 API，使得原本需要用户使用多个应用程序才能完成的复杂任务现在可以无缝地进行处理。例如，你的应用可启动社交网络应用来选择联系人，或启动结算应用程序来完成支付流程。









应用服务



在 Windows 10 中，应用可以使用应用服务为其他应用提供服务。应用服务采用后台任务形式。前台应用可通过在其他应用中调用应用服务，在后台执行任务。有关应用服务 API 的参考信息，请参阅 Windows.ApplicationModel.AppService。









应用包清单



对 Windows 10 的程序包清单架构参考的更新包括已添加、已删除和已更改的元素。

有关该架构中所有元素、属性和类型的参考信息，请参阅元素层次结构。

















设备



返回页首










Microsoft Surface Hub



Microsoft Surface Hub 是一个功能强大的团队协作设备，也是一个适用于 Universal Windows App（可在 Surface Hub 上本机运行也可在连接设备上运行）的大屏幕平台。

Universal Windows App

构建你自己的应用（专为你的企业设计），从而充分利用大屏幕、触摸和墨迹输入以及相机和传感器等丰富的板载硬件。

请参阅 Universal Windows App 设计基础知识中特定于 Surface Hub 的设计建议和 UX 指南。这些文档介绍了面向 Universal Windows App 的响应式设计技术。

有关支持社区共享应用的详细信息，请参阅 SharedModeSettings。
有关墨迹输入以及在 InkCanvas 控件上支持多点墨迹的详细信息，请参阅 Windows.UI.Input.Inking 和Windows.UI.Input.Inking.Core。
有关处理传感器输入的详细信息，请参阅集成设备、打印机和传感器。









位置



Windows 10 引入了一个新方法 RequestAccessAsync 来提示用户提供其位置的访问权限。

用户可通过“设置”应用中的“位置隐私设置”，设置其位置数据的隐私。仅当出现以下情况时你的应用才可以访问用户的位置：

“该设备的位置”已打开（不适用于手机版 Windows 10）
位置服务设置中的“位置”已“打开”
在“选择可以使用你的位置的应用”下，你的应用已设置为“打开”

在访问用户的位置之前，务必调用 RequestAccessAsync。此时，你的应用必须在前台，并且 RequestAccessAsync 必须从 UI 线程中进行调用。除非用户向你的应用授予访问其位置的权限，否则你的应用无法访问位置数据。









AllJoyn



Windows.Devices.AllJoyn Windows 运行时命名空间引入了 Microsoft 实现的 AllJoyn 开放源代码软件框架和服务。这些
 API 使通用 Windows 设备应用可以在 Internet of Things (IoT) 应用场景中参与到 AllJoyn 驱动的其他设备中。有关 AllJoyn C API 的详细信息，请在 AllSeen Alliance 处下载相关文档。

使用该版本中所包含的 AllJoynCodeGen 工具，生成可用于在设备应用中启用 AllJoyn 方案的 Windows 组件。

注意： Windows 10 IoT Core 当前适用于一类新的小型设备，并且允许你使用 Windows 和 Visual Studio 创建“物联网”(IoT) 设备。了解有关 Windows IoT 的详细信息，网址为 WindowsOnDevices.com









移动设备上的打印 API (XAML)



你可以使用一个统一的 API 组，在设备系列（包括移动设备）上通过基于 XAML 的 UWP 应用进行打印。现在，你可以从 Windows.Graphics.Printing 和 Windows.UI.Xaml.Printing 命名空间使用熟悉的与打印相关的 API，将打印添加到你的移动应用。









电池



通过 Windows.Devices.Power 命名空间中的电池 API，你的应用可了解连接到正在运行该应用的设备的所有电池的详细信息。

通过创建 Battery 对象来表示单个电池控制器或聚合的所有电池控制器（在它们分别由 FromIdAsync 或 AggregateBattery创建后）。
使用 GetReport 方法返回 BatteryReport 对象，该对象可指示相应电池的充电、容量和状态。









MIDI 设备



新的 Windows.Devices.Midi 命名空间允许你创建以下内容：

可以与外部 MIDI 设备通信的应用。
可直接与 Microsoft GS MIDI 软件合成��通信的应用和外部设备。
多个客户端同时访问单个 MIDI 端口的场景。









自定义传感器支持



Windows.Devices.Sensors.Custom 命名空间允许硬件开发人员定义新的自定义传感器类型，例如 CO2
 传感器。









基于主机的卡片模拟 (HCE)



使用主机卡模拟，可实现操作系统中所托管的 NFC 卡片模拟服务，并且仍然可以通过 NFC 射频硬件与外部读取器通信。

实现后台任务需通过 NFC 模拟智能卡。若要触发后台任务，请使用 SmartCardTrigger 类。

SmartCardTriggerType 枚举中的 EmulatorHostApplicationActivated
 值会让你的应用知道 HCE 事件已发生。

















图形



返回页首










DirectX



Windows 10 中的 DirectX 12 在 DirectX 的核心处引入了下一代版本的 Microsoft Direct3D，即 3D Graphics API。Direct3D 12 Graphics 能使低级别、类似控制台的
 API 发挥效率和性能。Direct3D 12 现在比以往更快、更有效。它提供更丰富的场景、更多的对象、更复杂的效果，并且能更好地利用现代图形硬件。









SoftwareBitmapSource



在通用 Windows 应用中，可将新的 SoftwareBitmapSource 类型用作
 XAML 图像源。这可将未编码的图像传递到 XAML 框架，从而立即显示在屏幕上，同时避免 XAML 框架对图像进行编码。你可以实现更快速的图像呈现，如直接通过相机呈现低延迟照片、使用自定义图像解码器、从 DirectX 图面捕获帧，或者甚至从零开始创建内存中图像并直接使用 XAML 呈现所有这些图像，延迟和内存开销均较低。









透视相机



在通用 Windows 应用中，XAML 具有全新 Transform3D API，它可用于将透视转换应用到 XAML 树（或场景），后者再根据该单一场景范围的转换（或相机）来转换所有 XAML 子元素。虽然在以前，你可以通过使用 MatrixTransform 和复杂的数学运算来实现此转换，但是 Transform3D 显著地简化了此效果，同时还可以动画方式呈现该效果。有关详细信息，请参阅 UIElement.Transform3D 属性、Transform3D、CompositeTransform3D 和 PerspectiveTransform3D。

















媒体



返回页首










HTTP 实时流



你可以使用新的 AdaptiveMediaSource 类将自适应视频流功能添加到你的应用。通过将对象指向流清单文件对其进行初始化。受支持的清单格式包括
 HTTP 实时流 (HLS) 和基于 HTTP 的动态自适应流 (DASH)。一旦将对象绑定到 XAML 媒体元素，将开始自适应播放。可以在适当情况下查询和设置流的属性，例如可用比特率、最小和最大比特率。









媒体基础转换代码视频处理器 (XVP) 支持媒体基础转换 (MFT)



使用媒体基础转换 (MFT) 的 Windows 应用现在可以使用媒体基础转换代码视频处理器 (XVP) 来转换、缩放和转化原始视频数据：

新 MF_XVP_CALLER_ALLOCATES_OUTPUT 属性支持输出到调用方分配的纹理，即使在
 Microsoft DirectX 视频加速 (DXVA) 模式下也是如此。
新 IMFVideoProcessorControl2 接口允许你的应用启用硬件效果、查询支持的硬件效果以及替代由视频处理器执行的旋转操作。









转码



新 MediaProcessingTrigger API
 让你的应用在后台任务中执行媒体转码，这样即使当前台应用已终止，也可以继续进行转码操作。









MediaElement 媒体失败事件



在通用 Windows 应用中，MediaElement 将播放包含多个流的内容，即使其中一个流具有解码错误，只要媒体内容包含至少一个有效流即可。例如，如果包含音频流和视频流的内容中的视频流失败，MediaElement 仍将播放音频流。 PartialMediaFailureDetected会通知你流内的其中一个流无法解码。它还允许你知道哪种类型的流失败，以便你可以在
 UI 中反映该信息。如果在媒体流内的所有流失败，将引发 MediaFailed 事件。









通过 MediaElement 支持自适应视频流



MediaElement 具有新的 SetPlaybackSource 方法，可支持自适应视频流。若要将你的媒体源设置为
 AdaptiveMediaSource，请使用此方法。









通过“MediaElement 和图像”进行强制转换



“MediaElement 和图像”控件具有新的 GetAsCastingSource 方法。你可以使用此方法，以编程方式将任何媒体或图像元素中的内容发送到更多远程设备，如
 Miracast、蓝牙和 DLNA。当你将 MediaElement 的 AreTransportControlsEnabled 设置为
 true 时，此功能将自动启用。









桌面应用的媒体传输控件



ISystemMediaTransportControls 接口和相关的 API 允许桌面应用与内置的系统媒体传输控件交互。这包括使用传输控件按钮响应用户交互，以及更新传输控件显示，以显示有关当前正在播放的媒体内容的元数据。









随机访问 JPEG 编码和解码



新的 WIC 方法 IWICJpegFrameEncode 和 IWICJpegFrameDecode 支持
 JPEG 图像的编码和解码。你现在还可以编制图像数据的索引，它以较大的内存占用为代价提供对大型图像的高效随机访问。









媒体组合的重叠



新 MediaOverlay 和 MediaOverlayLayer API
 更便于向媒体组合添加静态或动态媒体内容的多个层。可以为每个层调整不透明度、位置和计时，你甚至可以为输入层实现你自己的自定义复合器。









新效果框架



Windows.Media.Effects 命名空间提供了简单、直观的框架，以便将效果添加到音频和视频流。框架包含可以实现创建自定义的音频和视频效果并将它们插入到媒体管道的基本接口。

















网络



返回页首










套接字



套接字更新包括：

套接字代理。套接字代理可以代表处于应用生命周期中任意状态的应用建立和关闭套接字连接。这使应用和它们提供的服务更容易被发现。例如，通过套接字代理，Win32 服务仍可接受传入的套接字连接，即便是该服务不在运行也是如此。
吞吐量改进。套接字吞吐量已针对使用 Windows.Networking.Sockets 命名空间的应用进行了优化。









后台传输后续处理任务



你可以利用 Windows.Networking.BackgroundTransfer 命名空间中的新 API
 注册后续处理的任务组。这样你的应用便可以立即根据后台传输的成功或失败执行操作，而不是等待下次用户恢复它，即使该应用不在前台运行也是如此。









广告的蓝牙支持



借助 Windows.Devices.Bluetooth.Advertisement 命名空间，你的应用可以发送、接收并筛选蓝牙
 LE 广告。









Wi-Fi Direct API 更新



更新设备代理，以实现在不离开应用的情况下与设备匹配。除此之外，Windows.Devices.WiFiDirect 命名空间还可以让某个设备能够检测到其他设备，并让该设备侦听传入的连接通知。

注意在此版本中，Wi-Fi Direct 功能改进未内置于 UX 中，并且它们仅支持一键配对。此外，此版本仅支持一个活动连接。









JSON 支持改进



在调试会话期间，转换 JSON 对象时，Windows.Data.Json 命名空间现在能更好地支持已有的标准定义和开发人员体验。

















安全性



返回页首










ECC 加密



Windows.Security.Cryptography 命名空间中的新 API 支持椭圆曲线密码 (ECC)，后者是基于有限域上椭圆曲线的公共密钥加密实现。在算法上，ECC
 比 RSA 更为复杂，它提供更小的密钥大小、可减少内存占用并且可提高性能。它提供 Microsoft 服务并且向客户提供 RSA 密钥和 NIST 批准曲线参数的替代方法。









Microsoft Passport



Microsoft Passport 是身份验证的替代方法，它使用非对称加密和手势来替代密码。“凭据”命名空间中的类（如KeyCredentialManger）让开发人员可以轻松通过
 Microsoft Passport 来创建应用程序，而无需使用复杂的加密或生物识别。









Microsoft Passport for Work



Microsoft Passport for Work 是使用 Azure Active Directory 帐户登录 Windows 的替代方法，它无需使用密码、智能卡和虚拟智能卡。你可以选择是禁用还是启用此策略设置。









令牌代理



令牌是一个新型的身份验证框架，可让应用更加轻松地连接到联机标识提供程序（例如 Facebook）。通过诸如帐户用户名和密码管理以及简化的 UI 等功能，将大幅度改善为用户提供的身份验证体验。

















系统服务



返回页首










电源



现在，当节电模式处于启用或未启用状态时，你的 Windows 桌面应用程序将得到通知。通过响应电源条件更改，你的应用程序将有机会帮助延长电池使用时间。

GUID_POWER_SAVING_STATUS： 将此新的 GUID
 与 PowerSettingRegisterNotification 函数结合使用，以便在节电模式处于启用或未启用状态时收到通知。
SYSTEM_POWER_STATUS： 已将此结构更新为支持节电模式。第四个成员 SystemStatusFlag（以前称为
 Reserved1）现在指示节电模式是否处于启用状态。使用 GetSystemPowerStatus 函数检索指向此结构的指针。









版本



你可以使用版本帮助程序函数确定操作系统的版本。在 Windows 10 中，这些帮助程序函数包括一个新函数 IsWindows10OrGreater。如果你想要确定系统版本，则应该使用帮助程序函数，而不是使用已弃用的 GetVersionEx 和 GetVersion 函数。有关如何获取系统版本的详细信息，请参阅获取系统版本。

如果你使用已弃用的 GetVersionEx 或 GetVersion 函数在 OSVERSIONINFOEX 或 OSVERSIONINFO 结构中获取版本信息，请注意，这些结构包含的版本号将从适用于
 Windows 8.1 和 Windows Server 2012 R2 的 6.3 版增加到适用于 Windows 10 的 10.0 版。有关操作系统版本号的详细信息，请参阅操作系统版本。

你还需要在你的应用程序中明确定向到 Windows 8.1 或 Windows 10，以使用 GetVersionEx 或 GetVersion 函数获取有关这些版本的正确版本信息。有关如何针对这些版本的
 Windows 定向你的应用程序的信息，请参阅针对 Windows 定向你的应用程序。









用户信息



Windows.System 命名空间中的新 API 使你可以轻松访问用户相关信息，例如其用户名和头像。它还提供响应诸如登录和注销等用户事件的功能。









内存管理和分析



对 Windows.System 中内存分析 API 的支持已扩展至所有平台，并且其整体功能已通过新的类和函数进行增强。

















存储



返回页首










文件搜索 API 可用于 Windows Phone



作为应用发布者，你可以注册你的应用，以便通过将扩展添加到应用清单，与其他应用共享存储文件夹。然后，调用Windows.Storage.ApplicationData.GetPublisherCacheFolder 方法来获取共享的存储位置。

Windows 运行时应用的强大安全模型通常可防止应用在它们自己间共享数据。但是，在来自同一个发布者的应用基于每个用户共享文件和设置时，这可能会很有用。

















工具



返回页首










Visual Studio 中的 Live Visual Tree



Visual Studio 具备全新的 Live Visual Tree 功能。你可以在调试时用它来快速地了解应用可视化树的状态，并发现设置元素属性的方式。它还可用于在应用运行时更改属性值，以便在无需重新启动的情况下进行调整和实验。









跟踪日志记录



跟踪日志记录是适用于用户模式应用和内核模式驱动程序的全新事件跟踪 API；它构建在 Windows
 事件跟踪 (ETW) 的基础之上。此 API 提供了一种简化方式来检测代码和在结构数据中包括事件，而无需要求单独的检测清单 XML 文件。

WinRT、.NET 和 C/C++ 跟踪日志记录 API 可为不同的开发人员受众提供服务。

















用户体验



返回页首










语音识别



通用 Windows 平台现已支持针对长篇听写场景的连续语音识别。请参阅“语音交互”文档中的“如何启用连续听写”。









不同应用程序平台之间的拖放功能



新 Windows.ApplicationModel.DataTransfer.DragDrop 命名空间为通用
 Windows 应用提供拖放功能。以前，桌面程序中的常见拖放方案（例如将文档从文件夹拖动到需要附加它的 Outlook 电子邮件中）不适用于通用 Windows 应用。通过使用这些新的 API，你的应用可以让用户轻松地在不同的通用 Windows 应用和桌面之间移动数据。

为支持在应用间拖放，已向 XAML 添加以下新 API：

ListViewBase.DragItemsCompleted
UIElement： CanDrag、DragStarting、StartDragAsync、DropCompleted
DragOperationDeferral、DragUI、DragUIOverride
DragEventArgs： AcceptedOperation、DataView、DragUIOverride、GetDeferral、Modifiers
DragItemsCompletedEventArgs、DropCompletedEventArgs、DragStartingEventArgs









自定义窗口标题栏



对于适用于桌面设备系列的 UWP 应用，现在可以将 ApplicationViewTitleBar 类与 ApplicationView.TitleBar 属性和Window.SetTitleBar 方法结合使用，以便将默认
 Windows 标题栏内容替换为你自己的自定义 XAML 内容。你的 XAML 将被视为“系统镶边”，因此 Windows（而不是你的应用）将处理输入事件。这意味着用户仍可拖动窗口并调整大小，即使在单击自定义标题栏内容时也是如此。

















Web



返回页首










Internet Explorer



Internet Explorer 中引入了边缘模式，这是一种新的“动态”文档模式，旨在实现与其他现代浏览器和现代 Web 内容的最大互操作性。正在逐渐将此实验模式推广给随机选择的一组 Windows 10 用户。你可以通过新的 IE about:flags 机制手动启用或禁用边缘模式。有关详细信息，请参阅：

边缘模式实际应用 - 下一步是帮助 Web 正常工作
Internet Explorer for Windows 10 开发人员指南









WebView Edge 模式浏览



WebView 控件与新的 Edge 浏览器使用相同的呈现引擎。这提供了最精确、最符合标准的 HTML 呈现模式。









线程外 WebView



若要允许处理和显示单独后台线程上的 Web 内容，可以指定 WebView.ExecutionMode。这可以改进某些特定方案的性能。









WebView.UnsupportedUriSchemeIdentified 事件



新 WebView.UnsupportedUriSchemeIdentified 事件可用于确定你的应用处理不受支持的
 URI 方案的方式。若要让你的应用提供用于不受支持的 URI 方案的自定义处理方式，你可以处理此事件。

有关 HTML WebView 控件，请参阅 MSWebViewUnsupportedUriSchemeIdentified 事件。









WebView.NewWindowRequested 事件



新 WebView.NewWindowRequested 事件使你可以在 WebView
 中的脚本请求新浏览器窗口时做出响应。

有关 HTML WebView 控件，请参阅 MSWebViewNewWindowRequested 事件。









WebView.PermissionRequested 事件



新 WebView.PermissionRequested 事件允许 WebView
 内容使用丰富的全新 HTML5 API，它们需要获得特殊的用户权限，如地理位置。

有关 HTML WebView 控件，请参阅 MSWebViewPermissionRequested 事件。









WebView.UnviewableContentIdentified 事件



新 WebView.UnviewableContentIdentified 事件使你可以在
 WebView 导航到 PDF 文件或 Office 文档等非 Web 内容时做出响应

有关 HTML WebView 控件，请参阅 MSWebViewUnviewableContentIdentified 事件。









WebView.AddWebAllowedObject 方法



你可以通过调用新 WebView.AddWebAllowedObject 方法，将
 WinRT 对象注入 XAML WebView 中，然后通过托管在该 WebView 中的可信 JavaScript 来调用其函数。例如，Web 内容可以通过请求其父应用调用 ToastNotificationManager WinRT
 API，显示系统通知。

有关 HTML WebView 控件，请参阅 addWebAllowedObject 方法。









WebView.ClearTemporaryWebDataAync 方法



当用户与 XAML WebView 中的 Web 内容交互时，WebView 控件将根据该用户的会话缓存数据。若要清除此缓存，可以调用新的ClearTemporaryWebDataAsync 方法。例如，你可以在某位用户注销应用后清除缓存，这样另一位用户便无法访问上一会话中的任何数据。

概要
本文介绍了如何在 Windows Server 2003 中配置 DNS 动态更新功能。利用 DNS 动态更新功能，DNS 客户端计算机能够注册到 DNS 服务器并在每次发生更改时动态更新其资源记录。使用此功能可以减少对区域记录进行手动管理的需要，尤其是对于经常移动并使用“动态主机配置协议”(DHCP) 获取“Internet 协议”(IP) 地址的客户端更是如此。

Windows Server 2003 提供了对动态更新功能的支持，如“请求注释”(RFC) 2136 中所述。对于 DNS 服务器，DNS 服务允许您在每个配置为加载标准主区域或目录集成区域的服务器上按区域启用或禁用 DNS 动态更新功能。


回到顶端 

Windows Server 2003 DNS 动态更新功能
客户端计算机可通过 DNS 服务在 DNS 中动态更新其资源记录。使用此功能可以减少手动管理区域记录所需的时间，从而改进了 DNS 管理。您可以将 DNS 动态更新功能与 DHCP 结合使用，以便在计算机的 IP 地址更改时更新资源记录。运行 Windows Server 2003 的计算机可以发送动态更新。

Windows Server 2003 提供了下列与 DNS 动态更新协议相关的功能： • 支持将 Active Directory 目录服务用作域控制器的定位器服务。 
• 与 Active Directory 集成。

可以将 DNS 区域集成到 Active Directory 中以提供增强的容错功能和安全性。每个 Active Directory 集成的区域都在 Active Directory 域中的所有域控制器中进行复制。在这些域控制器上运行的所有 DNS 服务器都可以充当该区域的主服务器并接受动态更新。Active Directory 复制以属性为基础进行，并只传播相关的更改。 
• 支持老化和清理记录。

DNS 服务可以扫描并删除不再需要的记录。启用此功能可以防止在 DNS 中保留陈旧记录。 
• 支持在 Active Directory 集成的区域中进行安全动态更新。

您可以为 Active Directory 集成的区域配置安全动态更新，以便只允许授权用户更改区域或记录。 
• 在命令提示符下进行管理。 
• 增强的名称解析。 
• 增强的缓存和否定缓存。 
• 可以与其他 DNS 服务器实现进行互操作。 
• 与其他网络服务集成。 
• 增量区域复制。 

回到顶端 

基于 Windows Server 2003 的计算机如何更新其 DNS 名称
默认情况下，运行 Windows Server 2003 并以静态方式配置了 TCP/IP 的计算机尝试动态注册由其安装的网络连接配置和使用的 IP 地址的主机地址 (A) 和指针 (PTR) 资源记录。默认情况下，所有计算机注册记录均基于其完整的计算机名。

对于 Windows Server 2003 计算机，主要完整计算机名（一个完全合格的域名 [FQDN]）是附加到计算机名的计算机的主 DNS 后缀。要确定计算机的主 DNS 后缀和计算机名，请右键单击“我的电脑”，单击“属性”，然后单击“计算机名”。

动态更新可以根据以下任一原因或事件发送： • 在已安装的任一网络连接的 TCP/IP 属性配置中添加、删除或修改了 IP 地址。 
• IP 地址租约通过 DHCP 服务器更改或续订了任一已安装的网络连接。例如，当计算机启动时，或者您使用 ipconfig /renew 命令时。 
• 使用 ipconfig /registerdns 命令手动强制在 DNS 中刷新客户端名称注册。 
• 启动时，即打开计算机时。 
• 成员服务器升级为域控制器。 
当以上事件之一触发动态更新时，DHCP 客户端服务（而非 DNS 客户端服务）将发送更新。如果由于 DHCP 而导致 IP 地址信息发生更改，DNS 中会执行对应的更新，以同步计算机的名称到地址映射。DHCP 客户端服务为系统中的所有网络连接（包括未配置为使用 DHCP 的连接）执行此功能。

注意：• 使用 DHCP 获取其 IP 地址的基于 Windows Server 2003 的计算机的动态更新过程与本部分介绍的过程有所不同。有关更多信息，请参阅本文的 将 DHCP 与 DNS 集成 部分和Windows DHCP 客户端和 DNS 动态更新协议 部分。 
• 本部分介绍的更新过程假定 Windows Server 2003 安装默认值有效。如果将高级 TCP/IP 属性配置为使用非默认 DNS 设置，则可以调整特定名称和更新行为。 
• 除计算机的完整计算机名（或主要名称）以外，您可以配置其他特定于连接的 DNS 名称，也可以在 DNS 中注册或更新它们。 

动态更新工作原理的示例
对于 Windows Server 2003，当计算机的 DNS 名称或 IP 地址更改时，通常会请求动态更新。例如，名为“oldhost”的客户端最初在系统属性中配置为使用以下名称：
计算机名：oldhost
计算机的 DNS 域名：example.microsoft.com
完整计算机名：oldhost.example.microsoft.com
在本示例中，没有为计算机配置连接特定的 DNS 域名。如果将计算机从“oldhost”重命名为“newhost”，将发生以下名称更改：
计算机名：newhost
计算机的 DNS 域名：example.microsoft.com
完整计算机名：newhost.example.microsoft.com

在系统属性中应用名称更改后，Windows Server 2003 将提示您重新启动计算机。计算机重新启动 Windows 后，DHCP 客户端服务将按顺序执行以下步骤以更新 DNS： 1. DHCP 客户端服务使用计算机的 DNS 域名发送起始授权机构 (SOA) 类型查询。

客户端计算机使用计算机当前配置的 FQDN（如“newhost.example.microsoft.com”）作为此查询中指定的名称。 
2. 区域中包含此客户端 FQDN 的权威性 DNS 服务器响应此 SOA 类型查询。

对于标准的主要区域，在 SOA 查询中返回的主服务器（所有者）是固定和静态的。它始终与准确的 DNS 名称相匹配，因为该名称显示在区域中存储的 SOA 资源记录中。然而，如果正在更新的区域是目录集成的区域，则任何正在加载此区域的 DNS 服务器都可以响应此 SOA 查询并在 SOA 查询响应中插入它自己的名称作为此区域的主服务器（所有者）。 
3. DHCP 客户端服务尝试联系主 DNS 服务器。

客户端处理对其名称的 SOA 查询的响应，以确定被授权作为接受其名称的主服务器的 DNS 服务器的 IP 地址。如有必要，客户端将继续执行以下过程，以联系并动态更新其主服务器： a. 客户端向在 SOA 查询响应中确定的主服务器发送一个动态更新请求。

如果更新成功，则不执行其他操作。 
b. 如果此更新失败，则客户端接下来针对在 SOA 记录中指定的区域名称发送一个 NS 类型查询。 
c. 客户端在收到此查询的响应时，将向此响应中列出的第一个 DNS 服务器发送 SOA 查询。 
d. 解析此 SOA 查询后，客户端将向在返回的 SOA 记录中指定的服务器发送动态更新。

如果更新成功，则不执行其他操作。 
e. 如果此更新失败，则客户端将通过向在响应中列出的下一个 DNS 服务器发送动态更新来重复 SOA 查询过程。 

4. 联系到可以执行更新的主服务器后，客户端将发送更新请求，然后服务器处理该请求。 

更新请求的内容包括指示添加“newhost.example.microsoft.com”的 A（以及可能的 PTR）资源记录并删除“oldhost.example.microsoft.com”（先前注册的名称）的这些相同的记录类型。

服务器还将进行检查以确保允许根据客户端请求进行更新。对于标准的主要区域，动态更新是不安全的并且任何客户端的更新尝试都会成功。对于 Active Directory 集成的区域，更新是安全的并且使用基于目录的安全设置执行更新。 
动态更新定期发送或刷新。默认情况下，计算机每 7 天发送一次刷新。如果发生更新而区域数据未更改，则区域仍保持其当前版本并且不写入更改。仅当名称或地址实际更改时，才会传输导致实际区域更改或增大区域的更新。

注意：处于非活动状态或在刷新间隔（7 天）中未更新的名称将不从 DNS 区域中删除。DNS 不通过某种机制来释放或删除名称，尽管 DNS 客户端的确在应用新名称或地址更改后尝试删除或更新旧名称记录。

DHCP 客户端服务在注册 Windows Server 2003 计算机的 A 和 PTR 资源记录时，对主机记录使用默认的缓存生存期 (TTL) 值，即 15 分钟。该值决定其他 DNS 服务器和客户端对包含在查询响应中的计算机的记录进行缓存的时间长度。


将 DHCP 与 DNS 集成
使用 Windows Server 2003，DHCP 服务器可以在 DNS 名称空间中为支持动态更新的任何客户端启用动态更新。作用域客户端可以在 DHCP 为其分配的地址发生更改时，使用 DNS 动态更新协议更新其主机名到地址映射信息。（此映射信息存储在 DNS 服务器上的区域中。）Windows Server 2003 DHCP 服务器可以代表其 DHCP 客户端对任何 DNS 服务器执行更新。


DHCP/DNS 更新交互的工作原理
您可以使用 DHCP 服务器代表其启用了 DHCP 的客户端注册和更新 PTR 和 A 资源记录。执行此操作时，您必须使用另一 DHCP 选项，即“客户端 FQDN”选项（选项 81）。此选项允许客户端提供其 FQDN 并指示 DHCP 服务器如何代表它处理 DNS 动态更新（如果有更新）。

当合格的 DHCP 客户端（如运行 Windows Server 2003、Microsoft Windows 2000 或 Microsoft Windows XP 并启用了 DHCP 的计算机）发出此选项后，Windows Server 2003 DHCP 服务器将处理并解释此选项，以确定如何代表该客户端初始化更新。

例如，您可以使用以下任一配置来处理客户端请求： • 根据客户端请求，DHCP 服务器通过其配置的 DNS 服务器注册和更新客户端信息。

这是 Windows Server 2003 DHCP 服务器和运行 Windows Server 2003、Windows 2000 或 Windows XP 的客户端的默认配置。在此模式下，任何 Windows DHCP 客户端都可以指定 DHCP 服务器更新其主机 A 和 PTR 资源记录的方式。如果可能，DHCP 服务器将接受客户端对其 DNS 中的名称和 IP 地址信息进行更新的处理请求。

要将 DHCP 服务器配置为根据客户端的请求注册客户端信息，请打开服务器或单个作用域的 DHCP 属性，单击“DNS”选项卡，单击“属性”，然后单击“只有在 DHCP 客户端请求时才动态更新 DNS A 和 PTR 记录”复选框，将其选中。 
• DHCP 服务器始终通过其配置的 DNS 服务器注册和更新客户端信息。

这是修改后的配置，Windows Server 2003 DHCP 服务器和运行 Windows Server 2003、Windows 2000 或 Windows XP 的客户端均支持该配置。在此模式下，DHCP 服务器始终对客户端的 FQDN 和租用的 IP 地址信息（包括其主机 A 和 PTR 资源记录）执行更新，而不管客户端是否已请求执行它自身的更新。

要将 DHCP 服务器配置为通过其配置的 DNS 服务器注册和更新客户端信息，请打开服务器的 DHCP 属性，单击“DNS”，单击“属性”，单击“根据下面的设置启用 DNS 动态更新”复选框，然后单击“总是动态更新 DNS A 和 PTR 记录”。 
• DHCP 服务器从不通过其配置的 DNS 服务器注册和更新客户端信息。

要使用此配置，必须将 DHCP 服务器配置为禁止执行 DHCP/DNS 代理更新。使用此配置时，将不更新 DHCP 客户端的 DNS 中的客户端主机 A 或 PTR 资源记录。

要将服务器配置为从不更新客户端信息，请打开 DHCP 服务器或它在 Windows Server 2003 DHCP 服务器上的某个作用域的 DHCP 属性，单击“DNS”，单击“属性”，然后清除“根据下面的设置启用 DNS 动态更新”复选框。默认情况下，始终对新安装的 Windows Server 2003 DHCP 服务器和为其创建的任何新作用域执行更新。 

Windows DHCP 客户端和 DNS 动态更新协议
运行 Windows Server 2003、Windows 2000 或 Windows XP 的 DHCP 客户端与运行早期版本的操作系统的 DHCP 客户端在执行 DHCP/DNS 交互方式时存在差别。以下示例说明了此过程在不同情况下的差别。


Windows Server 2003、Windows 2000 和 Windows XP DHCP 客户端的 DHCP/DNS 更新交互的示例
Windows Server 2003、Windows 2000 和 Windows XP DHCP 客户端按以下方式与 DNS 动态更新协议进行交互： 1. 客户端向服务器初始化一个 DHCP 请求消息 (DHCPREQUEST)。该请求包含选项 81。 
2. 服务器向客户端返回 DHCP 确认消息 (DHCPACK)，该消息向客户端授予 IP 地址租约，并包含选项 81。如果 DHCP 服务器的配置为默认设置，则选项 81 告知客户端：DHCP 服务器将注册 DNS PTR 记录，客户端将注册 DNS A 记录。 
3. 客户端向 DNS 服务器异步发送一个 DNS 更新请求，请求更新它自身的正向查找记录（主机 A 资源记录）。

4. DHCP 服务器注册客户端的 PTR 记录。 

使用 Windows Server 2003 以前的 Windows 版本的 Windows DHCP 客户端的 DHCP/DNS 更新交互的示例
早期版本的 Windows DHCP 客户端不直接支持 DNS 动态更新过程，并且无法与 DNS 服务器直接交互。对于这些 DHCP 客户端，通常按以下方式处理更新： 1. 客户端向服务器初始化一个 DHCP 请求消息 (DHCPREQUEST)。该请求不包含选项 81。 
2. 服务器向客户端返回 DHCP 确认消息 (DHCPACK)，该消息向客户端授予 IP 地址租约，但不包含选项 81。 
3. 服务器向 DNS 服务器发送客户端的正向搜索记录（主机 A 资源记录）更新，服务器还发送客户端的 PTR 反向搜索记录更新。 

安全动态更新
对于 Windows Server 2003，只有已集成到 Active Directory 的区域才可以获得 DNS 更新安全性。将区域集成到目录后，您可以使用 DNS 管理单元中提供的访问控制列表 (ACL) 编辑功能在特定区域或资源记录的 ACL 中添加或删除用户或组。

有关更多信息，请参阅 Windows Server 2003 帮助，并搜索 To modify security for a resource record（修改资源记录的安全性）或 To modify security for a directory integrated zone（修改目录集成区域的安全性）。

默认情况下，按以下方式处理 Windows Server 2003 DNS 服务器和客户端的动态更新安全性： 1. Windows Server 2003 DNS 客户端首先尝试使用不安全的动态更新。如果不安全的更新被拒绝，则客户端尝试使用安全更新。

此外，客户端还使用允许它们尝试覆盖先前注册的资源记录的默认更新策略，除非更新安全性明确禁止这些客户端。 
2. 当区域成为 Active Directory 集成区域后，Windows Server 2003 DNS 服务器在默认情况下只允许安全动态更新。 
使用标准区域存储时，DNS 服务器服务在默认情况下不允许对其区域进行动态更新。对于目录集成的区域或使用基于标准文件的存储的区域，您可以将区域更改为允许所有动态更新。这样，即可通过使用安全更新来接受所有更新。

重要说明：“DHCP 服务器”服务可以为不支持动态更新的旧式客户端执行代理注册和 DNS 记录更新。有关更多信息，请参阅 Windows Server 2003 帮助，并搜索 Using DNS servers with DHCP（通过 DHCP 使用 DNS 服务器）。

如果在网络上使用多个 Windows Server 2003 DHCP 服务器，并将区域配置为只允许安全动态更新，请使用“Active Directory 用户和计算机”管理单元将 DHCP 服务器计算机添加到内置的 DnsUpdateProxy 组。这样，所有 DHCP 服务器都将拥有为任何 DHCP 客户端执行代理更新的安全权限。有关更多信息，请参阅 Windows Server 2003 帮助，并搜索 Using DNS servers with DHCP（通过 DHCP 使用 DNS 服务器）或 Manage groups（管理组）。

注意：在 Windows Server 2003 中，如果在域控制器上运行 DHCP 服务器，并将 Windows Server 2003 DHCP 服务器配置为代表其客户端执行 DNS 记录注册，则可能会对安全动态更新功能造成负面影响。要避免此问题，请将 DHCP 服务器和域控制器部署在不同的计算机上，或配置 DHCP 使用专用的用户帐户进行动态更新。有关更多信息，请参阅 Windows Server 2003 帮助，并搜索 Using DNS servers with DHCP（通过 DHCP 使用 DNS 服务器）。

有关更多信息，请参阅本文的 使用 DnsUpdateProxy 组时的安全注意事项 部分中列出的文件版本，则无需这些更新。


只允许安全动态更新
1. 单击“开始”，指向“管理工具”，然后单击“DNS”。 
2. 在“DNS”下，双击相应的 DNS 服务器，双击“正向查找区域”或“反向查找区域”，然后右键单击相应的区域。 
3. 单击“属性”。 
4. 在“常规”选项卡上，确认区域类型为“Active Directory 集成的区域”。 
5. 在“动态更新”框中，单击“安全”。 
6. 单击“确定”。 
注意：只有 Active Directory 集成的区域支持安全动态更新功能。如果配置其他区域类型，则必须更改区域类型并将其集成到目录中，然后才能对其进行安全的 DNS 动态更新。动态更新是对 DNS 标准的符合 RFC 的扩展。RFC 2136 的“域名系统中的动态更新 (DNS UpdateS)”部分定义了 DNS 更新过程。


使用 DnsUpdateProxy 安全组
您可以对 Windows Server 2003 DHCP 服务器进行配置，以便它能够代表 DHCP 客户端动态注册主机 A 和 PTR 资源记录。如果您对 Windows Server 2003 DNS 服务器使用此配置中的安全动态更新，则资源记录可能会变得陈旧。

例如，假设下面的情形： 1. Windows Server 2003 DHCP 服务器 (DHCP1) 代表它的某个客户端对特定的 DNS 域名执行安全动态更新。 
2. 由于 DHCP 服务器成功创建了此名称，因此它成为该名称的所有者。 
3. 当此 DHCP 服务器成为该客户端名称的所有者后，只有此 DHCP 服务器可以更新该名称。 
在某些情况下，这可能会引起问题。例如，如果 DHCP1 出现故障，且另一个备份 DHCP 服务器变为联机状态，则由于此备份服务器不是该客户端名称的所有者，因此它无法更新此客户端名称。

在另一示例中，如果 DHCP 服务器为旧式客户端执行动态更新，然后您将这些客户端升级到 Windows Server 2003、Windows 2000 或 Windows XP，那么升级后的客户端无法拥有或更新其 DNS 记录。

为解决此问题，Windows 提供了名为 DnsUpdateProxy 的内置安全组。如果所有 DHCP 服务器都被添加为 DnsUpdateProxy 组的成员，那么在某个服务器出现故障时，可以由其他服务器更新该服务器的记录。另外，由于 DnsUpdateProxy 组成员创建的所有对象都不受安全保护，第一个修改与 DNS 名称相关的记录集的用户（不是 DnsUpdateProxy 组成员）就成为名称的拥有者。因此，当旧式客户端升级后，它们可以获得自己在 DNS 服务器上的名称记录的所有权。如果为旧式客户端注册资源记录的每个 DHCP 服务器都是 DnsUpdateProxy 组成员，则可避免本文前面讨论的问题。


向 DnsUpdateProxy 组添加成员
使用“Active Directory 用户和计算机”管理单元配置 DnsUpdateProxy 安全组。

注意：如果使用多个 DHCP 服务器提供容错功能，并使用安全动态更新，请将每个服务器添加到 DnsUpdateProxy 全局安全组。


使用 DnsUpdateProxy 组时的安全注意事项
如果 DHCP 服务器是 DnsUpdateProxy 组成员，那么由 DHCP 服务器注册的 DNS 域名是不安全的。例如，DHCP 服务器自身的主机 (A) 资源记录就是这样的记录。另外，由于 DnsUpdateProxy 组成员创建的对象是不安全的，因此您无法在只允许安全动态更新的 Active Directory 集成的域中有效地使用该组，除非采取其他步骤允许对 DnsUpdateProxy 组成员创建的记录进行安全保护。

要防范不安全的记录或允许 DnsUpdateProxy 组成员在只允许安全动态更新的区域注册记录，您可以创建专用的用户帐户，并配置 DHCP 服务器使用该用户帐户凭据（用户名、密码和域）执行 DNS 动态更新。一个专用用户帐户的凭据可以由多个 DHCP 服务器使用。

专用用户帐户的唯一用途是向 DHCP 服务器提供用于 DNS 动态更新注册的凭据。在创建了专用用户帐户并为 DHCP 服务器配置帐户凭据后，每个 DHCP 服务器都在使用 DNS 动态更新代表 DHCP 客户端注册名称时提供这些凭据。您应该在要更新的区域的主 DNS 服务器所在的林中创建专用用户帐户。专用用户帐户也可以位于其他林中，只要该帐户所在的林与要更新的区域的主 DNS 服务器所在的林之间建立了林信任。

如果“DHCP 服务器”服务安装在域控制器上，您可以为 DHCP 服务器配置专用用户帐户的凭据，以防止服务器继承（也可能滥用）域控制器的权限。“DHCP 服务器”服务安装在域控制器上时，会继承域控制器的安全权限，并且有权更新或删除在安全的 Active Directory 集成的区域中注册的任何 DNS 记录。（其中包括由运行 Windows 2000 或 Windows Server 2003 操作系统的其他计算机（包括域控制器）安全注册的记录。）


配置 DNS 动态更新
Windows Server 2003 中包含的动态更新功能遵循 RFC 2136。动态更新允许客户端和服务器将 DNS 域名（PTR 资源记录）和 IP 地址映射（A 资源记录）注册到符合 RFC 2136 的 DNS 服务器。


为 DHCP 客户端配置 DNS 动态更新
默认情况下，基于 Windows Server 2003、Windows 2000 和 Windows XP 的 DHCP 客户端配置为请求客户端注册 A 资源记录，服务器注册 PTR 资源记录。默认情况下，DNS 注册中使用的名称由计算机名和主 DNS 后缀串联组成。要更改此默认名称，请打开网络连接的 TCP/IP 属性。

要更改动态更新客户端上的动态更新默认值，请按下列步骤执行操作： 1. 在“控制面板”中，双击“网络连接”。 
2. 右键单击要配置的连接，然后单击“属性”。 
3. 单击“Internet 协议 (TCP/IP)”，单击“属性”，然后单击“高级”。 
4. 单击“DNS”。

默认情况下，“在 DNS 中注册此连接的地址”已选中，而“在 DNS 注册中使用此连接的 DNS 后缀”未选中。此默认配置使客户端请求由客户端注册 A 资源记录，由服务器注册 PTR 资源记录。 
5. 单击“在 DNS 注册中使用此连接的 DNS 后缀”复选框，将其选中。

然后，客户端将请求服务器使用 FQDN 更新 PTR 记录。如果 DHCP 服务器配置为根据客户端的请求注册 DNS 记录，则客户端将注册以下记录： • PTR 记录。 
• A 记录，它使用由计算机名和主 DNS 后缀串联组成的名称。 
• A 记录，它使用由计算机名和连接特定的 DNS 后缀串联组成的名称。 

6. 要将客户端配置为不请求 DNS 注册，请单击以清除“在 DNS 中注册此连接的地址”复选框。 

在多主客户端计算机上配置 DNS 动态更新
如果动态更新客户端是一个多主客户端（拥有多个适配器和关联的 IP 地址），则它在默认情况下将向 DNS 注册其所有 IP 地址。如果不希望客户端注册其所有 IP 地址，则可在网络连接属性中将其配置为不注册一个或多个 IP 地址。

要禁止计算机注册其所有 IP 地址，请按下列步骤操作： 1. 在“控制面板”中，双击“网络连接”。 
2. 右键单击要配置的连接，然后单击“属性”。 
3. 单击“Internet 协议 (TCP/IP)”，单击“属性”，然后单击“高级”。 
4. 单击“DNS”。 
5. 单击“在 DNS 中注册此连接的地址”复选框，将其清除。 
您还可以将计算机配置为在 DNS 中注册它的域名。例如，如果一个客户端连接到两个不同的网络，则可以将其配置为在每个网络上使用不同的域名。



在 Windows Server 2003 DHCP 服务器上配置 DNS 动态更新
要为 Windows Server 2003 DHCP 服务器配置 DNS 动态更新，请按下列步骤操作： 1. 单击“开始”，指向“管理工具”，然后单击“DHCP”。 
2. 右键单击相应的 DHCP 服务器或作用域，然后单击“属性”。 
3. 单击“DNS”。 
4. 单击“根据下面的设置启用 DNS 动态更新”复选框，将其选中，以便为支持动态更新的客户端启用 DNS 动态更新。

注意：默认情况下，该复选框是选中的。 
5. 要为不支持 DNS 动态更新的 DHCP 客户端启用 DNS 动态更新，请单击“为不请求更新的 DHCP 客户端(例如，运行 Windows NT 4.0 的客户端)动态更新 DNS A 和 PTR 记录”复选框，将其选中。 
6. 单击“确定”。 

对 DNS 服务器启用 DNS 动态更新
在 Windows Server 2003 DHCP 服务器中，您可以为 Windows Server 2003 以前版本的客户端动态更新 DNS 记录（这些客户端无法自行完成此操作）。
要使 DHCP 服务器能够动态更新其客户端的 DNS 记录，请按下列步骤操作： 1. 在 DHCP 管理控制台中，选择要允许进行动态 DNS 更新的作用域或 DHCP 服务器。 
2. 在“操作”菜单上，单击“属性”，然后单击“DNS”。 
3. 单击“根据下面的设置启用 DNS 动态更新”复选框，将其选中。 
4. 要基于客户端生成的 DHCP 请求的类型并且仅当客户端请求进行更新时更新客户端的 DNS 记录，请单击“只有在 DHCP 客户端请求时才动态更新 DNS A 和 PTR 记录”，将其选中。 
5. 要始终更新客户端的正向和反向查找记录，请单击“总是动态更新 DNS A 和 PTR 记录”将其选中。 
6. 单击“在租约被删除时丢弃 A 和 PTR 记录”复选框，将其选中，使 DHCP 服务器在客户端的 DHCP 租约过期且未续订时删除该客户端的记录。 


禁用 DNS 动态更新
警告：“注册表编辑器”使用不当可导致严重问题，可能需要重新安装操作系统。Microsoft 不能保证您可以解决因“注册表编辑器”使用不当而导致的问题。使用“注册表编辑器”需要您自担风险。

默认情况下，基于 Windows Server 2003 的客户端上配置了动态更新。要对所有网络接口禁用动态更新，请按下列步骤操作： 1. 单击“开始”，然后单击“运行”。 
2. 在“打开”框中，键入 regedit。 
3. 在注册表编辑器中，找到以下注册表项：
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/ Tcpip/Parameters 
4. 在“编辑”菜单上，指向“新建”，然后单击“DWORD 值”。 
5. 键入 DisableDynamicUpdate，然后按 Enter 键。 
6. 按 Enter 键。 
7. 在“编辑 DWORD 值”对话框中的“数值数据”框中键入 1，然后单击“确定”。 
8. 退出“注册表编辑器”。 
要对特定接口禁用动态更新，请按下列步骤操作： 1. 单击“开始”，然后单击“运行”。 
2. 在“打开”框中，键入 regedit。 
3. 在注册表编辑器中，找到以下注册表项：
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/ Tcpip/Parameters/Interfaces/interface
其中 接口 是要对其禁用动态更新的接口的网络适配器的设备 ID。 
4. 在“编辑”菜单上，指向“新建”，然后单击“DWORD 值”。 
5. 键入 DisableDynamicUpdate，然后按 Enter 键。 
6. 按 Enter 键。 
7. 在“编辑 DWORD 值”对话框中的“数值数据”框中键入 1，然后单击“确定”。 
8. 退出“注册表编辑器”。 
 

为满足应用的双活改造和灵活切换的场景，很多企业依靠DNS系统实现应用与IP的解耦。搭建专业的DNS系统，替代传统Windows的DNS功能，成为了企业信息化发展健全的一个必要过程。

 

与域控结合，组建更加完善的DNS系统

Windows操作系统作为目前市面上常见的终端操作系统类型，不管是在企业的办公环境，或者是生产环境中，都扮演着重要的角色。Windows域是计算机网络的一种形式，其中所有用户帐户、计算机、打印机和其他安全主体都在位于称为域控制器的一个或多个中央计算机集群上的中央数据库中注册，从Windows Server 2003开始，Active Directory则是负责维护该中央数据库的Windows组件，然而该组建的安装条件中，必须要有相应的DNS服务器进行支持，提供域名解析，以及依靠SRV记录定位活动目录服务的功能。

除此之外，域控服务器还提供终端的主机域名的自动注册服务，可以将终端的主机名，加上域的后缀，对应终端的IP地址，形成一条域名的A记录，其他用户在仅知道主机名的情况下，就可通过域名的方式对该终端进行访问。

而DDNS动态域名更新，可以在终端的IP、主机名变更时，自动向域控的DNS设备上进行主机域名的更新注册。

 

DDNS动态域名更新过程展示

常规的域名对应IP的A记录解析，定位活动目录的SRV记录解析，都属于DNS的基本功能，那对于上文提到的DDNS动态域名更新，到底是如何实现的呢？很多人会说是通过终端配置的DNS地址进行的更新，假如我们使用了一套第三方的专业DNS系统，该系统上没有域控相关的域名信息，是不是会造成DDNS动态域名更新功能的缺失呢？我们来做个实验，还原一下更新的过程。

为了验证上述猜想，我们单独准备一台DNS设备，与域控自带的DNS服务进行区分，实验设备如下：


	
Windows server 2016域控服务器一台，安装的服务有：AD（Active Directory），DNS（域名解析），IP地址为：192.168.0.161
	
	

	
DNS服务器一台，安装DNS服务，针对域控的域名进行转发至域控服务器，IP地址为：192.168.0.16
	
	

	
Windows终端一台，作为加域终端，IP地址为：192.168.0.7
	
为模拟企业真实的使用场景，对终端电脑进行加域操作，我们将在终端电脑的网卡上，抓取终端所有的请求交互报文，实验拓扑如下：



终端电脑完成加域以后，系统属性中的域信息显示为：zdns.hd，我们修改主机名为：WIN-D47P443LDFH。



终端电脑上使用管理员权限打开CMD，使用命令ipconfig/registerdns，手动触发重新注册DNS域名。



我们在网络中，对该操作进行抓包，具体抓包数据如下：



从抓到的报文上来看，整个DDNS动态域名更新总共分三个交互过程：


	
第一个过程：终端向DNS发起主机域名的SOA记录查询；
	
	

	
第二个过程：终端向DNS发起权威域的主DNS地址查询；
	
	

	
第三个过程：终端向域控制器发起动态域名更新；
	
我们来具体分析一下，终端首先向DNS设备发起了WIN-D47P443LDFH.zdns.hd域名的SOA记录类型查询，查询自己的主机域名是否存在，不存在的情况下DNS返回了一个No such name的应答，紧接着终端又向DNS发起了win-s822c3qobki.zdns.hd域名的A记录查询，那这个域名从哪得来呢？我们打开第一个过程中，DNS的应答报文查看一下。



DNS返回的结果里面，虽然没有查询到WIN-D47P443LDFH.zdns.hd域名，但是返回了权威区zdns.hd的SOA记录，这个记录里面，包含了zdns.hd的主权威DNS的域名，有了这个域名就可以通过DNS查询到zdns.hd域名主权威服务器的IP地址，所以就有了上面的A记录查询，查询到了zdns.hd权威的IP地址。此时进行第三个过程，终端直接向权威DNS发起了DNS的动态更新Dynamic update报文。



进入域控服务器上查看，终端的主机域名的A记录以及出现在DNS管理器上，可以看到该域名的名称就是终端的主机名，数据列则为终端本地配置的IP地址，同时有时间戳表明动态更新的时间节点。



我们总结一下DDNS动态域名更新的整个交互过程：



结束语

根据上面的实验过程，我们发现DDNS动态域名更新的过程中，需要借助终端本地配置的DNS设备进行域名解析查询，但是实际的动态域名更新动作，却是终端直接向权威域发起，也就是说企业的终端电脑使用第三方的DNS系统，依旧可以保障域控DDNS的正常更新，这也使企业为适应双活甚至多活的应用场景，组建稳定性以及可靠性更高的专业DNS系统成为可能。

本期云学堂就先分享到这里，如果您有关于动态域名更新的其他问题，欢迎在文章下方留言，我们将安排专业的工程师为您答疑解惑，咱们下期再见！

 

 

 

 

 

前言：
 
有时候人们往往会爲了一个程式的啓动而头痛，因爲一些用户往往不知道那些文件是如何啓动的。所以经常会有些没用的东西挂在系统上占用资源。有时候也会有人因爲不知道如何啓动某个文件而头痛。更有些特洛依木马的作者因爲不清楚系统的自啓动方式而使自己的木马轻松被别人发现…… 
 
Windows的自啓动方式其实有许多方式。除了一些常见的啓动方式之外，还有一些非常隐蔽的可用来啓动文件的方式。本文总结如下，虽然不是全部，但我想应该会对大家有所帮助。文章全部以系统默认的状态爲准，以供研究。 
 
其中（English）代表英文作业系统，（Chinese）代表中文作业系统。本文没加说明指的全爲中文Windows98作业系统。 
 
警告： 
文中提及的一些操作可能会涉及到系统的稳定性。例如如果不正确地使用注册表编辑器可以导致可能重新安装系统这样严重的问题。微软也不能保证因不正常使用注册表编辑器而造成的结果可以被解决。笔者不对使用後果负责，请根据自己的情况使用。 
 
Windows的自啓动方式： 
一.自啓动目录： 
 
1.第一自啓动目录： 
默认路径位於： 
C:/windows/start menu/programs/startup（English） 
C:/windows/start menu/programs啓动（Chinese） 
这是最基本、最常用的Windows啓动方式，主要用於啓动一些应用软体的自啓动专案，如Office的快显功能表。一般用户希望啓动时所要啓动的文件也可以通过这里啓动，只需把所需文件或其快捷方式放入文件夹中即可。 
 
对应的注册表位置： 
HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Explorer/Shell Folders 
Startup=/"%Directory%/" 
HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Explorer/User Shell Folders
Startup=/"%Directory%/" 
其中“%Directory%”爲啓动文件夹位置。 
 
英文默认爲： 
C:/windows/start menu/programs/startup 
中文默认爲： 
C:/windows/start menu/programs啓动 
 
在开始功能表的“啓动”文件夹是可更改的，如果用户更改了啓动文件夹，则以上注册表的键值均会改变爲相应的名称。 
 
值得注意的是：开始功能表的“啓动”文件夹中的内容虽然在默认的状态下可以被用户看得一清二楚。但通过改动还是可以达到相当隐蔽地啓动的目的的： 
 
首先，“啓动”文件夹中的快捷方式或其他文件的属性可以改变爲“隐藏”。这样可以达到系统不啓动被隐藏的文件，等到需要啓动的时候又可以通过更改回文件属性而恢复啓动的作用。 

其次，其实“啓动”文件夹只是一个普通的文件夹，但是由於系统监视了这个文件夹，所以变得有些特殊，但文件夹有的功能该文件夹也是有的。譬如“啓动”文件夹的名称是可以更改的，并且“啓动”文件夹也可以设置属性。如果把属性设置爲“隐藏”，则在系统中的【开始】--->【程式】功能表中是看不到“啓动”文件夹的（即使在“文件夹选项”中已经设定了“显示所有文件”）。而系统还会啓动这个被隐藏的文件夹中的非隐藏文件。 
敏感的人们也许已经发现问题。举一个例子： 
 
如果我想啓动A木马的server端伺服器，我可以把原来的“啓动”功能表的名称更改爲“StartUp”（这里是随便改的，注册表相应的键值也会自动更改。）之後再创建一个名爲“啓动”的文件夹，把“StartUp”功能表中的文件全部复制（这里用复制，可以骗过用户的检查）到“啓动”功能表中，然後把A木马的server程式放入“StartUp”文件夹中，最後把“StartUp”文件夹隐藏。大功告成！ 
 
从外表看来，用户的【开始】--->【啓动】目录还在，而且要啓动的文件也在。但系统此时啓动的文件不是名爲“啓动”的文件夹中的文件，而是名爲“StartUp”的文件夹中的文件。如果木马做的好的话，完全可以在每次啓动的时候把“StartUp”中的文件复制到“啓动”目录中来达到即时更新啓动目录的目的。由於“StartUp”文件夹被隐藏，从【开始】--->【程式】中是无法看到真正的啓动功能表“StartUp”的，所以达到了隐蔽啓动的目的！ 
这个啓动方式虽然比较隐蔽，但通过msconfig依旧可以在“啓动”页中看出来。 
 
2.第二自啓动目录： 
是的，其实，Windows还有另外一个自啓动目录，而且很明显但却经常被人们忽略的一个。 
该路径位於： 
C:/WINDOWS/All Users/Start Menu/Programs/StartUp（English） 
C:/WINDOWS/All Users/Start Menu/Programs啓动（Chinese） 
这个目录的使用方法和第一自啓动目录是完全一样的。只要找到该目录，将所需要啓动的文件拖放进去就可以达到啓动的目的。 
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/explorer/User Shell Folders
/"Common Startup/"=/"%Directory%/" 
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/explorer/Shell Folders
/"Common Startup/"=/"%Directory%/" 
 
值得注意的是：该目录在开始功能表的“啓动”目录中是完全不能被看见的。而伴随着每次啓动，该目录下的非隐藏文件也会随之啓动！ 另外，在Msconfig中可以看到在这个目录下要啓动的文件。 

二.系统配置文件啓动： 
 
由於系统的配置文件对於大多数的用户来说都是相当陌生的；这就造成了这些啓动方法相对来说都是相当隐蔽的，所以这里提到的一些方法常常会被用於做一些破坏性的操作，请读者注意。 
 
1.WIN.INI啓动： 
啓动位置（file.exe爲要啓动的档案名称）： 
[windows] 
load=file.exe 
run=file.exe 
注意：load=与run=的区别在於：通过load=运行文件，文件会在後台运行（最小化）；而通过run=来运行，则文件是在默认状态下被运行的。 
 
2.SYSTEM.INI啓动： 
啓动位置（file.exe爲要啓动的档案名称）： 
默认爲： 
[boot] 
Shell=Explorer.exe 
可啓动文件後爲： 
[boot] 
Shell=Explorer.exe file.exe 
说明： 
笔者记得在诺顿先生（就是开发出Norton系列软体的人）写的一本书里面曾经说过，1、2这两个文件的有无对系统没有什麽影响，但由於时间的关系，笔者没有来得及试验，有兴趣者可以试一试。 
 
不过有一点是可以肯定的，这样的啓动方式往往会被木马或一些恶作剧程式（如，妖之吻）利用而导致系统的不正常。由於一般用户很少会对这两个文件关心，甚至有的人不知道这些文件是做什麽用的，所以隐蔽性很好。但由於其使用的越来越频繁，这种啓动方式也被渐渐的察觉了。用户可以使用msconfig这个命令实现检查是否有什麽程式被载入。具体的是在看是功能表中的“运行”中输入msconfig回车，之後按照文字说明即可。 
 
注意： 
1.和WIN.INI文件不同的是，SYSTEM.INI的啓动只能啓动一个指定文件，不要把Shell=Explorer.exe file.exe换爲Shell=file.exe，这样会使Windows瘫痪！ 
2.这种啓动方式提前於注册表啓动，所以，如果想限制注册表中的文件的啓动，可是使用这种方法。 
3.WININIT.INI啓动： 
Wininit.ini这个文件也许很多人不知道，一般的操作中用户也很少能直接和这个文件接触。但如果你编写过卸载程式的话，也许你会知道这个文件。 
WinInit即爲Windows Setup Initialization Utility。翻译成中文就是Windows安装初始化工具。这麽说也许不明白，如果看到如下提示资讯： 
Please wait while Setup updates your configuration files. 
This may take a few minutes... 
大家也许就都知道了！这个就是Wininit.ini在起作用！ 
 
由於在Windows下，许多的可执行文件和驱动文件是被执行到记忆体中受到系统保护的。所以在Windows的正常状态下更改这些文件就成了问题，因此出现了Wininit.ini这个文件来帮助系统做这件事情。它会在系统装载Windows之前让系统执行一些命令，包括复制，删除，重命名等，以完成更新文件的目的。Wininit.ini文件存在於Windows目录下，但在一般时候我们在C:Windows目录下找不到这个文件，只能找到它的exe程式Wininit.exe。原因就是Wininit.ini在每次被系统执行完它其中的命令时就会被系统自动删除，直到再次出现新的Wininit.ini文件……之後再被删除。 

文件格式： 
[rename] 
file1=file2 
file1=file2的意思是把file2文件复制爲档案名爲file1的文件，相当於覆盖file1文件。 
这样啓动时，Windows就实现了用file2更新file1的目的；如果file1不存在，实际结果是将file2复制并改名爲file1；如果要删除文件，则可使用如下命令： 
[rename] 
nul=file2 
这也就是说把file2变爲空，即删除的意思。 
以上档案名都必须包含完整路径。 
 
注意： 
1.由於Wininit.ini文件处理的文件是在Windows啓动以前处理的，所以不支援长档案名。 
2.以上的文件复制、删除、重命名等均是不提示用户的情况下执行的。有些病毒也会利用这个文件对系统进行破坏，所以用户如果发现系统无故出现： 
Please wait while Setup updates your configuration files. 
This may take a few minutes... 
那麽也许系统就有问题了。 
3. 在Windows 95 Resource Kit中提到过Wininit.ini文件有三个可能的段，但只敍述了[rename]段的用法。 
4.WINSTART.BAT啓动： 
这是一个系统自啓动的批次档案，主要作用是处理一些需要复制、删除的任务。譬如有些软体会在安装或卸载完之後要求重新啓动，就可以利用这个复制和删除一些文件来达到完成任务的目的。如： 
“@if exist C:WINDOWSTEMPPROC.BAT call C:WINDOWSTEMPPROC.BAT” 
这里是执行PROC.BAT文件的命令； 
“call file

三.注册表啓动： 
 
注册表中的啓动应该是被使用最频繁的啓动方式，但这样的方式也有一些隐蔽性较高的方法，大致有三种。 
 
1.常规啓动： 
其中%path%爲任意路径，file.exe爲要运行的程式。 HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/RunServices
/"Anything/"=/"%path%file.exe/" 
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/RunServicesOnce
/"Anything/"=/"%path%file.exe/" 
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Run 
/"Anything/"=/"%path%file.exe/" 
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/RunOnce 
/"Anything/"=/"%path%file.exe/" 
 
HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Run 
/"Whatever/"=/"c:runfolderprogram.exe/" 
HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/RunOnce 
/"Whatever/"=/"c:runfolderprogram.exe/" 
注意： 
(1).如果需要运行.dll文件，则需要特殊的命令行。 
如： 
Rundll32.exe C:WINDOWSFILE.DLL,Rundll32 
(2).解除这里相应的自啓动项只需删除该键值即可，但注意不要删除如SystemTray、ScanRegistry等这样的系统键值。 
(3).如果只想不啓动而保留键值，只需在该键值加入rem即可。如： 
“remC:Windowsa.exe” 
(4).在注册表中的自啓动项中没有这项： 
HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/RunServices
(5).Run和RunServices的区别在於：Run中的程式是在每次系统啓动时被啓动，RunServices则是会在每次登录系统时被啓动。 
关於： 
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/RunOnceEx
 
有特殊的语法： 
例如，运行notepad.exe 
HKLM/SOFTWARE/Microsoft/Windows/Current/Version/RunOnceEx 
/"Title/"=/"My Setup Title/" 
/"Flag/"=dword:00000002 
 
HKLM/SOFTWARE/Microsoft/Windows/Current/Version/RunOnceEx001 
/"RunMyApp/"=/"||notepad.exe/" 
语法爲： 
HKLM/SOFTWARE/Microsoft/Windows/Current/Version/RunOnceEx 
Flags = 0x0000000 
Title = /"Status Dialog Box Title/" 
 
HKLM/SOFTWARE/Microsoft/Windows/Current/Version/RunOnceExDepend 
0001 = /"xxx1/" 
000X = /"xxxx/" 
 
HKLM/SOFTWARE/Microsoft/Windows/Current/Version/RunOnceEx001 
Entry1 = /"MyApp1.exe/" 
EntryX = /"MyApp2.exe/" 
HKLM/SOFTWARE/Microsoft/Windows/Current/Version/RunOnceEx00x 
... 
注意： 
(1).“xxx1，xxxx”是一个动态连结程式库（DLL）或.OCX档案名（如My.ocx或My.dll）。 
(2).“0001，000x”是部分名字。可以是数位元元元和文字。 
(3).“entry1，entryX”是指向一个要运行的程式文件的注册表串值。 
键值的说明： 
Flags是一个定位在RunOnceEx键用来启动/禁止的DWORD值，具体如下： 
值功能功能定义 
0x00000000默认所有功能被禁止 
0x00000004检查壳状况打开壳的读写校验准备接受OLE命令 
0x00000008无报错对话错误对话方块不显示 
0x00000010创建错误报告文件创建 C:WindowsRunOnceEx.err 文件如果有错误出现 
0x00000020创建执行报告文件创建一个有命令状态的C:WindowsRunOnceEx.log文件 
0x00000040无例外限制当注册DLL时不限制例外 
0x00000080无状态对话当RunOnceEx运行时状态对话方块不显示 
 
由於涉及篇幅较多，具体做法请浏览微软网页： 
[url]http://support.microsoft.com/support/kb/articles/Q232/5/09.ASP[/url] 
 
2.特殊啓动1： 
在注册表中除了上述的普通的啓动方式以外，还可以利用一些特殊的方式达到啓动的目的： 
HKEY_CLASSES_ROOT/exefile/shell/open/command @=/"%1/" %* 
HKEY_CLASSES_ROOT/comfile/shell/open/command @=/"%1/" %* 
HKEY_CLASSES_ROOT/batfile/shell/open/command @=/"%1/" %* 
HKEY_CLASSES_ROOT/htafile/shell/open/command @=/"%1/" %* 
HKEY_CLASSES_ROOT/piffile/shell/open/command @=/"%1/" %* 
HKEY_LOCAL_MACHINE/Software/CLASSES/batfile/shell/open/command @=/"%1/" %* 
HKEY_LOCAL_MACHINE/Software/CLASSES/comfile/shell/open/command @=/"%1/" %* 
HKEY_LOCAL_MACHINE/Software/CLASSES/exefile/shell/open/command @=/"%1/" %* 
HKEY_LOCAL_MACHINE/Software/CLASSES/htafile/shell/open/command @= /"%1/" %* 
HKEY_LOCAL_MACHINE/Software/CLASSES/piffile/shell/open/command @=/"%1/" %* 
 
其实从注册表的路径上也许就隐约可以看出，这些都是一些经常被执行的可执行文件的键值。往往有些木马是可以更改这些键值从而达到载入的目的： 
如果我把“”%1”%*”改爲“file.exe”%1”%*”则文件file.exe就会在每次执行某一个类型的文件（要看改的是哪一个文件类型）的时候被执行！ 当然，可以被更改的不一定只是可执行文件，譬如冰河就利用了TXT文件的键值： 
HKEY_CLASSES_ROOT/txtfile/shell/open/command实现木马的一种啓动方式。 
 
3.特殊啓动2： 
在注册表中： 
HKEY_LOCAL_MACHINE/System/CurrentControl/SetServices/VxD 
的位置上有这样的地址。该位址是系统啓动VxD驱动文件放置的位址，就像PrettyPark这个蠕虫一样，可以建立一个主键之後把VxD文件添加到注册表中在这里。 
注意：不可以直接把一个EXE文件改名爲VxD文件，需要另外进行编程，生成的VxD文件。 
 
4.其他啓动方式： 
 
(一).C:Explorer.exe啓动方式： 
这是一种特殊的啓动方式，很少有人知道。 
在Win9X下，由於SYSTEM.INI只指定了Windows的外壳文件EXPLORER.EXE的名称，而并没有指定绝对路径，所以Win9X会搜索EXPLORER.EXE文件。 
搜索顺序如下： 
(1).搜索当前目录。 
(2).如果没有搜索到EXPLORER.EXE则系统会获取 
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControl/SetControl/Session/ Manager/Environment/Path]的资讯获得相对路径。 
(3).如果还是没有文件系统则会获取HKEY_CURRENT_USER/Environment/Path的资讯获得相对路径。 
 
其中： 
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControl/SetControl/Session/ Manager/Environment/Path和HKEY_CURRENT_USER/Environment/Path所保存的相对路径的键值爲：“%SystemRoot%System32;%SystemRoot%”和空。 
所以，由於当系统啓动时，“当前目录”肯定是%SystemDrive%（系统驱动器），这样系统搜索EXPLORER.EXE的顺序应该是： 
(1).%SystemDrive%（例如C:） 
(2).%SystemRoot%System32（例如C:WINNTSYSTEM32） 
(3).%SystemRoot%（例如C:WINNT） 
此时，如果把一个名爲EXPLORER.EXE的文件放到系统根目录下，这样在每次啓动的时候系统就会自动先啓动根目录下的EXPLORER.EXE而不啓动Windows目录下的EXPLORER.EXE了。 
在WinNT系列下，WindowsNT/Windows2000更加注意了EXPLORER.EXE的档案名放置的位置，把系统啓动时要使用的外壳文件（EXPLORER.EXE）的名称放到了： 
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/WindowsNT/CurrentVersion/WinlogonShell
这个位置。 
作爲默认这个位置是不存在的，默认爲是Explorer.exe。 
具体请参考：[url]http://www.microsoft.com/technet/security/bulletin/fq00-052.asp[/url] 
注意： 
一定要确定根目录下的EXPLORER.EXE要能啓动Windows目录下的EXPLORER.EXE，否则会导致Windows无法啓动！ 
现在流行的病毒CodeRed就会在C:和D:目录下放置两个约8KB的EXPLORER.EXE的文件！ 
在Windows 2000 SP2中微软已经更改了这一方式。 
(二).萤幕保护啓动方式： 
Windows的萤幕保护程式是一个.scr文件。这是一个PE格式的可执行文件。如果把萤幕保护程式.scr更名爲.exe的文件，则该程式仍然可以正常啓动。类似的.exe文件更名爲.scr文件也是一样可以被运行！ 
.scr文件默认存在於C:Windows目录中，他的名字就是在“显示”属性中的“萤幕保护程式”中的名称。在C:Windows目录下的所有*.scr文件都会被Windows的“萤幕保护程式”显示，而文件路径本身保存在System.ini中的SCRNSAVE.EXE=的这条中。有意思的是在SCRNSAVE.EXE=这条中，其规定的路径也包含了目录名称。即如果我想安装一个.scr文件时，譬如安装路径爲D:SCR1.scr，而D:SCR这个目录中还有2.scr，则在这个目录中的所有.scr（1.scr，2.scr）文件都会被显示在“萤幕保护程式”设置中。如果萤幕保护程式设爲“（无）”，则SCRNSAVE.EXE=这条不存在。但如果SCRNSAVE.EXE=这条所指的文件或目录是错误的，则在“萤幕保护程式设置”中仍然会显示“（无）”。 
 
萤幕保护程式的啓动时间保存在注册表中的这个位置上： 
HKEY_USERS.DEFAULTControl PaneldesktopScreenSaveTimeOut 
时间单位爲秒，不过虽然是秒，可啓动时间却爲分，即从60秒开始记录，如果记录时间小於60秒，则自动定爲1分钟。 
萤幕保护是否设置密码的键值爲： 
HKEY_USERS/.DEFAULT/Control Panel/desktop/Screen/SaveUsePassword 
有密码则值爲1没有密码则值爲0。 
由此可见，如果有人把自己所作的.exe程式更名爲.scr的程式，并使程式能够在SYSTEM.INI中添加“SCANSAVE.EXE=/%Path%”f/ile.scr”（/%Path%/file.scr爲所需要设置的文件的路径和档案名，如C:Program filestrojan.scr），修改注册表中的HKEY_USERS.DEFAULTControl PaneldesktopScreenSaveTimeOut，定时间爲60，则系统只要闲置一分钟该文件就会被啓动！ 
另外一个简单的破坏方式就是可以随机産生萤幕保护密码并写入相应文件的相应位置，定时间爲1分钟，则系统只要闲置一分钟则会被被锁！（由於涉及问题并非自啓动问题，所以不加以讨论。） 
注意：由於SCANSAVE.EXE=这里还会定义.scr文件的路径，所以最好不要把要啓动的文件放置在.scr文件较多的一些目录，否则容易引起怀疑。（Windows目录除外）
（三）.依附啓动： 
这类啓动方式已经有几分类似病毒了。这种方法是利用病毒的传染机制把要啓动的EXE文件附着在另外的一个和多个EXE文件上，从而达到啓动这个EXE文件就可以啓动要啓动的文件的目的。记得1999年YAI这个木马流行的时候，它就使用了依附一个EXE文件而达到啓动的目的，但是由於BUGS和方式问题该木马的破坏作用却体现在了它“病毒”的一面。 
使用这种啓动方法一定要注意不能破坏EXE文件（否则会很容易被发现），而且最好把木马定位在固定的一个或者几个EXE文件上。如：IEXPLORE.EXE（IE的EXE文件），RNAPP.EXE（拨号网路的EXE文件）等等。 
注意：这种方法的使用比较危险，技术上也需要相当功底，而且和病毒的距离很近，慎用。 
 
（四）.计划任务啓动方式： 
Windows的计划任务是Windows的一个预置实现某些操作而使用的一个功能。但是如果利用这个功能也是能够实现自啓动的目的的！由於很多电脑都会自动载入“计划任务”所以隐蔽性相对不错。 
 
在Windows默认的情况下，计划任务是一个个保存在C:WindowsTasks目录下的.job文件。.job文件里包括了啓动方式、文件路径等一系列的资讯。编制出或者使软体自己可以写出.job文件，则是关键。之後在相关地方写入标记啓动即可。 
由於时间关系，这个方法没有来得及试验，读者可以自己试验一下。 

（五）.AutoRun.inf啓动方式： 
Autorun.inf这个标识也许大家都见过。是的，这个最常出现在光碟中，用於光碟自啓动。每次把光碟放入光碟机中的时候，系统会通过这个文件来决定是否自动啓动光碟。但是有没有想过，这个文件也可以用来自啓动一些文件！ 
Autorun.inf的内容通常是： 
[AUTORUN] 
OPEN=file.exe 
ICON=icon.ico 
 
OPEN中是插入光碟或者双击光碟盘符就会运行的可执行文件的名称。 
ICON中是该光碟机驱动器的图示文件。该文件可以是其他文件。如： 
[AUTORUN] 
OPEN=file.exe 
ICON=icon.exe,2 
其中icon.exe是一个有图示文件的可执行文件，“,2”则是该文件中的第3个图示。（“,0”是第一个图示，无数位则默认爲第一个图示）。 
最关键的是该Autorun.inf文件是可以被用在硬碟的驱动器上的。也就是说，如果把光碟上的所有文件及目录原封不动的复制到某一硬碟的根目录下，则双击盘符会出现自动运行文件！ 
如果是木马的话，打一个比方：一个木马如果执行後被命名爲aaa.exe放置在C:Windows目录下。那麽该木马可以生成一个autorun.inf 
文件於C:下，内容如下： [AUTORUN] 
OPEN=Windowsaaa.exe 
ICON=aaa.exe 
这样的话，盘符图示爲aaa.exe的第一个图示文件。则在每次双击C盘的时候都会执行aaa.exe文件了。但要注意的是，aaa.exe文件 
最好能够打开C盘目录。（比较容易僞装） 
 
注意： 
（1）.autorun.inf的属性被改爲隐藏後仍可以正常使用。 
（2）.autorun.inf中的路径对相对路径和绝对路径都是可以实现的。也就是说，如果autorun.inf被放在1盘符下，也可以2盘符上的文件！如： 
如果把autorun.inf文件放在C盘根目录下，内容爲 
[AUTORUN] 
OPEN=D:CCCbbb.exe 
ICON=bbb.exe 
则这时如果双击C盘则可以执行D盘CCC目录上的bbb.exe文件！ 
（3）.如果没有OPEN专案，则系统不执行任何文件，而去执行下一个命令。 
（4）.如果没有ICON专案，则该盘符的图示爲原Windows盘符图示，但如果有ICON项却设置错误，或者所设置的文件没有图示，则系统会显示爲默认的空白图示。 
（5）.自动啓动相关： 
a.代啓动： 
这种啓动方式其实只是一个方法的问题。即可以用啓动一个正常文件来啓动另一个文件，SubSeven就用过啓动Windos.exe从而啓动SubSeven的Sever文件的方法。 
b.Start啓动： 
在“运行“中或“MS-DOS”方式中输入start回车，则会显示 
Runs a Windows program or an MS-DOS program. 
 
START [options] program [arg...] 
START [options] document.ext 
 
/m[inimized] Run the new program minimized (in the background). 
/max[imized] Run the new program maximized (in the foreground). 
/r[estored]Run the new program restored (in the foreground). [default] 
/w[ait]Does not return until the other program exits. 
如果要啓动的程式配合这个命令，则可以更加隐蔽，如： 
start/m file.exe 
但似乎有些有啓动画面的软体（如金山词霸）对这条命令并没有反映。 
 
c.控制面板啓动： 
这是利用控制面板程式可以被类似DLL执行，从而达到啓动目的。 
在控制面板中，.cpl文件是控制面板的原文件。默认的这些文件都会被放置在/％WINDOWS％/SYSTEM/目录下的，如desk.cpl是桌面属性、inetcpl.cpl是Internet选项之类。但这些.cpl文件全都是PE格式文件，也就是说如果用户把一个可执行的类似DLL的.cpl文件放入%Windows%System中，则在控制面板中可看到其图示，并可执行！ 
 
由於.cpl文件的特殊性，需要使用rundll32.exe来啓动该文件。rundll32.exe是Windows用来调用动态连接库函数时所使用的文件，在运行中输入： rundll32 shell32.dll,Control_RunDLL /%path%/desk