Microsoft-iagttager: .Net kommer til Windows Phone 7

Windows Phone skal udvikles med Silverlight, .Net, Visual Studio og Expression Blend. Det fremgår af en række lækkede Microsoft-dokumenter.

Udviklerplatformene for den nyligt annoncerede Windows Phone 7 bliver overvejende baseret på en eller anden form for .Net.

Det fremgår af en række lækkede dokumenter, skriver den Microsoft-kyndige journalist Mary Jo Foley på sin blog, All About Microsoft.

Vægten vil blive lagt på .Net-API'er og kun få API'er vil have adgang til det underliggende system.

Silverlight og spilframeworket XNA, som benyttes i Xbox og musikafspillleren Zune HD, bliver også en del af platformen sammen med XAML, som er et XML-sprog, der gør det muligt at skabe web-agtige applikationer i .Net-miljøet.

Ifølge dokumenter bragt på sitet WMPoweruser.com vil udviklingsværktøjerne til Windows Phone 7 blive Visual Studio 2010 og Microsoft Expression Blend, som er et grafisk værktøj til .Net- og Silverlight-udvikling.

Blandede meldinger om multitasking
En anonym kilde beskriver Microsofts udviklerstrategi på denne måde til All About Microsoft:

»Udviklerplatformen er Silverlight 3 med elementer af 4 med Blend og en Visual Studio-plugin. Det spændende er, at mens det er i stil med XAML, er det ikke ren XAML. Det er OK, da det sørger for at størrelsen er lille. Teoretisk set kan man skabe et helt program indefra Blend, men jeg tror man stadig har brug for at binde det hele sammen i C#.«

Der er modstridende meldinger om, i hvilken grad Windows Phone 7 vil understøtte multitasking. Nogle kilder fortæller, at der vil være mindre udstrakt multitasking end hvad der er kendt fra forgængeren Windows Mobile 6.5.

Der er heller ingen melding om, i hvor høj grad der vil være kompatibilitet mellem programmer skrevet i forrige version af miljøet og den nye Windows Phone 7.

Microsoft har meddelt, at det vil løfte sløret for flere detaljer angående dette på Mix-konferencen, der afholdes i midten af marts.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (19)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Christian Sparre

"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 :)

  • 0
  • 0
#4 Torben Mogensen Blogger

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

  • 0
  • 0
#5 Ulrik Moe

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. :)

  • 0
  • 0
#6 Rasmus Toftdahl Olesen

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.

  • 0
  • 0
#8 Jesper Poulsen

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.

  • 0
  • 0
#9 Jakob Damkjær

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

  • 0
  • 0
#11 Carsten Sonne

@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 ?

  • 0
  • 0
#12 Nick Frederiksen

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

  • 0
  • 0
#13 Niels Dybdahl

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.

  • 0
  • 0
#15 Mark Ruvald Pedersen

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!

  • 0
  • 0
#16 Niels Dybdahl

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.

  • 0
  • 0
#17 Rasmus Toftdahl Olesen

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.

  • 0
  • 0
#18 Venligst Slet Min Bruger

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 :-)

  • 0
  • 0
#19 Niels Dybdahl

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

  • 0
  • 0
Log ind eller Opret konto for at kommentere