Windows CE 6.0 R3 Build System Series – 5. I tool di build

Come già detto negli articoli precedenti, il Platform Builder costituisce esclusivamente un’interfaccia grafica verso il sistema di build che è in realtà costituito da una serie di tool (file eseguibili) e di script (file batch) che possono essere eseguiti anche da linea di comando.

In questo articolo, darò una breve descrizione del ruolo di ciascun tool in gioco, per poi approfondirne il comportamento negli articoli successivi.

Preparazione del build system

Per poter eseguire correttamente il build dell’immagine del sistema operativo, è necessario che il build system sia opportunamente configurato ed inizializzato, settando le variabili di ambiente necessarie. Per tale scopo entrano in gioco i due seguenti file batch :

• PBInitEnv.bat : l’acronimo del suo nome è autoesplicativo, ossia “Platform Builder Initialization Environment”. Esso viene eseguito in automatico dal Platform Builder quando lanciamo un’azione di build oppure nel caso in cui vogliamo eseguire delle operazione a linea di comando ed utilizziamo la voce “Open Release Directory in Build Window” dal menu Build. Il suo scopo è quello di settare le principali Environment Variable (es. _WINCEROOT, _FLATRELEASEDIR, …), nonchè le Sysgen Variable associate ai componenti selezionati nel Catalog Items e quelle relative alla BSP per i driver inclusi nell’immagine. Tale file viene sempre modificato ogni qual volta aggiungiamo/rimuoviamo componenti dall’immagine, perché a tali azioni corrisponde il set o meno di una variabile. Si trova al percorso %_PROJECTROOT%;
• wince.bat : viene invocato dal PBInitEnv.bat per settare altre variabili di carattere generale e soprattutto per inizializzare il _DEPTREES, la variabile che conterrà l’elenco delle cartelle sulle quali eseguire le operazioni di Sysgen e Build. Si trova al percorso %_PUBLICROOT%\COMMON\OAK\MISC;
• %_TGTPROJ%.bat : file batch che non è sempre presente ma che può essere creato dallo sviluppatore al percorso %_PROJECTROOT% per eseguire eventuali azioni custom. Esso è invocato dal wince.bat;

System Generation (SysGen)

La generazione dell’immagine viene eseguita attraverso una serie di file batch invocati in maniera gerarchica l’uno dopo l’altro e sono i seguenti :

• blddemo.bat : è il primo batch ad essere lanciato e coordina l’esecuzione di tutti gli altri batch. Si trova al percorso %_PUBLICROOT%\COMMON\OAK\MISC;
• cebuild.bat, sysgen.bat e cesysgen.bat : sono lanciati dal blddemo.bat in un’opportuna sequenza ed eseguono le operazioni di filtraggio dei componenti sulla base delle Sysgen e BSP Variable settate. Inoltre, invocano i tool di compilazione. Si trovano tutti al percorso %_PUBLICROOT%\COMMON\OAK\MISC;

Compilazione

Per quanto riguarda il processo di compilazione vero e proprio dei file sorgenti scritti in codice C, C++ o ASSEMBLER e la relativa generazione di librerie statiche, dinamiche e di file eseguibili, i tool in gioco sono i seguenti :

• build.exe : invocato dal sistema di build su ciascuna directory da compilare, questo tool esegue l’operazione di attraversamento della directory stessa nelle sue varie sottocartelle, utilizzando il file dirs contenuto in essa. Tale file specifica quali sottocartelle vanno analizzate a partire dalla cartella corrente. Ovviamente ciascuna sottocartella potrà contenere un file dirs e così via, creando proprio una gerarchia di attraversamento delle cartelle. Si trova al percorso %_PUBLICROOT%\COMMON\OAK\BIN\I386;
• nmake.exe : viene invocato dal tool build.exe su uno specifico target (contenuto di una cartella) da buildare, durante le operazioni di attraversamento delle directory. Esso utilizza un makefile per le operazioni di compilazione ed invoca a sua volta i vari compilatori C, C++ (cl.exe) ed ASSEMBLER (armasm.exe, ml.exe, ..) nonchè il linker (link.exe). Tutti questi tool si trovano al percorso %_WINCEROOT%\SDK\BIN\I386 considerando che l’nmake.exe è unico, mentre i compilatori ed i linker sono distinti per architettura in più sottocartelle (X86, ARM, MIPS, SH) poiché ovviamente le operazioni di compilazione e link variano a secondo del processore;

Release e make dell’immagine

La generazione si conclude con la copia dei componenti nella release directory e con la creazione del file binario NK.bin. I tool in gioco sono :

• buildrel.bat : ha il compito di copiare tutte le librerie e gli eseguibili nella _FLATRELEASEDIR, prelevandole dai percorsi relativi al progetto ed alla BSP sulla base del filtraggio dei componenti eseguito. Si trova al percorso %_PUBLICROOT%\COMMON\OAK\MISC;
• makeimg.exe : tool finale che ha il compito di generare il file binario dell’immagine (NK.bin) utilizzando le informazioni dei file .bib, .reg, .dat e .db. Si trova al percorso %_PUBLICROOT%\COMMON\OAK\BIN\I386;
• fmerge.exe : invocato dal makeimg.exe, ha il compito di eseguire il merge dei file .bib, .reg, .dat e .db. Si trova al percorso %_PUBLICROOT%\COMMON\OAK\BIN\I386;
• regcomp.exe : lanciato dal makeimg.exe, ha il compito di generare il file compresso del registro di sistema e dell’hive registry a partire dal reginit.ini. Si trova al percorso %_PUBLICROOT%\COMMON\OAK\BIN\I386;
• res2exe.exe : lanciato dal makeimg.exe, esegue la localizzazione delle risorse dell’immagine. Si trova al percorso %_PUBLICROOT%\COMMON\OAK\BIN\I386;
• romimage.exe : ultimo tool, lanciato dal makeimg.exe, per la creazione del file binario finale (NK.bin). Si trova al percorso %_PUBLICROOT%\COMMON\OAK\BIN\I386;

Windows Phone 7 : dov’è il mio aggiornamento ?

La Microsoft ha reso disponibile una pagine denominata Where’s my phone update ?attraverso la quale è possibile seguire lo stato degli aggiornamenti attraverso le varie fasi :

• Testing : l’update è stato fornito agli operatori mobili ed è in fase di test;
• Scheduling : il test degli operatori mobili è stato completato e la Microsoft sta schedulando il rilascio. Tipicamente questa fase dura circa 10 giorni o anche meno;
• Delivering update : Microsoft ha avviato il processo di rilascio dell’aggiornamento. Tenendo conto che il sistema di rilascio non è di massa su tutti gli utenti ma a blocchi, potrebbero passare anche alcune settimane prima di ricevere la notifica sul proprio terminale;

L’inaugurazione è ovviamente legata all’update “NoDo” atteso ormai da settimane da tutti gli utenti Windows Phone 7 ma nella tabella viene riportato anche lo stato dell’aggiornamento di Febbraio (pre-update) che in alcuni paesi e con alcuni operatori non è stato ancora eseguito.

Quindi non ci resta che domandarci….”dov’è il mio aggiornamento !??”

Windows CE 6.0 R3 Build System Series – 4. Build Phases

Il build dell’immagine di Windows CE è fondamentalmente eseguita in 5 fasi :

• Pre-Sysgen;
• Sysgen;
• Post-Sysgen Build (BSP e Subprojects);
• Build Release Directory;
• Make Run-Time Image;

 

Prima di analizzare nel dettaglio le fasi suddette, farò un breve accenno su quelli che sono i file di configurazione dell’immagine che entrano in gioco durante la compilazione.

Configuration Files

Per la generazione dell’immagine, vengono utilizzate le seguenti quattro tipologie di file di configurazione :

• BIB (Binary Image Builder) : utilizzati per la configurazione della memoria e per specificare i file da includere nell’immagine. La configurazione della memoria è strettamente correlata al target e viene eseguita mediante il file config.bib (%_PLATFORMROOT%\%_TGTPLAT%\FILES). I file da includere vengono specificati attraverso più file relativi al progetto (project.bib in %_PROJECTROOT%\OAK\Files), alla BSP (platform.bib in %_PLATFORMROOT%\%_TGTPLAT%\Files), ai sottoprogetti e per i componenti comuni ed hardware indipendent (common.bib in %_PUBLICROOT%\COMMON\OAK\FILES).
• REG (Registry) : utilizzati per definire le chiavi di registro del sistema. Anche in questo caso, esistono più file relativi al progetto (project.reg), alla BSP (platform.reg) ai sottoprogetti ed alle impostazioni comuni (common.reg);
• DAT (dat files): utilizzati per definire una specifica struttura di directory nel file system, aggiungendo o rimuovendo cartelle e creando eventuali link ai file nella directory \Windows. Come negli altri casi abbiamo il project.dat, platform.dat ed i medesimi file per i componenti hardware indipendent ed i subproject;
• DB (Database) : per l’inizializzazione e creazione di database EDB. Anche in questo caso abbiamo il project.db, platform.db i medesimi file per i componenti hardware indipendent ed i subproject;

Non approfondirò il contenuto dei file suddetti, in quando lo scopo di questa serie di mini articoli è quello di approfondire il sistema di build in relazione ai tools che vengono utilizzati ed al loro scopo.

Pre-Sysgen

Durante questa fase, vengono compilati tutti i codici sorgenti relativi ai componenti all’interno delle directory PUBLIC e PRIVATE, ossia rispettivamente tutto ciò che è hardware indipendet ed il codice sorgente rilasciato da Microsoft. Questa fase NON va mai eseguita, in quanto tali componenti sono rilasciati in forma già compilata al momento dell’installazione del Platform Builder sul PC di sviluppo. Inoltre, se lanciata, impiega anche delle ore per poter eseguire tutte le operazioni di compilazione.

Se si rendesse necessario modificare il comportamento di un componente delle cartelle PUBLIC o PRIVATE, la migliore strada perseguibile è quella del cloning del componente stesso all’interno della directory della BSP (sottocartella di PLATFORM), sulla quale stiamo lavorando, oppure nella directory 3RDPARTY.

Sysgen

Questa fase si rende tipicamente necessaria ogni qual volta aggiungiamo o rimuoviamo un catalog item dall’immagine del sistema operativo.

Infatti, essa ha un compito di filtraggio, ossia di individuare solo ed esclusivamente i componenti da noi selezionati rispetto a tutti quelli disponibili nel Catalog Items, e di risolvere anche tutte le possibili dipendenze che ci sono tra gli items stessi. Infatti, durante il build è possibile che alcuni componenti siano inclusi direttamente nell’immagine, seppur non selezionati da noi esplicitamente, in quanto da essi dipendo altri componenti inclusi esplicitamente.

Durante questa fase, l’operazione di filtraggio viene eseguita sui componenti i cui path sono specificati nella variabile _DEPTREES e per ciascuno di essi vengono analizzate le variabiliSYSGEN_XXX settate in modo da includerli nell’immagine.

Il risultato di questa fase, prevede una copia di tutti i componenti hardware indipendent necessari (per selezione esplicita oppure per dipendenza), all’interno delle sottocartelle al percorso %_PROJECTROOT%\cesysgen, evidenziando che tutto ciò che si vuole includere nell’immagine è strettamente correlato al progetto.

In particolare, le sottocartelle interessate saranno :

• oak/lib, sdk/lib, ddk/lib : contengono tutte le librerie statiche (file .lib);
• oak/inc, sdk/inc, ddk/inc : contengono gli headers ed i file .def (esportazione delle funzioni);
• oak/target : contiene tutti i file eseguibili (.exe) e le librerie dinamiche (.dll);

Post-Sysgen Build

In questa fase, vengono compilati tutti i codici sorgenti relativi alla BSP sulla quale stiamo lavorando e corrispondenti ai componenti che abbiamo selezionato. In particolare, vengono trattati i drivers del target device che vengono compilati utilizzando anche eventuali file headers e librerie statiche (.lib) filtrate nella fase precedente.

Inoltre, subito dopo, viene eseguita la compilazione dei subproject dell’OS design.

Al termine di questa fase, i componenti compilati, tipicamente librerie dinamiche o eseguibili, saranno disponibili in corrispondenza di alcune sottocartelle al percorso %_PLATFORMROOT%\%_TGTPLAT% (dove %_TGTPLAT% indica la target platform, ossia la BSP), evidenziando che tutto ciò che è stato compilato è relativo alla piattaforma.

In particolare, le sottocartelle interessate saranno :

• lib : contenente tutte le librerie statiche (.lib);
• target : contenente tutte le librerie dinamiche (.dll) ed eventuali eseguibili (.exe);

Build Release Directory

Questa fase ha il compito di copiare nella cartella _FLATRELEASEDIR, tutti i componenti filtrati e compilati nelle fasi precedenti, in modo da individuare un unico percorso nel quale attraverso l’ultima fase sia possibile generare il file binario dell’immagine.

In realtà, in luogo dell’operazione di copia fisica, vengono utilizzati gli hard links su volumi NTFS. E possibile comunque forzare la copia settando la variabile BUILDREL_USE_COPY (attraverso le Build Options”).

I file da copiare sono prelevati ai percorsi specificati nelle fasi precedenti ma ad essi vanno aggiunti i file di configurazione del sistema (.bib, .reg, .dat, .db) più altri eventuali file che vogliamo includere (es. immagini, documenti, …). Essi vengono tipicamente prelevati da :

• %_PROJECTROOT%\OAK\Files : tipicamente i file project.bib, project.reg, project.dat e project.db;
• %_PLATFORMROOT%\%_TGTPLAT%\Files : tipicamente i file config.bib, platform.bib, platform.reg, platform.dat, platform.db ed eventuali altri file che vogliamo includere;
• %_PUBLICROOT%\COMMON\OAK\FILES : generalmente i file common.bib, common.reg, common.dat, common.db;

Make Run-Time Image

Durante questa fase, il contenuto della _FLATRELEASEDIR viene assemblato in modo da costituire il file binario dell’immagine : NK.bin. Il tool in gioco è il makeimg.exe che a sua volta utilizza altri tool esterni.

In primo luogo viene lanciato il tool Fmerge.exe che esegue il merge dei file di configurazione nel modo seguente :

• file .bib sono fusi nell’unico file ce.bib;
• file .reg sono fusi nell’unico file reginit.ini;
• file .dat sono fusi nell’unico file initobj.dat;
• file .db sono fusi nell’unico file initdb.ini;

Viene eseguita anche l’operazione di localizzazione dell’immagine in accordo con il linguaggio selezionato (variabile LOCALE).

Infine, viene utilizzato il tool romimage.exe che analizza il file ce.bib per determinare i file da includere nell’immagine e quindi generare il file NK.bin.

Expression Blend 4 : errore di build “Debug|MCD is invalid”

Iniziando ad utilizzare Expression Blend 4 per lo sviluppo della UI di applicazioni su Windows Phone 7, mi sono imbattuto nel seguente errore in fase di compilazione :

The specified solution configuration “Debug|MCD” is invalid.

come riportato in maniera completa nella figura seguente

Per risolverlo, è necessario navigare attraverso il Registry Editor alla seguente percorso :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

e cancellare il valore MPD dalla chiave Platform.

Fatto ciò, il progetto in Expression Blend, compilerà correttamente.

Windows CE 6.0 R3 Build System Series – 3. Tree structure

Nell’ambito del build system di Windows CE, entra fortemente in gioco  la struttura delle directory (tree structure) all’interno della quale troviamo :

• il codice sorgente Microsoft e delle BSP installate;
• i tool per il build dell’immagine del sistema operativo;
• i file batch e gli script relativi al sistema di build;
• i componenti compilati (librerie statiche .lib, librerie dinamiche .dll ed eseguibili .exe);
• i file di configurazione dell’immagine (file di registro, file di database, …);
• l’immagine definitiva in formato binario;

Per poter comprendere al meglio il sistema di build, è utile se non necessario, conoscere bene la struttura delle directory di installazione del Platform Builder, considerando che vengono utilizzate anche delle variabili di ambiente per poter fare riferimento ad una directory piuttosto che ad un’altra.

Di seguito un elenco di tutte le variabili suddette e le directory associate con il relativo scopo :

• _WINCEROOT : è la directory root e tipicamente C:\WINCE600;
• _PUBLICROOT : è la directory PUBLIC al percorso %_WINCEROOT%\PUBLIC, all’interno della quale troviamo tutti i componenti hardware indipendent del sistema operativo;
• _PRIVATEROOT : è la directory PRIVATE al percorso %_WINCEROOT%\PRIVATE, nella quale troviamo il codice sorgente del sistema operativo se durante l’installazione del Platform Builder abbiamo selezionato la feature “Shared Source” accettando il relativo license agreement;
• _PLATFORMROOT : è la directory PLATFORM al percorso %_WINCEROOT%\PLATFORM, nella quale ci sono tutte le BSP installate (sia quale incluse di default durante l’installazione che quelle aggiunte successivamente perché fornite dal vendor del nostro target device). In ciascuna sottodirectory troviamo i drivers, l’implementazione dell’OAL, il bootloader ed i file di configurazione per la specifica BSP. E’ da segnalare anche la presenza della sottocartella COMMON, con del codice sorgente comune a più piattaforme;
• _PROJECTROOT : è la directory nella quale troviamo tutti i componenti compilati e filtrati nell’ambito del nostro OS design (tutto ciò che abbiamo deciso di includere), pronti per essere inclusi nell’immagine del sistema operativo. Ovviamente, è strettamente legata al nostro progetto e sarà  del tipo %_WINCEROOT%\OSDesigns\<MyOSDesignSolution>\<MyOSDesignProject>\Wince600\<MyOSDesign>_<TargetCPU>;
• _FLATRELEASEDIR : è la directory nella quale, al termine del build troviamo tutti i file che sono stati inclusi nell’immagine ed il file binario dell’immagine stessa. E’ ovviamente relativa al nostro progetto, ed avrà un percorso del tipo %_WINCEROOT%\OSDesigns\<MyOSDesignSolution>\<MyOSDesignProject>\RelDir\;

Per quanto riguarda invece i percorsi in cui trovare i tool e gli script del sistema di build :

• %_WINCEROOT%\PUBLIC\COMMON\OAK\BIN\I386 : qui troviamo tutti i tool necessari quali build.exe, makeimg.exe, fmerge.exe e così via;
• %_WINCEROOT%\PUBLIC\COMMON\OAK\MISC : contiene tutti i file batch utilizzati dal sistema di build;

Windows CE 6.0 R3 Build System Series – 2. Sysgen ed Environment Variables

Il design dell’immagine di Windows CE viene tipicamente eseguito utilizzando l’IDE Platform Builder e selezionando i componenti che vogliamo includere nell’immagine stessa attraverso il Catalog Items. Ebbene, ogni qual volta aggiungiamo o eliminiamo un componente dal progetto, l’IDE non fa nient’altro che settare o eliminare una variabile di ambiente associata al componente in oggetto.

Ad esempio, immaginiamo di voler includere nell’immagine il componente che permette l’installazione dei file .cab. Tale componente lo troveremo nel Catalog Items al seguente percorso : Core OS –> CEBASE –> Applications – End User –> CAB File Installer/Uninstaller. Ad esso è associata l’inclusione dell’eseguibile wceload.exe all’interno dell’immagine.

Se selezioniamo tale componente ed analizziamo la finestra delle proprietà, possiamo osservare che ad esso è associata una Sysgen Variable denominata SYSGEN_WCELOAD.

In corrispondenza di tale selezione, il Platform Builder modifica il contenuto del file batchPBInitEnv.bat al percorso %_PROJECTROOT% (che vedremo in futuro) che sarà ad del tipo C:\WINCE600\OSDesigns\<MyOSDesignSolution>\<MyOSDesignProject>\Wince600\<MyOSDesign>_<TargetCPU>. Nell’immagine che esegue, è evidenziata in giallo la variabile settata attraverso l’istruzione di set.

Le Sysgen Variables non sono le uniche variabile ad essere settate durante il design di un’immagine ma ce ne sono altre legate alla BSP del target device, legate al progetto ed alle configurazioni di carattere generale sull’immagine stessa. Complessivamente, abbiamo :

• SYSGEN_XXX : variabile associate ai componenti del sistema operativo da poter includere o meno nell’immagine;
• BSP_XXX, BSPNO_XXX : variabili associate ai componenti della BSP del target device. Esse possono essere relative all’inclusione di un driver oppure ai settings strettamente legati alla piattaforma per la quale stiamo sviluppando;
• IMG_XXX, IMGNO_XXX : variabili associate alla configurazione dell’immagine del sistema operativo. Esse vengono tipicamente settate nell’ambito delle Build Options. Un esempio tipico è l’inclusione o meno del KITL e del debugger nell’immagine; il primo attraverso la build option “Enable KITL” associato al set della variabileIMGNOKITL mentre il secondo attraverso la build option “Enable kernel debugger”associato al set della variabile IMGNODEBUGGER;
• PRJ_XXX : variabili strettamente legate al progetto corrente di design dell’imagine;

Tipicamente le BSP e Project Variables vengono settate attraverso la tab delle Environment Variables nella finestra delle proprietà del progetto.

In definitiva, la definizione o meno di tutte le variabili in gioco confluisce sempre nel file PBInitEnv.bat attraverso un’istruzione di set. Come vedremo, quindi, tale file è utilizzato per predisporre il sistema al build, poichè contiene al suo interno i setting relativi ai componenti che vorremo includere nell’immagine. Proprio per questo il suo nome ha il significato di Platform Builder Initialization Environment.

Windows CE 6.0 R3 Build System Series – 1. Introduzione

Con questa breve introduzione, inizia una serie di miniarticoli dedicati al sistema di build del Platform Builder per Windows CE 6.0 R3 (anche se ciò che dirò è fondamentalmente valido sia per la versione precedente, Windows CE 5.0, che quella successiva appena uscita, Windows Embedded Compact 7).

Attraverso il Platform Builder, come plugin di Visual Studio 2005, abbiamo la possibilità di realizzare un OS design, definendo quelli che sono i componenti che dovranno essere inclusi nell’immagine del sistema operativo ed i drivers da utilizzare sulla base del target device sul quale l’immagine sarà calata (usufruendo della BSP relativa al target device stesso). Come sappiamo, l’inclusione di componenti e drivers, nonché la configurazione di alcune impostazioni dell’immagine, si concretizza nella definizione di una serie di environment variables che verranno successivamente interpretate dal sistema di build per determinare cosa includere o meno nell’immagine finale. Al termine di tale configurazione, attraverso l’IDE, possiamo avviare la compilazione che ha il compito di generare il file NK.bin, rappresentativo dell’immagine stessa.

Ebbene, le features che l’IDE ci mette a disposizione non fanno altro che utilizzare una serie di tool e di file batch che compongono l’effettivo sistema di build. In pratica, un’immagine di Windows CE può essere generata anche senza l’utilizzo del Platform Builder ma settando opportunamente le environment variables associate ai componenti che vogliamo includere ed avviando nel modo opportuno i tool ed i batch di cui sopra.

In conclusione, il build system altro non è che un repository di tool (tipicamente file .exe), scripts, file batch e codice sorgente, attraverso il quale lo sviluppatore può compilare un’immagine di Windows CE. Il Platform Builder è “semplicemente” un IDE costruito al di sopra di esso, fornendo esclusivamente la semplicità che una UI può dare rispetto all’utilizzo della più ostica ma affascinante riga di comando.

Nel prossimo articolo, vedremo che cosa significa progettare un’immagine (scelta dei componenti, drivers e relativa configurazione) in relazione all’inizializzazione del sistema di build e come questa operazione sia possibile eseguirla manualmente oppure attraverso l’IDE.

WP7 : WebBrowserTask launcher … nasconde la pagina

Attraverso il launcher WebBrowserTask, è possibile lanciare il browser IE dalla nostra applicazione in WP7, specificando anche un URL dal quale avviare la navigazione. Tutto ciò è possibile con le seguenti semplici righe di codice :

WebBrowserTask web = new WebBrowserTask();
web.URL = "http://www.google.it";
web.Show();

Se inseriamo questo codice all’interno dell’event handler relativo, ad esempio, all’evento di click di un bottone, l’esecuzione in modalità debug (F5) all’interno dell’emulatore ci darà il seguente risultato :

Osserviamo (ed è evidenziato in rosso), che l’icona relativa al numero dei tab aperti indica che ce ne sono 2. Infatti, se clicchiamo su di essa, osserviamo la presenza dell’altro tab con la pagina da noi richiesta.

Ebbene, questo strano comportamento si evidenzia sull’emulatore e soltanto nella modalità di debug. Infatti, se lanciamo direttamente l’applicazione (senza debug con CTRL + F5), il browser si aprirà direttamente con la pagina da noi specificata.

Windows Embedded CE 6.0 R3 QFEs : Febbraio 2011

Sono stati rilasciati i QFEs di Febbraio 2011 per Windows Embedded CE 6.0 R3 e sono scaricabili al seguente indirizzo :

Windows Embedded CE 6.0 Monthly Update February 2011

Riporto di seguito i principali fix, come descritto nel file allegato al download :

Component:  ASN1

• 110207_KB2477769 – This update resolves some issues with ASN1 module.

Component:  CETK

• 110225_KB2444533 – This release installs updated CETK test files.
• 110224_KB2495864 – This update addresses an error that may occur when radiometricsdll is launched.

Component:  DirectX

• 110214_KB2495868 – Memory leak may occur when using ceplayer.exe to play AVI and WMV files through playlist with repeat playback option.

Component:  Filesys

• 110211_KB2495580 – This update addresses a possible deadlock.

Component:  Flash Lite

• 110222_KB982918 – This update addresses an issue with flash not rendering under certain circumstances.

Component:  FSD

• 110209_KB2492043 – An exception may occur when unplugging and external storage device while playing a file from it.

Component:  Internet Explorer

• 110221_KB2450800 – Screen is not properly redrawn in Internet Explorer if a floating window is shown inside a window and scrollbars are moved.

Component:  NK

• 110211_KB982563 – This update implements L2 cacheable page table support for ARM processor.

Component:  Pictor

• 110224_KB2465661 – This update adds registry entries to support custom resolution entries for Pictor screen.

Component:  RDP

• 110210_KB2175812 – When connecting from a Windows Embedded CE 6.0 R3 device to Windows 2003 server or later, the state of the CAPS LOCK/NUM LOCK keys may not be correctly updated from the RDP client device to the terminal server.

Windows Phone 7 Emulator : keyboard shortcuts

Per poter utilizzare la testiera del computer host nell’ambito dell’emulatore di Windows Phone 7, ci sono degli shortcuts da poter utilizzare :

• F1 : tasto Back;
• F2 : tasto Start;
• F3 : tasto Search;
• Page Up / Page Down : permettono di passare dall’uso della tastiera del computer host alla tastiera dell’emulatore.

Per quanto riguarda l’utilizzo della tastiera del computer host per poter scrivere nelle TextBox, è necessario attivare la TextBox e premere PageUp per far scomparire la tastiera dell’emulatore ed utilizzare quella fisica. Per poter riattivare la tastiera dell’emulatore è però necessario disattivare prima la TextBox (premendo in un qualsiasi punto dell’applicazione) e poi premere Page Down. Successivamente, riattivando la TextBox, la tastiera dell’emulatore comparirà automaticamente.