Microsoft Windows CE .NET 常见技术问答集

Microsoft Windows CE .NET 常见技术问答集 Microsoft Windows CE .NET 常见技术问答集 Microsoft Corporation   2002 年 10 月 适用于 MicrosoftR WindowsR CE .NET (4.0 和 4.1 版) Microsoft Windows CE 3.0 摘要：了解关于 Microsoft Windows CE .NET 和 Windows CE 3.0 操作系统之常见问题的答案，包括有关 Windows CE 应用程序开发的问题。 (打印共 34 页) (此文章包含连结至英文网页的链接) 内容 Windows CE 一般常见问题 Windows CE Windows CE 应用程序开发常见问题 其它资源 我们很在意您对这些常见问题的意见。请将您的意见传送到 [email protected]。 Windows CE 一般常见问题 何谓 Windows CE？ Microsoft Windows CE 是开放式、可扩充的 Windows 平台，适用各种通讯、娱乐和行动计算机装置。标准架构的 Windows CE 平台是全新的操作系统，从基础开始进行建构，让新类型的企业和消费者能够使用非个人计算机装置与彼此进行通讯，利由 Windows 架构的个人计算机分享信息，并连接到因特网。 Microsoft 为什么要开发 Windows CE？ Microsoft 在过去几年来已勾勒出一个蓝图，就是「浩瀚信息，尽在弹指间」(Information at Your Fingertips)，这种概念就是每张桌上和每个家中的个人计算机，都发展成为各种企业和消费者环境中的其中一个计算机架构装置。Windows CE 操作系统是多年来努力实现此蓝图的成果。Microsoft 藉由 Windows CE 提供一个开放式、具有标准架构的平台，能够大幅降低原始设备厂商 (OEM)、硬件制造商、软件开发者、甚至是客户采用新式非个人计算机技术与方案时的障碍。 哪些人使用 Windows CE？ 如需目前 Windows Embedded 合作伙伴的清单，请造访 Microsoft Windows Embedded Partner 网站。 Windows CE 3.0 与 Pocket PC 的差异？ Windows CE 是作为建置区块的操作系统。Pocket PC 是从这些 Windows CE 建置区块所建置的特定装置。因此在 Pocket PC 和 Pocket PC 2002 装置上执行的 Windows CE 3.0 操作系统并不等同于在其它装置上执行的 Windows CE 3.0 操作系统。 如需详细信息以及关于 Pocket PC 的常见问题，请造访 Microsoft MSDN 网站。 何谓 Microsoft Windows CE .NET？ icrosoft Windows CE .NET 是 Windows CE 3.0 的延续。它是一种坚固、实时的操作系统，能够快速建置新一代的智能行动和小型机体 (Footprint) 装置。Windows CE .NET 可在四种主要 CPU 架构系列及 200 种以上的 CPU 类型上运作，而且能够应用于广泛的装置类型，包括：行动/手持装置 (PDA)、Windows Thin Client、智能电话、Web Pad、网络家电/多媒体装置、视讯转换盒 (Set-Top Box)、Residential Gateway、零售点销售装置 (POS) 和工作自动化装置 (Industrial Automation Device)。由于 Windows CE .NET 具有高度可塑性，因此可以自订小型机体的摆设区大小，以符合一些装置的特定产品需求。 Windows CE .NET 4.1 (又名 Jameson) 新增了哪些功能？ Jameson 是新近发行 Windows CE .NET 技术的次要更新，在推出 Windows CE .NET 产品的主要修订版本前，提供客户一些额外的技术。 开发人员将发现许多的全新和加强的功能，包括： 支持无线技术，如蓝芽和 802.11 网络类型 装置仿真，可让您仿真完整的装置环境，而不用另外投资其它的硬件 平台精灵 (Platform Wizard)，可让您选取一些预先设定的装置设计，快速启动开发程序 丰富多媒体和浏览功能，如 Microsoft Internet Explorer 5.5 和 Microsoft Windows Media? 转码器和控件 此外还有名为 Windows CE .NET 4.1 版的次要更新，增强 Windows CE .NET 对以下的支持： Internet Protocol version 6 (IPv6) 档案检视器 新的 Systems Management Server (SMS) 2003 客户端 所有最新发行的快速修正工程 (Quick Fix Engineering, QFE)，包括安全性修正程序 如需详细信息，请造访此 Microsoft Windows Embedded 网站。 Windows CE .NET 中的 ".NET" 代表什么？ Microsoft .NET 是一组 Microsoft 软件技术，用来连接您与信息、人员、系统和装置的世界。它透过使用延伸标记语言 (Extensible Markup Language，XML) Web 服务将软件整合带向全新的境界：小型、分离的建置区块应用程序—加上其它大型的应用程序—都可透过因特网彼此连接。.NET 连接的软件可提供开发人员建立 XML Web 服务并将其相互结合所需的对象。对于个人而言的优点在于顺畅且令人惊叹的共享信息体验。在 Windows CE .NET 上实作的 .NET 技术包括 XML、简单对象存取通讯协议 (Simple Object Access Protocol，SOAP)、Microsoft Passport、Microsoft Windows Messenger 以及 Microsoft .NET Compact Framework，能够提高开发人员的生产力。 为什么要在 Windows CE .NET 上建构嵌入式操作系统？ Windows CE .NET 提供嵌入式操作系统开发人员需要的工具和技术。开发人员将会找到多种新的、增强的功能，包括支持蓝芽之类的无线技术、装置仿真、新的「平台精灵」和丰富多媒体及浏览等功能。这个端对端的工具组可让您快速建构各种智能型设计，在最新的硬件上执行多媒体应用程序。使用 Windows CE .NET 建置新式嵌入式设计的好处包括： Windows CE .NET 允许您建置可扩充的无线平台，灵活地将行动装置与现有基础结构连接。 PAN、LAN 和 WAN 的全面性无线支持，包括蓝芽技术和 802.11 网络类型。 同时支持 IPv4 和 IPv6 两种通讯协议，包括 Microsoft Internet Explorer 5.5 和 Winsock 等网络应用程序，还包括一系列可让双堆栈网络相互通讯与测试的技术。 扩充您现有的管理基础结构，以包括使用目前正在开发的 Microsoft Systems Management Server 的装置。 Windows CE .NET 提供可靠的核心操作系统服务，能够跨各种装置，有效地启用要求最严苛的实时嵌入式设计。 使用坚固的实时操作系统 (Real Time Operating System，RTOS) 核心支持来启用低延迟和系结的决定性系统效能。 针对数据的储存和传输实作本机和网络安全性。 最佳化复合 CPU 环境中的装置效能、价格和动力。 Windows CE .NET 可让您建置智能型 .NET 装置，并建立跨越装置、PC、服务器和 Web 服务的丰富个人化体验。 让使用者检视最普遍使用的办公文件，包括 Microsoft Word、Microsoft Excel、Microsoft PowerPointR、Adobe Acrobat 和影像文件，而不用经过档案转换。 建置能够提供最新多媒体体验的设计，除了数字权利管理 (Digital Rights Management，DRM) 外，还包括 Microsoft Windows Media? 8 转码器和控件。 利用现成的多语言支持有效地建置当地语系化的嵌入式装置及应用程序。 利用 XML 3.0 的支持，安全地将 Web 服务整合到智能型装置。 使用 .NET Compact Framework 建置可以跨多个装置执行的功能强大应用程序。 Windows CE .NET 提供端对端工具组，快速在最新硬件上建置具备丰富应用程序的智能型设计。 利用主机工作站内的仿真技术，不用购买额外的硬件即可建置设计和制作原型。 使用新的「平台精灵」快速启动嵌入式设计，该精灵可支持 12 种预先设定的装置设计。 使用 Microsoft eMbedded Visual C++R 4.0 这种独立的整合开发环境 (Integrated Development Environment，IDE)，提高 Windows CE .NET 开发的生产力，且不用牺牲弹性、效能或操控性。 使用 Microsoft Visual StudioR .NET 简化分布式 XML Web Services 及应用程序的开发与部署。 为什么应该使用 Windows CE .NET 而非 Linux 来建构嵌入式操作系统？ Windows CE .NET 提供包含功能多样化且全面性的整合嵌入式操作系统平台，由全球经验丰富和不断成长的合作伙伴和开发人员作为后盾，让 OEM 厂商能加快上市时间，利用有限的资源区隔产品—而非操作系统开发与维护—并使用知名且受信任的厂商及商业模式来保护具有附加价值的智能财产。Windows CE. NET 包含超过 400 种经过专业测试的精简且易设定的组件、坚固实时的先占式多任务核心、多种无线网络、多媒体、浏览和电源管理功能，并内建支持 200 种以上的 32 位 CPU，包括 ARM、MIPS、SuperH (SH) 和 x86 架构。 Windows CE .NET 可用来开发那些装置？ 您可以为使用 Windows CE .NET 的各种不同装置建置自订平台。Windows CE .NET 内包含的新「平台精灵」，包括适用以下目标装置的预先组态平台，能够帮助您加快开发流程： 行动电话/智能电话装置 自订装置 数字影像装置 工业自动化装置 网络家电 多媒体装置 PDA/行动手持装置 Residential Gateway 零售点销售装置 视讯转换盒 (Set-Top Box) 微核心 Web Pad Windows Thin Client Windows CE .NET 仿真技术有什么功能？ Windows CE .NET 模拟技术可让开发人员在 Windows 2000 或 Windows XP 架构工作站上建置和测试他们的设计，而不用购买任何额外的硬件。 何谓 IPv6？ Internet Protocol version 6 是一种新的工业网络通讯协议，可以支持较大的地址空间。现在您可以选择 IPv4 或 IPv6，包括 IPv6 版本的网络组件，例如 Internet Explorer 5.5 和 Windows Media 等等。Windows CE .NET 也包含一些可让双堆栈网络互相通讯及测试的工具，以支持从 IPv4 到 IPv6 的转换阶段。 适用 Windows CE 的档案检视器与随附于 Pocket PC 平台和 Handheld PC 中的应用程序有何不同？ Windows CE .NET 包含一组档案检视器，能够让使用者检视和打印原生 Microsoft Office 以及 Adobe Acrobat 的文件。这种检视工具与 Pocket PC 和 Handheld PC 平台上所用的 Pocket 应用程序进行对照，后者可以使用 Microsoft ActiveSyncR 技术将文件转换后再加以编辑。Windows CE .NET 中的档案检视器并不提供编辑功能，但可以在 Windows CE .NET 装置上使用，不需要藉由 ActiveSync 或进行档案转换。 如何远程管理使用 Windows CE .NET 4.1 建置的装置？ Windows CE .NET 4.1 采用新的装置管理客户端，来补足现有的 SNMP v 4.2 客户端。发行对应的系统管理软件 (System Management Software，SMS) 2003 服务器时，这个新的 SMS 2003 客户端将会启用企业管理功能，例如硬件/软件库存和软件部署，以加强客户的软件散布及资产管理。我们在发行 SMS 2003 先提供 SMS 2003 客户端，以便客户能有较多的时间进行测试和部署。对于希望建置自己的服务器以便与 SMS 客户端搭配使用的客户，Windows CE .NET 附有关于客户端及通讯协议的文件。 我已经取得 Windows CE .NET，该如何取得 4.1 更新中包含的其它组件呢？ Microsoft 会透过经销商，提供所有 Windows CE .NET 现用客户最新的 Windows CE .NET 发行版本。如果有任何问题，请连络 Microsoft 客户经理或经销商。 如果目前尚有项目未完成，不希望升级到 Windows CE .NET 的最新版本时该怎么办？ 开发人员能够选择安装 Windows CE .NET 的最新版本并保留前版本，或者是升级为最新版本。如果选择并列开发，任何新的项目将会使用最新版本的 Windows CE .NET 启动。Windows CE .NET 更新版可以读取前版本的项目及工作区，并在第一次储存时将它们转换为 4.1 版的格式。不过，在最新版本中所作的变更则无法储存为前版本的格式。 如果目前正在进行的项目需要用到 Windows CE .NET 最新版本中才有的功能时该怎么办？ 您可以选择安装 Windows CE .NET 更新版，然后继续执行项目。Windows CE .NET 的最新版本能够开启前版本的现存工作区及项目。不过，在新版本中所作的变更则无法储存回前版本。 何谓 Windows CE .NET 的最小机体？ 延续先前缩减嵌入式装置操作系统所占空间的目标，Windows CE .NET 的核心功能可视需要分别选取，因此能最小化组件对象模型 (COM)/XML 实作所占的空间。最小组态为 200 KB，这是透过高压缩的字型储存方式，以及可分散为网络、多媒体和浏览器技术来达成。 Windows CE .NET 支持哪些处理器？ Windows CE .NET 支援很多种的 CPU。如需支持处理器的完整清单，请参阅 Supported Processors。 为什么应该使用 Windows CE .NET，而不要继续使用先前版本的 Windows CE？ Windows CE .NET 增添了许多先前版本没有的新功能。Windows CE .NET 提供开发人员以前必须自行实作的多项技术，例如 802.11 或 Kerberos 支持等等。而 Windows CE .NET 则简化了更先进装置的建置过程，可提高开发人员的生产力，加快装置的上市时间。 何时该选择 Windows XP Embedded 而不是 Windows CE .NET？ TMicrosoft 的策略是提供各种以 Windows 为基础的嵌入式操作系统解决方案，以满足客户多样化的需求。但装置的设计需求仍决定所选择的最佳作业平台。了解每套操作系统的开发重点，将有助您的决策判断。 如果您需要一套能够提供实时、小型机体和多重处理器支持的解决方案，请选择 Windows CE .NET。 如果您需要一套以 x86 处理器为基础所建置的最新 Windows 技术解决方案，请选择Windows XP Embedded。 如需详细信息，请参阅 选择哪一种 Microsoft Windows 嵌入式操作系统。 如何评估 Windows CE .NET 及其开发工具？ Windows CE .NET 的评估很简单。有两种评估方式： 您可以下载模拟版 (Emulation Edition)，让您使用模仿硬件的软件来设计和建置 Windows CE 架构的平台并进行测试，由此避免投资额外的硬设备。Emulation Edition 也会提供虚拟硬件平台，可以用来开始为平台开发及测试应用程序。 您可以花费少许的运送及处理费用，获得有试用期间的完整产品的评估版。 何谓 Windows CE .NET 的授权模式？ Windows CE .NET 的授权程序牵涉两个步骤：取得 Windows CE .NET 工具组开始建置装置影像，以及为将要散布包含影像的每个装置购买 Runtime 授权。利用最新版本的 Window CE .NET，Microsoft 已引进新的执行期间授权。如需授权条件的详细信息，请参阅 Important Licensing Information 或 连络您的经销商。 如何为 Windows CE .NET 撰写应用程序？ 若要为 Windows CE .NET 撰写应用程序，Microsoft 提供一组包含多种程序语言的工具，可以建立 Managed (.NET) 或 Unmanaged 应用程序。使用 Microsoft Visual Studio .NET 撰写 Managed 程序代码或使用 eMbedded Visual C++ 撰写原始程序代码。 可以使用 eMbedded Visual C++ 3.0 为 Windows CE .NET 撰写应用程序吗？ 不必。您将会需要 eMbedded Visual C++ 4.0 来撰写应用程序。这个产品已随附于 Windows CE .NET。 使用 eMbedded Visual Basic 3.0 建立的应用程序可以在 Windows CE .NET 上执行吗？ 不必。使用 Microsoft eMbedded Visual BasicR 3.0 建立的应用程序无法在 Windows CE .NET 上执行。想要使用 Visual Basic 撰写新应用程序的开发人员可使用 Visual Studio .NET 与 Visual Basic .NET。如需详细信息，请造访 Visual Studio 网站。 如何从 eMbedded Visual Basic 移转到 Visual Basic .NET？ 若要了解如何从 eMbedded Visual Basic 移转到 Visual Basic .NET，请参阅 Visual Studio .NET 网站的 Embedded Applications: Getting Started with Smart Device Extensions for Visual Studio .NET 文件。 为何应该使用 Visual Studio .NET 而不是 eMbedded Visual C++ 来撰写应用程序？ 要建立的应用程序类型将会决定该使用原始程序代码还是 Managed 程序代码 (.NET)。当效能与控制为首要优先时，开发人员应该改为采用 eMbedded Visual C++ 或原始程序代码。当程序撰写模型的一致性与上市时间为主要考虑时，Visual Studio .NET 则具有无与伦比的优势。 何谓 C# (C Sharp)？ C# 是一种新的应用程序撰写语言，专为利用 .NET Compact Framework 而设计的。 如何取得 Smart Device Extensions，使用 Visual Studio .NET 来撰写 .NET Compact Framework 应用程序？ Smart Device 扩充功能的 Beta 1 版本与 .NET Compact Framework 现在已经推出。您可以申请以取得 Beta 版。 何谓 Microsoft .NET Compact Framework？ .NET Compact Framework 是 Microsoft .NET Framework 的子集，专为有限机体的装置而设计。.NET Compact Framework 是安全、可下载应用程序的硬件独立程序执行环境，这种应用程序以有限资源计算机装置为目标并加以最佳化。它也提供一些程序语言 (最初是 Visual Basic 和 Microsoft Visual C#?) 可供选择，并消除语言互相通讯时所面临的常见问题。 为什么应该在使用 Windows CE .NET 所建置的操作系统组态中包含 .NET Compact Framework？ 在装置上包含 .NET Compact Framework 可有数种好处。从一般使用者的观点而言，在装置上包含 .NET Compact Framework 可扩充对丰富应用程序及 Web 服务的使用数目。从开发人员的观点而言，包含 .NET Compact Framework 可简化并缩短开发程序，因此而增加开发人员的生产力。.NET Compact Framework 提供一些程序语言 (最初是 Visual Basic 和 Visual C#) 可供选择，并消除语言互相通讯时所面临的常见问题。例如，Visual C# 和 Visual Basic 组件可以轻易地在解决方案内混合使用，因此装置上可以执行更多种的应用程序。此外，.NET Compact Framework 所支持的每个程序语言同样都能存取架构及操作系统的基础功能。.NET Compact Framework 也能让程序设计人员使用丰富的架构，包括使用者接口类别、数据存取、XML 支持、自动内存管理及内存回收。 .NET Run Time 在 Windows CE .NET 中时有多大？ 虽然 .NET Compact Framework 尚未完成，但其目前所占空间大约是 2 MB，而采用 eMbedded Visual Basic 应用程序后约为 1.3 MB。 .NET Compact Framework 应用程序的执行与 eMbedded Visual C++ 应用程序一样好吗？ 在大部份的情况中，使用 eMbedded Visual C++ 撰写的应用程序将会比使用 Visual Basic .NET 或 Visual C# 所撰写的应用程序的执行速度较快。 不过，对于应用程序的计算机执行密集部份而言，开发人员将会在 Visual Basic .NET 应用程序上看到比相等的 eMbedded Visual Basic 应用程序较显著的改善。 为什么 eMbedded Visual C++ 没有整合到 Visual Studio .NET 中？ 根据客户的意见回馈，我们一开始就全心投注在让使用者更容易采用 Visual Basic 来设计装置。然而，使用原始程序代码 (C++) 建立装置的功能最终还是会整合到 Visual Studio .NET 中。 必须在平台上启用 .NET 吗？ 不必。在平台上启用 .NET 是选择性的。但是，在平台上包含 .NET Compact Framework 可带来一些好处。.NET Compact Framework 是受欢迎的 .NET Framework 的子集，而且完全得到 Visual Studio .NET 2003 的支援。它可让数百万的 Visual Studio .NET 开发人员使用已知的技术，快速且轻松地处理您的自订平台。其次，.NET Compact Framework 为您的平台提供功能强大、可以使用 XML Web Services 的执行环境，包括支持 Windows Form、Microsoft ADO .NET 数据存取、网络等等。 该如何取得 Windows CE .NET SDK？ 有几种方式： 从 MSDN 网站下载 Windows CE .NET 模拟版。 从 Microsoft Windows Embedded 网站订购 Windows Embedded Evaluation Kit。Evaluation Kit 会收取小额运送费用。 取得 Windows CE .NET 产品。 何谓 Shared Source Initiative？ 您可以在以下网站找到更多信息： Microsoft Windows Embedded Evaluation MSDN 何谓 Windows CE .NET 中提供的新原始程序代码？ 共享来源现在包含于 Windows CE .NET Test Kit (CETK)。这是开发人员用来自动化 Windows CE .NET 装置的测试及疑难排解的组件，而且是开发人员梦寐以求的重要程序代码。 共享来源在可下载的评估版及仿真版本以及上市产品中都是一样的吗？ 是的。 有任何我可以使用的内存遗漏 (Memory Leak) 侦测工具吗？ 有一些协力厂商提供这类工具： Entrek - CodeSnitch 或 ProcMan CodeGuru 有哪些工具可以不用连接主机，就能编辑装置的登录？ 有一些协力厂商提供这些工具，Microsoft 没有发行这类工具。 如需范例，请参阅 PHM Registry Editor。 Windows CE 实时 Windows CE 是否为实时的操作系统 实时效能的测量并不困难，但是很难定义。根据 Open, Modular, Architecture Control (OMAC) 使用者群组制定的标准，Microsoft Windows CE .NET 确实是实时的操作系统。 如需详细信息，请参阅下列数据： Real Time with Windows Embedded Real Time and Windows CE .NET 如需关于透过 Windows CE 3.0 (或 Windows CE .NET) 获得实时 Siemens 体验的非 Microsoft 看法，请造访 MSDN 网站。 配量是否有可以设定的最小值？ 没有强制性的最小值，但是此值不应低于 10ms，因为执行绪的交换为需要额外的负担。 如何检查执行中执行绪的优先级？ 您可以使用 "gi thrd" 指令或使用 Platform Builder 的执行绪窗口来检查侦错 shell 中的执行绪优先级。 有为所有执行绪设定预设执行绪配量的方法吗？ 预设执行绪配量在 OEM Adaptation Layer (OAL) (dwDefaultThreadQuantum) 中是设定为 100ms。OEM 可以在 OEMInit() 中将此变量设定为另一个值。 我可以从哪里进一步取得关于 Windows CE .NET 实时功能的详细信息？ 以下是一些额外的资源： Hard Real-Time -Tips and Tricks and Some Cool New Features Online Seminar - Windows CE 3.0 Real-Time 音讯 音讯驱动程序在 Windows CE 3.0 上运作正常，但是在 Windows CE .NET 上音质非常差。 如何修正此问题呢？ 在 Windows CE .NET 之前，音讯驱动程序通常都无法适当地支持数据流，因为数据流极少进行测试或演练。Windows CE .NET 软件混音器可让多种声音同时播放，但只利用相当小的缓冲区 (2-4KB) 将音讯数据传送到驱动程序。 不正确的数据流有两种最常见的原因： 过大的直接内存存取 (DMA) 缓冲区 无法正确处理音讯干扰 第一个问题 (过大的 DMA 缓冲区) 的修正方式是将 DMA 缓冲区大小缩小为 2k，或是使用登录覆写来增加从软件混音器传送的缓冲区的大小 (Platform Builder 文件说明如何执行此操作—请搜寻「SoftwareMixer」)。但是并不建议采用后面那一种方法，因为它会增加音讯的延迟而影响使用者聆听体验品质。 第二个问题的实际修正方式是依情况的不同，必须侦错驱动程序才能判定问题的原因。 Windows CE .NET 的文件讨论的新的 Unified Audio Model (UAM) 驱动程序模式。需要重新撰写音讯驱动程序或者可以使用现有的驱动程序吗？ 您应该可以重复使用现有的驱动程序，只有在下列情况才考虑转换为 UAM 驱动程序： 您想要支持平台上的 DirectSound，而且您的音讯装置支持硬件加速混音模式。 –或– 您想要支持混音器的应用程序发展接口 (API) (mixerOpen、mixerGetLineInfo 等等)。 简单音讯播放有范例程序代码吗？那么数据流音讯播放呢？ Windows CE .NET 附有非常简单的音讯播放应用程序，显示如何播放简短、简单的 .wav 档案，但是不会显示如何处理数据流播放—也就是说，大于可用随机存取内存 (RAM) 的档案或从网络上下载的音讯。 范例应用程序预设位置为 public/common/sdk/samples/audio/wavplay 目录。 简单音讯撷取有范例程序代码吗？那么数据流音讯撷取呢？ Windows CE .NET 附有非常简单的音讯撷取应用程序，显示如何录制简短、简单的 .wav 档案，但是不会显示如何处理资料流撷取—也就是说，大于可用 RAM 的档案或透过网络传送出去的音讯。 范例应用程序预设位置为 public/common/sdk/samples/audio/wavrec 目录。 我正在为 Pocket PC 装置撰写音讯应用程序。它在桌上型计算机及其它 Windows CE 装置—即使是另一种 Pocket PC—都运作良好，但是在我的装置上却无法使用。出了什么问题呢？ 您的音讯驱动程序可能已故障。请连络您的 Pocket PC 制造商，取得详细信息及更新程序。 多媒体 Windows CE .NET Media Player 支持 MPEG-4 视讯数据流吗？ 这取决于档案所使用的编码器。Windows CE .NET 支持 Microsoft MPEG-4，这是 Microsoft Windows Media Encoder v6 中使用的旧式 MPEG-4 实作。Windows CE .NET 也支持 Microsoft MPEG-4 ISO v1，它符合 MPEG-4 ISO 标准简易设定档。另外也支持 Windows Media Video。如需这些各种译码器的确实版本信息，请参阅 Windows CE .NET 文件。 一般规则是您要使用 Microsoft 支持的编码器，Windows CE .NET 最有可能支持 MPEG-4 视讯格式。如果您使用不同的编码器，最好的方式是使用 MPEG-4 简易设定文件来编码视讯，以确保可与 Windows CE .NET 译码器相容。 驱动程序 该如何为 Pocket PC 撰写 USB 驱动程序？ 这取决于您尝试撰写的驱动程序类型。您的 Pocket PC 可能没有 USB 主机硬件；您无法有效地为 Pocket PC 撰写任何 USB 客户端驱动程序，除非它具备必要的硬件。那些附有 USB 人性化接口装置 (Universal Serial Bus Human Interface Device，USBHID)、打印机和储存级客户端驱动程序的 Pocket PC。如果您想要撰写其它的客户端驱动程序，可以在 Platform Builder 文件中查看与 USB 客户端驱动程序有关的部份。 Windows CE 附有开放主机控制器接口 (Open Host Controller Interface，OHCI) 和通用主机控制器接口 (Universal Host Controller Interface，UHCI) 驱动程序；您不需要撰写主机控制器驱动程序，除非您是建置 Pocket PC 装置的 OEM，而且该装置具有非标准的主机控制器。Platform Builder 文件涵盖一些如何执行上述操作以及如何安排让驱动程序与 USB 互动的指导方针。如果您尝试撰写功能端的驱动程序，让 Pocket PC 作为主机 ActiveSync 客户端以外的功能来执行，那么我们无法提供进一步的帮助。您需要知道特定的 Pocket PC 上使用了哪些功能控制器，然后必须熟知控制器规格与 USB 规格。目前尚未为功能端的 USB 驱动程序定义更高层级的 Windows CE API。 电源管理 Windows CE 电源管理中的新功能有哪些？ Microsoft 从 Windows CE .NET 开始已加入一种新的系统模块，称为电源管理员。电源管理员对 Windows CE 带来以下功能及改变： 装置采用智能型电源管理架构。 从系统的暂停/恢复状态减低装置的电源状态。 OEM 可自订的模块，具有系统环境、电源状态和装置电源状态的全域检视。OEM 可以自订该全域检视，以最适合平台的方法来制定关于电源的全系统智能型决策。 它会将包围平台暂停的程序代码 (基本上是呼叫 OEMPowerOff()) 移动到 OEM 可以自订的模块中。这样可让 OEM 准备暂停，然后在执行绪/处理序内容中接着恢复，如同像 COM_PowerUp()/COM_PowerDown() 的装置驱动程序电源回复中的干扰内容。 在 Windows CE .NET 4.1 中，电源管理员已经在下列方面经过修改： 它已经纳入为模型装置驱动程序 (Model Device Driver，MDD) 以及平台从属驱动程序 (Platform-Dependent Driver，PDD) 中的组件。OEM 通常仅需要为他们的平台自订 PDD 即可。 PDD 包含的程序代码可以决定何时变更系统电源状态，包括何时暂停系统。这个决定过去是由 Graphics, Windowing, and Events Subsystem (GWES) 制定的。 电源管理员支持「聆听」多个装置类别。使用 ActivateDeviceEx() 加载装置时，装置管理员会为这些装置通告列示于其 IClass 的接口全域唯一识别项 (GUID)。藉由为这些装置变更登录的方式，OEM 可以自订电源管理员为特定装置提供特殊处理方法。这种方法已经为 Network Driver Interface Specification (NDIS) Miniport 和区块储存装置完成。 电源管理员 MDD 现在参考次数装置对象，来避免跨 DeviceIoControl() 呼叫处理保留关键区段。 现在呼叫 GwesPowerOffSystem() 的作用与 SetSystemPowerState(NULL, POWER_STATE_SUSPEND, POWER_FORCE) 的作用 (在包含 GWES 的系统上) 完全相同。 在 Windows CE .NET 中，GwesPowerOffSystem() 会在呼叫电源管理员暂停系统的前后执行一些工作。 在 Windows CE .NET 中，如果 POWER_FORCE 旗标设定为系统电源状态转换，就不会呼叫 IOCTL_POWER_QUERY。即使呼叫此 IOCTL，电源管理员也不一定会接受装置的响应。在 Windows CE .NET 4.1 中，电源管理员永远不会呼叫 IOCTL_POWER_QUERY。 不过，呼叫的基础结构在范例程序代码中提供，避免 OEM 决定实作永远提出要求以及永远允诺传回值的系统。 电源管理员在自己的 MDD 中实作全系统的作用中定时器。这是由 OEM 定义并用于电源管理员 PDD。 电源管理员利用 OEM 核心的支持，了解并使用系统唤醒原始码。 RequestPowerNotifications() 将 Flags 参数设定为 POWER_NOTIFY_ALL，因此不再需要应用程序来登录所有的通知。 电源管理员支持新的 PBT_POWERINFOCHANGE 通知，其中包含电池用量的信息。使用此通知会让应用程序不用决定要使用哪一个 GWES API (如果有的话) 来取得系统电源信息。 除了电源管理员之外，Windows CE .NET 4.1 也包括以下与电源有关的更新程序： Personal Computer Memory Card International Association (PCMCIA) 客户端 (包括 NDIS 和档案系统) 现在可以要求在暂停/恢复处理期间不要卸载卡片装置驱动程序，直到确实移除卡片为止。 IOCTL_HAL_ENABLE_WAKE、IOCTL_HAL_DISABLE_WAKE、IOCTL_HAL_GET_WAKE_SOURCE 和 IOCLT_HAL_PRESUSPEND 核心 I/O 控制已在范例平台中定义并实作。它们支持电源管理员以及被要求进入 D3 电源状态的装置驱动程序。 对电源管理员作用中定时器的支持已整合入 GWES、档案系统与网络堆栈中。 核心现在支持在电源处理例程中呼叫 DEBUGMSG() 和 RETAILMSG()。 核心现在严格强制在电源处理例程中系统呼叫的限制。在 PowerUp()/PowerDown() 回复中尝试呼叫不合法 API 将会显示一个讯息并停止系统。 对电源管理员输入/输出控制 (IOCTL) 的支持已经加入到更多的驱动程序中，包括 com16550 和 ddi_perm3。 GWES 暂停管理可以经由将 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Power/DisableGwesPowerOff 设定为不是零的值来停用。 停用 GWES 暂停管理会让使用 SystemParametersInfo 来设定 GWES 逾时值的尝试因为 ERROR_RESOURCE_DISABLED 而失败。 这个会影响 SPI_SETBATTERYIDLETIMEOUT、SPI_SETEXTERNALIDLETIMEOUT、SPI_SETWAKEUPIDLETIMEOUT 参数。SPI_GETBATTERYIDLETIMEOUT、SPI_GETEXTERNALIDLETIMEOUT、SPI_GETWAKEUPIDLETIMEOUT 参数将都会读成 0。 电源管理员与 Windows CE 永远使用的电源回复系统之间的关系是什么？ 电源管理员的目标是启用装置电源的智能管理。在电源管理员架构内，OEM 定义建立最大装置电源状态的系统电源状态，装置会呼叫 DevicePowerNotify() 来规范自己的电源量，而应用程序则呼叫 SetPowerRequirement() 确定所需的装置正在适合其需求的效能层级上执行。 电源回呼 (亦即 xxx_PowerDown()/xxx_PowerUp()) 与电源管理员无关。当系统准备进入 CPU 停止的暂停模式时即发生这些回呼。它们在呼叫 OEMPowerOff() 之前会立即产生。装置驱动程序通常会在系统暂停要求关闭自己之前收到，但是并非永远都是这种情形。电源管理员架构可让装置在系统执行或是系统暂停时关闭。 这取决于装置驱动程序实作器，当它们在装置电源装置为 D0、D1 或 D2 收到电源减弱回呼时要决定采用的动作。 通常解决方案会关闭装置，并在电源增加回复发生时重新开启。不过，如果装置没有 CPU 也可运作，那么就可以让它保持开启。 一般来说，电源管理员是如何运作的？ 电源管理员作为以下三个实体之间的中介物： 装置，得采智能型电源管理。 OEM，定义系统电源状态，限制装置的秏电量。 应用程序，需要收到电源相关事件的通知，队在秏电量最少的情况下保留使用中的装置。 电源管理员实作下列几组规则，让这三个部份可以一起运作： 系统电源状态在所有装置上加上秏电量上限。 应用程序在特定装置上加上秏电量下限 (以获得最小的效能等级)。 电源管理员将可让装置采智能型电源管理，只要装置将其秏电量保持在上限与下限之间。 如果下限高于上限，那么只要应用程序需要装置，装置的秏电量会持续攀高。 如果系统转换为暂停的系统电源状态，则系统暂停时将忽略应用程序强制的「下限」。 OEM、装置驱动程序撰写者及应用程序如何与电源管理员互动？ OEM 会在登录设定命名的系统电源状态。它们具有以下特征： 它们定义最大或上限的装置秏电量。 它们会包含一组的提示旗标，可告知电源管理员如何处理电源状态的转换。 例如，POWER_STATE_SUSPEND 旗标会告诉电源管理员它除了变更装置状态外还需要呼叫 PowerOffSystem()。 OEM 一般会自订电源管理员，让它根据系统的环境具有关于特定时间的适合状态的特殊知识。例如，OEM 可能定义后述各种状态：电池、电池用量过低、AC 电源、插入底座、拔除底座等等。 可管理电源的装置有下列特征： 它们需要通告电源管理员了解的电源管理接口。 这通常是预设 GUID，{A32942B7-920C-486b-B0E6-92A702A99B35}。它们可以使用 AdvertiseInterface() 或是在它们的组态登录机码将 GUID 加入至 IClass REG_MULTI_SZ 值来完成此动作。 装置可以使用时，电源管理员会传送一个它必须响应的 IOCTL_POWER_CAPABILITIES 要求。 电源管理员将会使用 IOCTL_POWER_SET 呼叫更新装置的电源状态。 如果装置驱动程序想要聪明地管理装置的电源，可以使用 DevicePowerNotify() API 要求电源更新。 将来某个时候或许可能会造成电源管理员发出一个 IOCTL_POWER_SET。 应用程序可以下列方式与电源管理员进行互动： 它们会使用 RequestPowerNotifications() 要求电源相关事件的通知。 不再需要通知时会呼叫 StopPowerNotifications()。 它们可以使用 SetPowerRequirement() 要求以最小的秏电量来保留正在使用的装置。 它们应该在最短的可能时间内让条件有效，然后使用 ReleasePowerRequirement() 来释放这些条件。 这些都在 Platform Builder 的文件及 MSDN 网站中有详尽的记载。 Microsoft 范例电源管理员实作如何区别哪些系统电源状态？ 它定义四种状态：On、UserIdle、SystemIdle 和 Suspend。当使用者活跃地使用系统执行某些动作时，它会进入「On」状态。如果使用者停止使用系统，它会进入「UserIdle」状态。当更多位使用者没有动作时，它会进入「SystemIdle」状态。只要装置驱动程序正在执行工作，系统就会维持在这个状态，但是如何装置驱动程序变成非作用时，系统就会进入「Suspend」状态。 「UserIdle」状态是用于使用者可能使用装置 (亦即看着显示器) 但没有实作与装置互动时。「SystemIdle」状态是用于使用者没有直接使用装置但其上的系统程序仍在作用时。例如，在档案转换期间，使用者可能以为装置变成闲置，即使系统程序实际仍在执行工作。 电源管理员实作制定关于使用者及系统活动的决定取决于两个作用中定时器，分别是「UserActivity」和「SystemActivity」。在系统电源状态间转换的逾时等候值会依照使用 AC 电源及电池电源而有所不同。 Windows CE 所提供的范例平台全都是采用 AC 电源。OEM 在系统仰赖电池电源、在底座上、在多种高频宽 RF 网络等时可能选择实作使用不同的电源状态。将范例电源管理员 PDD 复制到平台目录并适当地修改，即可实作这些类型的自订。 该如何设定让电源管理员闲置一段时间后暂停系统？ 电源管理员实作范例支持一组与系统电源状态转换相关联的逾时，并且能够将它们连结到作用中定时器。若要启用这个程序代码，您必须宣告作用中定时器并传送登录中的逾时。如需如何执行此动作的范例，请参阅 public/common/oak/files/common.reg。 电源管理器在系统闲置一段时间后有暂停系统。出了什么问题呢？ 如果您已包含电源管理员组件，系统电源状态转换逾时会定义于 common.reg。确定系统上已设定这些登录值。 如果登录设计看起来可以接受，请开启侦错区域取得其它信息。「定时器」和「平台」区域是很好的起点。系统中有些组件有可能重设非作用定时器，而防止系统暂停。 如果电源管理员是管理系统逾时，那么 SystemIdleTimerResetFunction() 的作用是什么呢？ 它的首要作用是通知 GWES 停止显示屏幕保护程序。使用作用中定时器的 OEM 通常会设定 NoIdleTimerReset 登录值，即便有连接的通讯端也会启用屏幕保护程序。 如何防止 GWES 暂停系统 (而由电源管理员执行这个工作)？ 将 HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/Power/DisableGwesPowerOff 设定为非零的 REG_DWORD 值。将此值设定为 0 会让 GWES 暂停管理保持在启用状态。此登录变量只会读取一次，就是在系统开机时间加载 GWES 时。 不要电源管理员决定何时暂停系统。该如何设定才能让 GWES 继续做此决定？ 身为 OEM，您可以永远自订电源管理员执行您想要的动作。但是让电源管理员被动执行的简单方法是从登录移除 AC/电池逾时。它会告知电源管理员允许 GWES (或其它程序) 决定何时要变更系统电源状态。 如需电源管理员如何决定是否在主动或被动模式中执行的范例，请参阅 public/common/oak/drivers/pm/platform/platform.cpp 中 PlatformPMActivelyManagesPower() 的实作。另外也请确定将 DisableGwesPowerOff 登录值设定为 0，这样 GWES 即可为您管理暂停。 电源管理员组件的确很棒，但是我想再另外设定装置驱动程序。需要做任何修改吗？ 不必。您的装置将会继续接收 PowerUp()/PowerDown() 回呼，如同 Windows CE 的前版本一样。 如何在应用程序中使用 SetDevicePower() API？ 应用程序不应该使用这个 API。 SetDevicePower() API 会覆写电源管理员和装置在管理装置电源状态的设定。例如，只有 OEM 作为控制台一部份所提供的程序代码才应该使用此 API。 如何在应用程序中使用 SetSystemPowerState() API？ 如果电源管理员主动管理系统电源，应用程序除非是暂停系统，否则不应该使用此 API。若要暂停系统，请呼叫 SetSystemPowerState(NULL, POWER_STATE_SUSPEND, 0)。此 API 的作用是允许 OEM 在电源管理员之外实作系统电源状态转换程序代码。电源管理员预设实作将不会允许应用程序初始化任何系统电源状态转换。 对 SetSystemPowerState() 的呼叫因为 ERROR_ACCESS_DENIED 而失败。 这是什么意思？ 电源管理员范例实作维护一个简单的状态计算机，来判断特定时刻最适用的系统电源状态。如果电源管理员正在管理电源，那么使用者正在使用系统时，应用程序能够「转换为系统闲置时间」就没有任何意义。电源管理员将会使用 ERROR_ACCESS_DENIED 拒绝这类不恰当的要求。 电源管理员将允许应用程序暂停系统，并将系统电源状态设定为目前的值，从登录重新加载电源状态组态。如需详细信息，请参阅 public/common/oak/drivers/pm/platform/platform.cpp 中 PlatformSetSystemPowerState() 的实作。 电源管理员目前定义哪一种装置类别 GUID？ 电源管理员预设实作理解下列 GUID： {A32942B7-920C-486b-B0E6-92A702A99B35}—一般可以管理电源的装置 {8DD679CE-8AB4-43c8-A14A-EA4963FAA715}—可管理电源的阻断装置 {98C5250D-C29A-4985-AE5F-AFE5367E5006}—可管理电源的 NDIS Miniport 应用程序藉由列举 HKEY_LOCAL_MACHINE/System/CurrentControlSet/Control/Power/Interfaces 的方式可以取得电源管理类别的清单。 应用程序呼叫参考特定装置的电源管理员 API 时，它们应该使用其类别限定装置的名称。如果未使用类别限制装置名称，电源管理员将假设装置属于一般可管理电源的装置类别。 限定类别的装置名称前面会加上类别 GUID 的前缀，以字符串显示，后面跟着反斜线。例如，「{8DD679CE-8AB4-43c8-A14A-EA4963FAA715}/DSK1:」指的是可管理电源的阻断装置，其名称为「DSK1:」。 装置如何开始取得电源管理员 IOCTL？ 装置必须通告它了解的接口，以电源管理员进行登录。在此内容中，接口与 COM 无关。 它仅仅表示登录的装置理解电源管理员 IOCTL。大部份的装置是使用从 CreateFile() 传回的控制代码存取，但是类别 GUID 也可以告诉电源管理员使用其它机制将 IOCTL 转换至装置。 接口的通告可以暗地里进行，只要在驱动程序的 IClass REG_MULTI_SZ 值由 ActivateDeviceEx() 加载时将 GUID 包含在内，或是明确地呼叫 AdvertiseInterface() 即可。 即使您知道您将会支持电源管理，仍建议您采用登录的方式。尽管您直接呼叫 AdvertiseInterface()，但是请考虑从登录读取要通告的 GUID。 可管理电源装置的预设 GUID 为 {A32942B7-920C-486b-B0E6-92A702A99B35}，而且定义于 pm.h 中。OEM 可以自订电源管理员来处理其它 GUID。这样 OEM 就可以为所有特定类型的装置 (或特殊装置) 来实作特殊处理。这就是为什么最好使用登录来宣告装置是可管理电源的原因。 电源管理员找到装置后，它会开启传送它电源管理员 IOCTL，从 IOCTL_POWER_CAPABILITIES 开始。 NDIS Minipor 是由 NDIS 数据流驱动程序加载的，而且没有自己的 IClass。电源管理员如何找出这些对象？ 如果 Miniport 支持 NDIS 电源管理 (也就是如果它们支持 OID_PNP_CAPABILITIES)，则 NDIS 只会将它们报告给电源管理员。因此，不是所有的 Miniport 都可以使用电源管理员来管理电源。 例如，NE2000 Ethernet Miniport 不能管理电源，因为它不支持 OID_PNP_CAPABILITIES。 无法变更 NDIS Miniport 或磁盘驱动器上的电源需求设定。可能是发生什么问题？ 磁盘和 Miniport 在使用电源管理员登录时并不使用一般可管理电源装置类别。如果装置名称为「CISCO1」，而且您呼叫 SetPowerRequirement(_T("CISCO1"), D0, 0)，那么这只会影响具有该名称以及使用预设类别进行登录的装置。最安全的做法永远是使用 GUID 限定装置名称，装置在通告其电源管理员接口时会使用该 GUID。在 Miniport 的情况中，名称应该是 "{98C5250D-C29A-4985-AE5F-AFE5367E5006}/CISCO1"。如果您之前尝试管理磁盘，则可能会使用 "{8DD679CE-8AB4-43c8-A14A-EA4963FAA715}/DSK1:"。 NDIS 如何处理电源管理员要求？ NDIS 将电源管理员装置电源状态对应到 NDIS 装置电源状态，如下所示： 电源管理员状态 NDIS 状态 D0 NdisDeviceStateD0 D1 NdisDeviceStateD0 D2 NdisDeviceStateD0 D3 请参阅下表。 D4 NdisDeviceStateD3 在 D3 的情况中，如果适配卡支持唤醒原始码，则 NDIS 会将电源管理员装置电源状态 D3 对应到最高秏电量状态，该状态是在 Miniport 驱动程序响应 OID_PNP_CAPABILITIES 查询时所报告的。例如，假设 Miniport 报告： MinLinkChangeWakeUp NdisDeviceStateD2 MinMagicPacketWakeUp NdisDeviceStateD1 MinPatternWakeUp NdisDeviceStateD2 对于此 Miniport，NDIS 会将 D3 从电源管理员转译为 NdisDeviceStateD1。 请注意，common.reg 会将 Miniport 的预设暂停电源状态定义为 D4。 如何使用电源管理员启用网络适配卡的 Wake-on-LAN 功能？ 有些 Miniport 支持 Wake-on-LAN。这个功能藉由将 Miniport 设定为电源管理员的 D3 状态来启用的。NDIS 会在内部将电源管理员装置电源状态转译为 NDIS 装置电源状态，如上面所示。特定 Wake-on-LAN 功能可能需要利用如控制台 applet 之类的装置特定方法来设定。例如，唤醒模式相符项目可能需要将特定模式以程序设计加入适配卡。同样地，如果适配卡支持多种类型的 Wake-on-LAN (也就是 Magic 封包和连结状态变更)，那么适配卡将会选择的类型必须在电源管理员接口以程序设计。在暂停期间将适配卡置于 D3 状态可以下列几种方式完成： 定义或更新暂停系统电源状态，以允许 Miniport 在暂停期间维持在 D3 状态。 范例： [HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Power/State/Suspend("{98C5250D-C29A-4985-AE5F-AFE5367E5006}] "Default"=dword:4 ; D4 "CISCO1"=dword:3 ; D3 应用程序可以使用 POWER_FORCE 旗标来呼叫 SetPowerRequirement()，在暂停期间继续供电给装置。 范例： h = SetPowerRequirement(_T("{98C5250D-C29A-4985-AE5F-AFE5367E5006}/CISCO1}"), D3, POWER_NAME | POWER_FORCE, NULL, 0); ReleasePowerRequirement(h); 由于这些方法可能导致装置在系统暂停时仍然耗用额外的电源，因此应该小心使用。 在暂停期间继续供电给 PCMCIA NDIS 适配卡，并使用接口的功能性干扰作为唤醒原始码。该如何启用这个功能？ 首先，请注意这与 Wake-on-LAN 不同，因为即使在系统暂停时，适配卡也应该可以正常运作。所以，如果启用 Wake-on-LAN 功能，PC 卡将会耗用较多的电源。NDIS D0 电源状态 (由 NdisDeviceStateD0 列举值表示) 是适配卡可以正常运作的唯一 NDIS 电源状态，而且可以撷取任意流量。如果必须在暂停期间也保持 Miniport 卡的电源，可以下列方式完成： 定义或更新暂停系统电源状态，以允许 Miniport 在暂停期间维持在 D0 状态。 范例： [HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Power/State/Suspend("{98C5250D-C29A-4985-AE5F-AFE5367E5006}] "Default"=dword:4 ; D4 "CISCO1"=dword:0 ; D0 应用程序可以使用 POWER_FORCE 旗标来呼叫 SetPowerRequirement()，在暂停期间继续供电给装置。 范例： h = SetPowerRequirement(_T("{98C5250D-C29A-4985-AE5F- AFE5367E5006}/CISCO1}"), D0, POWER_NAME | POWER_FORCE, NULL, 0); ReleasePowerRequirement(h); OEM 应用程序可以使用 SetDevicePower() 强迫适配卡即使在暂停期间仍保持在 D0。 注意 由于所有这些方法可能造成装置随时有电，因此必须小心使用。 范例： SetDevicePower(_T("{98C5250D-C29A-4985-AE5F-AFE5367E5006}/CISCO1}"), POWER_NAME, D0); SetDevicePower(_T("{98C5250D-C29A-4985-AE5F-AFE5367E5006}/CISCO1}"), POWER_NAME, PwrDeviceUnspecified); 是否有方法可以不要让 Windows CE 卸载并重新加载 PCMCIA 网络卡的 Miniport 驱动程序？ 是的。 登录项目 "ResetOnResume" 会告诉 NDIS 在恢复期间不要卸载 NDIS PCMCIA Miniport 驱动程序。NDIS 设定 CardRequestConfiguration() 呼叫 PCMCIA 适配卡服务中的 CFG_ATTR_NO_SUSPEND_UNLOAD 来进行此操作。 在恢复期间，会呼叫 Miniport 的 ResetHandler 将它还原成已知状态。 范例： [HKEY_LOCAL_MACHINE/Comm/Cisco1/Parms] "ResetOnResume"=dword:1 这个登录项目不是新的；现在它只是套用到 PCMCIA 适配卡。PCMCIA 网络适配卡的 ResetOnResume 默认值为 FALSE。如需 CFG_ATTR_NO_SUSPEND_UNLOAD 的详细信息 (此项目在 Windows CE .NET 4.1 中是新项目)，请参阅 PCMCIA 文件。请注意，装置不需要支持 OID_PNP_CAPABILITIES 此机制也能作用。另外，PCMCIA 驱动程序需要得到 OAL 的支持才能启动这个组态属性。 我有一个使用其它装置驱动程序的装置驱动程序。如何建立电源需求的阶层结构呢？ 关于这个操作的范例是依靠 COM 端口驱动程序的 Infrared Data Association (IrDA) 驱动程序。可惜的是 Windows CE .NET 或 Windows CE .NET 4.1 都没有这样的机制，因为两个装置驱动程序之间的相依性无法透过操作系统加以传播。另外，装置驱动程序不知道应用程序对其强加的需求—只有电源管理员知道这些需求。 执行此操作的一个方法是自订电源管理员，使其支持与每个装置相关联的选择性 DependsOn 登录机码。假设 IrDA 界面是 COM5: 而且它依靠称为 COM2: 的串行端口接口。 当应用程序在 COM5: 上呼叫 SetPowerRequirement()时，电源管理员会寻找登录，并在 COM2: 上强加适当的相符需求。 或者，COM2: 驱动程序只要不直接使用电源管理员来通告其接口。当 IrDA 驱动程序在 COM5: 启动时，它可以使用 IOCTL_POWER_CAPABILITIES 决定 COM2: 是可管理电源的，然后将 IOCTL_POWER_SET 呼叫套用到 COM2: 以及自己本身上。 我需要特定应用程序在执行重要程序时能够拦截并中断暂停要求。该如何做？ 电源管理员不提供这种机制，因为系统应该要能决定是否必须暂停。使用者可能会觉得没有可自订的暂停按钮很不方便。如果 OEM 正确设定作用中定时器，那么网络活动或磁盘活动将会防止系统尝试自动暂停。 如果 OEM 仔细考虑后，仍然决定需要防止暂停发生，则可自订电源管理员来支持此功能。其中一个可能的方法是让电源管理员公开包含 IOCTL 的可安装装置驱动程序接口来达这个目的。 当我暂停/恢复时看到讯息「!Unrecoverable Error: Exception or calling API inside Power Handler」和一个地址。这是什么意思？ 当驱动程序在其 PowerUp()/PowerDown() 回呼中造成一个例外状况时就会出现此讯息。这个例外状况可能是一个 API 呼叫，因为这些使用例外状况来转换为核心模式，但是造成的原因也可能除以零、解除参考不好的指标或尝试在断点停止。 Windows CE 永远会记录下特殊内容中所发生的电源回呼，其中仅支持少数一些 API。但是呼叫没有支持的 API 不一定会导致明显的问题，有时是因为 OEM 不小心安装可能让系统不稳定的驱动程序。不稳定的原因是特殊堆栈的 API 呼叫参数可能已经在电源回呼时即在使用。 从 Windows CE .NET 4.1 开始，操作系统都在 API 强加限制。 此讯息中显示的地址识别进行无效 API 呼叫的驱动程序。若要找出造成问题的驱动程序，请将地址与侦错工具中模块/符号窗口中的「Image Load Address」(影像加载地址) 进行比对。这样会显示所有动态链接库 (DLL) 的加载位置。 知道例外状况发生的地址后，即可到程序代码的该行，如下所示： 重新启动系统。 中断侦错工具。 开启监视窗口，然后在地址字段输入地址 (前缀为 0x)。 开启反组译码窗口。 从监看窗口将地址拖曳到反组译码窗口。IDE 应该会在错误地址显示反组译的原始程序代码。 在 PmResumeSystem 中收到 DEBUGCHK()。为什么？ 这种情况有两种常见的原因： 系统中有些组件正在电源管理员的外部初始化暂停作业—例如，直接呼叫 PowerOffSystem()。Microsoft 随附的电源管理员并不支持这个功能。不过，有些 OEM 可能选择在他们的平台上加入此支持，如果是这种情况他们应该要从原始程序代码移除 DEBUGCHK() 呼叫。 在系统暂停期间，电源管理员会在执行绪呼叫 SetSystemPowerState() 的内容中呼叫 FileSystemPowerFunction(FSNOTIFY_POWER_OFF)。这样会清除缓冲区，然后纳入并保留档案系统的关键区段。如果更高优先的执行绪试图存取档案系统，包括登录，将会阻断它直到呼叫 FileSystemPowerFunction(FSNOTIFY_POWER_ON) 为止。它将也会升高呼叫 SetSystemPowerState() 的执行绪的优先级。 如果此优先级的转换将执行绪的优先级升高到电源管理员恢复执行绪之上，那么恢复执行绪将会 DEBUGCHK()。这种情形的解决方法是设定登录中电源管理员的 ResumePriority256 值来调整恢复执行绪的优先级，让恢复执行绪永远以较高的优先级执行。 我从未在驱动程序中看过 IOCTL_POWER_QUERY 要求。为什么？ 电源管理员的预设实作完全不使用 IOCTL_POWER_QUERY。在 Windows CE .NET 版本的电源管理员中，只会偶尔呼叫这个 IOCTL，而且在某些被呼叫的时候才回产生传回值。这表示它是驱动程序不能仰赖、但仍会实作的 IOCTL，因此 Windows CE .NET 4.1 版本的电源管理员不会使用它。 有些 OEM 可能想要自订电源管理员，让它会永远呼叫此 IOCTL，而且永远允诺其传回值，所以支持 IOCTL_POWER_QUERY 的程序代码仍保留在模型装置驱动程序 (MDD) 中。 不过，它是有条件地编译—若要将它带回来，请设定 PM_SUPPORTS_DEVICE_QUERIES 并更新平台以便进行适当的 MDD 呼叫。 我从未在驱动程序中看过 IOCTL_POWER_GET 要求。为什么？ 电源管理员的设计是知道所有可管理电源装置的装置电源状态。它一般将不会对装置发出 IOCTL_POWER_GET，除非应用程序使用 POWER_FORCE 旗标集呼叫 GetDevicePower()。 如果要使用 Windows CE 的持续登录 (开机 Hive)，需要做任何修改吗？ 电源管理员会在开机阶段 0 期间读取 Managed GUID 和作用中定时器清单。 这些登录设定应该属于开机 Hive 的一部份。OEM 也可以包含一组预设的系统电源状态组态；这些组态可以使用持续登录的资料加以更新，但是开机阶段 0 期间永远可以使用预设设定。 唤醒原始码如何运作于 Windows CE .NET 4.1？ 以下 KernelIoControl() 程序代码会影响唤醒原始码：OCTL_HAL_ENABLE_WAKE、IOCTL_HAL_DISABLE_WAKE、IOCTL_HAL_GET_WAKE_SOURCE 和 IOCTL_HAL_PRESUSPEND。上述的前三个会将唤醒原始码识别项作为输入或输出参数。唤醒原始码识别项是参考系统唤醒原始码的 DWORD 值。IOCTL_HAL_PRESUSPEND 不需要参数。 如果一般装置干扰可以作为唤醒原始码，则装置的对应 SysIntr 值则可作为唤醒原始码 ID。SysIntrs 永远不得大于 SYSINTR_MAXIMUM，但是会为此群组保留可高达 (SYSWAKE_BASE—1) 的值。 Microsoft 在 nkintr.h 中定义一些唤醒原始码识别项。 其中包含如 SYSWAKE_RING_INDICATE 的值，指示 Ring Indicate 已经在 COM 埠上宣告。Microsoft 针对一般唤醒原始码保留介于 SYSWAKE_BASE 和 (SYSWAKE_OEMBASE—1) 之间的值。 OEM 可以专门为其平台定义唤醒原始码识别项。这些识别项开始于 SYSWAKE_OEMBASE。考虑想要区分 COM1 和 COM2 上 Ring Indicate 之间差别的 OEM。他们可以将 SYSWAKE_COM1_RING_INDICATE 和 SYSWAKE_COM2_RING_INDICATE 分别定义为 (SYSWAKE_OEMBASE + 0) 和 (SYSWAKE_OEMBASE + 1)。 IOCTL_HAL_ENABLE_WAKE 和 IOCTL_HAL_DISABLE_WAKE I/O 控件呼叫可分别启用及停用唤醒原始码。装置通常在取得电源管理员要求以进入或离开 D3 状态 (假设它支持 D3) 时，会发出这些 I/O 控件呼叫。这些呼叫告诉核心以程序设计电源管理单位，以启用对应于识别项的唤醒原始码。核心需要聪明地处理 ID 之间的重迭。例如，如果启用 SYSWAKE_RING_INDICATE 但明确停用 SYSWAKE_COM1_RING_INDICATE，则核心应该在 COM1 以外的所有 COM 埠上启用 Ring Indicate 唤醒。 IOCTL_HAL_GET_WAKE_SOURCE I/O 控件会传回唤醒原始码的识别码，该识别码会将系统从其最近的暂停中叫醒。如果唤醒原始码不明，或者系统从未暂停，则会传回 SYSWAKE_UNKNOWN。 核心应该将唤醒原始码对应到暂停期间启用的最适合 ID。例如，假设核心支持平台特定 ID SYSWAKE_COM1_RING_INDICATE 和 Microsoft 定义的一般 ID SYSWAKE_RING_INDICATE 两者，但是在系统暂停时只会启用 SYSWAKE_COM1_RING_INDICATE。在这种情况下，这个 I/O 控件会传回 SYSWAKE_COM1_RING_INDICATE。 如果只启用 SYSWAKE_RING_INDICATE，则会传回该 ID。如果两个 ID 都启用但是 COM1 叫醒了系统，则核心将传回 SYSWAKE_COM1_RING_INDICATE；如果是 COM2 或其它端口叫醒系统，则会传回 SYSWAKE_RING_INDICATE。 IOCTL_HAL_GET_WAKE_SOURCE 传回值是系统暂停期间的常数。 电源管理员会先呼叫 IOCTL_HAL_PRESUSPEND 再呼叫 PowerOffSystem()，让核心有机会在暂停前清除搁置的唤醒原始码。这样会消除唤醒原始码干扰在呼叫 PowerOffSystem() 及呼叫 OEMPowerOff() 的时间之间发生的竞赛情况。如果特别的逻辑，核心很难分辨此间隔期间已发生的干扰，因此它可能在唤醒原始码干扰搁置时暂停。 关于唤醒原始码的知识可以藉由明确编辑原始程序代码的方法以程序设计到电源管理员中。电源管理员也可以建立唤醒原始码与作用中定时器的关联，在这种情形中它会将唤醒事件视为装置活动，用来判断哪一个系统电源状态应该从暂停进入恢复状态。 无法让系统暂停。按暂停按钮时，系统会呼叫 OEMPowerOff()，但是无法作用。 您平台上的 OAL 可能认为应该作为唤醒原始码的干扰要求 (IRQ) 已经引发。范例 BSP 会保留一些已经发生的干扰。在 OEMPowerOff() 期间，OAL 会检查启用唤醒的干扰是否在呼叫 PowerOffSystem() 后已经发生。如果已经发生这类干扰，就会退回。 您的 OAL 应该实作 IOCTL_HAL_PRESUSPEND 并在呼叫时清除干扰清单，来防止这种情况发生。 作用中定时器如何运作？ 当它启动时，电源管理员会读取登录，取得作用中定时器名称的清单。对于每个定时器，它会寻找逾时 (以秒为单位) 以及选择性的唤醒原始码清单。接着它会建立三个命名的事件： 定时器重设事件 (这是自动重设事件) 「作用中」手动重设事件 「非作用」手动重设事件 如果与定时器关联的逾时过期而没有发出重设事件的讯号，则电源管理员会重设「作用中」事件并设定「非作用」事件。如果发出重新事件的讯号，电源管理员则会重设「非作用」事件并设定「作用中」事件。 任何驱动程序数量可能会对作用中定时器的重设事件开启控制代码，惯常使用 OpenEvent()，并在适当时机使用 SetEvent() 发出讯号。驱动程序应该从登录读取事件的名称—这样可让 OEM 决定电源管理员如何解译驱动程序的活动。 任何执行绪数量可能会对手动重设作用中/非作用事件开启控件代码，并等待它们决定系统的状态。 系统暂停时，电源管理员会重设与作用中定时器相关联的「作用中」手动重设事件。在恢复时，它会扫瞄定时器，查看是否与唤醒原始码相关联的任何定时器造成系统恢复。如果找到相符项目，就会发出该作用中事件的讯号。这样可让电源管理员恢复回与该作用中定时器 (如果有的话) 相关联的系统电源状态。 哪些登录设定会启用 GWES、档案系统、网络堆栈和 PCMCIA 总线驱动程銙中的作用中定时器？ GWES 会从 HKEY_LOCAL_MACHINE/System/GWE/ActivityEvent 读取事件名称。如果事件在此机码中被名称，而且它的控制代码可以开启，那么每次 GWES 使用者输入执行绪叫醒以处理输入事件将会发出事件的讯号。 只要连接的状态中至少有一个通讯端，网络堆栈中的 CXPORT 模块将会定期发出名称为 HKEY_LOCAL_MACHINE/Comm/CXPORT/NoIdleTimerEvent 的作用中定时器事件的讯号。许多 OEM 如果使用作用中定时器，则可能选择设定登录中的 "NoIdleTimerReset" 旗标。 只要退出或插入适配卡时，PCMCIA 驱动程序将会发出名称为 HKEY_LOCAL_MACHINE/Drivers/PCMCIA/StatusChangeActivityEvent 的作用中计时间事件的讯号。 可以不要修改 CPU 设定来变更驱动程序中的作用中定时器事件吗？ 是的。 电源管理员在等候定时器过期时不会处理定时器重设事件。作用中定时器逾时后，它将会检查过渡期间是否设定任何事件。如果没有，就会将定时器视为过期。否则，它会重设逾时然后继续等待。当定时器因为重设事件未发出讯息而过期时，或是非作用一段时间后重设事件第一次发生讯号时，它只会更新手动重设定时器事件。 即使电源管理员在驱动程序呼叫 SetEvent() 时主动处理定时器重设事件，如果驱动程序执行绪以较高优先级执行，那么将只会排程电源管理员的作用中定时器执行绪 (而且不会执行)。根据预设，作用中定时器执行绪以 THREAD_PRIORITY_ABOVE_NORMAL 执行，而大部份的驱动程序以 THREAD_PRIORITY_HIGHEST 或更高值执行，因此作用中定时器执行绪将不会比驱动程序先执行。作用中定时器执行绪优先级可以设定 TimerPriority256 登录值的方法来调整。 当数据实际是传送到远程系统，而不是连接通讯端时，可以让网络堆栈重设作用中定时器吗？ 有些 OEM 可能对于让电源管理员知道应用程序主动使用通讯端的事情更有兴趣，而对知道何时连接通讯端的事情并没有什么兴趣。网络堆栈不对此提供直接支持。 不过，OEM 可以建立定期轮询 GetTcpStatistics() 和 GetUdpStatistics() 的执行绪，判断 TCP 区段或 UDP 数据包被用来传送或接收。如果被用来传送或接收，这个执行绪可以重设作用中定时器。此执行绪可以当作可安装装置驱动程序来实作，作为电源管理员的一部份，或是作为应用程序的一部份。 如何告诉电源管理员我想要变更作用中定时器逾时？ 当系统开机时，作用中定时器是从登录读取的，但是之后并不会更新。请注意，作用中定时器逾时是用来指示何时某些部份的系统为作用中或非作用，而不是用来控制何时应该变更系统电源状态。系统电源状态转换定时器可以在系统执行时进行调整。 那么如何重设系统状态转换定时器呢？ 建立呼叫 _T("PowerManager/ReloadActivityTimeouts") 的已命名自动重设事件，然后在其控制代码上呼叫 SetEvent()。这样可以告诉电源管理员从其 Timeouts 机码重新读取状态转换定时器设定。 作用中定时器逾时与电源控制台 Applet 中看到的逾时选项之间有什么关系？ 作用中定时器逾时指出电源管理员在决定特定作用中来源变成非作用前应该等候的时间。这样会导致非作用事件发出讯号。控制台 applet 会决定电源管理员将会初始化系统电源状态转换前，非作用事件必须维持有讯号的时间长度 (没有让对应的作用中事件变成有讯号)。 一般来说，作用中定时器逾时应该与系统电源状态逾时没有很大的关系，但是却与预期的作用中间隔非常相关。例如，系统状态逾时可能以分钟来计算，而使用者作用中定时器可能是 10 秒。这样可防止在正常作业期间发生经常性的作用中定时器状态转换，但是使用者可能在系统「通知」前这 10 秒内并不会实际做任何事。因此，作用中定时器应该被视为「粗糙的」。 电源管理员以外的系统模块可以使用作用中定时器的信息吗？ 是的。 属于作用中定时器输出的手动重设定时器会被命名，所以电源管理员以外的模块可以存取这些对象。如果定时器的名称为「OEM_Activity」，则电源管理员将会建立名称为「PowerManager/OEM_Activity_Active」和「PowerManager/OEM_Activity_Inactive」的手动重设事件。 如何将作用中定时器的信息整合到夜光照明驱动程序中？ 您的夜光照明驱动程序需要取得对应于使用者活动的作用中定时器的名称。它可以从您定义的登录机码得到这项信息，或是将定时器名称内建到原始程序代码内。 假设只有一个定时器会反映使用者活动，则夜光照明驱动程序可以实作以下简单演算： 如果使用者在作用中，请确定夜光照明启动，然后等候设定非作用事件。设定时，请到步骤 2。 如果设定非作用事件，请等候一些可以设定的逾时时间，以便设定作用中事件。如果发生逾时，请关闭夜间照明。否则，当设定作用中事件时跳到步骤 1。夜光照明驱动程序一般会在作用中事件或非作用事件上执行 WaitForSingleObject()。如果它需要判断使用者作用中事件的目前状态，可以使用 0 的逾时来避免阻断。 我正在建立必须计算影像中每个位的装置。所有将会在此装置上执行的应用程序和驱动程序都由我控制，但我不想采用大部份的电源管理员基础结构。是否有方法可以将它从影像中移除？ 如果您使用不包含 GWES 的 HLBASE 影像，则系统中完全不需要电源管理员组件。或者，您可以使用 PMSTUBS 组件，该组件可透过目录选取。这是电源管理员 DLL 的最小版本，其中不会实作大部份的 API。电源管理员的片段版本仅支持要求 PBT_POWERSTATUSCHANGE 和 PBT_POWERINFOCHANGE 通知，并使用 SetSystemPowerState(NULL, POWER_STATE_SUSPEND, 0) 暂停系统。选取电源管理员的片段版本可以会对仰赖电源管理员服务的驱动程序或应用程序造成兼容性的问题。 驱动程序传递到电源管理员的 OWER_CAPABILITIES 结构中有些字段似乎没有用到。应该如何处理这些字段？ 电源管理员的范例实作不会使用 WakeFromDx、InrushDx、Power 或 Latency 结构成员。这些字段是作为 OEM 的预留位置，在 Microsoft 的电源管理员未来版本中可能会提供支持。 新的 PBT_POWERINFOCHANGE 通知的功用是什么？ PBT_POWERINFOCHANGE 通知包含最常从 GWES 要求的电池用量信息。 应用程序可以登录以接收此通知，而不用轮询电源状态的变更。 可以使用电源管理员来清除档案和重新启动装置吗？可否完全关闭系统以便运送呢？ 上述两个问题的答案都是「是」。只要使用您偏好的特殊语法来定义系统电源状态，并自订电源管理员来实行它就可以了。接着应用程序可以使用系统电源状态的名称或相关联的提示旗标来呼叫 SetSystemPowerState()。pm.h 标头档为这两种情况定义 POWER_STATE_RESET 和 POWER_STATE_OFF。OEM 也可以依自己的偏好来定义自订旗标。 若要实际实作上述行为，请定义电源状态如同它们处于暂停状态，而不要为实际电源关闭呼叫 PowerOffSystem() 呼叫 IOCTL_HAL_RESET 或平台特定 API。 如何将「活动讯号」定时器加入至应用程序？如果定时器过期，我想要清除并重新启动应用程序。 电源管理员并没有执行监视应用程序的设计。然而，您可以复制及修改 pmtimer.cpp 中的程序代码，为应用程序建立活动讯号定时器。您将需要修改定时器循环，让定时器在执行阶段建立和摧毁，然后您将需要为应用程序建立一个使用应用程序监视器来登录定时器的机制。讯息队列可能是好的选择。 其它 Platform Builder 3.0 和 Platform Builder 4.0 可以同时存在吗？ 应该是没有问题，只要它们安装在不同的目录中。 在 Windows CE .NET (4.0) 文件中 (主题：在虚拟对应上建立实体)，其内容说明： 「开机程序期间核心建立原始对应后，应用程序或 OAL 可以呼叫 CreateStaticMapping 或 NKCreateStaticMapping，加入至静态对应的虚拟地址集区。以这种方式对应的内存的范围为 C400 0000 到 E000 0000，而且仅建立为未快取的内存。」 但是对于 ARM 处理器而言，这个功能的作用则完全不同。它会查询硬式编码的 OEMAddressTable，这样就不会加入静态对应的虚拟地址集区。因此，这个范围就与文件中所述的范围不符。 NKCreateStaticMapping 的确不会建立新区域 (SHx 上也一样)。相反地，它只是传回现有的对应。 我为平台建立 Platform Software Development Kit (SDK) 以便与 Embedded VC++ 4.0 一起使用。 在 Platform Builder 上执行时，模拟环境的执行很正常。也建立了 MSI 套件且已顺利安装，同时可从 eVC 设计环境中使用。项目可以成功编译，而且在开始侦错时都下载了所有档案。 但是虽然仿真窗口有出现，应用程序却没有执行。为什么？ 在 Platform Builder 平台影像中停用 Kernal Independent Transport Layer (KITL) 就可能解进这个问题，这个选项预设是启用的。若要执行这个动作，透过平台精灵设定新的平台影像时，最后一个对话框将可让您选择是否「修改您的建置选项」。 按这个选项，然后清除 [启用 KITL] 选项。 建置平台完成后，汇出这个平台的 SDK，然后如以前的执行步骤来安装和使用它。仿真器无法连接启用 KITL 的 SDK。 建置时收到「影像对目前的 RAM 和 RAMIMAGE 设定过大」的错误讯息。这是什么意思？ 这个警告表示您建置的影像大小超过您在 config.bib 中指定的内存数量。 如何知道哪些组件是 Platform Builder for Windows CE .NET 提供的？ MSDN 概略描述了核心操作系统组件，另外还有可以利用的选择性模块的额外功能： Windows CE 应用程序开发常见问题 可以使用哪些开发工具来制作 Windows CE 架构的装置？ Microsoft eMbedded Visual Tools 3.0 (eVT) 包含 Microsoft eMbedded Visual Basic 3.0 (eVB) 与 eMbedded Visual C++ 3.0 (eVC) 两者。 eMbedded Visual Tools 可以制作以下对象： 执行 Windows CE 2.1x 的掌上型大小的 PC 执行 Windows CE 2.1x 的 Handheld PC Pro 装置 执行 Windows CE 3.0 的 Handheld PC 2000 装置 执行 Windows CE 3.0 的 Pocket PC 2000 装置 执行 Windows CE 3.x 的 Pocket PC 2002 装置 Microsoft eMbedded Visual C++ 4.0 可以制作执行 Windows CE .NET 的装置。目前已经设计 eVC 4.0 以便安装在与 eVC 3.0 相同的系统上，而且不会干扰 eVC 3.0 的操作。 此外，自订装置 (不包含于上列清单) 可能会包含 eVB 和 (或) eVC 的支持。如需详细信息，请连络装置制造商。 Microsoft .NET Compact Framework 是 .NET Framework 的子集，专为在智能型装置执行而设计的，可以支持 Managed 程序代码与 XML Web Services。由于 .NET Compact Framework 是桌面上 .NET Framework 的子集，所以熟悉 .NET 的开发人员将会发现很容易为智能型装置撰写 .NET 应用程序。 Visual Studio .NET 的 Smart Device Extensions 是一组扩充 Visual Studio .NET 的增强功能，可让开发人员为执行 .NET Compact Framework 的装置开发、侦错和部署应用程序。这些扩充功能包括适用 Visual C# .NET 和 Visual Basic .NET 的装置特定功能、远程装置侦错功能、装置仿真和一些其它的功能。 可以从何处取得这些开发工具呢？ eVT3.0 现在提供免费下载，下载网址为 Microsoft Download 网站。 eVC4.0 现在也提供免费下载，下载网址为 Microsoft Download 网站： .NET Compact Framework 目前仅提供 Beta 版。如需如何收到 Beta 版的详细信息，请参阅 GotDotNet 网站。 eMbedded Visual Basic 如何从 eVB 自动化 Media Player 呢？ 但是，eVB 无法自动化 Media Player。有两种其它方法可以从 eVB 播放媒体文件： 使用 CreateProcess API 启动 Media Player，以媒体文件作为其中一个指令行参数。 如果只是播放 .wav 档，请使用 PlaySound API。 MSND 网站上提供 Windows Media Player for Pocket PC SDK。遗憾的是，它并不支持直接从 eVB 使用。有一个与 SDK 一起下载的 eVC 范例：「SDK 也包含一个程序代码范例，示范如何使用 Microsoft eMbedded Visual C++R 将自订 C++ 程序中的控件嵌入。」如此您就可以将它包装在 eVC 并公开至 eVB。 如何显示 JPEG、GIF 和其它图形文件？ eVB 所附的 PictureBox 控件只支持 BMP 和 2BP 档案格式。若要显示其它图形格式，可使用协力厂商的控件。以下是一些其它的选项： S309PictureBox Control Imgdecmp OleThingo 尝试从 eVB 定位 Handheld PC 2000 装置时，看到「目标平台与目前连接到您系统的装置不符」讯息。为什么？ 除了 CEPC 以外的所有处理器，必须加入下列字符串到装置登录，以便让 eVC 和 eVB 能够辨识平台并允许档案正确地下载： HKEY_LOCAL_MACHINE/Windows CE Tools 字符串值 Platform={0F9D255B-97DA-4641-A8E6-7A7411D2472F} 加入此项目后，对装置执行软重设以便让变更生效。 使用数据库进行程序设计 如何将 Access 数据库转换为 CDB 数据库以便在装置上与 eVB 一起使用？ 此协力厂厂商的网站 DEVBUZZ.COM 有详尽的说明。 可以在 Pocket Access 数据库中的 eVB 使用 Seek 和 Find 方法吗？ 不必。Seek 与 Find 在 ADOCE 3.1 中实作时，必须有 OLEDB 支持 (如适用 CE 的 SQL 中的一样)。CEDB 数据提供者不是 OLEDB 架构，而且没有支持 Seek/Find。CEDB 是使用 CDB 档案的数据库提供者。 换句话说，「seek」和「find」仅在使用 ADOCE 3.1 与 SQL for Windows CE 时才有作用。 Pocket Access 数据库与 ADOCE 的限制有哪些？ 在 Windows CE 2.1x 装置中： 最大记录大小 128K 最大数据库档案大小 16MB 最大字段计数无限制 最大属性大小 64K 最大排序顺序 4 最大对象数目 64K 请注意，对象可以视为对象储存或数据库容量中的数据区块。以下是一些不同类型的对象： 登录机码或值 (仅在对象储存) 目录 (仅在对象储存) 档案标头 (仅在对象储存) 数据区块 - 最大可到 4KB 的档案数据，或最大可到 4KB 的数据库记录 数据库标头 在 Windows CE 3.0 装置中，其 3.0 的限制与上述列示的相同，除了最后一个。数据库档案中一个数据表是限制为 64K 的记录，但是数据库档案通常可以更高 (方法是在其中包含一个以上的数据表)。对象 (记录、数据表、4K 的属性数据区块) 的最大数量为 4096*1024=大约 4 百万 Pocket PC 在数据库大约写入 15,000 笔记录后就锁住了。 如果您开发使用 Windows CE 3.0 的平台，这问题的修正方法如 Microsoft Knowledge Base 的文件中所述。 如果您为已发行的装置开发应用程序，而且该装置包含这个问题，那么修正程序必须放置在 ROM 中，如此一来只有装置制造商可以执行这个修正。 如果您无法更新已发行装置上的 ROM，对于此问题有几个因应措施： 切割您的数据放入较小的数据库，每个包含大约 10,000 笔记录。 如果数据库包含 10,000 个以上的记录，请不要排序字符串。 使用 Microsoft SQL Server? for Windows CE 进行开发。SQL Server for CE 没有这个程序错误，而且使用大型数据库时其效能较好。 其它资源： 下列新闻群组可用来张贴： Windows CE .NET/Platform Builder Windows XP Embedded Windows NT Embedded Windows CE Embedded Programming eMbedded Visual C++ eMbedded Visual Basic Pocket PC Development .NET Compact Framework Windows CE Application Development Win32 Programmers targeting Windows CE Windows CE .NET 操作系统： Windows CE .NET Tips Frequently Asked Questions, Steve Maillet 的网站 Windows XP Embedded： WindowsXP Embedded Tips Frequently Asked Questions Windows Server Appliance Kit： Frequently Asked Questions Windows CE 应用程序开发 Microsoft .NET Compact Framework 和 Smart Device Extensions： GotDotNet Microsoft eMbedded Visual C++ 4.0： MSDN ADOCE： Pocket PC Developer's Network MSDN Microsoft eMbedded Visual Basic： Frequently Asked Questions About eVB3 DevBuzz (http://www.devbuzz.com/) Microsoft Knowledge Base (搜寻字词：eVB) PocketPC.com Pocket PC Developer's Network