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

febbraio 2011 - Post

Windows Phone 7 : preupdate in vista di “NoDo”

In questa settimana, la Microsoft ha eseguito l’aggiornamento dei dispositivi con Windows Phone 7 con un preupdate in vista di “NoDo”.

Io posseggo un LG Optimus 7 (noto anche come LGE900) e purtroppo sino a stasera, collegandomi in Wi-Fi, non ricevevo alcuna notifica di un aggiornamento disponibile. A questo punto ho pensato di collegare il dispositivo al PC per capire se almeno attraverso Zune, veniva rilevata la presenza dell’aggiornamento previsto. Bingo !!

Zune mi segnala la presenza di una nuova versione, la 7.0.7008.0 in luogo della 7.0.7004.0 presente sul mio dispositivo e mi chiede se avviare l’operazione che può durare sino a circa 25 minuti. Non disperate….almeno nel mio caso è durato non più di 10 minuti !

Complessivamente le fasi sono 10 ma le prime 6 sono rapidissime e tra di esse è previsto il download del pacchetto di aggiornamento ed il riavvio del dispositivo.

Passiamo direttamente alla fase 7, in cui viene eseguito un backup dei dati….

update1

…successivamente si passa alla fase di aggiornamento vero e proprio….

update2

…seguita da un riavvio del dispositivo….

update3

…e finalmente…l’aggiornamento è completato !

update4

Ed ecco il terminale aggiornato.

DSC_0046

Posted: 25 feb 2011 19:55 da Paolo | con no comments
Inserito sotto:
Windows Embedded CE 6.0 R3 QFEs : Gennaio 2011

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

Windows Embedded CE 6.0 Monthly Update January 2011

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

Component:  Cellcore

Component:  CDROM

  • 110112_KB2437113 - This update addresses an issue with CDROM detection and an error that occurs when ejecting CD.

Component:  COMM

  • 110112_KB2484550 - This update addresses an issue with L2TP connection failure through NAT Gateway.

Component:  DirectX

Component:  FSDMGR

  • 110118_KB2482648 - After a suspend-resume operation, any storage volume whose partition type is Microsoft Installable File System (MSIFS) gets remounted as a different volume name. Explorer window to that storage volume gets closed and is inaccessible.

Component:  GDIEX

Component:  Internet Explorer

Component:  RDP

  • 110125_KB2487075 - An error may occur in RDP session if Smart Card redirector is enabled.

Component:  UDFS

Posted: 23 feb 2011 21:43 da Paolo | con no comments
Inserito sotto:
wceTip #1 : Conoscere i valori di tutte le environment variables

Il sistema di build di un’immagine di Windows CE 6.0 si basa su una serie di tool (tipicamente file batch) che eseguono delle azioni sulla base di un insieme di environment variables settate automaticamente quando aggiungiamo i catalog items, BSP drivers e quant’altro oppure che possiamo settare manualmente.

Per conoscerle tutte con i relativi valori, è possibile utilizzare il comando set aprendo il prompt del Platform Builder (in VS2005) alla voce di menu :

Build –> Open Release Directory in Build Window

Di seguito uno screenshot …

wce_set_cmd

Posted: 17 feb 2011 8:23 da Paolo | con no comments
Inserito sotto: ,
MWC 2011 : il multitasking su Windows Phone 7

Eccovi la presentazione di Joi Belfiore al Mobile World Congress 2011 di Barcellona che mostra il futuro multitasking su Windows Phone 7.

Posted: 14 feb 2011 21:42 da Paolo | con no comments
Inserito sotto:
.netTip #1 : Debugging delle properties in Visual Studio

A partire da Visual Studio 2008 è possibile abilitare e disabilitare il debugging all’interno di una property quando utilizziamo il comando di Step Into. In questo modo, possiamo decidere se debuggare step by step le istruzioni che costituiscono le get e set di una property.

L’opzione è disponibile nel seguente menu :

Tools –> Options –> Debugging –> General

alla voce “Step over properties and operators (Managed only)” (io utilizzo sempre la versione inglese di un qualsiasi ambiente di sviluppo).

debug_prop

Di default essa è attiva e ciò vuol dire che durante il debug non saremo in grado di debuggare le singole istruzioni che costituiscono il corpo di una property.

Posted: 14 feb 2011 8:36 da Paolo | con no comments
Inserito sotto: ,
Un approfondimento sulla keyword “params”

Introduzione

In C#, attraverso la keyword params, è possibile specificare un numero variabile di argomenti per un metodo. Una possibilità sicuramente utile, quando vogliamo fornire una certa flessibilità a coloro che lo utilizzeranno. Ma come è gestito dal compilatore e dal CLR l’utilizzo di params ?

Il codice IL generato dal compilatore

Consideriamo il seguente codice, nel quale è definito un semplice metodo che esegue una somma di una serie di valori interi passati attraverso un array :

   1: static int Add(params int[] array)
   2: {
   3:     int sum = 0;
   4:     if (array != null)
   5:     {
   6:         for (int index = 0; index < array.Length; index++)
   7:         {
   8:             sum += array[index];
   9:         }
  10:     }
  11:     return sum;
  12: }

Ciò che osserviamo è l’utilizzo della keyowrd params prima della dichiarazione del parametro.

La tipica modalità con cui chiamiamo un metodo con questa firma è la seguente :

   1: int[] array = new int[] { 1, 2, 3, 4, 5 };
   2: int sum = Add(array);

oppure con una sola istruzione :

   1: int sum = Add(new int[] { 1, 2, 3, 4, 5 });

Ciò che facciamo è definire un array di interi previsto dal metodo Add() e lo passiamo come parametro a quest’ultimo.

Ebbene, attraverso l’utilizzo di params, possiamo evitare di definire un array e passare direttamente l’elenco dei valori dei quali vogliamo eseguirne la somma.

   1: int sum = Add(1, 2, 3, 4, 5);

Che cosa accade dietro le quinte che permette questo tipo di notazione ?

Banalmente, il compilatore genera del codice che alloca l’array e lo passa al metodo !

params

Nella figura precedente, ho evidenziato in rosso la parte di codice IL generata dal compilatore che non fa altro che creare un array con l’elenco dei valori da noi specificati ed invocare il metodo Add().

Nessun argomento ? La differenza di performance …

Detto ciò, consideriamo le due seguenti particolari invocazioni del metodo Add() :

   1: Add();
   2: Add(null);
 
Non è stato definita alcuna serie di valori sui quali eseguire la somma ma le due soluzioni sono nettamente diverse. Se la prima soluzione sembra essere stilisticamente la migliore, è la seconda che invece garantisce le migliori performance. Infatti, nel primo caso, il compilatore genera del codice IL che alloca un array di dimensione 0 mentre nel secondo caso ciò non accade.
 
params2

Possiamo rendercene conto anche eseguendo il debug e constatando che, nel primo caso, l’esecuzione supera il controllo array != null ma non riesce ad entrare nel ciclo for in quanto l’array ha dimensione 0.

params3

Nel secondo caso, il parametro array è null per cui il check suddetto non è superato.

params4

Conclusioni

In definitiva, l’uso di params non è la migliore delle soluzioni per le seguenti motivazioni :

  • viene sempre allocato un array sull’heap;
  • vengono eseguite le operazioni di inizializzazione dell’array;
  • essendo stata allocata memoria heap…c’è sempre il Garbage Collector in gioco;

In molti casi è sempre preferibile definire più overload dello stesso metodo con uno o più parametri e lasciare come ultima possibilità allo sviluppatore l’uso dell’overload con params.

Un esempio noto è il metodo String.Format della BCL che ha i seguenti overload :

  • string String.Format(string format, object arg0);
  • string String.Format(string format, object arg0, object arg1);
  • string String.Format(string format, object arg0, object arg1, object arg2);
  • string String.Format(string format, params object[] args);

In questo modo, lo sviluppatore utilizzerà sempre i primi tre overload fino ad un massimo di 3 parametri. Se necessita di passare un quarto parametro, verrà utilizzato l’ultimo overload con params.

L’individuazione del giusto overload da invocare viene eseguita ovviamente dal compilatore che, in primo luogo verifica se esiste un metodo che non ha params  e che riesce a matchare il numero di parametri passati. Se ciò non dovesse portare ad un risultato, allora il compilatore cerca il match con un metodo che ha una dichiarazione con params.

Posted: 12 feb 2011 16:28 da Paolo | con no comments
Inserito sotto: ,
Windows Phone 7 : aggiornamento rimandato a Marzo ?

windows-phone-7-update

La data del 7 Febbraio, per la quale si era parlato dell’aggiornamento denominato “NoDo” per Windows Phone 7, è ormai passata….e l’aggiornamento non si è visto.

Ufficialmente, Microsoft non ha mai specificato una data precisa per il rilascio ma adesso alcuni rumors indicano come l’8 Marzo la data fatidica.

Sicuramente la marcia di avvicinamento è iniziata con l’aggiornamento al software Zune, necessario per eseguire l’update di Windows Phone 7, e con il rilascio della nuova versione dell’ SDK per gli sviluppatori che contiene anche la funzionalità di copia-incolla.

Sicuramente ne sapremo di più durante il Mobile World Congress che si terrà a Barcellona dal 14 al 17 Febbraio. Potrete seguire online la keynote di Steve Ballmer.

mwlkeynotemicrosoft

Non ci resta che aspettare fiduciosi !

Posted: 11 feb 2011 8:45 da Paolo | con no comments
Inserito sotto:
Ancora un altro free ebook su Windows Phone 7

Per chi vuole iniziare a sviluppare su Windows Phone 7, è disponibile online e scaricabile gratuitamente ancora un altro free ebook.

Free-EBook-Silverlight-for-Windows-Phone

Per il download…cliccate qui !

Posted: 6 feb 2011 20:39 da Paolo | con no comments
Inserito sotto:
Inside “Extension Methods” … call vs callvirt

Capita sempre di dover utilizzare delle classi delle quali non abbiamo il codice sorgente (basti pensare a quelle del .Net Framework) ma sulle quali non possiamo eseguire determinate operazioni in assenza dei corrispondenti metodi. Non abbiamo quindi la possibilità di estenderle e dotarle del nuovo comportamento di cui abbiamo bisogno.

In questi casi, risolviamo il problema implementando tale metodo al di fuori della classe stessa e ad esempio aggiungendolo in una nuova classe statica.

Per esempio, supponiamo di aver bisogno del metodo IndexOf() sulla classe StringBuilder (di cui essa non è dotata). Possiamo realizzare una nuova classe statica all’interno della quale implementiamo tale metodo.

   1: public static class StringBuilderExtensions
   2: {
   3:     public static int IndexOf(StringBuilder sb, char value)
   4:     {
   5:         for (int index = 0; index < sb.Length; index++)
   6:         {
   7:             if (sb[index] == value)
   8:                 return index;
   9:         }
  10:         return -1;
  11:     }
  12: }

Ovviamente, per invocare tale metodo dobbiamo definire un’istanza della classe StringBuilder e passare tale oggetto al metodo statico implementato.

   1: int index;
   2: StringBuilder sb = new StringBuilder("Paolo");
   3: index = StringBuilderExtensions.IndexOf(sb, 'o');
 
Per fortuna, attraverso l’utilizzo degli Extension Methods, abbiamo la possibilità di estendere in maniera naturale una classe ed invocare direttamente sull’istanza dell’oggetto il nuovo comportamento implementato.
L’implementazione di un extension method viene realizzata con la tecnica precedente ma con la differenza nell’aggiungere la parola chiave this davanti al primo parametro del nuovo metodo, per indicare che esso sarà l’oggetto su cui andrà ad agire.
 
   1: public static class StribgBuilderExtensionMethods
   2: {
   3:     public static int IndexOf(this StringBuilder sb, char value)
   4:     {
   5:         for (int index = 0; index < sb.Length; index++)
   6:         {
   7:             if (sb[index] == value)
   8:                 return index;
   9:         }
  10:         return -1;
  11:     }
  12: }
 
Attraverso questa tecnica, l’Intellisense di Visual Studio ci mette a disposizione tale nuovo metodo, direttamente sull’istanza della classe StringBuilder.
 
em_1

A questo punto, possiamo però dimostrare che le due implementazioni sono perfettamente identiche e che la feature degli extension methods è più che altro una facility per lo sviluppatore.

Infatti, invocare un extension method equivale esattamente ad invocare un metodo statico come nel caso precedente con la differenza che non dobbiamo eseguire esplicitamente il passaggio del parametro su cui il metodo andrà ad agire. Basta confrontare le due seguenti invocazioni :

   1: index = StringBuilderExtensions.IndexOf(sb, 'o');
   2: index = sb.IndexOf('o');
 
Sarà il compilatore a generare il codice IL che passa il parametro “sb” all’extension method.
Consideriamo il seguente esempio con il relativo codice IL :
 
   1: static void Main(string[] args)
   2: {
   3:     int index;
   4:     StringBuilder sb = new StringBuilder("Paolo");
   5:     sb.Append("Embedded Life");
   6:     index = StringBuilderExtensions.IndexOf(sb, 'o');
   7:     index = sb.IndexOf('o');
   8: }
 
em_2

Come si può osservare nel codice IL generato, le due invocazioni di IndexOf() sono perfettamente identiche ed il fatto che siano invocazioni di metodi statici lo evidenzia anche l’utilizzo della call al posto della callvirt come nel caso del metodo Append() che è un metodo di istanza della classe StringBuilder.

Infatti, esiste una sostanziale differenza tra call e callvirt :

  • call : può essere usata per l’invocazione di metodi statici, di istanza e virtuali. Tipicamente soprattutto per i metodi statici, preferendo la callvirt agli altri tipi di metodi. Essa assume che l’oggetto su cui viene eseguita la chiamata non sia null e quindi non esegue questo tipo di check;
  • callvirt : utilizzata per l’invocazione di metodi virtuali e di istanza, quindi non viene mai utilizzata per i metodi statici. Essa esegue sempre un check per verificare che l’oggetto su cui viene eseguita l’invocazione non sia null ed in tal caso viene sollevata una NullReferenceException;

La differenza sul check di oggetto null o meno lo si può apprezzare con il seguente esempio :

   1: static void Main(string[] args)
   2: {
   3:     int index;
   4:     StringBuilder sb = null;
   5:     sb.Append("Paolo");
   6:     index = sb.IndexOf('o');
   7: }
 
Nel caso dell’invocazione del metodo Append() attraverso la callvirt, il CLR solleverà l’eccezione proprio in corrispondenza della chiamata.
 
em_3

Viceversa, nel caso dell’invocazione dell’extension method IndexOf() attraverso la call, l’invocazione viene eseguita (non esiste il check sul fatto che l’oggetto è null) ma ovviamente l’eccezione viene sollevata all’interno del metodo quando si tenta di accedere all’oggetto.

em_4

Posted: 6 feb 2011 11:57 da Paolo | con no comments
Inserito sotto: , ,
BeforeFieldInit … un type attribute invisibile ma determinante !

L’inizializzazione dei campi statici di una classe può essere eseguita con le due seguenti diverse modalità oppure con un mix di esse :

  • Type Initializer : inizializzazione di un campo statico in corrispondenza della sua dichiarazione;
  • Type Constructor : costruttore statico della classe che viene invocato una sola volta (per application domain) sulla stessa;

Ebbene, la presenza o meno dell’uno o dell’altro può produrre sequenze di esecuzioni differenti da parte del CLR sulla nostra classe.

Consideriamo le due seguenti classi, che a prima vista risultano semanticamente uguali :

   1: class FirstClass
   2: {
   3:     // type initializer
   4:     public static int x = 1;
   5: }
   6:  
   7: class SecondClass
   8: {
   9:     public static int x;
  10:  
  11:     // type constructor
  12:     static SecondClass()
  13:     {
  14:         x = 1;
  15:     }
  16: }
 
Entrambe hanno il campo statico “x”  ma che viene inizializzato in maniera diversa. Con un Type Initializer nel primo caso e con un costruttore statico (Type Constructor) nel secondo. Il risultato finale sarà ovviamente lo stesso ma, se utilizziamo il Reflector oppure ILDASM, constatiamo come il compilatore abbia tradotto in codice IL le due classi in maniera leggerment diversa :
 
beforefieldinit_1
 
beforefieldinit_2
 
Alla classe che non ha il costruttore statico è stato aggiunto l’attributo beforefieldinit.
Cosa comporta la presenza di questo attributo ?
 
E’ noto che, nell’ambito di una stessa classe, l’invocazione di un Type Initializer avviene sempre prima del Type Constructor ed inoltre, l’inizializzazione di un campo statico di una classe viene eseguita ovviamente prima che si acceda a tale campo. Ma quanto prima ? Siamo certi che avviene immediatamente prima ? O magari viene eseguita molto tempo prima ? Se tentassimo di accedere al campo “x”  di ciascuna delle due classi, esso sarà stato inizializzato immediatamente prima dell’accesso o molto tempo prima ?
 
Per rendercene conto, consideriamo le due seguenti classi :
 
   1: class BeforeFieldInit
   2: {
   3:     // type initializer
   4:     public static string x = WriteLine("BeforeFieldInit Type Initializer");
   5:  
   6:     // static method
   7:     public static string WriteLine(string s)
   8:     {
   9:         Console.WriteLine(s);
  10:         return s;
  11:     }
  12: }
  13:  
  14: class NotBeforeFieldInit
  15: {
  16:     public static string x;
  17:  
  18:     // type constructor
  19:     static NotBeforeFieldInit()
  20:     {
  21:         x = WriteLine("NotBeforeFieldInit Static Constructor");
  22:     }
  23:  
  24:     // static method
  25:     public static string WriteLine(string s)
  26:     {
  27:         Console.WriteLine(s);
  28:         return s;
  29:     }
  30: }
 
Entrambe hanno un metodo statico per la scrittura di una stringa su console ma, mentre la prima sarà compilata con l’attributo beforefieldinit, la seconda non sarà dotata di questo attributo.
Considerando la seguente applicazione delle due classi suddette ed osserviamone l’output :
 
   1: static void Main(string[] args)
   2: {
   3:     string tmp;
   4:     Console.WriteLine("Starting Main");
   5:     tmp = BeforeFieldInit.x;
   6:     tmp = NotBeforeFieldInit.x;
   7:     Console.ReadLine();
   8: }

beforefieldinit_3

Nonostante l’accesso al campo “x” della classe BeforeFieldInit sia l’istruzione 5, il Type Initializer viene invocato addirittura prima dell’istruzione 4. Mentre il costruttore statico della classe NotBeforeFieldInit viene invocato immediatamente prima dell’accesso al campo.

Ciò fa capire che la presenza dell’attributo beforefieldinit (aggiunto dal compilatore quando una classe non è dotato esplicitamente di costruttore statico), indica al CLR di poter invocare l’inizializzazione dei campi statici anche tempo prima che ci sia un accesso su di essi mentre l’assenza dell’attributo ritarda l’inizializzazione immediatamente prima all’accesso.

Conseguenze sulle performance

A questo punto, vediamo come questa semplice differenza possa comportare un impatto sulle performance di un’applicazione.

Consideriamo nuovamente le due classi FirstClass e SecondClass precedenti, dotate entrambe di un campo statico intero “x” ma la prima, ovviamente compilata con l’attributo beforefieldinit. Utilizziamole nel seguente applicativo di esempio :

   1: static void PerformanceTest1()
   2: {
   3:     Stopwatch sw = Stopwatch.StartNew();
   4:     for (int i = 0; i < 1000; i++)
   5:     {
   6:         FirstClass.x = 1;
   7:     }
   8:     Console.WriteLine("Performance access ... {0} : FirstClass", sw.Elapsed);
   9:  
  10:     sw = Stopwatch.StartNew();
  11:     for (int i = 0; i < 1000; i++)
  12:     {
  13:         SecondClass.x = 1;
  14:     }
  15:     Console.WriteLine("Performance access ... {0} : SecondClass", sw.Elapsed);
  16: }
  17:  
  18: static void Main(string[] args)
  19: {
  20:     PerformanceTest1();
  21:     Console.ReadLine();
  22: }
 
Vogliamo valutare il tempo necessario per eseguire 100 assegnazioni consecutive sul campo statico “x” di ciascuna classe. Il risultato è il seguente (i tempi possono ovviamente variare da computer a computer e tra un avvio e l’altro, ma il rapporto rimarrà comunque lo stesso) :
 
beforefieldinit_4

Utilizzando la classe compilata con l’attributo beforefieldinit, abbiamo un miglioramento di performance dell’80% circa (5 volte più veloce) !!

A cosa è dovuta questa notevole differenza ?

Quando il JIT compiler compila il metodo PerformanceTest1() produce un codice macchina leggermente diverso :

  • nel caso di utilizzo della FirstClass, il Type Initializer viene invocato prima dell’ingresso del ciclo for;
  • nel caso di utilizzo della SecondClass, la chiamata al Type Constructor viene inserita all’interno del ciclo for ma ovviamente il costruttore statico dovrà essere invocato una sola volta (alla prima iterazione). Per questo motivo, il JIT compiler produce un codice che esegue un check per verificare se tale costruttore sia stato o meno invocato; ciò determina un peggioramento delle performance !

Per rendercene conto, riporto di seguito il codice macchina (mixato con le istruzioni C#) prodotto dal JIT compiler :

beforefieldinit_5

Nel caso della FirstClass, constatiamo la presenza della sola istruzione che assegna il valore 1 al campo statico “x” della classe stessa.

beforefieldinit_6

Nel caso della SecondClass, prima dell’istruzione di assegnazione del valore 1 al campo statico “x”, notiamo la presenza di una call. Con questa call, viene invocato il costruttore statico e viene eseguito il check che verifica, quindi ad ogni iterazione, se sulla classe SecondClass il costruttore stesso sia stato già invocato in precedenza.

Aggiungiamo un’altra funzione al nostro esempio che verrà invocata nel main :

   1: static void PerformanceTest2()
   2: {
   3:     Stopwatch sw = Stopwatch.StartNew();
   4:     for (int i = 0; i < 1000; i++)
   5:     {
   6:         FirstClass.x = 1;
   7:     }
   8:     Console.WriteLine("Performance access ... {0} : FirstClass", sw.Elapsed);
   9:  
  10:     sw = Stopwatch.StartNew();
  11:     for (int i = 0; i < 1000; i++)
  12:     {
  13:         SecondClass.x = 1;
  14:     }
  15:     Console.WriteLine("Performance access ... {0} : SecondClass", sw.Elapsed);
  16: }
  17:  
  18: static void Main(string[] args)
  19: {
  20:     PerformanceTest1();
  21:     PerformanceTest2();
  22:     Console.ReadLine();
  23: }
 
Osserviamo che la funzione PerformanceTest2() è volutamente uguale alla PerformanceTest1() e viene invocata subito dopo di essa nel main. Non ho utilizzato la stessa funzione chiamandola due volte, perché voglio forzare il JIT compiler ad eseguire una nuova compilazione (nel caso della doppia chiamata alla PerformanceTest1() ciò non accadrebbe). L’output sarà il seguente :
 
beforefieldinit_7

Eseguendo la funzione PerformanceTest2(), nonostante sia comunque diversa dalla PerformanceTest1() (anche se il codice è lo stesso), si osserva che le performance sono praticamente le stesse. Cosa è successo ? Semplicemente questo…

Quando il JIT compiler esegue la compilazione della funzione PerformanceTest2(), sa già che il costruttore statico della SecondClass è stato invocato (nella funzione PerformanceTest1()) e non genera il codice macchina che invoca il costruttore ed il check di verifica ad ogni iterazione.

beforefieldinit_8

Per quanto riguarda la classe FirstClass non è cambiato ovviamente nulla.

beforefieldinit_9

Viceversa, per la SecondClass non esiste più la call al costruttore statico della classe.

Posted: 5 feb 2011 13:10 da Paolo | con no comments
Inserito sotto: ,