DevExperience

.Net Framework, Internet of Things & M2M, Embedded Systems, Design Patterns Paolo Patierno's Blog

MVP Award

I'm Microsoft MVP for Windows Embedded

Recent Posts

Apps & Articles

Progetti

Pubblicazioni

Tags

My Profiles

 

My Embedded101 Blog

My YouTube Channel

Windows Embedded CE 6.0

Building Embedded Devices using Windows Embedded CE 6.0 R2

Archives

Sto leggendo...

Windows Embedded

.Net Micro Framework

.Net Framework & CLR

Email Notifications

Open Source Hardware

RSS Blog Post

marzo 2011 - Post

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;

 

buildsystem

Posted: 31 mar 2011 8:19 da Paolo | con no comments
Inserito sotto:
Windows Phone 7 : dov’è il mio aggiornamento ?

wp7_update

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 !??”

Posted: 29 mar 2011 13:28 da Paolo | con no comments
Inserito sotto:
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;

build_phases

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 variabili SYSGEN_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.

Posted: 29 mar 2011 9:26 da Paolo | con no comments
Inserito sotto:
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

BuildError1

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.

BuildError2

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

BuildError3

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;
Posted: 25 mar 2011 8:39 da Paolo | con no comments
Inserito sotto:
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.

wceload

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

wceload_props

In corrispondenza di tale selezione, il Platform Builder modifica il contenuto del file batch PBInitEnv.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.

wceload_sysgen

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 variabile IMGNOKITL 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.

Posted: 24 mar 2011 8:47 da Paolo | con no comments
Inserito sotto:
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.

Posted: 23 mar 2011 8:49 da Paolo | con no comments
Inserito sotto:
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 :

   1: WebBrowserTask web = new WebBrowserTask();
   2: web.URL = "http://www.google.it";
   3: 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 :

wbt1

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.

wbt2

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.

Posted: 18 mar 2011 15:51 da Paolo | con no comments
Inserito sotto:
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

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

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.

Posted: 17 mar 2011 12:00 da Paolo | con no comments
Inserito sotto:
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.

wp7_emulator

Posted: 11 mar 2011 18:55 da Paolo | con no comments
Inserito sotto:
Windows Phone 7 Developer Tools Update (Gennaio 2011) : installazione terminata… fantasma !

Questa sera ho deciso ed ho avuto finalmente il tempo di installare l’update rilasciato a Gennaio per i Windows Phone 7 Developer Tools che possiamo scaricare qui.

Sembra che il pacchetto di installazione abbia però qualche problema; infatti una volta avviato, la schermata relativa all’installazione rimane attiva per parecchi minuti dopodiché si chiude senza segnalarne il completamento in maniera corretta o con errori.

Ebbene….sembra che sia normale !

Per verificare che l’update sia stato installato correttamente, basta andare nel Pannello di Controllo –> Programmi e Funzionalità –> Aggiornamenti installati e verificare che compaia la seguente voce :

Microsoft Windows Phone 7 Developer Resources – January 2011 Update

In questo caso, l’installazione è terminata correttamente !

Posted: 10 mar 2011 21:33 da Paolo | con no comments
Inserito sotto:
Windows Embedded CE 6.0 : Cloning public component

Introduzione

L’installazione di Windows CE 6.0 R3 prevede la distribuzione dei codici sorgenti e dei file binari nelle tre seguenti sottocartelle della root di installazione (variabile d’ambiente _WINCEROOT, tipicamente C:\WINCE600) :

  • PRIVATE : codice sorgente del sistema operativo (Microsoft Shared Source);
  • PUBLIC : componenti hardware indipendent, ossia che non hanno alcun legame con il target device su cui l’immagine del sistema operativo sarà calata;
  • PLATFORM : tutte le BSP (Board Support Package) installate e quindi tutto ciò che è hardware dipendent (OAL, drivers, bootloader e file di configurazione per una specifica board);

Capita in molti casi di voler modificare uno o più componenti pubblici; ovviamente questa è un’operazione da non fare assolutamente per i seguenti principali motivi :

  • La Microsoft rilascia mensilmente i pacchetti di aggiornamento QFE (Quick Fix Engineering), che potrebbero sovrascrivere le vostre modifiche, qualora l’update interessasse proprio un componente pubblico da voi modificato;
  • Sviluppando progetti diversi per target device differenti, vorreste poter mantenere il componente pubblico originario per alcuni progetti e quello modificato per altri; l’unica soluzione sarebbe quella di creare più copie della cartella PUBLIC (es. PUBLIC_OSDesign1, PUBLIC_OSDesign2, …);
  • Ultima ma non meno importante motivazione è legata al fatto che modificando il contenuto della cartella PUBLIC, l’operazione di build dell’immagine può impiegare anche alcune ore;

La tecnica che viene utilizzata in questi casi, prevede la clonazione (cloning) del componente da voler modificare. Di seguito affronteremo le varie fasi di questa operazione, supponendo di voler modificare l’applicazione ping.exe (appunto un componente pubblico) per apportarvi delle modifiche.

In alcuni casi, questa attività può essere eseguita direttamente dall’ambiente di sviluppo cliccando con il tasto destro sul componente nella Catalog Items View e selezionando dal menù contestuale la voce “Clone Catalog Item”. Questa semplice funzionalità non è sempre disponibile e per questo motivo, esporrò quella la tecnica più lunga e complessa ma l’unica da poter adottare in tutti gli altri casi.

Prima di iniziare, sottolineo che nel mio ambiente ho clonato la BSP del device emulator (creando la cartella %_WINCEROOT%\PLATFORM\DEVICEEMULATOR_CLONE); questa è un’operazione che va sempre fatta nel momento in cui si inizia un progetto per un nuovo target device e si vuole adottare una certa BSP. In questo modo, potremmo modificare la BSP clonata senza alterare quella originale che potrà essere ulteriormente clonata per altri progetti. L’operazione di clonazione di una BSP è possibile utilizzando la seguente voce di menù Tools –> Platform Builder for CE 6.0 –> Clone BSP.

Copia dei codici sorgenti

Il primo passo prevede la copia del componente da clonare all’interno di una cartella della nostra BSP. Nella fattispecie, l’applicazione ping.exe si trova al seguente percorso :

%_WINCEROOT%\PUBLIC\COMMON\OAK\DRIVERS\NETSAMP\PING

Tipicamente, nell’eseguire il cloning, si preferisce separare la cartella contenente i codici sorgenti , attraverso la quale verrà generata una libreria statica (.lib), dalla cartella con le direttive per la compilazione dell’eseguibile (.exe) ottenuto linkando la libreria statica suddetta e tutte le altre eventuali librerie di cui necessita il componente clonato.

Nel nostro caso, suppongo di voler clonare il componente al seguente percorso :

%_WINCEROOT%\PLATFORM\DEVICEEMULATOR_CLONE\SRC\APPS

Creiamo in corrispondenza di esso, una sottocartella PING e due relative sottocartelle : src ed exe. All’interno della prima cartella, copiamo tutto il contenuto della cartella PING originale.

cloning1

cloning2

Compilazione della libreria statica

A questo punto, è necessario modificare il file sources della nuova directory copiata (PING\src), aggiungendo la linea RELEASETYPE=PLATFORM oppure modificando il valore di RELEASETYPE a PLATFORM se essa già esiste. Questa opzione è necessaria per fare in modo che il componente compilato, venga poi copiato in una sottocartella della directory %_TARGETPLATROOT% che contiene i componenti eseguibili strettamente legati alla BSP. Nel nostro esempio abbiamo che %_TARGETPLATROOT% sarà C:\WINCE600\PLATFORM\DEVICEEMULATOR_CLONE e che la riga suddetta va aggiunta.

Inoltre va aggiunta l’impostazione WINCEOEM=1 che è necessaria ogni qual volta un componente utilizza dei file headers e delle librerie statiche che sono nella cartella PUBLIC. In questo modo, evitiamo errori sia in fase di compilazione che linking.

cloning3

Siamo pronti per eseguire il build per generare la libreria statica ping.lib. Affinché la nuova cartella creata sia visibile dal Solution Explorer in Visual Studio 2005, è necessario creare nella cartella PING un nuovo file dirs come riportato in figura.

cloning4

cloning5

A questo punto dal Solution Explorer, possiamo compilare la libreria.

cloning6

NOTA : la presenza di (excluded from build) al fianco della cartella PING denota che tale cartella non è stata definita nella direttiva DIRS del file dirs della cartella apps; ciò vorrà dire che, per il momento, il componente sarà possibile compilarlo solo manualmente e non rientrerà nell’operazione di build complessivo dell’intera immagine.

L’operazione di build genera il file ping.lib all’interno di una sottocartella del percorso %_TARGETPLATROOT%\lib ed in particolare in C:\WINCE600\PLATFORM\DEVICEEMULATOR_CLONE\lib\ARMV4I\debug (dove ARMV4I indica la CPU target e debug indica la configurazione di build che sto adottando).

Utilizzo del tool Sysgen Capture

Poiché un componente pubblico può avere una serie di dipendenze da altri componenti, per evitare di dover riscrivere da zero il file sources, ci viene in aiuto il tool Sysgen Capture che esegue l’operazione per nostro conto (maggiori informazioni sono reperibili qui).

Avviamo una shell con tutte le variabili inizializzate dal menu Build –> Open Release Directory in Build Window e andiamo nella cartella %_WINCEROOT%\PLATFORM\DEVICEEMULATOR_CLONE\SRC\APPS\EXE dove ci aspettiamo di poter generare il file definitivo ping.exe. Avviamo il seguente comando :

sysgen_caputer ping

Al termine dell’operazione, troveremo una serie di file generati al percorso suddetto

cloning7

Compilazione del componente

Lasciando inalterati i file originali, facciamo una copia nella stessa cartella del file sources.ping, chiamandola sources ed apriamolo constatandone il seguente contenuto :

cloning8

Come possiamo osservare, il componente ha bisogno di alcune librerie statiche tra cui la ping.lib. Quest’ultima, però, ha il percorso che punta alla libreria statica originale e non a quella precedentemente compilata da noi. E’ quindi necessario modificare tale percorso nel modo seguente :

cloning9

Personalmente, ho preferito non cancellare il riferimento originale ma l’ho incluso in un !if…!endif mai verificato (con condizione a 0). Infine, è necessario un makefile che possiamo prendere ad esempio dalla cartella APPS\PING\src. Tale operazione è lecita, in quanto la maggior parte dei makefile non fanno altro che includere il file makefile.def che troviamo in %_WINCEROOT%\PUBLIC\COMMON\OAK\MISC.

A questo punto possiamo buildare il componente per ottenere il file ping.exe al seguente percorso %_TARGETPLATROOT\target ed in particolare in C:\WINCE600\PLATFORM\DEVICEEMULATOR_CLONE\target\ARMV4I\debug.

Eseguendo esclusivamente l’operazione di Make Runtime Image, il nostro ping.exe verrà incluso nell’immagine del sistema operativo in luogo di quello originale. C’è da sottolineare che l’inclusione avviene in quanto dal Catalog Items ho selezionato il componente originale al seguente percorso Core OS –> Communication Services and Networking –> Networking – General –> Network Utilities con la differenza che il sistema di build ritroverà nella RelDir il nostro componente in luogo dell’originale.

Se non volessimo includere il catalog item suddetto, avremmo due possibili strade :

  • modificare il project.bib oppure il platform.bib per far includere il nostro ping.exe nell’immagine;
  • creare un nuovo catalog item ed includerlo nell’immagine;

Per adesso, seguirò la prima strada e quindi deseleziono le Network Utilities dal Catalog Items (ovviamente perdendo le altre utilities tra cui il tracert) e modifico il platform.bib nel modo seguente :

cloning10

Posted: 4 mar 2011 18:54 da Paolo | con no comments
Inserito sotto:
C# : Implementazione delle interfacce e la derivazione

Supponiamo di avere una semplice interfaccia così definita :

   1: interface IMyInterface
   2: {
   3:     void MyMethod();
   4: }

e di definire una classe che la implementa :

   1: class BaseClass : IMyInterface
   2: {
   3:     public void MyMethod()
   4:     {
   5:         Console.WriteLine("BaseClass.MyMethod()");
   6:     }
   7: }

Supponiamo di voler derivare da quest’ultima una nuova classe per poter eseguire l’override del metodo MyMethod(). Ebbene un’operazione di questo tipo non sarà ovviamente possibile, considerando che ogni metodo di un’interfaccia viene marcata come virtual ma soprattutto come sealed dal CLR.

Il fatto che sia virtual, permette alla classe che implementa l’interfaccia di implementarne il metodo mentre il fatto che sia sealed non ne permette l’override nella classe derivata.

A questo punto le possibili soluzioni sono due :

  • nella BaseClass, marchiamo il metodo come virtual in modo che la classe derivata potrà farne l’override e non avrà bisogno di implementare l’interfaccia. Con questa soluzione perdiamo però lo sviluppo e le invocazioni per interfacce;
  • facciamo in modo che anche la classe derivata implementi l’interfaccia ma a quel punto sarà necessario utilizzare l’operatore new nella dichiarazione del metodo che altrimenti nasconderà quello della classe base. Nella classe base non sarà necessario utilizzare virtual;

Con la prima soluzione abbiamo :

   1: class BaseClass : IMyInterface
   2: {
   3:     public virtual void MyMethod()
   4:     {
   5:         Console.WriteLine("BaseClass.MyMethod()");
   6:     }
   7: }
   8:  
   9: class DerivedClass : BaseClass
  10: {
  11:     public override void MyMethod()
  12:     {
  13:         Console.WriteLine("DerivedClass.MyMethod()");
  14:     }
  15: }

mentre con la seconda :

   1: class BaseClass : IMyInterface
   2: {
   3:     public void MyMethod()
   4:     {
   5:         Console.WriteLine("BaseClass.MyMethod()");
   6:     }
   7: }
   8:  
   9: class DerivedClass : BaseClass, IMyInterface
  10: {
  11:     new public void MyMethod()
  12:     {
  13:         Console.WriteLine("DerivedClass.MyMethod()");
  14:     }
  15: }

A questo punto consideriamo il seguente Main di esempio :

   1: static void Main(string[] args)
   2: {
   3:     BaseClass bClass = new BaseClass();
   4:     bClass.MyMethod();
   5:  
   6:     bClass = new DerivedClass();
   7:     bClass.MyMethod();
   8: }

il cui output sarà il seguente rispettivamente per la prima e per la seconda soluzione :

interface2

interface3

Nel primo caso, il concetto di interfaccia è decaduto passando dalla classe base a quella derivata e quindi invocando la seconda volta bClass.MyMethod() viene giustamente invocata l’implementazione della DerivedClass (in quanto bClass punta ad un’istanza di tale classe).

Nel secondo caso, viene invece invocato sempre il metodo della classe base, in quanto nella DerivedClass, il metodo MyMethod() non è un’override del corrispondente metodo nella classe base ma una nuova versione (operatore new) nell’implentazione dell’interfaccia. Per ovviare a questo comportamento è necessario esplicitare il casting all’interfaccia IMyInterface nella seconda invocazione nel modo seguente :

   1: bClass = new DerivedClass();
   2: ((IMyInterface)bClass).MyMethod();

per cui l’output sarà il seguente :

interface4

Ovviamente, se avessimo utilizzato direttamente un riferimento di tipo DerivedClass per puntare ad un’istanza della stessa DerivedClass, questo cast esplicito non si sarebbe reso necessario.

Posted: 3 mar 2011 8:50 da Paolo | con no comments
Inserito sotto: ,
Windows Embedded Compact 7 : finalmente il rilascio !

wce7

Windows Embedded Compact 7 è stato rilasciaot ieri, 1° Marzo, a New York ed all’ Embedded World di Norimberga.

Tutte le informazioni sono disponibili su questo sito dedicato, anche per scaricare una trial, ed un datasheet è disponibile qui.

Posted: 2 mar 2011 13:19 da Paolo | con no comments
Inserito sotto:
Windows Embedded : il sito si rinnova !

Dal 25 Febbraio, il sito dedicato a tutte le tecnologie embedded della Microsoft ha cambiato volto. Sono aumentate le potenzialità della ricerca all’interno del sito e non è più dedicato esclusivamente al pubblico dei commerciali ma anche agli sviluppatori con numerosi contenuti. Questi ultimi sono organizzati per “Top Tasks”, ossia per argomenti di maggior interesse sulla sviluppo embedded. Infine, va sottolineato che è notevolmente aumentato la mole delle informazioni !

Insomma, un sito tutto da riscoprire !

www.windowsembedded.com

wce_site

Posted: 1 mar 2011 8:11 da Paolo | con no comments
Inserito sotto: