C ++, C # e JavaScript su WinRT

Dall’immagine sotto, piattaforma Windows 8 e strumenti. So che questo significa che posso usare C ++, C # o JavaScript per l’app Metro style. Guardo anche alcuni keynote di build e ho un paio di domande qui.

Piattaforma e strumenti di Windows 8 http://sofit.miximages.com/c%23/windows8-platform-tools_2.jpg

  1. Hanno qualche differenza in C ++, C # e JavaScript su WinRT, ad esempio prestazioni, funzionalità, capacità, ecc.
  2. Come posso creare l’app Metro nativa usando JavaScript, ho bisogno di usare la libreria js di MS o posso usare qualsiasi js con cui ho familiarità, ad esempio jQuery.
  3. Nell’app Metro style, i servizi di sistema sono solo WinRT, vuol dire che non posso più usare dll di basso livello? Questo arriverà con i costi delle prestazioni?

Per quanto riguarda il n. 1, la formazione sarebbe approssimativamente la seguente:

JavaScript – GC di livello più elevato, digitato in modo dinamico. È ansible utilizzare solo HTML5 / CSS per l’interfaccia utente, il framework XAML (spazio dei nomi Windows.UI.XAML ) non è disponibile. Fornisce alcune API JS standard (specificate da HTML5) oltre alla superficie disponibile di WinRT, ad esempio la memoria locale o IndexedDB. Essendo dynamicmente tipizzato, l’elaborazione pesante legata alla CPU rischia di essere più lenta di .NET o C ++, sebbene il motore JS sia ancora molto veloce grazie alla compilazione JIT e fortemente ottimizzato. Puoi consumare componenti C ++ e .NET WinRT, ma non scrivere i tuoi in JS. Alcuni aspetti della proiezione del linguaggio sembrano essere limitati in modo corrispondente – ad esempio, per quanto posso vedere, non c’è modo di implementare un’interfaccia WinRT in JS, ad esempio. Le librerie JS esistenti possono di solito essere riutilizzate senza sforzo minimo o minimo, a condizione che funzionino in IE10.

.NET (C # / VB): di livello medio, tipizzato staticamente con digitazione dynamic facoltativa (parola chiave dynamic ecc.) E GC. Il framework XAML UI è quello predefinito per l’interfaccia utente, ma è anche ansible utilizzare l’HTML utilizzando il controllo WebView . Fornisce pieno accesso alle librerie WinRT, ma anche alcune delle sue IInputStream , che a volte sono più comode da usare (es. Stream vs IInputStream / IOutputStream ). Inoltre, l’unico che include un supporto a livello di lingua speciale per le operazioni asincrone ( async e await parole chiave), che vengono utilizzate pesantemente quando si utilizzano API WinRT a causa del loro design altamente asincrono. In generale, fornisce la maggior parte dello zucchero sintattico – a parte le cose asincrone, ottieni LINQ sugli oggetti (che funziona su raccolte WinRT). È ansible scrivere i propri componenti WinRT, che possono quindi essere utilizzati da JS o C ++ / CX. Le librerie .NET esistenti possono essere o meno facilmente riutilizzabili, a seconda di quali classi si basano su .NET Framework; i componenti scritti per Silverlight o WP7 sono più probabilmente riutilizzabili con modifiche minime o minime, mentre i componenti scritti per .NET 4 Full o Client Profile possono richiedere modifiche significative per l’esecuzione.

C ++ / CX (Estensioni dei componenti di Visual C ++) – basso / medio livello, tipizzato staticamente, nessun GC – solo conteggio dei conti. Più vicino “al metallo” in quanto il suo modello a oggetti è progettato per mappare direttamente su WinRT senza alcuna mancata corrispondenza dell’impedenza – quindi conteggio – ma ancora ad alto livello per evitare lo schema di stampa ed essere generalmente sicuro da usare (ad es. Eccezioni piuttosto che HRESULT, stringhe viste come oggetti e non maniglie, dynamic_cast piuttosto che QueryInterface ecc.). Nessun layer aggiuntivo, oggetti proxy, ecc. Tra te e WinRT, tutte le chiamate sono dirette. Nella maggior parte dei casi, il più veloce di tutti e tre, anche se la differenza esatta varia in modo significativo a seconda dell’attività specifica, e può essere minuscola per alcuni (ad esempio app basata sull’evento con calcolo piccolo o basso), e considerevole per altri (es. ). La storia dell’interfaccia utente è la stessa di .NET. Inoltre, hai a disposizione l’intera libreria standard C ++ e un sottoinsieme di ATL. È ansible scrivere i propri componenti WinRT, che possono quindi essere utilizzati da JS o .NET. Le librerie C ++ esistenti possono essere o non essere facilmente riutilizzabili, a seconda di quali API usano; quelli che fanno affidamento esclusivamente su Standard C / C ++ di solito funzionano senza modifiche, mentre quelli che chiamano API Win32 possono rappresentare un problema se si basano su API non disponibili nel contenitore di app Metro.


Per quanto riguarda la # 3, questo video – http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C – dovrebbe rispondere alla maggior parte delle vostre domande sull’uso di Win32 (che presumo cosa significhi “DLL di basso livello” ) dalle app Metro. Nota che mentre il video riguarda il C ++, questo vale anche per C #, poiché P / Invoke e COM Interop sono ancora lì. Quindi se puoi chiamarlo dal C ++, puoi chiamarlo da C #.

1) Il punto di consentire la scelta della lingua è quello di consentire di scegliere una lingua per i vantaggi intrinseci della lingua e non perché è l’unico modo per accedere a un’API. Se ti piacciono le lingue dinamiche, scegli JavaScript. Se ti piace la digitazione statica, ma non vuoi occuparti della memoria, usa C #. Se vuoi l’esecuzione più veloce (ma la maggior capacità di spararti nel piede), scegli C ++.

2) Dipende da cosa intendi per nativo. Se vuoi solo dire che vuoi che sembrino app in stile Metro, il modo migliore è usare le librerie WinJS fornite con l’SDK dell’anteprima dello sviluppatore.

3) WinRT ti dà la possibilità di scrivere e chiamare le tue DLL C ++ o gli assembly C # dal tuo codice JavaScript. La restrizione è che devi esporre la DLL come un object WinRT e non puoi chiamare nessuna funzione che non sia altrimenti consentita per essere utilizzata nelle app in stile Metro.

  1. Le stesse differenze che hanno sempre avuto. Non esiste C # senza la gestione automatica della memoria. Le lingue gestite avranno un overhead simile come sempre.

  2. Se esegue Javascript, dovresti essere in grado di usare jQuery (che è puro javascript). Potrebbe essere necessario chiamare alcune funzioni MS per l’inizializzazione, ecc., Ma le funzioni di script esistenti dovrebbero comunque essere eseguite.

  3. Le fonti più affidabili che ho visto hanno indicato che (almeno per lo più) WinRT si trova in cima a Win32. Il blocco “Windows Kernel Services” è kernel32.dll di Win32. Qualche roba di Win32 di livello superiore non viene utilizzato in Metro, ma quale applicazione ha mai utilizzato TUTTO di Win32?

Altre persone hanno spiegato la differenza tra i 3 pozzi delle opzioni, quindi non lo ripeterò.

Comunque penso che venga fatto per:

  • Scegli quello che sai
  • Scegli cosa ti consente di riutilizzare il maggior numero di codice

Così

  • Se sei un programmatore .net, usa C # o VB.Net
  • Se stai effettuando il porting di un’app dal telefono Windows, usa C # o VB.NET
  • Se hai una grande base di codice C ++, allora considera l’utilizzo di C ++ non gestito con WinRT
  • Se si dispone di un sito Web e si desidera fornire una versione off-line di esso, è ansible ottenere un buon riutilizzo del codice (e delle competenze) utilizzando JavaScript con HTML
  • Se ti piace JavaScript e HTML, ma non ti piace .Net allora usa ….
  • Eccetera

Questo video mostra come chiamare il proprio codice C ++ da JScript:

http://channel9.msdn.com/posts/Raman-Sharma-Building-Metro-Style-Apps-with-C-and-JavaScript

Suggerimento:

  • Perché non scarichi l’anteprima dello sviluppatore e cerchi te stesso:

http://msdn.microsoft.com/en-us/windows/apps/br229516

I fatti:

  • Naturalmente sarai ancora in grado di usare Win32 .dll (a un livello o altro), proprio come puoi con .Net.

  • Windows 8 è ufficialmente fuori più di un anno: non c’è modo di dire a questo punto quali “funzionalità” e “capacità” specifiche saranno nella versione finale.