(0) exportieren Drucken
Alle erweitern

Häufig gestellte technische Fragen zu Microsoft Windows CE .NET

Veröffentlicht: 19. Jan 2003 | Aktualisiert: 09. Nov 2004

Wir sind an Ihrem Feedback zu diesen häufig gestellten Fragen interessiert. Senden Sie Ihr Feedback bitte an edevfdbk@microsoft.com.

* * *

Auf dieser Seite

Allgemeine häufig gestellte Fragen zu Windows CE Allgemeine häufig gestellte Fragen zu Windows CE
Windows CE Windows CE
Sonstiges Sonstiges
Häufig gestellte Fragen zur Windows CE-Anwendungsentwicklung Häufig gestellte Fragen zur Windows CE-Anwendungsentwicklung

Allgemeine häufig gestellte Fragen zu Windows CE

Was ist Windows CE?
Microsoft Windows CE ist eine offene, skalierbare Windows-Plattform für ein breites Spektrum an Kommunikations-, Unterhaltungs- und Mobile Computing-Geräten. Bei der standardisierten Windows CE-Plattform handelt es sich um ein völlig neuartiges Betriebssystem, das von Grund auf neu konzipiert wurde, um neue Kategorien von Nicht-PC-Geräten für den geschäftlichen und privaten Bereich zu ermöglichen, die miteinander kommunizieren, Informationen mit Windows-PCs austauschen und eine Verbindung zum Internet herstellen können.

Warum hat Microsoft Windows CE entwickelt?
In den letzten Jahren hat Microsoft seine Vision des Begriffs "Informationen auf Tastendruck" immer wieder neu formuliert. Dabei hat sich die Vorstellung, dass auf jedem Schreibtisch und in jedem Haushalt ein PC vorhanden sein sollte, in die Idee von computerbasierten Geräten in einer Vielzahl von geschäftlichen und privaten Umgebungen geändert. Das Windows CE-Betriebssystem ist das Ergebnis einer mehrjährigen Entwicklungsanstrengung, um diese Vision zu erfüllen. Mit Windows CE bietet Microsoft eine offene, standardisierte Plattform, die es den OEM-Herstellern (Original Equipment Manufacturer), Hardwareherstellern, Softwareentwicklern und letztendlich Endverbrauchern wesentlich einfacher macht, ihre Produkte an neue Nicht-PC-Technologien und -Lösungen anzupassen.

Wer verwendet Windows CE?
Eine aktuelle Liste der Windows Embedded-Partner finden Sie auf der Microsoft Windows Embedded Partner-Site.

Was ist der Unterschied zwischen Windows CE 3.0 und dem Pocket PC?
Bei Windows CE handelt es sich um ein Betriebssystem, das als Bausteinsystem ausgeliefert wird. Pocket PC ist ein spezifisches Gerät, das aus diesen Windows CE-Bausteinen erstellt wird. Das Windows CE 3.0-Betriebssystem auf Pocket PC- und Pocket PC 2002-Geräten ist deshalb nicht mit dem Windows CE 3.0-Betriebssystem identisch, das auf anderen Geräten ausgeführt wird.

Weitere Informationen und häufig gestellte Fragen zu Pocket PC finden Sie auf der Microsoft MSDN-Website.

Was ist Microsoft Windows CE .NET?
Microsoft Windows CE .NET ist der Nachfolger von Windows CE 3.0. Es handelt sich um ein robustes Echtzeitbetriebssystem für die schnelle Entwicklung der nächsten Generation von intelligenten und ressourcensparenden Geräten. Windows CE .NET wird von den vier wichtigsten CPU-Architekturen sowie von über 200 CPU-Typen unterstützt und in einer Vielzahl von Gerätetypen verwendet, unter anderem PDA (Handheld), Windows Thin Client, Smartphone, Web Pad, Internet-/Medienanwendungen, Set-Top Box, Residential Gateway, Retail Point-of-Sale (POS) (Kassenterminal) und Industrial Automation Device (Industrieautomationsgerät). Da Windows CE .NET modular aufgebaut ist, kann der Ressourcenbedarf an die spezifischen Produktanforderungen einer Vielzahl von Geräten angepasst werden.

Was ist neu bei CE .NET v4.1 (Codename Jameson)?
Jameson ist ein kleineres Update zur kürzlich veröffentlichten Windows CE .NET-Technologie, das eine Reihe von zusätzlichen Technologien bietet, die von Kunden gewünscht wurden und noch vor dem Erscheinen der nächsten Hauptversion von Windows .NET bereitgestellt werden sollten.

Entwickler finden ein breites Spektrum an neuen und verbesserten Funktionen, einschließlich:

  • Unterstützung für drahtlose Technologie, wie etwa Bluetooth und 802.11.

  • Geräteemulation, mit der die gesamte Geräteumgebung ohne zusätzliche Hardwareinvestition emuliert werden kann.

  • Ein Plattform-Assistent, der es Ihnen ermöglicht, aus einer Vielzahl von vordefinierten Geräteentwürfen auszuwählen, um Ihren Entwicklungsprozess zu beschleunigen.

  • Vielfältige Multimedia- und Browserfunktionen, wie etwa Microsoft Internet Explorer 5.5 und Microsoft Windows MediaT-Codecs und Steuerelemente.

Darüber hinaus erweitert ein kleineres Update mit der Bezeichnung Windows CE .NET, Version 4.1, die bestehende Version von Windows CE .NET um folgende Funktionen:

  • Internet Protocol Version 6 (IPv6)

  • File Viewer

  • Den neuen Systems Management Server (SMS) 2003-Client

  • Alle bisher veröffentlichten QFE-Updates (Quick Fix Engineering), einschließlich Sicherheitsupdates.

Weitere Informationen finden Sie auf der "Microsoft Windows Embedded-Site".

Was bedeutet das ".NET" in Windows CE .NET?
Microsoft .NET bezeichnet eine Reihe von Microsoft-Softwaretechnologien, die dazu dienen, Informationen, Benutzer, Systeme und Geräte miteinander zu verbinden. Sie ermöglicht ein noch nie da gewesenes Maß an Softwareintegration durch Verwendung von XML Web Services (XML, Extensible Markup Language). Dabei handelt es sich um kleine modulare Anwendungen, die miteinander und mit anderen größeren Anwendungen über das Internet kommunizieren. Auf diese Weise liefert Software, die über .NET kommuniziert, die Voraussetzungen, die Entwickler benötigen, um XML Web Services zu erstellen und miteinander zu verbinden. Der Vorteil für einzelne Benutzer ist eine nahtlose und beeindruckende Erfahrung des Informationsaustausches. Zu den in Windows CE .NET implementierten .NET-Technologien gehören XML, Simple Object Access Protocol (SOAP), Microsoft Passport, Microsoft Windows Messenger sowie das Microsoft .NET Compact Framework, das die Produktivität von Entwicklern steigert.

Warum sollte ich ein eingebettetes System unter Windows CE .NET erstellen?
Windows CE .NET bietet die Tools und Technologien, die Entwickler von eingebetteten Systemen fordern. Entwickler finden ein breites Spektrum an neuen und verbesserten Funktionen vor, einschließlich Unterstützung für drahtlose Technologien wie Bluetooth, Geräteemulation, einen neuen Plattform-Assistenten und vielfältige Multimedia- und Browserfunktionen. Diese umfassende Toolsammlung ermöglicht die schnelle Entwicklung intelligenter Entwürfe für die Ausführung vielfältiger Anwendungen auf der aktuellen Hardware. Wenn Sie Ihren nächsten eingebetteten Entwurf mit Windows CE .NET erstellen, profitieren Sie von den folgenden Vorteilen:

  • Windows CE .NET ermöglicht die Erstellung skalierbarer drahtloser Plattformen, um mobile Geräte flexibel in vorhandene Infrastrukturen einzubinden.

    • Umfassende Unterstützung drahtloser Kommunikation für PANs, LANs und WANs, einschließlich Bluetooth und 802.11.

    • Unterstützung für sowohl IPv4- als auch IPv6-Protokolle, einschließlich einer Vielzahl netzwerkfähiger Anwendungen wie Microsoft Internet Explorer 5.5 und Winsock sowie einer Reihe von Technologien, die Interoperabilität und das Testen von Dual Stack-Netzwerken ermöglichen.

    • Erweitern Sie Ihre vorhandene Managementinfrastruktur mit Geräten, die den derzeit in Entwicklung befindlichen Microsoft Systems Management Server nutzen.

  • Windows CE .NET bietet zuverlässige Betriebssystembasisdienste und ermöglicht somit die effiziente Realisierung anspruchsvoller Echtzeitentwürfe von eingebetteten Systemen auf einer Vielzahl von Geräten.

    • Aktivieren Sie niedrige Latenz und gebundene deterministische Systemleistung mit fester RTOS-Kernelunterstützung (Real Time Operating System).

    • Implementieren Sie lokale und Netzwerksicherheit für die Speicherung und Übertragung von Daten.

    • Optimieren Sie die Geschwindigkeit, das Preis-/Leistungsverhältnis und die Leistungsfähigkeit von Geräten durch eine breite Auswahl von CPUs.

  • Windows CE .NET ermöglicht die Entwicklung intelligenter .NET-Geräte, so genannter Smart Devices, sowie komplexe personalisierte Benutzererfahrungen, die Geräte, PCs, Server und Web Services umspannen.

    • Ermöglichen Sie Benutzern die Anzeige der gängigsten Office-Dokumente, einschließlich Microsoft Word, Microsoft Excel, Microsoft PowerPoint®, Adobe Acrobat sowie Bilddateien ohne Dateikonvertierung.

    • Erstellen Sie Entwürfe, die die neusten Multimediaerfahrungen bieten, einschließlich Microsoft Windows MediaT 8-Codecs und -Steuerelemente sowie DRM (Digital Rights Management).

    • Erstellen Sie auf effiziente Weise lokalisierte eingebettete Geräte und Anwendungen mit einsatzfertiger Unterstützung für mehrere Sprachen.

    • Integrieren Sie Web Services sicher in Ihre intelligenten Geräte mit Unterstützung für XML 3.0.

    • Erstellen Sie mit dem .NET Compact Framework leistungsfähige Anwendungen, die auf mehreren Geräten lauffähig sind.

  • Windows CE .NET bietet eine umfassende End-to-End-Toolsammlung für die schnelle Entwicklung intelligenter Entwürfe auf der aktuellen Hardware unter Verwendung vielfältiger Anwendungen.

    • Erstellen Sie Entwürfe und Prototypen ohne die Anschaffung zusätzlicher Hardware, indem Sie die Emulationstechnologien innerhalb der Hostworkstation verwenden.

    • Beschleunigen Sie Ihre eingebetteten Entwürfe mit dem neuen Plattform-Assistenten, der Unterstützung für zwölf vorkonfigurierte Geräteentwürfe bietet.

    • Eröffnen Sie der Windows CE .NET-Entwicklung eine neue Ebene der Produktivität ohne Kompromisse bei der Flexibilität, Leistung oder Kontrolle, indem Sie Microsoft eMbedded Visual C++® 4.0 verwenden, eine eigenständige IDE (Integrated Development Environment).

Vereinfachen Sie die Entwicklung und Weitergabe von verteilten XML Web Services und Anwendungen mit Microsoft Visual Studio .NET.

Warum sollte ich ein eingebettetes System unter Windows CE .NET anstatt unter Linux erstellen?
Windows CE .NET bietet eine umfassende und integrierte eingebettete Betriebssystemumgebung mit zahlreichen Features, die von einer wachsenden internationalen Infrastruktur aus erfahrenen Partnern und Entwicklern unterstützt wird. Diese ermöglichen OEM-Herstellern kürzere Markteinführungszeiten, die Nutzung von eingeschränkten Ressourcen zur Produktdifferenzierung (und nicht zur Betriebssystementwicklung und -wartung) sowie den Schutz ihres geistigen Eigentums mithilfe eines renommierten Vertriebs- und Geschäftsmodells. Windows CE .NET enthält über 400 professionell getestete und konfigurierbare einfache Komponenten, einen präemptiven Multitaskingkernel mit Echtzeitunterstützung, vielfältige Funktionen für die drahtlose Übertragung, Multimedia- und Internetanwendungen und für die Energieverwaltung sowie eine integrierte Unterstützung für über 200 unterschiedliche 32-Bit-CPUs, einschließlich ARM-, MIPS-, SuperH (SH)- und x86-Architekturen.

Für welche Art von Geräten kann ich Windows CE .NET verwenden?
Mit Windows CE .NET können angepasste Plattformen für ein breites Spektrum an Geräten erstellt werden. Der neue Plattform-Assistent in CE .NET enthält eine Reihe vordefinierter Plattformen für die folgenden Geräte, um Ihren Entwicklungsprozess zu beschleunigen:

  • Mobiltelefon/Smartphone

  • Benutzerdefiniertes Gerät

  • Digital Imaging-Gerät

  • Industrieautomationsgerät

  • Internetgerät

  • Mediengerät

  • PDA/Mobiles Handheld-Gerät

  • Residential Gateway

  • Retail Point-of-Sale (POS)-Gerät

  • Set-Top Box

  • Tiny Kernel

  • Web Pad

  • Windows Thin Client

Welche Möglichkeiten bietet die Emulationstechnologie von Windows CE .NET?
Die Emulationstechnologie ermöglicht Entwicklern das Erstellen und Testen ihrer Entwürfe auf Workstations mit Windows 2000 oder Windows XP, ohne dass die Anschaffung zusätzlicher Hardware erforderlich ist.

Was ist IPv6?
Internet Protocol Version 6 ist ein neuer Industriestandard für Netzwerkprotokolle, der einen wesentlich größeren Adressraum unterstützt. Sie haben jetzt die Wahl zwischen IPv4 und IPv6, einschließlich IPv6-Versionen von Netzwerkkomponenten, wie etwa Internet Explorer 5.5 und Windows Media, um nur einige zu nennen. Windows CE .NET enthält auch eine Reihe von Technologien, die die Interoperabilität und das Testen von Dual Stack-Netzwerken (bieten Unterstützung für IPv4 und IPv6) ermöglichen, um den Übergang von IPv4 nach IPv6 zu erleichtern.

Welcher Unterschied besteht zwischen den File Viewern für Windows CE und den Anwendungen, die in der Pocket PC-Plattform und im Handheld PC enthalten sind?
Windows CE .NET enthält eine Reihe von File Viewern, die Benutzern das Anzeigen und Drucken von systemeigenen Microsoft Office- und Adobe Acrobat-Dokumenten ermöglichen. Dies unterscheidet sich von den Pocket-Anwendungen für die Pocket PC- und Handheld PC-Plattformen, die das Bearbeiten von Dokumenten ermöglichen, nachdem diese mit der Microsoft ActiveSync-Technologie konvertiert wurden. Die File Viewer in Windows CE .NET können auf einem Windows CE .NET-Gerät ohne ActiveSync- oder Dateikonvertierung verwendet werden, wenn auch keine Bearbeitungsfunktionen zur Verfügung stehen.

Wie funktioniert die Remoteverwaltung von Geräten, die mit Windows CE .NET 4.1 entwickelt wurden?
Windows CE .NET 4.1 verfügt über einen neuen Gerätemanagementclient, um den vorhandenen SNMP V. 4.2-Client zu ergänzen. Sobald der neue SMS 2003-Server veröffentlicht ist, ermöglicht dieser neue SMS 2003-Client Funktionen zur Unternehmensverwaltung wie Hardware-/Softwareinventarisierung und Softwareweitergabe, wodurch die Softwareverteilung und das Bestandsmanagement von Kunden verbessert wird. Der neue SMS 2003-Client wurde vor der Veröffentlichung von SMS 2003 freigegeben, um dem Umstand gerecht zu werden, dass viele Kunden zusätzliche Zeit für das Testen und die Weitergabe benötigen. Für Kunden, die ihren eigenen Server für die Verwendung mit dem SMS-Client erstellen möchten, wird Windows CE .NET 4.1 mit einer Dokumentation zum Client und zum Protokoll ausgeliefert.

Ich besitze bereits eine Kopie von Windows CE .NET. Wie erhalte ich die zusätzlichen Komponenten aus dem 4.1-Update?
Microsoft stellt die aktuelle Version von Windows CE .NET allen vorhandenen Windows CE .NET-Kunden über ihre Distributoren zur Verfügung. Wenden Sie sich bei Fragen an Ihren Microsoft Account Manager oder Distributor.

Was ist, wenn ich mitten in einem Projekt stecke und kein Upgrade auf die aktuelle Version von Windows CE .NET durchführen möchte?
Entwickler haben die Möglichkeit, entweder die aktuelle Version neben der vorherigen Version von Windows CE .NET zu installieren oder ein Upgrade auf die aktuelle Version durchzuführen. Wenn Sie sich für eine parallele Entwicklung entscheiden, sollten alle neuen Projekte mit der aktuellen Version von Windows CE .NET gestartet werden. Das Upgrade ist in der Lage, Projekte und Arbeitsbereiche aus der vorherigen Version von Windows CE .NET zu lesen und diese beim ersten Speichern in das 4.1-Format zu konvertieren. Jedoch können Änderungen, die mit der aktuellen Version durchgeführt wurden, nicht in der Vorgängerversion gespeichert werden.

Was ist, wenn ich mitten in einem Projekt stecke und eine Funktion benötige, die nur in der aktuellen Version von Windows CE .NET verfügbar ist?
Sie haben die Möglichkeit, das Update von Windows CE .NET zu installieren und ihr Projekt zu aktualisieren. Die aktuelle Version von Windows CE .NET unterstützt das Öffnen vorhandener Arbeitsbereiche und Projekte aus der vorherigen Version des Produkts. Jedoch können Änderungen, die mit der neuen Version durchgeführt wurden, nicht in der Vorgängerversion gespeichert werden.

Wie groß ist der minimale Ressourcenbedarf für Windows CE .NET?
Windows CE .NET setzt die Anstrengungen zur Minimierung der Ressourcenanforderungen des Betriebssystems für eingebettete Geräte fort. Aus diesem Grund werden grundlegende Kernelfunktionen auf Funktionsbasis ausgewählt, was eine minimale Implementierung von COM (Component Object Model)/XML möglich macht. Die minimale Konfiguration beträgt unter Umständen nur 200 KB und wird über modulare Netzwerk-, Multimedia- und Browsertechnologien sowie eine hoch komprimierte Schriftartenspeicherung erreicht.

Welche Prozessoren werden von Windows CE .NET unterstützt?
Windows CE .NET unterstützt ein breites Spektrum an CPUs. Eine vollständige Liste der unterstützten Prozessoren finden Sie unter Supported Processors.

Warum sollte ich Windows CE .NET verwenden, anstatt bei früheren Versionen von Windows CE zu bleiben?
Windows CE .NET verfügt über wesentliche Weiterentwicklungen gegenüber den Vorgängerversionen. Windows CE .NET bietet ein breites Spektrum an Technologien, die Entwickler bisher selbst implementieren mussten, wie etwa Unterstützung für 802.11 oder Kerberos. Mit Windows CE .NET ist es daher einfacher, modernere Geräte zu entwickeln und diese Geräte durch verbesserte Entwicklerproduktivität schneller auf den Markt zu bringen.

Wann sollte ich Windows CE .NET anstelle von Microsoft Windows XP Embedded verwenden?
Die Strategie von Microsoft besteht darin, ein breites Spektrum an Windows-basierten, eingebetteten Betriebssystemlösungen anzubieten, um den unterschiedlichen Anforderungen von Kunden gerecht zu werden. Letztendlich entscheiden die Entwurfsanforderungen Ihres Geräts darüber, welches die optimale Plattform für Sie ist. Auch kann es bei der Entscheidungsfindung hilfreich sein, wenn Sie sich den Entwicklungsschwerpunkt für jedes Betriebssystem vor Augen führen.

  • Wählen Sie Windows CE .NET für Lösungen, die Echtzeitunterstützung mit geringem Ressourcenbedarf für verschiedene Prozessoren benötigen.

  • Wählen Sie Windows XP Embedded für Lösungen, die aktuelle Windows-Technologien auf der Basis des x86-Prozessors erfordern.

  • Weitere Informationen darüber, welches eingebettete Betriebssystem von Microsoft am besten Ihren Anforderungen entspricht, finden Sie unter Welches Betriebssystem wählen: Windows CE .NET oder Windows XP Embedded?.

Wie kann ich Windows CE .NET und die dazugehörigen Entwicklungstools testen?
Das Testen von Windows CE .NET ist einfach. Es gibt zwei Testoptionen:

Sie können die Emulation Edition downloaden, die Ihnen den Entwurf und die Entwicklung einer Windows CE-basierten Plattform ermöglicht. Dabei können Sie die Plattform mithilfe von Software testen, die Hardware imitiert, wodurch zusätzliche Hardwareinvestitionen vermieden werden können. Die Emulation Edition bietet auch eine virtuelle Hardwareplattform, mit der Sie Anwendungen für unterschiedliche Plattformen entwickeln und testen können.

Gegen eine Versand- und Bearbeitungsgebühr erhalten Sie ein Evaluierungs Kit des vollständigen Produkts, das nur für einen begrenzten Zeitraum gültig ist.

Welches Lizenzierungsmodell wird für Windows CE .NET verwendet?
Der Lizenzierungsvorgang für Windows CE .NET umfasst zwei Schritte: Sie erwerben zunächst das Windows CE .NET-Toolkit, um mit dem Erstellen des Geräteabbilds zu beginnen und kaufen dann eine Laufzeitlizenz für jedes zu vertreibende Gerät, das das Abbild enthält. Mit der aktuellen Version von Windows CE .NET hat Microsoft eine neue Laufzeitlizenz eingeführt. Zusätzliche Lizenzierungsinformationen finden Sie unter Important Licensing Information, oder wenden Sie sich an Ihren Distributor.

Wie erstelle ich Anwendungen für Windows CE .NET?
Um Anwendungen für Windows CE .NET zu erstellen, bietet Microsoft eine reichhaltige Palette an Sprachen für die Entwicklung verwalteter (.NET) oder systemeigener (nicht verwalteter) Anwendungen. Mit Microsoft Visual Studio .NET erstellen Sie verwalteten Code, mit eMbedded Visual C++ erstellen Sie systemeigenen Code.

Kann ich mit eMbedded Visual C++ 3.0 Anwendungen für Windows CE .NET erstellen?
Nein. Sie benötigen eMbedded Visual C++ 4.0, um Anwendungen erstellen zu können. Dieses Produkt ist in Windows CE .NET enthalten.

Sind Anwendungen, die mit eMbedded Visual Basic 3.0 erstellt wurden, unter Windows CE .NET lauffähig?
Nein. Mit Microsoft eMbedded Visual Basic 3.0 erstellte Anwendungen können nicht unter Windows CE .NET ausgeführt werden. Entwickler, die neue Anwendungen mit Visual Basic erstellen möchten, können Visual Studio .NET mit Visual Basic .NET verwenden. Weitere Informationen finden Sie auf der Visual Studio-Website.

Wie führe ich eine Migration von eMbedded Visual Basic nach Visual Basic .NET durch?
Informationen zur Migration von eMbedded Visual Basic nach Visual Basic .NET finden Sie im Artikel Embedded Applications: Getting Started with Smart Device Extensions for Visual Studio .NET auf der Visual Studio .NET-Website.

Warum sollte ich Visual Studio .NET anstelle von eMbedded Visual C++ zum Entwickeln von Anwendungen verwenden?
Der zu entwickelnde Anwendungstyp bestimmt die Wahl zwischen systemeigenem und verwaltetem Code (.NET). Wenn Leistung und Kontrolle die Prioritäten sind, sollten sich Entwickler für eMbedded Visual C++ oder systemeigenen Code entscheiden. Falls ein konsistentes Programmiermodell und eine schnelle Markteinführung vorrangig sind, dann bietet Visual Studio .NET einmalige Vorteile.

Was ist C# (gesprochen "C Sharp")?
C# ist eine neue Anwendungsprogrammiersprache, die speziell für die Nutzung des .NET Compact Framework entwickelt wurde.

Wie erhalte ich Smart Device-Erweiterungen zur Entwicklung von .NET Compact Framework-Anwendungen mit Visual Studio .NET?
Die Beta 1-Version der Smart Device-Erweiterungen und das .NET Compact Framework sind jetzt verfügbar. Sie können sich für den Erhalt er Betaversion anmelden.

Was ist das Microsoft .NET Compact Framework?
Das .NET Compact Framework ist eine Teilmenge des Microsoft .NET Framework, das für Geräte entwickelt wurde, die über eingeschränkte Ressourcen verfügen. Das .NET Compact Framework ist eine hardwareunabhängige Programmausführungsumgebung für sichere downloadbare Anwendungen, die auf Computergeräte mit Ressourcenbeschränkungen zugeschnitten und dafür optimiert sind. Es bietet außerdem eine Auswahl an Sprachen (zunächst Visual Basic und Microsoft Visual C#T) und beseitigt die allgemeinen Probleme, die mit der Spracheninteroperabilität verbunden sind.

Warum sollte ich das .NET Compact Framework in die Betriebssystemkonfigurationen einbinden, die ich mit Windows CE .NET erstelle?
Es gibt eine Vielzahl von Vorteilen für die Einbindung des .NET Compact Framework in Ihr Gerät. Aus der Sicht des Endbenutzers bedeutet das Vorhandensein des .NET Compact Framework auf einem Gerät, dass zusätzliche Anwendungen und Web Services genutzt werden können. Aus der Sicht des Entwicklers vereinfacht und verkürzt die Einbindung des .NET Compact Framework den Entwicklungsprozess und steigert somit die Entwicklerproduktivität. Das .NET Compact Framework bietet eine Auswahl an Sprachen (zunächst Visual Basic und Microsoft Visual C#T) und beseitigt die allgemeinen Probleme, die mit der Spracheninteroperabilität verbunden sind. So können beispielsweise Visual C#- und Visual Basic-Komponenten innerhalb einer Lösung problemlos nebeneinander existieren, wobei eine größere Vielfalt von Anwendungen ermöglicht wird, die auf Ihrem Gerät ausgeführt werden können. Darüber hinaus besitzen alle vom .NET Compact Framework unterstützten Sprachen die gleichen Zugriffsrechte auf die zugrunde liegenden Funktionen des Framework und des Betriebssystems. Das .NET Compact Framework stellt allen Programmierern ein umfangreiches Framework zur Verfügung, einschließlich Benutzerschnittstellenklassen, Datenzugriff, XML-Unterstützung, automatische Speicherverwaltung und Garbage Collection.

Wie groß ist die .NET-Laufzeit in Windows CE .NET?
Obwohl die Arbeit am .NET Compact Framework noch nicht abgeschlossen ist, hat die Laufzeit derzeit eine Größe von 2 MB, im Vergleich zur 1,3 MB-Laufzeit, die die Ausführung von eMbedded Visual Basic-Anwendungen ermöglicht.

Entspricht die Leistung von .NET Compact Framework-Anwendungen der von eMbedded Visual C++-Anwendungen?
In den meisten Fällen sind Anwendungen, die mit eMbedded Visual C++ erstellt wurden, etwas schneller als solche, die mit Visual Basic .NET oder Visual C# erstellt wurden. Bei Anwendungsbereichen mit intensiven Rechenoperationen werden Entwickler jedoch eine wesentliche Verbesserung ihrer Visual Basic .NET-Anwendungen gegenüber ihren eMbedded Visual Basic-Entsprechungen feststellen.

Warum ist eMbedded Visual C++ nicht in Visual Studio .NET integriert?
Auf der Basis von Kundenfeedback richteten sich unsere Anstrengungen zunächst darauf, Visual Basic-Benutzern das einfachere Programmieren von Geräten zu ermöglichen. Die Möglichkeit, Geräteanwendungen mithilfe von systemeigenem Code zu erstellen (C++) wird jedoch letztendlich in Visual Studio .NET integriert werden.

Muss ich .NET auf meiner Plattform aktivieren?
Nein. Die Aktivierung von .NET auf Ihrer Plattform ist optional. Die Einbindung des .NET Compact Framework in Ihre Plattform hat jedoch eine Reihe von Vorteilen. Das .NET Compact Framework ist eine Teilmenge des gängigen .NET Framework und wird vollständig von Visual Studio .NET 2003 unterstützt. Es ermöglicht Millionen von Visual Studio .NET-Entwicklern mit bereits vorhandenen Kenntnissen, schnell und problemlos für Ihre benutzerdefinierte Plattform zu programmieren. Zweitens bietet das .NET Compact Framework eine leistungsfähige Ausführungsumgebung mit Unterstützung von XML Web Services für Ihre Plattform, einschließlich Unterstützung für Windows Forms, Microsoft ADO .NET-Datenzugriff, Netzwerk usw.

Wie kann ich das Windows CE .NET-SDK beziehen?
Es gibt eine Reihe von Optionen:

Was versteht man unter der Shared Source Initiative?
Weitere Informationen erhalten Sie auf einer der folgenden Websites:

Was ist der neue Quellcode, der mit Windows CE .NET ausgeliefert wird?
Der freigegebene Quellcode enthält jetzt das Windows CE .NET Test Kit (CETK). Mit dieser Komponente automatisieren Entwickler das Testen und die Problembehandlung von Windows CE .NET-Geräten. Dabei handelt es sich um den zentralen Quellcode, auf den Entwickler gewartet haben.

Ist der freigegebene Code in den downloadbaren Evaluierungs- und Emulationsversionen und im "Verkaufsprodukt" identisch?
Ja.

Gibt es ein Tool, mit dem ermittelt werden kann, dass nicht der gesamte reservierte Speicher freigegeben wird?
Es gibt eine Reihe Dritthersteller, die solche Tools zur Verfügung stellen:

Gibt es Tools, mit denen die Registrierung auf dem Gerät bearbeitet werden kann, ohne mit einem Host verbunden zu sein?
Es gibt Tools von Fremdanbietern, jedoch nicht von Microsoft. Ein Beispiel finden Sie unter PHM Registry Editor.

Windows CE

Echtzeit

Arbeitet Windows CE tatsächlich in Echtzeit?
Die Echtzeitleistung ist zwar einfach zu messen, kann aber schwer zu definieren sein. Auf der Grundlage der Standards, die von der OMAC-User Group (Open, Modular, Architecture Control) definiert wurden, ist Microsoft Windows CE .NET ein wahres Echtzeitbetriebssystem.

Weitere Informationen finden Sie unter den folgenden Adressen:

Um einen Microsoft-externen Standpunkt über Erfahrungen von Siemens hinsichtlich der Echtzeittauglichkeit von Windows CE 3.0 (oder Windows CE .NET) zu erhalten, besuchen Sie die MSDN-Site.

Gibt es einen minimalen Wert, auf den das Quantum eingestellt werden kann?
Es gibt kein vorgeschriebenes Minimum, aber es sollte wegen der zusätzlichen Restkapazität, die für Threadwechsel erforderlich ist, nicht unter 10 ms liegen.

Kann ich die Priorität für die Ausführung eines Threads überprüfen?
Sie können die Threadprioritäten in der Debugshell mit dem Befehl "gi thrd" oder mithilfe des Threadfensters des Platform Builders überprüfen.

Gibt es eine Möglichkeit, das Standardthreadquantum für alle Threads festzulegen?
Das Standardthreadquantum ist in der OEM Adaptation Layer (OAL) (dwDefaultThreadQuantum) auf 100 ms eingestellt. Ein OEM kann diese Variable in OEMInit() auf einen anderen Wert setzen.

Wo erhalte ich weitere Informationen zu den Echtzeitfunktionen von Windows CE .NET?
Im Anschluss erhalten Sie einige zusätzliche Ressourcen:

Audio

Mein Audiotreiber funktionierte unter Windows CE 3.0 einwandfrei, aber klingt unter Windows CE .NET fürchterlich. Wie kann ich das korrigieren?
Vor Windows CE .NET verfügten Audiotreiber selten über eine korrekte Streamingunterstützung, da dies selten getestet oder ausgeführt wurde. Der Windows CE .NET-Softwaremixer, der das gleichzeitige Abspielen mehrerer Sounds ermöglicht, streamt Audiodaten an den Treiber immer in relativ kleinen Puffern (2-4 KB).

Die zwei geläufigsten Ursachen für inkorrektes Streaming sind:

  • Zu große DMA-Puffer (Direct Memory Access)

  • Inkorrekte Verarbeitung von Audiointerrupts

Die Lösung für das erste Problem (zu große DMA-Puffer) ist die Verringerung der DMA-Puffergröße auf 2 KB oder die Verwendung einer Außerkraftsetzung der Registrierung, um die vom Softwaremixer gesendete Puffergröße zu erhöhen (suchen Sie in der Platform Builder-Dokumentation nach "SoftwareMixer"). Der zweite Ansatz wird nicht jedoch nicht empfohlen, da dabei die Audiolatenz erhöht und die Benutzererfahrung verschlechtert wird.

Die tatsächliche Korrektur für das zweite Problem erfordert ein individuelles Debugging des Treibers, um das Problem zu ermitteln.

In der Windows CE .NET-Dokumentation wird vom UAM-Treibermodell (Unified Audio Model) gesprochen. Muss ich meinen Audiotreiber neu erstellen oder kann ich meinen vorhandenen Treiber wieder verwenden?
Sie sollten in der Lage sein, Ihren vorhandenen Treiber wieder zu verwenden, und nur in folgenden Fällen einen Wechsel zu einem UAM-Treiber in Erwägung ziehen:

  • Sie möchten DirectSound auf Ihrer Plattform unterstützen, und Ihr Audiogerät unterstützt hardwarebeschleunigtes Mixing.

-Oder-

  • Sie möchten die Mixer-API unterstützen (mixerOpen, mixerGetLineInfo usw.).

Gibt es Beispielcode für eine einfache Audiowiedergabe? Wie sieht es mit dem Streaming der Audiowiedergabe aus?
Windows CE .NET wird mit einer sehr einfachen Audiowiedergabeanwendung ausgeliefert, die das Abspielen kurzer einfacher .wav-Dateien demonstriert, jedoch nicht auf die Verarbeitung von Streamingwiedergabe eingeht, d.h von Dateien, die größer als der verfügbare RAM-Speicher sind, oder Audiodaten, die aus dem Netzwerk kommen.

Die Beispielanwendung befindet sich standardmäßig im Verzeichnis public\common\sdk\samples\audio\wavplay.

Gibt es Beispielcode für eine einfache Audioaufnahme? Wie sieht es mit dem Streaming der Audioaufnahme aus?
Windows CE .NET wird mit einer sehr einfachen Audioaufnahmeanwendung ausgeliefert, die das Aufzeichnen kurzer einfacher .wav-Dateien demonstriert, jedoch nicht auf die Verarbeitung von Streamingaufnahme eingeht, d.h von Dateien, die größer als der verfügbare RAM-Speicher sind, oder Audiodaten, die über das Netzwerk gesendet werden.

Die Beispielanwendung befindet sich standardmäßig im Verzeichnis public\common\sdk\samples\audio\wavrec.

Ich entwickle eine Audioanwendung für mein Pocket PC-Gerät. Sie funktioniert einwandfrei auf meinem Desktop oder anderen Windows CE-Geräten - selbst auf einem anderen Pocket PC - jedoch nicht auf meinem Gerät. Woran kann das liegen?
Ihr Audiotreiber ist eventuell fehlerhaft. Wenden Sie sich an den Pocket PC-Hersteller, um weitere Informationen und Updates zu erhalten.

Multimedia

Unterstützt der Windows CE .NET Media Player MPEG-4-Videostreaming?
Die hängt vom Encoder ab, der für die Datei verwendet wurde. Windows CE .NET unterstützt Microsoft MPEG-4, eine Legacyimplementierung von MPEG-4, die im Microsoft Windows Media Encoder V6 verwendet wurde. Windows CE .NET unterstützt auch Microsoft MPEG-4 ISO V1 (kompatibel zum einfachen MPEG-4 ISO-Standardprofil). Windows Media Video wird ebenfalls unterstützt. Genaue Versionsinformationen für alle diese Decoder erhalten Sie in der Windows CE .NET-Dokumentation.

In der Regel gilt: Wenn Sie einen von Microsoft unterstützten Encoder verwenden, werden die MPEG-4-Videoformate mit großer Wahrscheinlichkeit unter Windows CE .NET unterstützt. Wenn Sie einen anderen Encoder verwenden, sollten Sie Videodaten mit dem einfachen MPEG-4-Profil codieren, um Kompatibilität mit dem Windows CE .NET-Decoder zu gewährleisten.

Treiber

Wie erstelle ich einen USB-Treiber für meinen Pocket-PC?
Das hängt davon ab, welche Art von Treiber Sie erstellen möchten. Ihr Pocket PC verfügt wahrscheinlich nicht über USB-Hosthardware. Wenn Ihr Pocket PC nicht über die erforderliche Hardware verfügt, können Sie keinen USB-Clienttreiber erstellen. Diejenigen Geräte mit der entsprechenden Hardware werden wahrscheinlich mit USBHID (Universal Serial Bus Human Interface Devices)-, Drucker- und Speicherklassen-Clienttreibern ausgeliefert. Wenn Sie andere Clienttreiber erstellen möchten, können Sie in den Abschnitten in der Platform Builder-Dokumentation nachschlagen, die sich auf USB-Clienttreiber beziehen.

Windows CE wird mit OHCI- (Open Host Controller Interface) und UHCI-Treibern (Universal Host Controller Interface) ausgeliefert. Sie müssen also keinen Hostcontrollertreiber erstellen, es sei denn, Sie sind ein OEM, der ein Pocket PC-Gerät mit einem Hostcontroller herstellt, der nicht dem Standard entspricht. Die Platform Builder-Dokumentation enthält einige entsprechende Anweisungen dazu und beschreibt, wie der Treiber für die Interaktion mit USB eingerichtet werden kann. Wenn Sie versuchen, einen funktionsseitigen Treiber zu erstellen, der bewirken soll, dass Ihr Pocket PC für den Host als etwas anderes als ein ActiveSync-Client erscheint, dann sind Sie praktisch auf sich gestellt. Sie müssen wissen, welcher Funktionscontroller auf Ihrem spezifischen Pocket PC verwendet wird, und Sie müssen sich mit den Controllerspezifikationen und den USB-Spezifikationen vertraut machen. Derzeit sind keine höheren Windows CE-APIs für funktionsseitige USB-Treiber definiert.

Energieverwaltung

Was ist neu an der Windows CE-Energieverwaltung?
Mit Windows CE .NET hat Microsoft ein neues Modul mit der Bezeichnung "Power Manager" (Energieverwaltung) eingeführt. Die Energieverwaltung enthält die folgenden Funktionen und Änderungen gegenüber Windows CE:

  • Ein Framework, in dem Geräte auf intelligente Art und Weise ihre eigene Energie verwalten können.

  • Der Energiestatus eines Geräts wird vom Standby-/Wiederherstellenstatus des Systems abgekoppelt.

  • Ein vom OEM anpassbares Modul, das über einen Gesamtüberblick über die Systemumgebung, den Energiestatus und die Energiezustände des Geräts verfügt. OEM-Hersteller können Anpassungen vornehmen, um intelligente Entscheidungen bezüglich der Energieverwaltung auf eine Art und Weise fällen zu können, die sich am besten für ihre Plattform eignet.

  • Dabei wird der Code für den Standbymodus der Plattform (im Grunde der Aufruf von OEMPowerOff()) in ein Modul verlagert, das OEM-Hersteller anpassen können. Auf diese Weise können sich OEMs auf Standbys vorbereiten und die Wiederherstellung in einem Thread/Prozess-Kontext anstatt in einem Interruptkontext in Gerätetreiber-Energierückrufen wie COM_PowerUp()/COM_PowerDown() durchführen.

In Windows CE .NET v4.1 wurde die Energieverwaltung wie folgt geändert:

  • Sie wurde in zwei Komponenten aufgeteilt, einen Modellgerätetreiber (MMD, Model Device Driver) und einen plattformabhängigen Treiber (PDD, Platform-dependent Driver). OEMs müssen in der Regel nur den PDD für die Plattform anpassen.

  • Der PDD enthält Code, mit dem entschieden werden kann, wann die Energiezustände des Systems geändert werden sollen. Anhand des Code wird zudem entschieden, wann das System in den Standbymodus übergeht. Die Entscheidung wurde bisher immer vom GWES (Graphics, Windowing, Events Subsystem) gefällt.

  • Die Energieverwaltung unterstützt die "Empfangsbereitschaft" für mehrere Geräteklassen. Wenn Geräte mit ActivateDeviceEx() geladen werden, kündigt der Gerätemanager in ihrem Auftrag die Schnittstellen-GUIDs (Globally Unique IDentifiers) an, die in ihrer IClass aufgelistet sind. Durch Änderung der Registrierung für diese Geräte können OEM-Hersteller die Energieverwaltung so anpassen, dass ein spezieller Umgang mit bestimmten Geräten möglich ist. Dies wurde bereits für NDIS-Miniports (Network Driver Interface Specification) sowie für Blockspeichergeräte durchgeführt.

  • Der MDD der Energieverwaltung führt nun eine Referenzzählung der Geräteobjekte durch, um zu vermeiden, dass kritische Abschnitte in DeviceIoControl()-Aufrufen gehalten werden müssen.

  • Der Aufruf von GwesPowerOffSystem() hat jetzt die gleiche Funktion wie SetSystemPowerState(NULL, POWER_STATE_SUSPEND, POWER_FORCE) (auf Systemen mit GWES). In Windows CE .NET führte GwesPowerOffSystem() einige Funktionen vor und nach dem Standbyaufruf der Energieverwaltung durch.

  • In Windows CE .NET wurde IOCTL_POWER_QUERY nicht aufgerufen, falls das POWER_FORCE-Attribut während eines Übergangs des Energiestatus des Systems festgelegt wurde. Selbst bei Aufruf von IOCTL wurde die Antwort des Geräts von der Energieverwaltung nicht immer berücksichtigt. In Windows CE .NET v4.1 ruft die Energieverwaltung niemals IOCTL_POWER_QUERY auf. Jedoch steht die Infrastruktur für den Aufruf im Beispielcode zur Verfügung, falls sich OEMs für die Implementierung eines Systems entscheiden, das immer eine Anforderung durchführt und stets den Rückgabewert berücksichtigt.

  • Die Energieverwaltung implementiert systemweite Aktivitätszeitgeber in ihrem MDD. Diese werden vom OEM definiert und im PDD der Energieverwaltung verwendet.

  • Die Energieverwaltung verwendet und versteht Systemaktivierungsquellen mit Unterstützung des OEM-Kernels.

  • RequestPowerNotifications() setzt nicht mehr voraus, dass sich Anwendungen für alle Benachrichtigungen registrieren, indem der Flags-Parameter auf POWER_NOTIFY_ALL gesetzt wird.

  • Die Energieverwaltung unterstützt die neue PBT_POWERINFOCHANGE-Benachrichtigung, die Informationen über den Akkuladezustand enthält. Mithilfe dieser Benachrichtigung müssen Anwendungen nicht mehr ermitteln, welche GWES-API (falls vorhanden) für das Abrufen von Energieinformationen des Systems verwendet werden soll.

Neben der Energieverwaltung enthält Windows CE .NET v4.1 die folgenden energierelevanten Updates:

  • PCMCIA-Clients (Personal Computer Memory Card International Association), einschließlich NDIS und Dateisystem, können nun anfordern, dass Kartengerätetreiber nur während der Standby-/Wiederherstellungsverarbeitung entladen werden, wenn auch die Karte tatsächlich herausgenommen wird.

  • Die Kernel-E/A-Steuerungen IOCTL_HAL_ENABLE_WAKE, IOCTL_HAL_DISABLE_WAKE, IOCTL_HAL_GET_WAKE_SOURCE und IOCLT_HAL_PRESUSPEND werden in den Beispielplattformen definiert und implementiert. Sie unterstützen die Energieverwaltung und Gerätetreiber, die in den D3-Energiestatus übergehen sollen.

  • Unterstützung für Aktivitätszeitgeber der Energieverwaltung wurde in GWES, das Dateisystem und den Netzwerkstack integriert.

  • Der Kernel unterstützt jetzt den Aufruf von DEBUGMSG() und RETAILMSG() in Energiehandlern.

  • Der Kernel übt nun strenge Beschränkungen bei Systemaufrufen in Energiehandlern aus. Der versuchte Aufruf einer ungültigen API in einem PowerUp()/PowerDown()-Rückruf führt zur Anzeige einer Meldung und zum Anhalten des Systems.

  • Einige Treiber wurden um die Unterstützung für Eingabe-/Ausgabesteuerungen (IOCTLs, Input/Output Controls) der Energieverwaltung erweitert, einschließlich com16550 und ddi_perm3.

  • Die GWES-Standbyverwaltung kann durch Setzen des Registrierungsschlüssels HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\DisableGwesPowerOff auf einen anderen Wert als Null deaktiviert werden.

  • Die Deaktivierung der GWES-Standbyverwaltung führt dazu, dass Versuche, die GWES-Timeoutwerte mit SystemParametersInfo zu setzen, mit dem Wert ERROR_RESOURCE_DISABLED fehlschlagen. Dies betrifft die Parameter SPI_SETBATTERYIDLETIMEOUT, SPI_SETEXTERNALIDLETIMEOUT und SPI_SETWAKEUPIDLETIMEOUT. Die Parameter SPI_GETBATTERYIDLETIMEOUT, SPI_GETEXTERNALIDLETIMEOUT und SPI_GETWAKEUPIDLETIMEOUT haben alle den Wert Null.

In welcher Beziehung stehen die Energieverwaltung und das System der Energierückrufe, das Windows CE bisher immer verwendet hat?
Ziel der Energieverwaltung ist die Ermöglichung einer intelligenten Geräteenergieverwaltung. Innerhalb des Framework der Energieverwaltung definieren OEMs die Energiezustände des Systems, die den maximalen Energiestatus von Geräten ermitteln. Geräte rufen DevicePowerNotify() auf, um ihren eigenen Energiestatus festzustellen, und Anwendungen rufen SetPowerRequirement() auf, um sicherzustellen, dass die benötigten Geräte auf einem Leistungsniveau laufen, das ihren Anforderungen entspricht.

Die Energierückrufe (das heißt xxx_PowerDown()/xxx_PowerUp()) sind von der Energieverwaltung abhängig. Diese Rückrufe treten auf, wenn das System dabei ist, in einen Standbymodus zu wechseln, in dem die CPU angehalten wird. Diese Rückrufe werden unmittelbar vor dem Aufruf von OEMPowerOff() generiert. Gerätetreiber empfangen häufig IOCTLs vor dem Standby des Systems, die diese auffordern, sich abzuschalten. Jedoch ist dies nicht immer der Fall. Das Framework der Energieverwaltung ermöglicht das Abschalten von Geräten, während das System aktiv ist, oder das Nichtausschalten von Geräten, während das System in den Standbymodus versetzt wird.

Die weitere Vorgehensweise bleibt der Entscheidung der Gerätetreiberimplementierer überlassen, wenn diese einen Abschaltenrückruf empfangen, während der Geräteenergiestatus D0, D1 oder D2 ist. Häufig liegt die Lösung darin, das Gerät abzuschalten und es wieder einzuschalten, wenn ein Einschaltenrückruf auftritt. Wenn jedoch das Gerät in der Lage ist, ohne die CPU zu funktionieren, ist es eventuell besser, es eingeschaltet zu lassen.

Wie sieht die allgemeine Funktionsweise der Energieverwaltung aus?
Die Energieverwaltung fungiert als Vermittler zwischen den folgenden Einheiten:

  • Geräten, die eventuell über eine eigene intelligente Energieverwaltung verfügen.

  • Dem OEM, der die Energiezustände des Systems definiert, die den Energieverbrauch von Geräten einschränken.

  • Anwendungen, die Benachrichtigungen über energierelevante Ereignisse empfangen müssen und die die verwendeten Geräte eventuell auf einem minimalen Energieniveau halten möchten.

Die Energieverwaltung implementiert die folgenden Regeln, um eine Zusammenarbeit dieser drei Parteien zu ermöglichen:

  • Systemenergiezustände legen Obergrenzen des Energieverbrauchs für alle Geräte fest.

  • Anwendungen legen Untergrenzen des Energieverbrauchs für bestimmte Geräte fest (um minimale Leistungsniveaus zu erhalten).

  • Die Energieverwaltung ermöglicht Geräten die intelligente Verwaltung der eigenen Energie, so lange sie ihre Energieniveaus zwischen diesen beiden Grenzwerten halten.

  • Falls die Untergrenze die Obergrenze überschreitet, bleibt das Energieniveau des Geräts so lange erhalten, wie die Anwendung das Gerät benötigt.

  • Wenn das System in einen Standbyenergiestatus übergeht, werden die von der Anwendung auferlegten Untergrenzen so lange außer Kraft gesetzt.

Wie interagieren OEM-Hersteller, Entwickler von Gerätetreibern und Anwendungen mit der Energieverwaltung?
OEMs richten benannte Systemenergiezustände in der Registrierung ein. Diese besitzen die folgenden Merkmale:

  • Sie definieren ein maximales Energieniveau für Geräte (Obergrenze).

  • Sie können eine Reihe von Hinweisattributen enthalten, die der Energieverwaltung mitteilen, wie die Übergänge in die Energiezustände durchzuführen sind.

So weist z.B. das POWER_STATE_SUSPEND-Attribut die Energieverwaltung an, dass diese neben der Änderung der Gerätezustände zusätzlich PowerOffSystem() aufrufen muss.

Der OEM passt in der Regel die Energieverwaltung so an, dass diese über spezielle Kenntnisse darüber verfügt, welcher Status je nach Systemumgebung in bestimmten Situationen geeignet ist. Mögliche Zustände sind z.B. "Akkubetrieb", "Niedriger Akkuladezustand", "Netzbetrieb", "In Dockingstation", "Außerhalb Dockingstation" usw.

Geräte mit Energieverwaltung besitzen die folgenden Merkmale:

  • Sie müssen eine Energieverwaltungsschnittstelle ankündigen, die die Energieverwaltung versteht, in der Regel die Standard-GUID, {A32942B7-920C-486b-B0E6-92A702A99B35}. Dies lässt sich mithilfe von AdvertiseInterface() oder durch Hinzufügen ihrer GUID zum IClass REG_MULTI_SZ-Wert in ihrem Konfigurationsregistrierungsschlüssel realisieren.

  • Sobald das Gerät verfügbar wird, sendet ihm die Energieverwaltung eine IOCTL_POWER_CAPABILITIES-Anforderung, auf die es antworten muss.

  • Die Energieverwaltung aktualisiert den Energiestatus des Geräts mithilfe von IOCTL_POWER_SET-Aufrufen.

  • Falls ein Gerätetreiber eine intelligente Energieverwaltung seines Geräts wünscht, kann er Energieaktualisierungen mithilfe der DevicePowerNotify()-API anfordern. Diese können eventuell dazu führen, dass die Energieverwaltung einen IOCTL_POWER_SET zu einem bestimmten Zeitpunkt in der Zukunft ausgibt.

Anwendungen können mit der Energieverwaltung auf folgende Art und Weise interagieren:

  • Sie können Benachrichtigungen über energierelevante Ereignisse mithilfe von RequestPowerNotifications() anfordern. Wenn diese keine Benachrichtigungen mehr benötigen, können sie StopPowerNotifications() aufrufen.

  • Sie können anfordern, von ihnen verwendete Geräte auf einem minimalen Energieniveau mithilfe von SetPowerRequirement() zu halten. Sien sollte diese Anforderung so kurz wie möglich aufrecht erhalten, und diese anschließend mithilfe von ReleasePowerRequirement() wieder freigeben.

Diese Informationen sind in Platform Builder und auf der MSDN-Site ausführlicher dokumentiert.

Zwischen welchen Energiezuständen des Systems unterscheidet die Beispielimplementierung der Energieverwaltung von Microsoft?
Sie definiert vier Zustände: "On", "UserIdle", "SystemIdle" und "Suspend". Wenn Benutzer aktiv mit dem System arbeiten, geht es in den Status "On" über. Wenn Benutzer nicht mehr mit dem System arbeiten, nimmt es den Status "UserIdle" an. Hält die Benutzerinaktivität an, wird der Status "SystemIdle" aktiviert. So lange Gerätetreiber noch aktiv sind, verbleibt das System in diesem Status, aber wenn Gerätetreiber ebenfalls keine Aktivität mehr zeigen, geht das System in den Status "Suspend" über.

Der Status "UserIdle" ist für Situationen gedacht, in denen Benutzer das Gerät zwar verwenden (das heißt das Display ansehen), aber nicht damit aktiv interagieren. Im Status "SystemIdle" verwenden Benutzer das Gerät zwar nicht mehr direkt, jedoch sind darauf noch Systemprozesse aktiv. So betrachten Benutzer während Dateiübertragungen das Gerät eventuell schon als im Leerlauf, obwohl noch Systemprozesse arbeiten.

Die Beispielimplementierung der Energieverwaltung unterscheidet über Benutzer- und Systemaktivität auf der Basis von zwei Aktivitätszeitgebern: "UserActivity" und "SystemActivity". Die Timeouts für den Übergang zwischen diesen Energiezuständen des Systems sind unterschiedlich, je nachdem, ob sich das System im Netzbetrieb oder im Akkubetrieb befindet.

Die mit Windows CE ausgelieferten Beispielplattformen befinden sich alle im Netzbetrieb. OEMs können sich für die Implementierung anderer Energiezustände entscheiden, die genutzt werden, wenn sich das System im Akkubetrieb, in einer Dockingstation oder im Bereich eines Breitbandfunknetzwerks usw. befindet. Durch das Kopieren des Beispiel-PDD der Energieverwaltung in das Plattformverzeichnis und seine entsprechende Modifizierung können diese Arten von Anpassungen implementiert werden.

Ich möchte, dass die Energieverwaltung mein System nach einer gewissen Inaktivität in den Standbymodus versetzt. Wie kann ich das einrichten?
Die Beispielimplementierung der Energieverwaltung unterstützt eine Reihe von Timeouts, die mit Energiestatusübergängen des Systems verbunden sind und verknüpft diese mit Aktivitätszeitgebern. Um diesen Code zu aktivieren, müssen Sie die Aktivitätszeitgeber deklarieren und die Timeouts in die Registrierung übertragen. Ein Beispiel dafür finden Sie unter public\common\oak\files\common.reg.

Ich habe erwartet, dass der Gerätemanager mein System nach einer gewissen Zeit der Inaktivität in den Standbymodus versetzt, aber es geschieht nichts. Woran kann das liegen?
Timeouts für Energiestatusübergänge des Systems sind in der Datei common.reg definiert, falls Sie die Energieverwaltungskomponente eingebunden haben. Stellen Sie sicher, dass diese Registrierungswerte in Ihrem System eingerichtet sind.

Falls die Registrierungseinstellungen akzeptabel aussehen, sehen Sie in den Debugzonen nach, um weitere Informationen zu erhalten. Die Zonen "Timers" und "Platform" sind ein guter Ausgangspunkt. Es ist möglich, dass eine Komponente in Ihrem System die Inaktivitätszeitgeber zurücksetzt und den Standbybetrieb des Systems verhindert.

Falls die Energieverwaltung Timeouts auf meinem System verwaltet, welche Funktion hat dann die "SystemIdleTimerResetFunction()"?
Sie informiert hauptsächlich das GWES, die Anzeige des Bildschirmschoners zu beenden. OEMs, die mit Aktivitätszeitgebern arbeiten, setzen häufig den Registrierungswert NoIdleTimerReset, um den Bildschirmschoner zu aktivieren, selbst wenn keine verbundenen Sockets vorhanden sind.

Wie kann ich verhindern, dass das GWES das System in den Standbymodus versetzt (ich möchte stattdessen die Energieverwaltung verwenden)?
Legen Sie unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\DisableGwesPowerOff einen Wert für REG_DWORD fest, der nicht Null ist. Wenn dieser Wert auf Null gesetzt ist, bleibt die GWES-Standbyverwaltung aktiviert. Diese Registrierungsvariable wird einmal gelesen, wenn das GWES beim Neustart geladen wird.

Ich möchte nicht, dass die Energieverwaltung entscheidet, wann mein System in den Standbymodus versetzt wird. Welche Einstellungen sind erforderlich, damit das GWES weiterhin diese Entscheidung trifft?
Als OEM können Sie die Energieverwaltung immer an Ihre Bedürfnisse anpassen. Die einfachste Methode für eine passive Ausführung der Energieverwaltung ist das Entfernen der Netz-/Akkutimeouts aus der Registrierung. Dadurch wird die Energieverwaltung angewiesen, dem GWES (oder einem anderen Programm) die Änderung der Energiezustände des Systems zu überlassen.

Ein Beispiel dafür, wie die Energieverwaltung ermittelt, ob sie im aktiven oder passiven Modus ausgeführt wird, finden Sie in der Implementierung von PlatformPMActivelyManagesPower() im Verzeichnis public\common\oak\drivers\pm\platform\platform.cpp. Stellen Sie weiterhin sicher, dass der Registrierungswert DisableGwesPowerOff auf Null gesetzt ist, damit das GWES die Verwaltung von Standbys übernimmt.

Diese ganze Sache mit der Energieverwaltung ist großartig, aber ich möchte mich nicht in meinem Gerätetreiber darum kümmern. Muss ich irgendetwas ändern?
Nein. Ihr Gerät empfängt weiterhin PowerUp()/PowerDown()-Rückrufe wie in früheren Versionen von Windows CE.

Wie verwende ich die "SetDevicePower()"-API in meiner Anwendung?
Anwendungen sollten diese API nicht verwenden. Die SetDevicePower()-API setzt die Energieverwaltung außer Kraft, und das Gerät verwaltet die Energiezustände des Geräts. Diese API sollte nur vom Code des OEM-Herstellers verwendet werden, z.B. als Teil der Systemsteuerung.

Wie verwende ich die "SetSystemPowerState()"-API in meiner Anwendung?
Falls die Energieverwaltung aktiv die Systemenergie verwaltet, sollten Anwendungen diese API nicht verwenden, außer um das System in den Standbymodus zu versetzen. Rufen Sie dazu SetSystemPowerState(NULL, POWER_STATE_SUSPEND, 0) auf. Diese API soll es dem OEM-Hersteller ermöglichen, Code für den Energiestatusübergang des Systems außerhalb der Energieverwaltung zu implementieren. Die Standardimplementierung der Energieverwaltung gestattet es Anwendungen nicht, beliebige Energiestatusübergänge des Systems zu initiieren.

Meine Aufrufe von "SetSystemPowerState()" schlagen mit der Meldung "ERROR_ACCESS_DENIED" fehl. Was bedeutet das?
Die Beispielimplementierung der Energieverwaltung betreibt einen einfachen Statusmechanismus, um zu ermitteln, welcher Energiestatus des Systems zu einem bestimmten Zeitpunkt geeignet ist. Falls die Energieverwaltung aktiv ist, macht es keinen Sinn, dass Anwendungen in der Lage sind, "in den Leerlaufstatus überzugehen", wenn Benutzer aktiv das System verwenden. Die Energieverwaltung verweigert solche unpassenden Anforderungen mit der Meldung ERROR_ACCESS_DENIED.

Die Energieverwaltung gestattet Anwendungen, das System in den Standbymodus zu versetzen und den Energiestatus des Systems auf den aktuellen Wert zu setzen, wodurch die Energiestatuskonfiguration aus der Registrierung geladen wird. Weitere Informationen finden Sie in der Implementierung von PlatformSetSystemPowerState() im Verzeichnis public\common\oak\drivers\pm\platform\platform.cpp.

Welche Geräteklassen-GUIDs werden derzeit von der Energieverwaltung definiert?
Die Standardimplementierung der Energieverwaltung kann die folgenden GUIDs interpretieren:

  • {A32942B7-920C-486b-B0E6-92A702A99B35} - Generische Geräte mit Energieverwaltung

  • {8DD679CE-8AB4-43c8-A14A-EA4963FAA715} - Blockgeräte mit Energieverwaltung

  • {98C5250D-C29A-4985-AE5F-AFE5367E5006} - NDIS-Miniports mit Energieverwaltung

Anwendungen können eine Liste der Klassen mit Energieverwaltung durch Enumeration von HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\Interfaces abrufen.

Sobald Anwendungen eine Energieverwaltungs-API aufrufen, die sich auf ein bestimmtes Gerät bezieht, sollte der Name des Geräts mit seiner Klasse angegeben werden. Wird der Gerätename nicht mit der Klasse angegeben, geht die Energieverwaltung davon aus, dass das Gerät zur generischen Geräteklasse mit Energieverwaltung gehört.

Gerätenamen mit Klassenangaben besitzen die Klassen-GUID in Form einer Zeichenfolge als Präfix, gefolgt von einem umgekehrten Schrägstrich (\). So verweist beispielsweise {8DD679CE-8AB4-43c8-A14A-EA4963FAA715}\DSK1: auf das Blockgerät mit Energieverwaltung DSK1:.

Wie rufen Geräte Energieverwaltungs-IOCTLs ab?
Geräte müssen sich bei der Energieverwaltung registrieren, indem sie eine bekannte Schnittstelle ankündigen. In diesem Kontext hat "Schnittstelle" nichts mit der COM zu tun. Es bedeutet einfach, dass das registrierende Gerät die IOCTLs der Energieverwaltung interpretiert. Der Zugriff auf die meisten Geräte erfolgt über Handles, die von CreateFile() zurückgegeben werden, aber die Klassen-GUID kann die Energieverwaltung auch anweisen, einen anderen Mechanismus zur Übertragung von IOCTLs an das Gerät zu verwenden.

Die Ankündigung einer Schnittstelle kann implizit erfolgen, indem die GUID in den IClass REG_MULTI_SZ-Wert des Treibers beim Laden von ActivateDeviceEx() einbezogen wird, oder explizit durch Aufrufen von AdvertiseInterface(). Der empfohlene Ansatz ist die Verwendung der Registrierung, selbst wenn Sie wissen, dass Sie die Energieverwaltung verwenden. Selbst wenn Sie AdvertiseInterface() direkt aufrufen, sollten Sie die anzukündigende GUID aus der Registrierung lesen.

Die Standard-GUID für Geräte mit Energieverwaltung lautet {A32942B7-920C-486b-B0E6-92A702A99B35} und ist in der Datei pm.h definiert. OEMs haben die Möglichkeit, die Energieverwaltung für die Verarbeitung anderer GUIDs anzupassen. Dies ist eventuell gewünscht, um eine spezielle Verarbeitung für alle Geräte eines bestimmten Typs (oder für ein bestimmtes Gerät) zu implementieren. Aus diesem Grund ist es besser, die Energieverwaltung eines Geräts über die Registrierung zu deklarieren.

Nachdem die Energieverwaltung das Gerät erkannt hat, beginnt sie, Energieverwaltungs-IOCTLs an dieses zu senden, angefangen mit IOCTL_POWER_CAPABILITIES.

NDIS-Miniports werden vom NDIS-Streamtreiber geladen und besitzen keine eigene "IClass". Wie können diese von der Energieverwaltung erkannt werden?
NDIS meldet nur dann Miniports an die Energieverwaltung, wenn diese NDIS-Energieverwaltung unterstützen (das heißt OID_PNP_CAPABILITIES). Aus diesem Grund unterstützen nicht alle Miniports die Energieverwaltung.

Dies gilt z.B. für den NE2000 Ethernet-Miniport, weil dieser OID_PNP_CAPABILITIES nicht unterstützt.

Ich versuche, Energieanforderungen für einen NDIS-Miniport oder ein Laufwerk festzulegen, aber es scheint keinen Effekt zu haben. Woran könnte das liegen?
Laufwerke und Miniports verwenden nicht die Klassen der generischen Geräte mit Energieverwaltung, wenn sie sich bei der Energieverwaltung registrieren. Wenn z.B. der Name des Geräts "CISCO1" lautet und Sie SetPowerRequirement(_T("CISCO1"), D0, 0) aufrufen, hat dies nur eine Auswirkung auf ein Gerät mit diesem Namen, das über die Standardklasse registriert wurde. Am sichersten ist es, den Gerätenamen immer mit der GUID anzugeben, die das Gerät verwenden würde, um seine Energieverwaltungsschnittstelle anzukündigen. Im Falle eines Miniports würde der Name {98C5250D-C29A-4985-AE5F-AFE5367E5006}\CISCO1 lauten. Bei Verwaltung eines Laufwerks könnten Sie {8DD679CE-8AB4-43c8-A14A-EA4963FAA715}\DSK1: verwenden.

Wie verarbeitet NDIS Anforderungen der Energieverwaltung?
NDIS ordnet Geräteenergiezustände der Energieverwaltung den NDIS-Geräteenergiezuständen wie folgt zu:

Status der Energieverwaltung

NDIS-Status

D0

NdisDeviceStateD0

D1

NdisDeviceStateD0

D2

NdisDeviceStateD0

D3

Siehe unten.

D4

NdisDeviceStateD3

Im Fall von D3 gilt: Falls ein Adapter Aktivierungsquellen unterstützt, ordnet NDIS den Geräteenergiestatus D3 der Energieverwaltung dem Status mit dem höchsten Energieverbrauch zu, der vom Miniporttreiber als Antwort auf eine OID_PNP_CAPABILITIES-Anfrage gemeldet wird. Angenommen, der Miniport meldet folgende Zustände:

MinLinkChangeWakeUp

NdisDeviceStateD2

MinMagicPacketWakeUp

NdisDeviceStateD1

D2

NdisDeviceStateD0

MinPatternWakeUp

NdisDeviceStateD2

Für diesen Miniport übersetzt NDIS den Status D3 der Energieverwaltung in NdisDeviceStateD1.

Beachten Sie, dass common.reg den Standardstandbystatus für Miniports als D4 definiert.

Wie verwende ich die Energieverwaltung zur Aktivierung von Wake-on-LAN für meinen Netzwerkadapter?
Einige Miniports unterstützen Wake-on-LAN. Diese Funktion wird aktiviert, indem für den Miniport der Status D3 der Energieverwaltung festgelegt wird. NDIS übersetzt intern Geräteenergiezustände der Energieverwaltung in NDIS-Geräteenergiezustände, wie oben gezeigt. Die spezifische Wake-on-LAN-Funktion muss eventuell mit einer gerätespezifischen Methode, wie etwa einer Systemsteuerungsoption, konfiguriert werden. So setzt beispielsweise die Aktivierung bei Mustervergleich eventuell voraus, dass ein bestimmtes Muster in den Adapter programmiert wird. Wenn analog dazu der Adapter mehrere Typen von Wake-on-LAN unterstützt (das heißt Magic Packet und Verknüpfungsstatusänderung), muss der vom Adapter ausgewählte Typ außerhalb der Energieverwaltungsschnittstelle programmiert werden. Es gibt mehrere Möglichkeiten, den Adapter im Standbymodus in den Status D3 zu versetzen:

  • Definieren oder Aktualisieren von Standbyenergiezuständen, um es dem Miniport zu ermöglichen, im Standbymodus den Status D3 zu erhalten.

Beispiel:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\State\Suspend("{98C5250D-C29A-4985-AE5F-AFE5367E5006}]
"Default"=dword:4 ; D4 
"CISCO1"=dword:3 ; D3
  • Anwendungen können SetPowerRequirement() mit dem POWER_FORCE-Attribut aufrufen, um das Gerät im Standbymodus eingeschaltet zu lassen.

Beispiel:

h = SetPowerRequirement(_T("{98C5250D-C29A-4985-AE5F-AFE5367E5006}\CISCO1}"), D3, POWER_NAME | POWER_FORCE, NULL, 0);
ReleasePowerRequirement(h);

Da diese Ansätze dazu führen können, dass das Gerät im Standbymodus zusätzliche Energie verbraucht, sollten sie mit Vorsicht verwendet werden.

Ich möchte meinen PCMCIA-NDIS-Adapter im Standbymodus eingeschaltet lassen und den Funktionsinterrupt der Karte als Aktivierungsquelle nutzen. Wie kann ich dies ermöglichen?
Beachten Sie zunächst, dass dies nicht das Gleiche ist wie Wake-on-LAN, da vom Adapter eine normale Funktionsweise erwartet wird, obwohl das System im Standbymodus ist. Aus diesem Grund verbraucht eine PC-Karte mehr Energie, als wenn Wake-on-LAN aktiviert wäre. Der NDIS-Energiestatus D0 (repräsentiert durch den NdisDeviceStateD0-Enumerationswert) ist der einzige NDIS-Energiestatus, in dem der Adapter normal funktioniert und beliebigen Datenverkehr empfängt. Wenn es erforderlich ist, die Karte des Miniports im Standbymodus eingeschaltet zu lassen, gibt es dafür mehrere Möglichkeiten:

  • Definieren oder Aktualisieren von Standbyenergiezuständen, um es dem Miniport zu ermöglichen, im Standbymodus den Status D0 zu erhalten.

Beispiel:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\State\Suspend("{98C5250D-C29A-4985-AE5F-AFE5367E5006}]
"Default"=dword:4 ; D4
"CISCO1"=dword:0 ; D0
  • Anwendungen können SetPowerRequirement() mit dem POWER_FORCE-Attribut aufrufen, um das Gerät im Standbymodus eingeschaltet zu lassen.

Beispiel:

h = SetPowerRequirement(_T("{98C5250D-C29A-4985-AE5F- AFE5367E5006}\CISCO1}"), D0, POWER_NAME | POWER_FORCE, NULL, 0);.
ReleasePowerRequirement(h);

Eine OEM-Anwendung kann mithilfe von SetDevicePower() erzwingen, dass ein Adapter selbst im Standbymodus den Status D0 behält.
Anmerkung:
Da alle diese Ansätze dazu führen können, dass das Gerät immer eingeschaltet bleibt, sollten sie mit Vorsicht verwendet werden.
Beispiel:

SetDevicePower(_T("{98C5250D-C29A-4985-AE5F-AFE5367E5006}\CISCO1}"), POWER_NAME, D0);
SetDevicePower(_T("{98C5250D-C29A-4985-AE5F-AFE5367E5006}\CISCO1}"), POWER_NAME, PwrDeviceUnspecified);

Gibt es eine Möglichkeit, um zu verhindern, dass Windows CE den Miniporttreiber für meine PCMCIA-Netzwerkkarte lädt und wieder entfernt?
Ja. Der Registrierungseintrag ResetOnResume weist NDIS an, den NDIS-PCMCIA-Miniporttreiber bei der Wiederherstellung nicht zu entfernen. NDIS ermöglicht dies durch Setzen von CFG_ATTR_NO_SUSPEND_UNLOAD im CardRequestConfiguration()-Aufruf von PCMCIA-Kartendiensten.

Während der Wiederherstellung wird der ResetHandler des Miniports aufgerufen, um ihn wieder in einen bekannten Status zu versetzen.

Beispiel:

[HKEY_LOCAL_MACHINE\Comm\Cisco1\Parms]
"ResetOnResume"=dword:1

Dieser Registrierungseintrag ist nicht neu, er gilt einfach nun auch für PCMCIA-Adapter. Der Standardwert von ResetOnResume für PCMCIA-Netzwerkadapter ist FALSE. Weitere Informationen zu CFG_ATTR_NO_SUSPEND_UNLOAD (neu in Windows CE .NET v4.1) finden Sie in der PCMCIA-Dokumentation. Beachten Sie, dass Geräte nicht OID_PNP_CAPABILITIES unterstützen müssen, damit dieser Mechanismus funktioniert. Darüber hinaus benötigt der PCMCIA-Gerätetreiber Unterstützung von der OAL, um dieses Konfigurationsattribut zu aktivieren.

Ich habe einen Gerätetreiber, der einen anderen Gerätetreiber verwendet. Wie erstelle ich eine Hierarchie von Energieanforderungen?
Ein Beispiel dafür ist ein IrDa-Treiber (Infrared Data Association), der von einem COM-Anschlusstreiber abhängig ist. Leider gibt es dafür weder in Windows CE .NET noch in Windows CE .NET v4.1 einen Mechanismus, da die Abhängigkeit eines Gerätetreibers von einem anderen nicht innerhalb des Betriebssystems übertragen wird. Weiterhin haben Gerätetreiber keinerlei Kenntnisse über Anforderungen, die ihnen von Anwendungen auferlegt wurden - nur die Energieverwaltung kennt diese Anforderungen.

Eine Möglichkeit wäre es, die Energieverwaltung so anzupassen, dass ein optionaler DependsOn-Registrierungsschlüssel unterstützt wird, der mit jedem einzelnen Gerät verknüpft ist. Angenommen, die IrDA-Schnittstelle ist COM5: und diese ist abhängig von der seriellen Schnittstelle COM2:. Wenn eine Anwendung SetPowerRequirement() für COM5: aufruft, kann die Energieverwaltung in der Registrierung nachschlagen und eine passende Anforderung für COM2: auferlegen.

Alternativ besteht die Möglichkeit, dass der COM2:-Treiber seine Schnittstelle nicht direkt bei der Energieverwaltung ankündigt. Wenn der IrDA-Treiber auf COM5: startet, könnte er mit IOCTL_POWER_CAPABILITIES ermitteln, dass COM2: die Energieverwaltung unterstützt und IOCTL_POWER_SET-Aufrufe auf COM2: und sich selbst anwenden.

Ich verfüge über eine Anwendung, die in der Lage sein muss, Standbyanforderungen abzufangen und diese so lange zu verhindern, bis wichtige Verarbeitungsvorgänge abgeschlossen sind. Wie kann ich dies ermöglichen?

Die Energieverwaltung bietet dafür keinen Mechanismus. Begründung: Wenn ein System in den Standbymodus übergehen muss, sollte es daran nicht gehindert werden. Benutzer können nicht funktionierende Standbyschaltflächen ziemlich frustrierend finden. Falls ein OEM-Hersteller Aktivitätszeitgeber korrekt einrichtet, verhindern Netzwerkaktivität oder Festplattenaktivität, dass das System automatisch in den Standbymodus übergeht.

Hat ein OEM-Hersteller sorgfältig alle Optionen abgewägt und ist trotzdem zu dem Schluss gekommen, dass Standbys unbedingt verhindert werden müssen, kann die Energieverwaltung angepasst werden, um diese Funktion zu unterstützen. Ein möglicher Ansatz wäre es, dass die Energieverwaltung eine installierbare Gerätetreiberschnittstelle mit benutzerdefinierten IOCTLs für diesen Zweck anzeigt.

Beim Übergang in den Modus Standby/Wiederherstellen wird die Meldung "!Unrecoverable Error: Exception or calling API inside Power Handler" (Nicht behebbarer Fehler: Ausnahme oder API-Aufruf in Energiehandler) sowie eine Adresse angezeigt. Was bedeutet das?
Diese Meldung tritt auf, wenn ein Treiber eine Ausnahme in seinem PowerUp()/PowerDown()-Rückruf verursacht. Bei dieser Ausnahme könnte es sich um einen API-Aufruf handeln, da diese Aufrufe mithilfe von Ausnahmen in den Kernelmodus übergehen. Weitere Ursachen könnten eine Division durch Null, die Dereferenzierung eines ungültigen Zeigers oder der Versuch sein, an einem Haltepunkt anzuhalten.

In Windows CE wurde immer schon dokumentiert, dass Energierückrufe in einem speziellen Kontext auftreten, in dem nur wenige APIs unterstützt werden. Leider hat der Aufruf nicht unterstützter APIs nicht immer zu offensichtlichen Problemen geführt, weshalb einige OEM-Hersteller versehentlich Treiber veröffentlicht haben, die das System destabilisieren können. Sie wirken deshalb destabilisierend, weil API-Aufrufe in einen speziellen Stack wechseln, der bei Energierückrufen eventuell bereits in Verwendung ist.

Ab Windows CE .NET v4.1 werden APIs vom Betriebssystem Einschränkungen auferlegt.

Die zusammen mit dieser Meldung angezeigte Adresse identifiziert den Treiber, der den ungültigen API-Aufruf durchführt. Um zu entschlüsseln, welcher Treiber das Problem verursacht, vergleichen Sie die Adresse mit der "Image Load Address" im Fenster modules/symbols des Debuggers. Diese zeigt an, wo alle DLLs geladen werden.

Nachdem Sie wissen, wo die Ausnahme auftritt, gelangen Sie zur exakten Codezeile, indem Sie die folgenden Schritte ausführen.

  • Starten Sie das System neu.

  • Springen Sie in den Debugger.

  • Öffnen Sie das Überwachungsfenster, und geben Sie die Adresse (mit dem Präfix 0x) in das Adressfeld ein.

  • Öffnen Sie das Disassemblyfenster.

  • Ziehen Sie die Adresse aus dem Überwachungsfenster in das Disassemblyfenster. Die IDE sollte den disassemblierten Quellcode an der Fehlerstelle anzeigen.

Ich erhalte "DEBUGCHK()"-Aufrufe in "PmResumeSystem". Woran liegt das?
Es gibt zwei häufige Gründe dafür:

  • Eine Komponente im System initiiert eine Standbyoperation außerhalb der Energieverwaltung, indem z.B. PowerOffSystem() direkt aufgerufen wird. Die von Microsoft gelieferte Energieverwaltung unterstützt diesen Vorgang nicht. Einige OEM-Hersteller entscheiden sich eventuell dafür, ihrer Plattform Unterstützung für diesen Vorgang hinzuzufügen. In diesem Fall sollten sie den DEBUGCHK()-Aufruf aus dem Quellcode entfernen.

  • Im Standbymodus ruft die Energieverwaltung FileSystemPowerFunction(FSNOTIFY_POWER_OFF) im Kontext des Threads auf, der wiederum SetSystemPowerState() aufruft. Dadurch werden Puffer entleert und anschließend der dateisystemkritische Abschnitt übernommen und gehalten. Wenn ein Thread mit einer höheren Priorität versucht, auf das Dateisystem zuzugreifen, wird dieser so lange blockiert, bis FileSystemPowerFunction(FSNOTIFY_POWER_ON) aufgerufen wird. Außerdem wird die Priorität des Threads erhöht, der SetSystemPowerState() aufruft. Falls diese Prioritätsumkehrung die Priorität des Threads über die des Wiederherstellungsthreads der Energieverwaltung erhöht, ruft der Wiederherstellungsthread DEBUGCHK() auf. Die Lösung dafür besteht darin, die Priorität des Wiederherstellungsthreads anzupassen, indem der ResumePriority256-Wert der Energieverwaltung in der Registrierung so gesetzt wird, dass der Wiederherstellungswert immer mit einer höheren Priorität ausgeführt wird.

Ich sehe keine "IOCTL_POWER_QUERY"-Anforderungen in meinem Treiber. Woran liegt das?
In der Standardimplementierung der Energieverwaltung wird IOCTL_POWER_QUERY überhaupt nicht verwendet. In der Windows CE .NET-Version der Energieeverwaltung wurde diese IOCTL nur manchmal aufgerufen und der Rückgabewert nur bei einigen Aufrufen berücksichtigt. Dies bedeutete, dass sich die Treiber auf die IOCTL zwar nicht verlassen konnten, diese aber trotzdem implementieren mussten. Aus diesem Grund wird sie in der Windows CE .NET v4.1-Version der Energieverwaltung nicht verwendet.

Einige OEM-Hersteller möchten die Energieverwaltung eventuell so anpassen, dass diese IOCTL immer aufgerufen und ihr Rückgabewert immer berücksichtigt wird, weshalb sich der Code für die Unterstützung von IOCTL_POWER_QUERY nach wie vor im MDD (Model Device Driver) befindet. Sie wird jedoch bedingt herauskompiliert. Um sie wieder in die Kompilierung aufzunehmen, setzen Sie PM_SUPPORTS_DEVICE_QUERIES, und aktualisieren Sie die Plattform für die Durchführung der entsprechenden MDD-Aufrufe.

Ich sehe keine "IOCTL_POWER_GET"-Anforderungen in meinem Treiber. Woran liegt das?
Die Energieverwaltung ist so konzipiert, dass sie den Energiestatus aller Geräte kennt, die Energieeverwaltung unterstützen. Sie sendet allgemein keinen IOCTL_POWER_GET an das Gerät, es sei denn, eine Anwendung ruft GetDevicePower() mit dem POWER_FORCE-Attribut auf.

Muss ich etwas Besonderes beachten, wenn ich die persistente Registrierung von Windows CE (Boot Hive) verwende?
Die Energieverwaltung liest die verwaltete GUID und Aktivitätszeitgeberlisten während Bootphase 0. Die Registrierungseinstellungen sollten Teil des Boot Hive sein. OEM-Hersteller können auch ein Standardset mit Energiestatuskonfigurationen zur Verfügung stellen. Diese können zwar mit Daten aus der persistenten Registrierung aktualisiert werden, aber die Standardeinstellungen stehen immer während der Bootphase 0 zur Verfügung.

Wie funktionieren Aktivierungsquellen in Windows CE .NET v4.1?
Die folgenden KernelIoControl()-Codes betreffen Aktivierungsquellen: IOCTL_HAL_ENABLE_WAKE, IOCTL_HAL_DISABLE_WAKE, IOCTL_HAL_GET_WAKE_SOURCE und IOCTL_HAL_PRESUSPEND. Die ersten drei akzeptieren eine Aktivierungsquellen-ID als Eingabe- und Ausgabeparameter. Bei diesen IDs handelt es sich um DWORD-Werte, die sich auf Systemaktivierungsquellen beziehen. IOCTL_HAL_PRESUSPEND akzeptiert keine Parameter.

Wenn ein typischer Geräteinterrupt als Aktivierungsquelle fungieren kann, kann der entsprechende SysIntr-Wert als Aktivierungsquellen-ID dienen. SysIntr-Werte sind niemals größer als SYSINTR_MAXIMUM, aber Werte bis (SYSWAKE_BASE-1) sind für diese Gruppe reserviert.

Microsoft definiert einige Aktivierungsquellen-IDs in nkintr.h. Diese enthalten Werte wie SYSWAKE_RING_INDICATE, der angibt, dass Ring Indicate auf einem COM-Anschluss bestätigt wurde. Microsoft reserviert Werte zwischen SYSWAKE_BASE und (SYSWAKE_OEMBASE-1) für generische Aktivierungsquellen.

OEM-Hersteller können Aktivierungsquellen definieren, die für ihre Plattform spezifisch sind. Die Kennungen starten bei SYSWAKE_OEMBASE. Stellen Sie sich einen OEM-Hersteller vor, der zwischen Ring Indicate auf COM1 und COM2 unterscheiden möchte. Dabei könnte SYSWAKE_COM1_RING_INDICATE und SYSWAKE_COM2_RING_INDICATE als (SYSWAKE_OEMBASE + 0) bzw. (SYSWAKE_OEMBASE + 1) definiert werden.

Die E/A-Steuerungsaufrufe IOCTL_HAL_ENABLE_WAKE und IOCTL_HAL_DISABLE_WAKE aktivieren bzw. deaktivieren eine Aktivierungsquelle. Ein Gerät gibt in der Regel diese E/A-Steuerungsaufrufe aus, wenn es eine Anforderung von der Energieverwaltung erhält, den Status D3 zu aktivieren bzw. zu deaktivieren (vorausgesetzt wird die D3-Unterstützung). Diese Aufrufe weisen den Kernel an, die Energieverwaltungseinheit für die Aktivierung von Aktivierungsquellen mit der entsprechenden ID zu programmieren. Der Kernel muss bei der Verarbeitung überlappender IDs intelligent vorgehen. Beispiel: Falls SYSWAKE_RING_INDICATE aktiviert, aber SYSWAKE_COM1_RING_INDICATE explizit deaktiviert ist, sollte der Kernel Rufanzeigenaktivierungen auf allen COM-Anschlüssen bis auf COM1 aktivieren.

Die E/A-Steuerung IOCTL_HAL_GET_WAKE_SOURCE gibt die ID der Aktivierungsquelle zurück, die das System aus seinem letzten Standby aktiviert hat. Falls die Aktivierungsquelle unbekannt ist oder das System niemals in den Standbymodus versetzt wurde, gibt sie SYSWAKE_UNKNOWN zurück. Der Kernel sollte die Aktivierungsquelle der geeignetsten ID zuordnen, die zum Zeitpunkt des Standby aktiviert war. Angenommen, der Kernel unterstützt sowohl die plattformspezifische ID SYSWAKE_COM1_RING_INDICATE als auch die von Microsoft definierte, generische ID SYSWAKE_RING_INDICATE, aber nur SYSWAKE_COM1_RING_INDICATE ist im Standby des Systems aktiviert. In diesem Fall gibt die E/A-Steuerung SYSWAKE_COM1_RING_INDICATE zurück. Falls nur SYSWAKE_RING_INDICATE aktiv ist, wird diese ID zurückgegeben. Falls beide IDs aktiv sind, aber COM1 das System aktiviert, gibt der Kernel SYSWAKE_COM1_RING_INDICATE zurück. Falls COM2 oder ein anderer Anschluss das System aktiviert, wird SYSWAKE_RING_INDICATE zurückgegeben.

Der IOCTL_HAL_GET_WAKE_SOURCE-Rückgabewert ist zwischen Systemstandbys konstant.

Die Energieverwaltung ruft IOCTL_HAL_PRESUSPEND vor PowerOffSystem() auf, um dem Kernel die Möglichkeit zu geben, alle ausstehenden Aktivierungsquellen vor dem Übergang in den Standbymodus zu löschen. Dadurch wird eine Wettkampfbedingung beseitigt, in der ein Aktivierungsquelleninterrupt zwischen dem Aufruf von PowerOffSystem() und dem Aufruf von OEMPowerOff() auftritt. Ohne eine spezielle Logik kann der Kernel nur schwer unterscheiden, welche Interrupts in diesem Intervall aufgetreten sind, weshalb er eventuell in den Standbymodus übergeht, während der Aktivierungsquelleninterrupt noch aussteht.

Informationen über Aktivierungsquellen können durch Bearbeiten ihres Quellcodes explizit in die Energieverwaltung programmiert werden. Die Energieverwaltung kann auch Aktivierungsquellen mit Aktivierungszeitgebern verknüpfen. In diesem Fall werden Aktivierungsereignisse als Geräteaktivität behandelt, um zu ermitteln, in welchen Energiestatus nach der Wiederherstellung aus dem Standbybetrieb übergegangen werden soll.

Ich kann den Standbymodus meines Systems nicht aktivieren. Wenn ich auf die Standbyschaltfläche klicke, wird OEMPowerOff() zwar aufgerufen, aber ich springe gleich wieder heraus.
Die OAL auf Ihrer Plattform nimmt eventuell an, dass eine Unterbrechungsanforderung (IRQ), die als Aktivierungsquelle fungieren soll, ausgelöst wurde. Die Beispiel-BSPs verwalten eine Reihe von Interrupts, die aufgetreten sind. Während der Ausführung von OEMPowerOff() überprüft die OAL, ob aktivierungsfähige Interrupts seit dem letzten Aufruf von PowerOffSystem() aufgetreten sind. Wenn ein solcher Interrupt aufgetreten ist, wird er einfach zurückgegeben.

Ihre OAL sollte dies durch Implementieren von IOCTL_HAL_PRESUSPEND und Löschen der Interruptliste bei diesem Aufruf verhindern.

Wie funktionieren Aktivitätszeitgeber?
Beim Starten liest die Energieverwaltung die Registrierung, um eine Liste der Bezeichnungen von Aktivitätszeitgebern zu erhalten. Für jeden Zeitgeber wird nach einem Timeout (in Sekunden) sowie einer optionalen Liste von Aktivierungsquellen gesucht. Anschließend werden drei benannte Ereignisse erstellt:

  • Ein Zeitgeber-Zurücksetzenereignis (hierbei handelt es sich um ein automatisches Zurücksetzenereignis).

  • Ein "aktives" manuelles Zurücksetzenereignis

  • Ein "inaktives" manuelles Zurücksetzenereignis

Falls das mit dem Zeitgeber verknüpfte Timeout ohne Signalisierung des Zurücksetzenereignis überschritten wird, setzt die Energieverwaltung das "aktive" Ereignis zurück und setzt das "inaktive Ereignis". Falls das Zurücksetzenereignis signalisiert wird, setzt die Energieverwaltung das "inaktive" Ereignis zurück und setzt das "aktive" Ereignis.

Eine beliebige Anzahl von Treibern können Handles zu Zurücksetzenereignissen des Aktivitätszeitgebers öffnen, bevorzugt mit Hilfe von OpenEvent() und bei Bedarf durch Signalisieren mit SetEvent(). Treiber sollten die Namen des Ereignisses aus der Registrierung lesen. Auf diese Weise kann der OEM-Hersteller entscheiden, wie die Aktivität des Treibers von der Energieverwaltung interpretiert werden sollte.

Eine beliebige Anzahl von Threads können Handles für manuelle Zurücksetzenereignisse der Aktivität/Inaktivität öffnen und auf diese warten, um den Status des Systems zu ermitteln.

Wenn das System in den Standbymodus übergeht, setzt die Energieverwaltung die "aktiven" manuellen Zurücksetzenereignisse mit Aktivitätszeitgebern zurück. Bei der Wiederherstellung werden die Zeitgeber daraufhin untersucht, ob sie mit der Aktivierungsquelle verknüpft sind, die die Wiederherstellung des Systems bewirkt hat. Falls die Energieverwaltung eine Übereinstimmung findet, wird das Aktivitätsereignis signalisiert. Auf diese Weise kann die Energieverwaltung wieder in den Energiezustand übergehen, der mit dem Aktivitätszeitgeber verknüpft ist (falls vorhanden).

Welche Registrierungseinstellungen aktivieren Aktivitätszeitgeber im GWES, im Dateisystem, im Netzwerkstack und in PCMCIA-Bustreiber?
Das GWES liest einen Ereignisnamen aus HKEY_LOCAL_MACHINE\System\GWE\ActivityEvent. Falls ein Ereignis in diesem Schlüssel genannt und sein Handle geöffnet werden kann, wird das Ereignis immer dann signalisiert, wenn der GWES-Eingabethread aktiviert wird, um ein Eingabeereignis zu verarbeiten.

Das CXPORT-Modul im Netzwerkstack signalisiert regelmäßig ein von HKEY_LOCAL_MACHINE\Comm\CXPORT\NoIdleTimerEvent benanntes Aktivitätszeitgeberereignis, und zwar immer dann, wenn sich mindestens ein Socket im verbundenen Zustand befindet. Viele OEM-Hersteller setzen eventuell das NoIdleTimerReset-Attribut in der Registrierung, falls sie Aktivitätszeitgeber verwenden.

Der PCMCIA-Treiber signalisiert immer dann ein von HKEY_LOCAL_MACHINE\Drivers\PCMCIA\StatusChangeActivityEvent benanntes Aktivitätszeitgeberereignis, wenn eine Karte ausgeworfen oder eingeschoben wird.

Kann ich Aktivitätszeitgeberereignisse in meinem Gerätetreiber setzen, ohne die CPU zu belasten?
Ja. Die Energieverwaltung wartet nicht auf das Zurücksetzenereignis des Zeitgebers, während sie auf das Timeout des Zeitgebers wartet. Nach dem Timeout des Zeitgebers überprüft sie, ob das Ereignis in der Zwischenzeit gesetzt wurde. Falls nicht, betrachtet sie den Zeitgeber als abgelaufen. Andernfalls wird das Timeout zurückgesetzt und erneut gewartet. Die manuellen Zurücksetzenereignisse des Zeitgebers werden nur aktualisiert, wenn der Zeitgeber ohne Signalisierung des Zurücksetzenereignis abgelaufen ist oder wenn das Zurücksetzenereignis nach einem Zeitraum der Inaktivität das erste Mal signalisiert wurde.

Selbst wenn die Energieverwaltung aktiv auf das Zurücksetzenereignis des Zeitgebers wartet, während der Treiber dafür SetEvent() aufruft, wird der Aktivitätszeitgeberthread der Energieverwaltung geplant (und nicht ausgeführt), falls der Treiberthread mit einer höheren Priorität ausgeführt wird. Standardmäßig wird der Aktivitätszeitgeberthread mit THREAD_PRIORITY_ABOVE_NORMAL und die meisten Treiber mit THREAD_PRIORITY_HIGHEST oder höher ausgeführt, weshalb der Aktivitätszeitgeberthread den Treiber nicht präemptiv verdrängt. Die Priorität des Aktivitätszeitgeberthreads kann durch Setzen des Registrierungswerts TimerPriority256 angepasst werden.

Kann der Netzwerkstack einen Aktivitätszeitgeber zurücksetzen, wenn Daten gerade an ein Remotesystem übertragen werden, anstatt wenn ein Socket verbunden ist?
Einige Hersteller sind eventuell mehr daran interessiert, dass die Energieverwaltung weiß, dass Anwendungen aktiv Sockets verwenden, als bekanntzugeben, wann Sockets verbunden sind. Der Netzwerkstack bietet dafür keine direkte Unterstützung.

Jedoch können OEM-Hersteller einen Thread erstellen, der periodisch GetTcpStatistics() und GetUdpStatistics() abruft, um zu ermitteln, ob TCP-Segmente oder UDP-Datagramme übertragen oder empfangen werden. Ist dies der Fall, kann dieser Thread den Aktivitätszeitgeber zurücksetzen. Dieser Thread könnte als installierbarer Gerätetreiber, als Teil der Energieverwaltung oder als Teil einer Anwendung implementiert werden.

Wie informiere ich die Energieverwaltung darüber, dass ich Timeouts des Aktivitätszeitgebers ändern möchte?
Aktivitätszeitgeber werden beim Systemstart aus der Registrierung gelesen und nachher nicht mehr aktualisiert. Beachten Sie, dass Timeouts des Aktivitätszeitgebers angeben, wann ein bestimmter Teil des Systems aktiv oder inaktiv ist, und nicht steuern, wann Energiezustände des Systems geändert werden sollen. Zeitgeber für Energiestatusübergänge des Systems können angepasst werden, während das System aktiv ist.

Wie lassen sich also Zeitgeber für Energiestatusübergänge des Systems zurücksetzen?
Erstellen Sie ein benanntes automatisches Zurücksetzenereignis mit der Bezeichnung _T("PowerManager/ReloadActivityTimeouts"), und rufen Sie SetEvent() auf seinem Handle auf. Dadurch wird die Energieverwaltung angewiesen, die Zeitgebereinstellungen für den Statusübergang aus ihrem Timeouts-Schlüssel zu lesen.

Welche Beziehung besteht zwischen den Timeouts des Zeitgebers und den Timeoutoptionen in den Systemsteuerungseinstellungen zur Energieverwaltung?
Die Timeouts des Aktivitätszeitgebers geben an, wie lange die Energieverwaltung warten soll, bevor sie entscheidet, dass eine bestimmte Aktivitätsquelle inaktiv ist. Dies bewirkt die Signalisierung eines Inaktivitätsereignisses. Die Systemsteuerungsoption legt fest, wie lange das Inaktivitätsereignis signalisiert werden muss (ohne dass das entsprechende Aktivitätsereignis signalisiert wird), bevor die Energieverwaltung einen Energiestatusübergang des Systems initialisiert.

Allgemein sollten Timeouts des Aktivitätszeitgebers relativ klein im Verhältnis zu Timeouts des Systemenergiestatus sein, aber groß im Verhältnis zum erwarteten Aktivitätsintervall. So wird beispielsweise das Timeout des Systemenergiestatus in Minuten gemessen, während der Aktivitätszeitgeber des Benutzers 10 Sekunden beträgt. Dadurch werden zwar während des normalen Betriebs häufige Statusübergänge des Aktivitätszeitgebers verhindert, aber Benutzer können schon zehn Sekunden inaktiv sein, bevor dies vom System bemerkt wird. Aus diesem Grund sollte Aktivitätszeitgeber als "grobkörnig" angesehen werden.

Können andere Systemmodule als die Energieverwaltung Informationen des Aktivitätszeitgebers nutzen?
Ja. Die Zeitgeber für manuelles Zurücksetzen, bei denen es sich um Ausgaben von Aktivitätszeitgebern handelt, sind benannt, weshalb Module außerhalb der Energieverwaltung darauf zugreifen können. Falls der Name des Zeitgebers OEM_Activity lautet, erstellt die Energieverwaltung manuelle Zurücksetzenereignisse mit der Bezeichnung PowerManager/OEM_Activity_Active und PowerManager/OEM_Activity_Inactive.

Wie kann ich Inaktivitätszeitgeberinformationen in meine Beleuchtungstreiber integrieren?
Ihr Beleuchtungstreiber muss den Namen der/des Aktivitätszeitgeber/s entsprechend der Benutzeraktivität abrufen. Er kann diese Informationen aus von Ihnen definierten Registrierungsschlüsseln abrufen, oder die Zeitgebernamen können in seinen Quellcode integriert werden.

Angenommen, die Benutzeraktivität wird nur von einem Zeitgeber wiedergegeben, kann der Beleuchtungstreiber den folgenden einfachen Algorithmus implementieren:

  • Wenn der Benutzer aktiv ist, sicherstellen, dass die Beleuchtung eingeschaltet ist, und auf das Setzen des Inaktivitätsereignisses warten. Nachdem es gesetzt ist, zu Schritt 2 gehen.

  • Falls das Inaktivitätsereignis gesetzt ist, über einen konfigurierbaren Timeoutzeitraum auf das Setzen des Aktivitätsereignisses warten. Bei Auftreten des Timeouts die Beleuchtung ausschalten. Falls ansonsten das Aktivitätsereignis gesetzt ist, zu Schritt 1 gehen. Der Beleuchtungstreiber führt allgemein ein WaitForSingleObject() am aktiven oder inaktiven Ereignis aus. Wenn er den aktuellen Status des Benutzeraktivitätsereignisses ermitteln muss, kann er einen Timeoutwert von 0 verwenden, um ein Blockieren zu vermeiden.

Ich erstelle ein Gerät, bei dem jedes Byte in meinem Image relevant ist. Ich steuere alle Anwendungen und Treiber, die auf diesem Gerät ausgeführt werden, aber ich möchte auf einen Großteil der Energieverwaltungsinfrastruktur verzichten. Kann ich diese irgendwie aus meinem Image entfernen?
Wenn Sie ein HLBASE-Image ohne GWES verwenden, benötigen Sie die Energieverwaltungskomponente überhaupt nicht in Ihrem System. Andernfalls können Sie die PMSTUBS-Komponente verwenden, die über den Katalog auswählbar ist. Dabei handelt es sich um eine Minimalversion der Energieverwaltungs-DLL, in der ein Großteil der APIs nicht implementiert ist. Die Stubversion der Energieverwaltung unterstützt nur die Anforderung der PBT_POWERSTATUSCHANGE- und PBT_POWERINFOCHANGE-Benachrichtigungen und eine Standbyschaltung des Systems mit SetSystemPowerState(NULL, POWER_STATE_SUSPEND, 0). Die Wahl der Stubversion der Energieverwaltung kann zu Kompatibilitätsproblemen bei Treibern oder Anwendungen führen, die von Diensten der Energieverwaltung abhängig sind.

Einige der Felder in der "POWER_CAPABILITIES"-Struktur, die mein Treiber an die Energieverwaltung übergibt, scheinen ungenutzt. Was geschieht mit diesen?
In der Beispielimplementierung der Energieverwaltung werden folgende Strukturmember nicht genutzt: WakeFromDx, InrushDx, Power und Latency. Diese Felder dienen als Platzhalter für OEM-Hersteller und werden eventuell in zukünftigen Versionen der Energieverwaltung von Microsoft unterstützt.

Welche Funktion hat die neue "PBT_POWERINFOCHANGE"-Benachrichtigung?
Die PBT_POWERINFOCHANGE-Benachrichtigung enthält die Informationen zum Akkuladezustand, die am häufigsten vom GWES angefordert werden. Anwendungen können sich für den Empfang dieser Benachrichtigung registrieren, anstatt Energiestatusänderungen abzufragen.

Kann ich die Energieverwaltung zum Löschen von Dateien und Neustarten meines Geräts verwenden? Kann das System für den Versand auch vollständig ausgeschaltet werden?
Die Antwort lautet in beiden Fällen "Ja". Definieren Sie einfach einen Systemenergiestatus mit der gewünschten Semantik, und passen Sie die Energieverwaltung für seine Implementierung an. Anschließend können Anwendungen SetSystemPowerState() mit dem Namen des Systemenergiestatus oder mit einem entsprechenden Hinweisattribut aufrufen. Die pm.h-Headerdatei definiert POWER_STATE_RESET und POWER_STATE_OFF für diese beiden Fälle. OEM-Hersteller können nach Bedarf ebenfalls benutzerdefinierte Attribute definieren.

Um die oben genannte Funktionsweise in der Praxis zu implementieren, definieren Sie die Energiezustände so, als ob es sich um Standbyzustände handelt, aber rufen Sie anstelle von PowerOffSystem() die Benachrichtigung IOCTL_HAL_RESET oder eine plattformspezifische API auf, um das System auszuschalten.

Wie kann ich einer Anwendung einen Taktzeitgeber hinzufügen? Ich möchte die Anwendung nach Ablauf des Zeitgebers stoppen und neu starten.
Die Energieverwaltung ist nicht für die Anwendungsüberwachung ausgelegt. Sie können jedoch den Code in pmtimer.cpp kopieren und anpassen, um Taktzeitgeber für Anwendungen zu erstellen. Sie müssen dazu die Zeitgeberschleife anpassen, um das Löschen und Erstellen von Zeitgebern zur Laufzeit zu ermöglichen. Außerdem müssen Sie einen Mechanismus erstellen, der es Anwendungen ermöglicht, ihre Zeitgeber bei der Anwendungsüberwachung zu registrieren. Eine gute Möglichkeit dafür sind eventuell Meldungswarteschlangen.

Sonstiges

Können Platform Builder 3.0 und Platform Builder 4.0 koexistieren?
Dies sollte kein Problem darstellen, so lange sie in unterschiedlichen Verzeichnissen installiert sind.

In der Dokumentation von Windows CE .NET 4.0 (Thema: Creating Physical to Virtual Mappings) heißt es:
"Nachdem der Kernel die ursprüngliche Zuordnung während des Startvorgangs erstellt, kann eine Anwendung oder die OAL zum statisch zugeordneten virtuellen Addressenpool durch Aufruf von CreateStaticMapping oder NKCreateStaticMapping beitragen. Auf diese Weise zugeordneter Speicher befindet sich im Bereich zwischen C400 0000 und E000 0000, und wird nur als nicht zwischengespeicherter Speicher erstellt."

Bei ARM-Prozessoren bewirkt diese Funktion jedoch etwas völlig anderes. Sie führt eine Suche in der fest codierten OEMAddressTable durch, also trägt sie nicht zum statisch zugeordneten virtuellen Adressenpool bei. Daraus ergibt sich, dass der Bereich nicht mit dem in der Dokumentation beschriebenen übereinstimmt.

Es stimmt, dass NKCreateStaticMapping keine neue Region erstellt (gleiches gilt auf SHx). Stattdessen wird nur eine vorhandene Zuordnung zurückgegeben.

Ich habe ein Platform Software Development Kit (SDK) für meine Plattform für die Verwendung mit Embedded VC++ 4.0 erstellt. Bei Ausführung unter Platform Builder funktioniert die Emulationsumgebung korrekt. Ich habe ein MSI-Paket erstellt, das sich problemlos installieren lässt und in der eVC-Entwurfsumgebung zur Verfügung steht. Mein Projekt wird erfolgreich kompiliert, und bei Beginn des Debugvorgangs werden alle Dateien gedownloadet. Das Emulationsfenster erscheint zwar, aber meine Anwendung wird nie ausgeführt. Warum?
Dies lässt sich wahrscheinlich durch Deaktivieren der Kernel Independent Transport Layer (KITL) im Platform Builder-Plattformimage lösen, die standardmäßig aktiviert ist. Gehen Sie dazu wie folgt vor: Wenn Sie das neue Plattformimage über den Plattform-Assistenten konfigurieren, erhalten Sie im letzten Dialogfeld die Option, Ihre Erstellungsoptionen zu ändern. Klicken Sie auf die entsprechende Option, und deaktivieren Sie das Kontrollkästchen zum Aktivieren von KITL. Wenn Sie die Erstellung der Plattform abgeschlossen haben, exportieren Sie Ihr SDK mit dieser Plattform, und installieren und verwenden Sie es wie zuvor. Der Emulator kann keine Verbindung zu einem SDK herstellen, bei dem KITL aktiviert ist.

Beim Erstellen erhalte ich neuerdings folgende Fehlermeldung: "Image is too large for current RAM and RAMIMAGE settings" (Image ist zu groß für aktuellen RAM-Speicher und RAMIMAGE-Einstellungen). Was bedeutet das?
Diese Warnung bedeutet, dass die Größe des erstellten Image den in der Datei config.bib festgelegten Arbeitsspeicher überschreitet.

Wie finde ich heraus, welche Komponenten im Platform Builder für Windows CE .NET enthalten sind?
Die MSDN-Site beschreibt die wichtigsten Betriebssystemkomponenten neben den optionalen Modulen, die Sie für zusätzliche Funktionen nutzen können.

Häufig gestellte Fragen zur Windows CE-Anwendungsentwicklung

Welche Entwicklungstools kann ich für Windows CE-basierte Geräte verwenden?
Die Microsoft eMbedded Visual Tools 3.0 (eVT) enthalten sowohl Microsoft eMbedded Visual Basic 3.0 (eVB) als auch eMbedded Visual C++ 3.0 (eVC). Die eMbedded Visual Tools eignen sich für folgende Geräte:

  • Taschen PCs mit Windows CE 2.1x

  • Handheld PC Pro-Geräte mit Windows CE 2.1x

  • Handheld PC 2000-Geräte mit Windows CE 3.0

  • Pocket PC 2000-Geräte mit Windows CE 3.0

  • Pocket PC 2002-Geräte mit Windows CE 3.x

Microsoft eMbedded Visual C++ 4.0 eignet sich für Geräte mit Windows CE .NET. Beim Entwurf von eVC 4.0 wurde darauf geachtet, dass es auf demselben System wie eVC 3.0 installiert werden kann, ohne den Betrieb von eVC 3.0 zu beeinflussen.

Darüber hinaus können benutzerdefinierte Geräte (die nicht in der Liste weiter oben enthalten sind) Unterstützung für eVB und/oder eVC enthalten. Weitere Informationen erhalten Sie von Ihrem Gerätehersteller.

Das Microsoft .NET Compact Framework ist eine Teilmenge des .NET Framework, das zur Ausführung auf intelligenten Geräten dient und Unterstützung für verwalteten Code und XML Web Services bietet. Da es sich bei dem .NET Compact Framework um eine Teilmenge des .NET Framework auf dem Desktop handelt, können Entwickler, die mit .NET vertraut sind, problemlos .NET-Anwendungen für intelligente Geräte erstellen.

Die Smart Device Extensions für Visual Studio .NET stellen eine Reihe von zusätzlichen Funktionen für Visual Studio .NET zur Verfügung, mit denen Entwickler Anwendungen für Geräte mit dem .NET Compact Framework entwickeln, debuggen und weitergeben können. Diese Erweiterungen enthalten gerätespezifische Funktionen für Visual C# .NET und Visual Basic .NET, Funktionen für Remotegerätedebugging, Geräteemulation und eine Vielzahl von anderen Funktionen.

Wo erhalte ich diese Entwicklungstools?
eVT3.0 steht als kostenloser Download auf der Microsoft-Downloadsite zur Verfügung.
eVC4.0 steht ebenfalls als kostenloser Download auf der Microsoft-Downloadsite zur Verfügung:
Das .NET Compact Framework befindet sich derzeit in der Betaphase. Weiter Informationen zum Erhalt der Betaversion finden Sie auf der GotDotNet-Site.

eMbedded Visual Basic

Wie ich den Media Player über eVB automatisieren?
Leider kann eVB den Media Player nicht automatisieren. Es gibt eine Reihe von Alternativen für das Abspielen von Mediendateien über eVB:

  1. Starten Sie den Media Player mit der CreateProcess-API, wobei die Mediendatei als einer der Befehlszeilenparameter verwendet wird.

  2. Wenn Sie nur eine .wav-Datei wiedergeben, verwenden Sie die PlaySound-API.

  3. Es steht ein Windows Media Player for Pocket PC SDK auf der Microsoft-Site zur Verfügung. Leider unterstützt dieser keine direkte Verwendung über eVB. Im Download des SDK ist auch ein eVC-Beispiel enthalten: "Das SDK enthält auch ein Codebeispiel, das zeigt, wie das Steuerelement in ein benutzerdefiniertes C++-Programm mit Microsoft eMbedded Visual C++® eingebettet wird." Also wäre es möglich, das Steuerelement in eVC einzubetten und es in eVB anzuzeigen.

Wie kann ich JPEG-, GIF- und andere Grafikdateien anzeigen?
Das mit eVB ausgelieferte PictureBox-Steuerelement unterstützt nur BMP- und 2BP-Dateiformate. Für die Anzeige weiterer Grafikformate können Steuerelemente von Fremdanbietern verwendet werden. Im Anschluss werden eine Reihe von Alternativen aufgezeigt:

Wenn ich versuche, mein Handheld PC 2000-Gerät von eVB anzusprechen, erhalte ich folgende Meldung: 'The targeted platform does not match the device currently connected to your system' (Die Zielplattform entspricht nicht dem Gerät, das derzeit an Ihr System angeschlossen ist). Warum? Auf Geräten mit allen Prozessoren bis auf CEPC muss der folgende Eintrag in die Geräteregistrierung eingefügt werden, damit eVC und eVB die Plattform erkennen können und der korrekte Download von Dateien ermöglicht wird:

  • HKEY_LOCAL_MACHINE\Windows CE Tools

  • String Value

  • Platform={0F9D255B-97DA-4641-A8E6-7A7411D2472F}

Führen Sie nach dem Eintrag einen Neustart des Geräts durch, damit die Änderungen in Kraft treten.

Programmieren mit Datenbanken

Wie konvertiere ich meine Access-Datenbank in eine CDB-Datenbank für die Verwendung mit eVB auf dem Gerät?
Die folgende Fremdanbietersite enthält eine gute Erläuterung: DEVBUZZ.COM.

Kann ich die "Seek"- und "Find"-Methoden in eVB mit einer Pocket Access-Datenbank verwenden?
Nein. Seek und Find, obwohl in ADOCE 3.1 implementiert, erfordern OLEDB-Unterstützung (wie in SQL für CE). Der CEDB-Datenbankprovider basiert nicht auf OLEDB und bietet keine Unterstützung für Seek/Find. CEDB ist der Datenbankprovider, der mit CDB-Dateien verwendet wird.

Anders ausgedrückt: seek und find funktionieren nur bei Verwendung von ADOCE 3.1 mit SQL für Windows CE.

Welche Beschränkungen gibt es für Pocket Access-Datenbanken und ADOCE?
Unter Windows CE 2.1x-Geräten:

  • Maximale Datensatzgröße: 128 KB

  • Maximale Größe der Datenbankdatei: 16 MB

  • Maximale Feldanzahl: Keine Begrenzung

  • Maximale Eigenschaftengröße: 64 KB

  • Maximale Sortiereihenfolge: 4

  • Maximale Anzahl der Objekte: 64KB

Sie können sich ein Objekt als eine Datenmenge im Objektspeicher oder in einer Datenbankdatei vorstellen. Im Anschluss finden Sie eine Liste unterschiedlicher Objekte:

  • Registrierungsschlüssel oder Wert (nur Objektspeicher)

  • Verzeichnis (nur Objektspeicher)

  • Dateiheader (nur Objektspeicher)

  • Datenblock - bis zu 4 KB Dateidaten oder bis zu 4 KB eines Datensatzes

  • Datenbankheader

Auf Windows CE 3.0-Geräten entsprechen die Grenzwerte für 3.0 bis auf den letzten den oben aufgelisteten. Eine Tabelle in einer Datenbankdatei ist auf 64 KB-Einträge beschränkt, jedoch die Datenbank selbst kann mehr haben (indem sie mehr als eine Tabelle enthält). Die maximale Anzahl von Objekten (Datensätze, Tabellen, 4 KB-Blöcke mit Eigenschaftendaten) beträgt 4096*1024=ca. 4 Millionen

Wenn ich in etwa 15.000 Datensätze in meine Datenbank schreibe, bleibt mein Gerät hängen.
Wenn Sie eine Plattform mit Windows CE 3.0 entwickeln, finden Sie in einem Microsoft Knowledge Base-Artikel eine Korrektur für dieses Problem.

Wenn Sie eine Anwendung für ein veröffentlichtes Geräts entwickeln, die diesen Fehler enthält, muss die Korrektur in den ROM-Speicher übertragen werden, was nur vom Gerätehersteller erledigt werden kann.

Wenn es Ihnen nicht möglich ist, den ROM-Speicher in einem veröffentlichten Gerät zu aktualisieren, gibt es einige Workarounds für dieses Problem:

  1. Teilen Sie Ihre Daten in kleinere Datenbanken mit bis zu jeweils 10.000 Datensätzen auf.

  2. Sortieren Sie nicht nach Zeichenfolgen, falls Ihre Datenbank mehr als 10.000 Datensätze benötigt.

  3. Verwenden Sie zur Entwicklung Microsoft SQL ServerT für Windows CE. SQL Server für CE enthält diesen Fehler nicht, und die Leistung ist bei der Arbeit mit großen Datenbanken viel größer.

Weitere Ressourcen:
Die folgenden aktiven Newsgroups stehen zur Verfügung:

Windows CE .NET-Betriebssystem:

Windows XP Embedded:

Windows CE-Anwendungsentwicklung
Microsoft .NET Compact Framework und Smart Device Extensions:

Microsoft eMbedded Visual C++ 4.0:

ADOCE:

Microsoft eMbedded Visual Basic:


Anzeigen:
© 2014 Microsoft