Microsoft-iagttager: .Net kommer til Windows Phone 7

"Microsoft-iagttager: .Net kommer til Windows Phone 7"

Duh! Havde han regnet med at det blev Java eller Objective-C?

Det har da længe været fremme at intefacet var Silverlight baseret, så den iagtagelse tror jeg mange har gjort for et stykke tid siden.

Mon ikke vi kan iagtage at Windows Phone 8 udvikling også kommer til at være .NET, ellers skal der da godt nok ske ting og sager hos Microsoft :)

.NET skal nok hive ydelsen ned på selv den kraftigste mobil-telefon. Hvor fedt er det at sidde med en telefon med så supermange features, hvis den end ikke kan slæbe sig selv afsted med at modtage et telefonopkald?

Nu er Android så vidt jeg er orienteret skrevet i Java ,og det giver vist ikke nævneværdige hastigsproblemer.

.NET er Microsofts forsøg på at frigøre sig fra afhængighed af en specifik processorarkitektur. Microsoft havde et tidligere forsøg på dette ved Windows NT, som også kom i versioner til MIPS, PowerPC og Alpha, men det gik i sig selv igen, da flertallet af Windowsapplikationer var kodet specifikt til x86 platformen. Så Microsoft har indset, at de bliver nødt til at gøre det gradvist: Ved at øge antallet af applikationer på .NET, sådan at de med tiden helt kan undvære x86-kompatibiliteten. Det kan de endnu ikke på Windows 7, men mobilmarkedet er ikke så afhængigt af gamle applikationer, så de kan her lave et nyt OS, som ikke er bagudkompatibelt, og diktere et API baseret på .NET. Det vil gøre det muligt for applikationer udviklet til Windows Phone 7 at køre på Windows 7 og senere desktop/laptop operativsystemer. Med tiden kan de så lave et desktop/laptop OS, der ikke kan køre x86 applikationer uden emulering.

Men det bliver et hårdt løb: Mange folk kører Windowsprogrammer, der er 10 år eller mere gamle, og de fleste forventer at blive ved med det, når de køber en ny maskine. Det har f.eks. gjort det nødvendigt for Microsoft at lave "compatibility modes", hvor ældre programmer kan køre i XP mode og lignende. Den kan de i princippet også, selv om de skifter processor, men det vil i givet fald ske under emulering, med det deraf følgende hastighedstab. Men når det drejer sig om 10 år gamle programmer, er hastighedskravene heller ikke så store, så det går sikkert.

Microsoft skal dog lige få overtalt udviklere af ny applikationer til at bruge .NET i stedet for native x86, for hvis en forholdsvis ny applikation kører langsomt på ny hardware, så vil det i høj grad afholde brugerne fra at købe denne hardware.

Men skiftet vil ske på et tidspunkt. Microsoft kan ikke tåle at være afhængig af, at et lille antal processorleverandører (Intel, AMD og VIA) vil blive ved med at levere konkurrencedygtige processorer, der er bagudkompatible med 80386. Omvendt er disse leverandører afhængige af, at Microsoft bliver ved med at lave software, der kun kører på disse processorer.

Nu er Android så vidt jeg er orienteret skrevet i Java ,og det giver vist ikke nævneværdige hastigsproblemer.

Android er skrevet i C og ikke java, punktum! Applikationer i Android kan skrives i Java, Ruby, Scala, xmlvm (Objective-c) og sikkert et par andre sprog , men den modificerede linux kerne er skrevet i C. Windows Phone OS er desuden skrevet i C++ og vi må derfor huske at skelne mellem compilers og kerne-sproget. :)

Jo, jo, godt ord igen, man kan ikke lave et OS uden en "smule" C kode (som f.eks. de par millioner linjer Linux kode i Android) ;)

Nu kan man sikkert også komme til at kode i mange andre skægge sprog på windows 7 phone series 7 windows phone ... series ... ligesom på Android. Men de er vel Java der er hoved "sproget" på Android ligesom .Net der bliver hoved "sproget" på microsoft's platform.

Og lur mig om microsoft kan nære sig fra at smide al deres gamle C OS kode væk og starte helt forfra - det virker til at det er noget de er meget dårlige til.

Mangler en mulighed for at redigere gamle posts, i sidste paragraf skal der naturligvis stå "... nære sig fra IKKE at smide ...".

JAVA-programmer er langsommere i udførelse end native programmer, men JAVA-platformen sløver ikke maskinen når den ikke er i brug.

.NET sløver maskinen allerede fra det øjeblik det installeres. Hvis jeg bliver træt at dual core ydelse på min Windows-maskine, så skal jeg bare ikstallere .NET - så er jeg tilbage på ydelse svarende til single core. Det holder ikke på en maskine der skal kunne yde noget.

Og kender vi Microsoft ret, så kommer det til at forholde sig på samme måde på mobiltelefonerne.

Slutningen af året er der lang lang lang tid til i IT tid...

http://monotouch.net/

Mono for the iPhone, iPad and iPod Touch

Wow WP7 er virkelig fremtiden... eller er det nutiden 9 måneder forsinket.

og når næste version af windows phone kommer ud så er version 8 lige på trapperne og er endnu mere fantastisk og ren vaporware igen....

Det ville være rart om Novell fik Mono til at virke tilfredsstillende på den oprindelige platform inden de fortsatte med nye afgreninger.

@Jesper Poulsen

Kan du ikke lige underbygge nedenstående påstand, meget gerne med en teknisk begrundelse?

.NET sløver maskinen allerede fra det øjeblik det installeres.

Kan du ikke linke til noget dokumentation, som påviser at Java bliver afviklet hurtigere end .Net samtidig ?

Vil egentlig også gerne se lidt dokumentation.

På en XP maskine kører .NET en smule langsommere, men på Vista og Windows 7, kører det fantastisk hurtigt, da hele styresystemet bygger på .NET frameworket.

Man kan altid gøre brug af værktøjet ngen.exe, hvis man vil have yderligere ydelse i ens .NET software.

Læs mere om det her:
http://msdn.microsoft.com/en-us/library/6t9t5wcf%28VS.80%29.aspx

JAVA-programmer er langsommere i udførelse end native programmer.

Det var i gamle dage før man begyndte at bruge Just-In-Time-compilere (JIT) til at compilere Javaprogrammerne til maskinkode før de bliver udført.

Så Javaprogrammer er i dag normalt ligeså hurtige som native programmer i selve udførslen, mens opstarten ofte er langsommere, fordi Javaruntimen skal startes, hvor native programmer i højere grad bygger på operativsystemet som allerede er "i luften".

På en mobiltelefon som er designet til at køre Javaprogrammer vil runtimen formodentlig "være i luften" allerede når applikationen startes.

.Net (CLI) er opbygget i samme stil som Javas JVM, så jeg formoder at de samme forhold gør sig gældende der.

"da hele styresystemet bygger på .NET frameworket."

Øhm, den må du gerne uddybe.. Tror du har misforstået noget. ;)

Så Javaprogrammer er i dag normalt ligeså hurtige som native programmer i selve udførslen,

Måske i troughput, men det hjælper ikke GUI's.
Min xmaple og NetBeans er temmelig langsomme.
Java egner sig i hvertfald ikke til GUI programmer så!

mens opstarten ofte er langsommere, fordi Javaruntimen skal startes, hvor native programmer i højere grad bygger på operativsystemet som allerede er "i luften".

Jep, og det er ikke til at holde ud! Latency er tælles i sekunder!

Måske i troughput, men det hjælper ikke GUI's. Min xmaple og NetBeans er temmelig langsomme. Java egner sig i hvertfald ikke til GUI programmer så!

Hvis man gør sig "umage" kan man selvfølgelig godt skrive langsomme Javaprogrammer. Men det gælder også native programmer.
Men man kan også nemt skrive hurtige GUI programmer i Java. Jeg har selv skrevet en del efterhånden.

Er det ikke bare en gammel fordom at GUI'er er langsommere på Java. Eclipse synes jeg da virker ligeså snappy som resten af min desktop.

Jeg tror at meget af "skræmme billederne" bunder i Swing, et projekt hvor Sun implmenterede low-level GUI drawing i Java, altså istedet for at sige DrawButton(x1,y1,x2,y2) til operativ systemet så sade man istedet DrawLine(blah), DrawLine(blah2), FillRect(stuff), etc. dengang jeg kodede Java var det ihvertfald Swing der var det største performance problem - men Eclipse gutterne har åbenbart klaret det ved at lave et platform udafhængigt GUI-lag der bruger platform specifikke elementer. Hvilket forresten også gør at java programmer ikke ligner noget katten har slæbt ing.

Jeg ser for mig en ung Jesper Poulsen, der har siddet med fråde om munden og desperat trykket F5 på version2.dk indtil der endelig dukkede en ny Microsoft-nyhed op!

"Nu skal der sgu flames", tænkte den kære Jesper og hamrede løs i tastaturet uden omtanke og uden hverken behov eller mulighed for at dokumentere sine påstande.

Hvad der er blevet af Jesper her godt et døgns tid senere ved kun guderne, men jeg taler vist på alles vegne, når jeg skriver, at vi krydser fingre for at han dukker op igen, så han kan fortsætte sit korstog i både denne og andre tråde :-)

Er det ikke bare en gammel fordom at GUI'er er langsommere på Java. Eclipse synes jeg da virker ligeså snappy som resten af min desktop.

Eclipse bruger SWT (som bruger operativsystemets knapper og paneler) mens NetBeans bruger Swing (som har javakode til at tegne alle knapper).
Så før JIT-compilerne kom ind i billedet var der en tydelig hastighedsforskel mellem Swing og SWT programmer, men det er mange år siden.
Jeg har lige prøvet at søge på nettet efter eksempler på hurtige Swing programmer og f.eks stødt på http://www.jgraph.com/jgraph.html