Exporter (0) Imprimer
Développer tout

Système de développement modulaire Windows CE .NET

Mike Hall
Microsoft Corporation

S'applique à :
    Microsoft® Windows® CE
    Microsoft Windows CE .NET

Résumé : Microsoft Windows CE a été conçu dès l'origine comme un système d'exploitation modulaire. Cet article décrit le modèle de modularité utilisé par Windows CE .NET et explique comment ajouter des composants et des fonctionnalités supplémentaires à Windows CE. Cet article contient des liens vers des pages en anglais.

Sommaire

Introduction
Présentation de la modularité
Système de génération
Environnement de développement intégré
Conclusion
Ressources supplémentaires

Introduction

Microsoft Windows CE et Windows XP Embedded sont tous deux des systèmes d'exploitation modulaires. Les outils fournis avec chacun de ces produits permettent aux développeurs de sélectionner les fonctionnalités requises pour leurs équipements embarqués. Mais pour quelle raison cette modularité est-elle si importante pour les systèmes embarqués ?

Il existe de nombreuses réponses à cette question. Toutefois, l'encombrement, la sécurité et la fiabilité figurent en tête de liste des raisons pour lesquelles un développeur choisira de recourir à un système d'exploitation modulaire pour développer un système embarqué.

Encombrement - Les développeurs peuvent être limités en termes de taille pour ce qui concerne le disque de démarrage et la RAM de leur système embarqué. Le fait d'utiliser uniquement les technologies et ressources dont ils ont vraiment besoin permet aux développeurs d'adapter parfaitement l'encombrement de la ROM ou de la RAM à un équipement spécifique.

Sécurité - Les systèmes embarqués sont non seulement de plus en plus intelligents, mais ils vous permettent également de rester connecté en permanence, soit à l'intranet de votre entreprise, soit directement sur l'Internet. Les développeurs peuvent réduire l'exposition du code aux attaques en incluant au système d'exploitation uniquement les composants requis. En outre, les tâches de configuration des services, indispensables pour minimiser les risques d'attaque, ont été considérablement réduites, car les services non souhaités sont tout simplement supprimés. Qui plus est, l'exclusion de composants, tels que WCELOAD, peut permettre de « confiner » un périphérique en empêchant les utilisateurs de télécharger et d'installer de nouvelles applications sur leur équipement embarqué. Pour obtenir davantage d'informations sur Windows CE, consultez l'article Les fonctionnalités de sécurité sous Windows CE .NET.

Fiabilité - Si un composant est absent de l'image d'un système d'exploitation, il ne pourra fonctionner et, dans ce cas, il ne pourra pas non plus provoquer de panne au niveau de l'équipement. Par conséquent, la réduction de la taille et des fonctionnalités ne peut qu'augmenter la fiabilité globale d'un équipement. Pour obtenir davantage d'informations sur la fiabilité et la tolérance aux pannes, consultez l'article Implementing Fault Tolerant Systems with Windows CE .NET (Lien externe au site MSDN France Site en anglais).

Présentation de la modularité

Windows CE a été conçu dès l'origine comme un système d'exploitation modulaire, offrant ainsi aux développeurs la possibilité d'adapter l'image d'un système d'exploitation aux besoins spécifiques d'un système embarqué. Les périphériques concernés sont notamment les équipements contrôlés à distance, tels que les décodeurs, les systèmes de commande industriels et les périphériques dotés d'une interface utilisateur, tels que les écrans Smart Display, les téléphones VoIP (voix sur encapsulation IP) et les périphériques Pocket PC fonctionnant sous Windows.

Pratiquement chaque nouvelle version de Windows CE ajoute un support à des processeurs, des cartes mères matérielles et des technologies d'exploitation supplémentaires. Lors de sa première mise sur le marché, en 1998, Windows CE 2.0 comportait environ 50 modules, alors que la nouvelle version Windows CE .NET 4.2 en contient plus de 350.

Windows CE est modulable à plus d'un niveau. Une image de système d'exploitation est constituée d'un certain nombre de fichiers exécutables et de DLL, tels que Coredll.dll et GWES.exe. Par exemple, GWES, le module de Windows CE qui présente l'architecture par composants la plus évoluée, est organisé en divers sous-composants (menu, presse-papiers, contrôles d'interface utilisateur, etc.) sélectionnables individuellement lors de la génération du système.

La façon de configurer et de générer un système d'exploitation a également évoluée avec le temps. Auparavant, les développeurs qui se servaient de Windows CE 2.0 disposaient uniquement d'une ligne de commande. Désormais, avec Windows CE .NET 4.2 ils ont le choix entre la ligne de commande et l'environnement de développement entièrement intégré (IDE). Cet environnement de développement dissimule le système de génération sous-jacent aux développeurs, simplifiant ainsi à l'extrême les tâches de configuration d'un système d'exploitation.

L'extensibilité est également primordiale pour Windows CE et les outils de développement Windows XP Embedded, car cela permet aux développeurs d'inclure la prise en charge à de nombreuses cartes mères matérielles supplémentaires (lien en anglais). En ce qui concerne la prise en charge de nouveaux pilotes et de nouvelles applications, des modules BSP tiers de prise en charge de cartes peuvent être ajoutés à Platform Builder (outil Windows CE de configuration/génération/déploiement/débogage) via l'ajout de fichiers de composants CE (.cec). En fait, tous les composants visibles à partir du catalogue Platform Builder sont hébergés via des fichiers .cec.

Système de génération

Les systèmes de génération Windows CE et Windows XP Embedded sont très différents l'un de l'autre. Windows XP Embedded inclut les fichiers binaires pré-construits du Service Pack 1 de Windows XP. Ce système de génération copie les fichiers binaires appropriés dans le dossier de sortie correspondant, ce qui inclut notamment la création de la structure de dossiers nécessaire pour prendre en charge le système d'exploitation Windows XP Embedded : \Windows, \Windows\System32, \Program Files.

Windows CE génère les fichiers associés au matériel, les composants du système d'exploitation et les applications utilisateur supplémentaires à partir des fichiers source. L'utilisation d'assembleurs, de compilateurs et d'éditeurs de liens peut s'avérer nécessaire pour produire l'image finale du système d'exploitation. Le système de génération Windows CE est lié au DDK (Driver Development Kit) de Microsoft Windows NT®, car il dépend considérablement des « variables d'environnement » pour contrôler l'inclusion ou l'exclusion de composants de l'image finale du système d'exploitation.

Le processus de génération est composé de quatre étapes principales :

  1. Création des projets Public (C:\Wince420\Public)
  2. Création de la plate-forme (C:\Wince420\Platform)
  3. Création du répertoire de destination (résultat de la génération)
  4. Création de l'image du système d'exploitation (nk.bin)

Étape 1 : Création des projets Public

Le dossier C:\Wince420\Public contient les projets créés par l'utilisateur et les projets du système d'exploitation. Windows CE comporte divers projets « public », par exemple Microsoft Internet Explorer, Microsoft DirectX® et le Shell.

Dans le cas d'un exemple de projet intitulé MyPlatform, basé sur le modèle de plate-forme Internet Appliance et incluant Internet Explorer, Microsoft .NET Compact Framework et le serveur Web HTTPD, il est facile de savoir quels seront les projets « public » créés. Une variable d'environnement (visible à partir d'une fenêtre de génération), appelée _DEPTREES, contient la liste des projets public, y compris le projet « MyPlatform ». Pour visualiser cette variable, lancez Platform Builder, créez une plate-forme à partir de Internet Appliance, ouvrez la fenêtre Build Release, puis utilisez la commande set _deptrees qui renverra les informations suivantes.

C:\WINCE420\PUBLIC\MyPlatform\RelDir\EMULAT~2>set _deptrees

_DEPTREES=winceos dcom netcf ie script servers rdp shellsdk shell wceshellfe wceappsfe viewers directx datasync SQLCE speech MYPLATFORM

De nombreux autres dossiers de projets Windows CE seront créés à partir de la variable d'environnement _deptrees ci-dessus, y compris les dossiers NETCF, SERVERS, RDP, SHELL et MYPLATFORM. L'ordre de création des projets dépend de la variable d'environnement _deptrees.

Étape 2 : Création de la plate-forme

Le système de génération Windows CE a besoin de savoir quels fichiers de la plate-forme et quels dossiers publics doivent être créés. Cette opération est prise en charge par les fichiers DIRS et SOURCES.

Le dossier C:\Wince420\Platform comporte des modules BSP de prise en charge des cartes matérielles ou des fichiers spécifiques à certains matériels. Notez que de nombreux pilotes de périphériques indépendants de la plate-forme sont inclus dans Windows CE .NET et qu'ils se trouvent dans le dossier C:\Wince420\Public\Common\Oak\Drivers.

L'émulateur BSP se trouve sous C:\Wince420\Platform\Emulator. La liste ci-dessous répertorie les fichiers du dossier.

Directory of C:\WINCE420\PLATFORM\EMULATOR

03/25/2003 11:00 AM <DIR> .
03/25/2003 11:00 AM <DIR> ..
03/25/2003 11:00 AM <DIR> CESYSGEN
03/21/2003 01:00 AM 476 dirs
03/25/2003 11:00 AM <DIR> DRIVERS
03/21/2003 01:00 AM 884 emulator.bat
03/25/2003 11:00 AM <DIR> FILES
03/25/2003 11:00 AM <DIR> GWE
03/25/2003 11:00 AM <DIR> INC
03/25/2003 11:00 AM <DIR> KERNEL
03/21/2003 01:00 AM 452 sources.cmn
 3 File(s) 1,812 bytes

Le fichier texte intitulé dirs contient une liste des sous-dossiers de ce module BSP qui doivent être générés. Le code ci-dessous indique le contenu de ce fichier.

DIRS= \
 gwe \
 kernel \
 drivers

Dans ce cas, trois sous-dossiers doivent être créés : GWE, Kernel et Drivers (dans cet ordre). Notez que l'ordre des dossiers répertoriés dans le fichier dirs correspond à l'ordre de création des pilotes. Grâce à cette particularité, les bibliothèques de pilotes courantes pourront être générées avant les pilotes pour lesquels ces bibliothèques sont indispensables.

Directory of C:\WINCE420\PLATFORM\EMULATOR\DRIVERS

03/25/2003 11:00 AM <DIR> .
03/25/2003 11:00 AM <DIR> ..
03/21/2003 01:00 AM 1,012 dirs
03/25/2003 11:00 AM <DIR> DISPLAY
03/25/2003 11:00 AM <DIR> DMA
03/25/2003 11:00 AM <DIR> EMULSERV
03/25/2003 11:00 AM <DIR> KBDMOUSE
03/25/2003 11:00 AM <DIR> NET
03/25/2003 11:00 AM <DIR> VCEFSD
03/25/2003 11:00 AM <DIR> WAVEDEV
 1 File(s) 1,012 bytes

Il existe également, dans ce cas, un fichier dirs qui contient une liste des sous-dossiers des pilotes qui doivent être générés. Pour ajouter un pilote, créez le sous-dossier et le code correspondant, puis modifiez le fichier dirs afin d'inclure ce nouveau dossier.

À un moment donné, vous aurez également besoin d'un fichier makefile qui décrit le type de projet (.exe, .dll ou bibliothèque), le point d'entrée dans le projet, les bibliothèques requises et les fichiers sources. Il n'existe aucun fichier dirs dans le dossier emulator\drivers\wavedev, car il s'agit de la fin de l'arborescence des dossiers. Par contre, il existe un fichier sources qui contient les informations make pour ce pilote.

En examinant le contenu du fichier sources, vous pouvez connaître le type d'exécutable du pilote, qui dans notre cas est DYNLINK ou DLL (ce qui est courant pour les pilotes d'équipements Windows CE). Vous pouvez également savoir quelles sont les bibliothèques requises, le point d'entrée du pilote DllEntry et les fichiers sources nécessaires.

TARGETNAME=wavedev
RELEASETYPE=PLATFORM
TARGETTYPE=DYNLINK

TARGETLIBS=$(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib
SOURCELIBS= \
 $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\wavemdd.lib \
 $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\ceddk.lib \

DEFFILE=$(_COMMONOAKROOT)\inc\wavedev.def

DLLENTRY=DllEntry

INCLUDES=..\..\inc; $(_PUBLICROOT)\common\oak\csp\i486\inc

SOURCES=wavepdd.c

Tout dossier d'un système de génération Windows CE doit contenir un fichier SOURCES ou un fichier DIRS. Les répertoires listés dans un fichier DIRS correspondent généralement aux sous-dossiers du dossier contenant le fichier DIRS. Notez que les dossiers ne comportant aucun fichier SOURCES ou DIRS ne sont pas pris en compte par le système de génération.

Comment le système de génération détermine-t-il les pilotes à inclure dans l'image finale du système d'exploitation ? Cette opération est contrôlée par les variables d'environnement et, dans le cadre du projet d'émulateur, les variables suivantes sont utilisées :

BSP_EMULDRIVEMAP=1
BSP_NO1394=1
BSP_NOCOMCARD=1
BSP_NOFIR=1
BSP_NOIDE=1
BSP_NONLED=1
BSP_NOPCIBUS=1
BSP_NOPCMCIA=1
BSP_NORNDIS=1
BSP_NOSIR=1
BSP_NOTOUCH=1
BSP_NOUSB=1
BSP_NOUSBSER=1

Étant donné que l'image exécutée sur votre ordinateur correspond à celle d'un émulateur, tout matériel comme une carte PCMCIA ou 1394 est inutile. Les variables d'environnement BSP_ excluent donc ces fonctionnalités de l'image finale. Par contre, des pilotes, tels que le pilote du clavier, sont inclus dans l'image, car la variable BSP_NOKEYBD n'est pas définie.

Les variables d'environnement contrôlent également la façon dont le système de génération déterminera les modules BSP à créer. La variable _TARGETPLATROOT suivante indique qu'il s'agit d'une plate-forme d'émulation.

_TARGETPLATROOT=C:\WINCE420\platform\Emulator

Étape 3 : Création du répertoire de destination

Le dossier de génération, souvent appelé _FLATRELEASEDIR (autre variable d'environnement), est créé pour le type de génération approprié. Dans notre exemple de plate-forme d'émulation, il existe deux dossiers de destination possibles : Debug et Release. Dans le cas de la génération d'une image de débogage, le dossier C:\Wince420\Public\MyPlatform\RelDir\EMULATOR_X86Debug sera créé et tous les fichiers temporaires seront copiés dans ce dossier.

Étape 4 : Création de l'image du système d'exploitation (nk.bin)

L'étape finale de génération d'une image de système d'exploitation est intitulée makeimg. Lors de ce processus, tous les composants individuels sont réunis pour former l'image finale correspondant au fichier NK.BIN. Ce fichier comporte les composants OAL, Drivers et Win32, le shell, les applications, etc.

Le système d'exploitation est constitué de divers composants. Certains de ces composants, tels que GWES (Graphical Windowing and Event Subsystem), sont également constitués de divers sous-composants optionnels. Le système de génération a aussi besoin d'une méthode pour déterminer quels modules et composants inclure dans le système d'exploitation. Ce processus est réalisé à l'aide des variables d'environnement et d'un fichier, appelé CESYSGEN.bat. Dans l'exemple MyPlatform, plate-forme créée à partir de Internet Appliance, le fichier cesysgen.bat est situé sous C:\Wince420\Public\MyPlatform\Wince420\Emulator\Oak\Misc.

Chaque composant est inclus dans le système d'exploitation final via le jeu de variables d'environnement « sysgen » approprié. Dans Platform Builder, vous pouvez examiner dans le catalogue la variable sysgen d'un composant donné. L'illustration ci-dessous indique la variable sysgen du composant .NET Compact Framework-SYSGEN_DOTNET.

Variable d'environnement .NET Compact Framework

Figure 1. Variable d'environnement .NET Compact Framework

Après avoir ajouté le composant du catalogue dans un espace de travail ou avoir défini directement la variable d'environnement SYSGEN_DOTNET dans une fenêtre de génération, vous pouvez poursuivre le processus de génération. À un moment donné, le système de génération devra déterminer quels sont exactement les éléments qui doivent être créés ou copiés pour obtenir les composants temporaires et comment transférer les fichiers requis dans le dossier de destination approprié.

Dans l'extrait de code ci-dessous du fichier CESYSGEN.bat pour le projet « MyPlatform », vous pouvez observer que la variable SYSGEN_DOTNET est sélectionnée. Le cas échéant, une variable d'environnement SYSGEN_DOTNET_SUPPORT est également activée, afin de définir des variables d'environnement supplémentaires nécessaires à la prise en charge du module .NET Compact Framework.

REM Add .Net Compact Framework to the platform
if "%SYSGEN_DOTNET%"=="1" set SYSGEN_DOTNET_SUPPORT=1

REM Add .Net Compact Framework dependency support to the platform
if not "%SYSGEN_DOTNET_SUPPORT%"=="1" goto NoDotNetSupp
 set SYSGEN_CPP_SEH=1
 set SYSGEN_CRYPTO=1
 set SYSGEN_WININET=1
 set __SYSGEN_IMGDECMP=1
:NoDotNetSupp

Comment la configuration de la variable d'environnement peut-elle se traduire par l'ajout d'un composant au système d'exploitation ? Il s'agit de nouveau d'un processus géré par les variables d'environnement. Le composant .NET Compact Framework est constitué de divers modules optionnels, dont l'utilitaire d'authentification Visual Studio .NET Smart Device Authentication Utility Lien externe au site MSDN France Site en anglais(SDAuthUtilDevice.exe) et le support pour SQL Server CE 2.0. Les développeurs peuvent choisir d'inclure ou d'exclure ces composants du système d'exploitation.

Dans le cas du composant .NET Compact Framework, vous définissez une variable d'environnement appelée NETCF_MODULES. Le fichier makefile du composant .NET Compact Framework utilisera cette variable d'environnement afin de déterminer les éléments à générer (le cas échéant) et ceux à copier dans le dossier de destination final. Notez que NETCF_MODULES sera défini sur dotnet si le composant .NET Compact Framework doit être inclus dans le système d'exploitation.

REM =======================================================
REM .NET Compact Framework modules
REM =======================================================

if "%SYSGEN_DOTNET%"=="1" set NETCF_MODULES=%NETCF_MODULES% dotnet
if "%SYSGEN_SQLCE20_DP%"=="1" set NETCF_MODULES=%NETCF_MODULES% sqlce20_dp
if "%SYSGEN_SQL2000_DP%"=="1" set NETCF_MODULES=%NETCF_MODULES% sql2000_dp

REM =======================================================
REM Visual Studio Add-in
REM =======================================================

if "%SYSGEN_VS_SD_AUTH%"=="1" set NETCF_MODULES=%NETCF_MODULES% vs_sd_auth

REM =======================================================
REM Microsoft SQLCE
REM =======================================================

if "%SYSGEN_SQLCE20%"=="1" set SQLCE_MODULES=%SQLCE_MODULES% sqlce20

Nous vous avons déjà expliqué que plusieurs projets public peuvent être créés dans le cadre du processus de génération (via la variable d'environnement _deptrees), notamment le projet NETCF. Ce projet contient le fichier makefile nécessaire pour la génération du composant .NET Compact Framework sous forme d'image du système d'exploitation. Le makefile du projet NETCF est situé sous C:\WINCE420\PUBLIC\NETCF\CESYSGEN. Le code ci-dessous correspond au contenu du fichier makefile. Une partie du code a été supprimée afin d'en faciliter la lecture.

dotnet:
 @echo Copying .NET Compact Framework Components to $(_FLATRELEASEDIR)
 -@xcopy /I /D /Q $(DOTNET_ROOT)\$(MAPPEDDIRNET)\*.exe $(_FLATRELEASEDIR) > nul $(SG_XCOPYREDIRECT)
 -@xcopy /I /D /Q $(DOTNET_ROOT)\$(MAPPEDDIRNET)\*.dll $(_FLATRELEASEDIR) > nul $(SG_XCOPYREDIRECT)
 -@xcopy /I /D /Q $(DOTNET_ROOT)\$(MAPPEDDIRNET)\*.nlp $(_FLATRELEASEDIR) > nul $(SG_XCOPYREDIRECT)
 -@xcopy /I /D /Q $(DOTNET_ROOT)\$(MAPPEDDIRNET)\*.rel $(_FLATRELEASEDIR) > nul $(SG_XCOPYREDIRECT)
 -@xcopy /I /D /Q $(DOTNET_ROOT)\managed\*.dll $(_FLATRELEASEDIR) > nul $(SG_XCOPYREDIRECT)

vs_sd_auth:
 @echo Copying Visual Studio .NET 2003 Windows CE Utilities to $(_FLATRELEASEDIR)
 -@xcopy /I /D /Q $(VS_ROOT)\$(MAPPEDDIRNET)\SDAuthUtilDevice.* $(_FLATRELEASEDIR) > nul $(SG_XCOPYREDIRECT)

Le composant .NET Compact Framework étant livré sous forme de fichiers binaires pré-construits, le makefile copie donc les fichiers appropriés dans le dossier de destination, qui est lui même défini via une variable d'environnement _FLATRELEASEDIR.

Vous avez maintenant une vague idée de la façon dont le système de génération transforme les modules et les composants en image de système d'exploitation, c'est-à-dire en recourant exclusivement aux variables d'environnement. Cette méthode peut sembler satisfaisante si vous développez un système d'exploitation à partir de la ligne de commande, car il vous suffit de définir les variables appropriées, puis de générer l'image. Mais, comment cela fonctionne-t-il à partir de l'environnement de développement intégré ?

Environnement de développement intégré

Deux choix s'offrent aux développeurs Windows CE lors de la génération d'une image de système d'exploitation : ils peuvent procéder à partir de la ligne de commande ou utiliser l'outil Platform Builder de l'environnement de développement intégré (IDE) de Windows CE.

Certains développeurs préfèrent générer leur système d'exploitation à partir de la ligne de commande, car celle-ci leur offre davantage de contrôle en leur permettant de sélectionner précisément les éléments dont ils ont besoin ou de choisir uniquement les composants qui ont été modifiés afin de réaliser des économies de temps sur le développement.

D'autres développeurs préfèrent utiliser l'outil Platform Builder de l'environnement de développement intégré de Windows CE pour la configuration et la génération d'une image de système d'exploitation. La ligne de commande n'est plus visible dans l'environnement de développement intégré. Pour définir les variables d'environnement qui seront ensuite utilisées par le système de génération pour inclure les modules et composants appropriés, il suffit de sélectionner des composants dans le catalogue.

Platform Builder, outil de développement de Windows CE, inclut un catalogue de composants dans lequel chaque composant est mis en correspondance avec un ou plusieurs fichiers de catalogue CE (.cec). Ce catalogue est parfaitement évolutif et permet aux développeurs d'ajouter facilement des fichiers .cec supplémentaires qui peuvent être utilisés comme « macro » pour les autres composants plus couramment utilisés. Par exemple, le composant .NET Compact Framework OS Dependencies peut être considéré comme une macro. Il n'est doté d'aucune fonctionnalité propre, mais peut, par contre, être transformé en quatre composants de système d'exploitation différents, en un pilote de périphérique pour un module BSP spécifique ou en un module BSP complet. Platform Builder comporte également un éditeur graphique .cec qui vous permet de créer entièrement de nouveaux composants, tels que des « macro », ou de personnaliser des composants existants.

Éditeur CEC

Figure 2. Éditeur CEC

Les composants du catalogue sont regroupés par types de technologies associées (multimédia, fichiers systèmes et banque de données, développement d'applications et de services, modules BSP et pilotes). Cette organisation permet au développeur de trouver plus facilement une fonctionnalité spécifique et accélère la procédure d'ajout de cette fonctionnalité à son espace de travail.

Catalogue Platform Builder

Figure 3. Catalogue Platform Builder

Ce catalogue fournit des informations qui ne sont pas directement accessibles à partir de la ligne de commande. Un développeur saura sans aucun doute que la variable SYSGEN_HTTPD doit être définie pour le composant HTTPD Web Server. Cependant, il est peu probable qu'il sache quel(s) processeur(s) est/sont pris en charge, quelle est la taille approximative de ce composant une fois ajouté à une plate-forme et quelles sont les autres dépendances système requises pour fonctionner avec ce composant.

Par exemple, l'outil Platform Builder de l'environnement de développement intégré associe un certain nombre de fonctionnalités au composant .NET Compact Framework. Si un développeur clique avec le bouton droit de la souris sur un composant du catalogue, puis sélectionne Properties pour ouvrir la boîte de dialogue illustrée à la Figure 4, il voit apparaître les détails suivants :

  • nom du composant tel qu'il apparaît dans le catalogue ;
  • nom du fournisseur et date de création du composant ;
  • numéro de version du composant ;
  • taille approximative du composant (celle-ci peut varier selon le type de processeur).

Composant .NET Compact Framework

Figure 4. Composant .NET Compact Framework

La boîte de dialogue Feature Properties contient trois onglets. Le premier affiche la taille et le nom de la plate-forme. Le deuxième indique la ou les variable(s) d'environnement qui devra/ont être définie(s) si ce composant est ajouté à la plate-forme. Pour le composant .NET Compact Framework, il s'agit de la variable SYSGEN_DOTNET, exactement la même que celle utilisée lors d'une génération à partir d'une ligne de commande.

Variable d'environnement .NET Compact Framework

Figure 5. Variable d'environnement .NET Compact Framework

Le troisième onglet répertorie les UC (la plupart des pilotes spécifiques à un matériel indiquent uniquement l'UC prise en charge par la fonctionnalité) et les types de configuration de la plate-forme pris en charge par cette fonctionnalité. Il existe schématiquement deux types de plate-forme : les configurations contrôlées à distance (HLBASE) et les configurations à affichage (IABASE). Notez que le composant .NET Compact Framework est uniquement pris en charge par les équipements IABASE, dotés d'une interface utilisateur.

Configurations prises en charge

Figure 6. Configurations prises en charge

Une autre fonctionnalité intéressante de l'outil de développement Platform Builder est qu'il est possible d'obtenir des informations sur les dépendances d'un composant. À chaque fonctionnalité répertoriée dans le catalogue correspond des informations sur ses dépendances, qui sont présentées de la façon suivante :

  1. Depends On    Les composants de cette liste sont indispensables pour que le composant sélectionné puisse fonctionner. Comme illustré ci-dessous, le composant .NET Compact Framework a besoin des composants C++ Exception Handling, Crypto API, Windows Internet Services et OS Dependencies.
  2. Dependency Of    Les composants de cette liste ont besoin du composant sélectionné. Comme illustré ci-dessous, le composant .NET Compact Framework dépend des composants Microsoft SQL Server™ 2000 .NET Data Provider et SQL Server CE 2.0 .NET Data Provider.

Dépendances du composant

Figure 7. Dépendances du composant

Conclusion

Depuis le lancement de Windows CE 2.0 en 1998, le nombre de processeurs, de plates-formes de référence matérielle et de technologies pris en charge n'a cessé d'augmenter. Les outils utilisés pour configurer, générer, télécharger et déployer les systèmes d'exploitation Windows CE ont également été considérablement améliorés. Ils offrent désormais de meilleures capacités d'extension vers les modules BSP de prise en charge des cartes et vers les pilotes et composants tiers (via les fichiers .cec). Ils autorisent également une personnalisation complète d'une plate-forme, grâce à l'utilisation de divers assistants, du catalogue Platform Builder et des informations sur les dépendances d'un composant. Windows CE .NET 4.2 fournit tous les outils et toutes les fonctionnalités du système d'exploitation nécessaires pour générer et déployer rapidement des systèmes embarqués « intelligents ».

Ressources supplémentaires

Pour obtenir davantage d'informations sur CE .NET, consultez le site Web Windows Embedded.

Pour obtenir la documentation en ligne et l'aide contextuelle de Windows CE .NET, consultez la documentation de Windows CE .NET (Lien externe au site MSDN France Site en anglais).



Dernière mise à jour le jeudi 18 septembre 2003

Afficher:
© 2015 Microsoft