Microsoft danneggerà deliberatamente Steam, secondo Tim Sweeney

Quando accadrà e si potra dimostrare allora probabilmente Microsoft sarà indagata e sanzionata per abuso di posizione dominante cosa che è in effetti già successo in passato, il punto è che come ha detto qualcuno qui si sta facendo il cosidetto processo alle intenzioni, e non è che mo si arrestano tutti quelli che hanno la patete perché potenzialmente sono dei pirati della strada.




Caciara? E pensare che avevo epurato dal testo tutti quei rimandi polemici come il farti notare il tuo distorcere la realtà e tirare in ballo cose che non centrano solo per portare acqua al tuo mulino, quella che hai quotato è una domanda sincera nata da un ragionamento serio:

Se la colpa di Microsoft è solo quella di essere sia proprietaria dello store che di windows, che la porterebbe a danneggiare i concorrenti, la si sta accusando di avere un conflitto d'interessi, e cos'è se non mettere in discussione il suo diritto ad avere o meno uno store proprio come già fanno da tempo altre aziende?

In passato si è più volte discusso di temi simili, come il suo diritto ad avere un web browser integrato nel sistema operativo, o anche un media player, tant'è che, anche se non ne ricordo i motivi esatti, Microsoft è ora costretta in alcune aree del mondo a vendere Windows senza codec e Media Player.

Oggi come oggi sappiamo bene che una applicazione compilata per W. e quindi con tanto di eseguibile, è di granlunga molto più performante di una applicazione dello store di W10 perché quest'ultima viene eseguita non direttamente ma attraverso una virtual machine.
Ora, Perché uno sviluppatore dovrebbe portare le sue applicazioni su W.Store? Perché la suite Adobe, un qualsiasi videogioco, autocad, dovrebbero decidere di passare a W.Store se le performance calerebbero? Non ne avrebbero nessun motivo, il W.Store è adatto alle "App" non alle "Applicazioni" quindi piccoli tool come la Calcolatrice o Messenger. L'unico vantaggio è poter essere multipiattaforma, ma se questo ne vale l'affidabilità e la performance meglio compilare per piattaforme separate le applicazioni serie.
In futuro Microsoft potrebbe e dico potrebbe, decidere di far peggiorare le prestazioni delle applicazioni compilate in rapporto a quelle precompilate ed eseguite con la VM. Non sto dicendo che le peggiora in senso assoluto, ma che con il tempo, attraverso escamotage SW, le prestazioni miglioreranno sempre meno nei compilati e sempre più usando la VM. Dopo anni saranno alla pari, frutto si di una castrazione SW, ma saranno alla pari, a quel punto agli sviluppatori, non essendoci alternativa, gli converrebbe passare su W.Store.
Quando ormai tutto stara su W.Store, M. potrebbe alla fine renderlo l'unico modo per installare qualcosa su W.
Magari non succede, oppure no, chi può saperlo? Ma se tua gestisci una aziende di software e hai, anche un solo minimo sospetto che ciò possa accadere tra oggi e 10 anni, fai bene a mettere le mani avanti, dirlo e prepararti per ogni evenienza. Se ti sbagliavi, la tua frase sarà dimenticata, se invece ci avevi preso, sarai ascoltato molto di più rispetto agli altri, su quali soluzioni ottenere.

FF lo uso da anni, ma ie cancellato oggi, fa veramente cagare

Innanzitutto da tutte le applicazioni win32 che hanno una versione UWP dove le prestazioni sono di un ordine di grandezza diverso e poi su quello che sta alla base della programmazione: Un SW compilato in codice eseguibile sarà sempre nettamente più performante che pre-compilato per una VM la quale lo compila in tempo reale durante l'esecuzione ed ogni volta che lo si esegue. Questa è una legge, non si può cambiare.

Non è per niente una VM,
Lato sviluppo è un insieme di SW e librerie che ti permettono di usare diversi codici di programmazione nello sviluppare una applicazione condividendo le librerie.
Lato cliente è una suite di librerie già compilate necessarie per l'avvio di applicazioni che le sfruttano tanto come sono le DirectX.

Quando compili del codice funge punto di mezzo, cioé se un codice usa 4 linguaggi differenti i rispettivi compilatori non creano direttamente il codice macchina ma un codice comune il quale viene poi compilato in codice macchina eseguibile, ma una volta creato l'eseguibile non c'è nessun tramite, ovviamente l'eseguibile richiama le librerie del FW ma anche queste sono compilate in codice macchina.
Se tu prendi un EXE fatto con .NET e lo apri con un disassembler troverai solo istruzioni codice macchina, mentre un file .java contiene le istruzioni comprensibili non dalla CPU ma dalla VM che a sua volta in tempo reale le tradurrà in un codice comprensibile dalla CPU sul quale è in esecuzione.Vale anche per le APP UWP, dentro non ci sono salvale le istruzioni eseguibili dalla CPU ma quelle eseguibili dalla VM che dovrà tradurle per la CPU.
La differenza principale tra Framework .NET e un VM è che il primo fa tutto il lavoro di compilazione prima di generare il file eseguibile ed una volta sola, mentre la VM "genera" l'eseguibile solo in memoria e durante l'esecuzione stessa ogni volta che viene avviata. Il primo permette di usare diversi linguaggi di programmazione nella stessa applicazione, ma una volta creata funziona solo per un tipo di CPU, la VM legge codice precompilato e lo traduce in tempo reale nel codice macchina specifico per la CPU dove è in esecuzione.

Stai facendo un bel pò di confusione.
Il .NET classico (lo chiamo classico perchè recentemente hanno introdotto anche il .NET NATIVE ma questo è un altro discorso ed ha altri impieghi, tra i quali proprio le UWP) si basa su tre pilastri:

1) CLI (Common Language Infrastructure)
2) CLR (Common Language Runtime)
3) BCL + FCL (i set di librerie standard)

Le applicazioni .NET possono essere scritte in una serie di linguaggi di programmazione. A prescindere da quale di questi venga utilizzato il codice verrà comunque precompilato in un linguaggio intermedio, il Common Intermediate Language (che puoi tranquillamente paragonare al bytecode Java).
Il CIL viene pertanto dato in pasto, quando si esegue il programma, al compilatore che eseguirà una compilazione JIT (come avviene in Java) e genererà del codice nativo eseguibile dalla macchina all'interno della CLR.

se la tua applicazione è un file ".exe" dentro c'è codice macchina, quello che dite voi si e una VM, più performante di Java ma è una VM, che può essere usata con .Net, ma le applicazioni .exe sono solo codice macchina e non usano nessuna VM. Inviatimi un exe come dite voi in messaggio privato

Fiddler, Paint.NET, milioni di utility scritte in .NET

Ma anche Xamarin Studio/MonoDevelop, l'editor di Unity, Visual Studio, una marea

Le applicazioni .NET sono impacchettate in eseguibili WinPE che hanno estensione .exe

Oltre a questo le UWP, anche quando scritte con .NET non girano in VM ma girano nativamente grazie a .NET Native, che è un compilatore AOT che prende codice IL e sputa fuori codice nativo al 100%

Oltre a questo, per le UWP puoi utilizzare direttamente C++, e avere direttamente codice nativo. La maggior parte dei giochi AAA sono scritti in C++ anche su UWP.

Un'eccezione possono essere quelli scritti con Unity (che girano anche su Android, iOS, Linux, OS X ecc), che sono scritti in C# e che possono girare sia su Mono (una VM open source compatibile con .NET) sia essere ricompilati in codice nativo tramite un transpiler chiamato IL2CPP (Pokemon GO è scritto così