Microsoft trekt waarschijnlijk api's en sdk's Windows en Windows Phone gelijk

Microsoft trekt de api's en sdk's van Windows en Windows Phone gelijk bij de volgende versie. Dat zegt Microsoft-volger Paul Thurrott op zijn blog. De samenvoeging van Windows en Windows Phone zit er al enige jaren aan te komen.

Met het samenvoegen van de runtimes, api's en sdk's zijn de omgevingen voor ontwikkelaars vanaf dan gelijk en kunnen apps vermoedelijk zonder enige vorm van omzetting op zowel Windows als Windows Phone werken. Daarmee zou Microsoft weer een stapje verder komen bij het samenvoegen van zijn besturingssystemen voor desktops en smartphones. Dat zal gebeuren met 'Windows 9' of hoe de volgende grote release van Microsofts besturingssysteem zal heten, zegt Thurrott.

De samenvoeging is al enkele jaren aan de gang. Windows en Windows Phone draaien al een jaar op dezelfde kernel, terwijl Windows Phone daarvoor gebaseerd was op de aparte Windows CE-kernel. Ook de Store is inmiddels al dezelfde. Apps kunnen daardoor nu al zonder veel moeite worden omgezet van Windows naar Windows Phone, maar er zijn nog altijd aanpassingen nodig. Microsoft zal vermoedelijk met deze stap het aantal apps voor zowel Windows als Windows Phone willen vergroten.

Thurrott meldt verder dat de Lumia 520 het bestverkopende apparaat op Windows is. De goedkoopste Windows Phone van Nokia, waarvan de telefoondivisie binnenkort door Microsoft zal worden ingelijfd, ligt in de winkels voor minder dan 150 euro.

Door Arnoud Wokke

Redacteur

27-09-2013 • 17:13

44 Linkedin

Reacties (44)

44
42
26
6
2
11
Wijzig sortering
Op dit moment hebben Windows 8 en WP8 een API overlap van ongeveer 20%. Microsoft heeft steeds geroepen dat het doel is om dit percentage te vergroten.

Het Windows en het WP team werken heel veel samen, ze werken in dezelfde code base. Optimalisaties gedaan door het WP team in de kernel om op low mem devices (512MB) te kunnen draaien resulteren meteen in performance winst op bijvoorbeeld een Windows RT device (dit zie je terug in de 8.1 update van Windows). Daarnaast wordt bij elke beslissing over API's samen gewerkt door de teams. Soms is het zelfs 1 team wat een API uitwerk wat dan door het andere team wordt gebruikt.

Toegang tot files is al hetzelfde, encryptie op de phone door bitlocker komt weer bij Windows vandaan etc.

Dus zelfs al voor de reorg naar 1 OS groep werd er al heel veel samen gewerkt door het Windows en Phone team.
Hoewel MS natuurlijk liever had gezien dat Windows phone wat sneller een groter marktaandeel had gehad is het op het gebied van technisch management weer een fantastische stap.

Afgelopen jaren hebben ze een strakke strategie gevolgd

- Kritiek over stabiliteit van de consumenten producten is verdwenen
- Altijd rekening gehouden met backwards compatibility zodat enterprises geen grote desinvesteringen hebben hoeven doen en loyaal zijn gebleven aan de producten
- convergentie van de server, desktop, consumer desktop en mobiele producten
- uitbreiden van office functionaliteit met business communications (Skype / Lync)

Natuurlijk verdient Apple kudo's voor het feit dat iedereen lange tijd bereid is geweest een premie te betalen voor het 'hebben' van een iPhone maar de lock in voor mobiele devices is nog steeds vrij laag.

Uurtje spelen met een iphone, android of windows phone en je kunt er redelijk mee uit de voeten.

Office / lync combinatie op een windows phone werkt echt goed en het feit dat windows phone prima draait om minder krachtige hardware maakt dit een ideale zakelijke combinatie.

duurt even maar windows phone zal niet zo snel van het toneel verdwijnen!
brengt dit geen nadelen mee, onvolledige windows of veel te zware windows phone?
Nee, de kernel is al hetzelfde. Door alleen datgene te implementeren wat nodig is voor een smartphone kun je het draaibaar houden.

Het zou ook kunnen dat MS met Windows 9 het OS zodanig optimaliseert dat deze op een smartphone kan draaien. (Vergeet niet dat smartphones tegen die tijd heel erg krachtig zullen zijn).
De basis van de kernel is waarschijnlijk hetzelfde.
De kernel van beide OS'sen zal echter toch wel flink verschillen omdat de Windows 8 kernel veel flexibeler moet zijn in bijvoorbeeld de ondersteuning van hardware en de ondersteuning van bestaande x86 windows applicaties.
Een Windows kernel ondersteund geen hardware, dat doen drivers.

De kernel "praat" ook niet rechtstreeks met de drivers maar met de z.g.n. Hardware Abstraction Layer (HAL). Aan de HAL zitten de drivers gekoppelt.

De HAL zorgt voor een universele interface voor kernel en applicaties voor het benaderen van hardware.

Het enorme voordeel hiervan is dat je applicaties en kernel onafhankelijk zijn van de hardware.
Nadeel is dat je geen rechtstreeks toegang hebt tot de hardware, en daardoor je vlucht moet zoeken in zoiets als DirectX om dat te bewerkstelligen.

Voordelig is echter dat je onbekommerd hardware in je systeem kan steken, vervangen of verwijderen zonder dat je de kernel hoeft aan te passen/hercompileren.

In het verleden was Linux een voorbeeld van een OS dat geen dergelijke scheiding tussen hardware en software kende, waardoor je voor elk verandering de kernel moest hercompileren.
Tegenwoordig is dat niet meer nodig door een soortgelijke oplossing.
De kernel is gewoon hetzelfde, de WP8 kernel is net zo flexibel als de Windows 8 kernel.
Windows 8 komt gewoon met een veel bredere hardware support en een stapel meer API's.
Niet echt, het gaat hem om de APIs voor apps, dus eigenlijk alles wat in de modern UI draait, en dat is vandaag al voor een groot deel gelijk tussen de 2. Men zal dus gewoon de laatste grote verschillen wegwerken.
Er draait niets in de Modern UI, dat is alleen een design taal. Het gaat hier om de WP8 api en de WinRT api (niet te verwarren met Windows RT).
Nee. Op deze manier luisteren de applicaties alleen maar naar dezelfde commando's. De groote of zwaarte van de applicatie kan dus alsnog ver uit elkaar lopen.
Ik had ooit begrepen dat dit al het plan was voor windows 8, maar blijkbaar ging dat toen alleen om de kernel. Goed dat nu alles gelijk getrokken gaat worden. Ben benieuwd wat dat voor de aantallen van apps voor wp8 gaat inhouden! En gezien ik eind dit jaar de 1020 kado ga doen aan mijn persoontje, is elke extra app een mooie stap
Ja die extra apps kunnen ze wel gebruiken. Hoewel een hele hoop mensen roepen dat alles beschikbaar is.
Ik vind dit persoonlijk geen goede ontwikkeling. Een telefoon is toch iets HEEL anders dan een PC of een Laptop? Daar wil je toch ook niet dezelfde interface voor? Ik kan me voorstellen dat een dev op deze manier makkelijk een app voor alle devices kan lanceren, maar wilt een dev niet liever een volledige PC ervaring bieden en een fantastische telefoon ervaring?

De tijd zal leren hoe dit zich ontwikkeld. Ik ben in ieder geval erg benieuwd.
Je maakt een klassieke vergissing: je haalt User Interfaces en Application Programming Interfaces door elkaar. Het verschil in het kort: een UI is voor eindgebruikers en een API voor developers.
Het punt is, die 2 dingen kunnen los van elkaar ontwikkeld en gebruikt worden. Dat de API identiek is betekent dus niet automatisch dat de UIs hetzelfde of uberhaupt suboptimaal hoeven te zijn. Sterker nog, ik ga zo ver te zeggen dat ik 1 coherente API prefereer boven 1 API voor de desktop en eentje voor smartphones en tablets.

Een concreet voorbeeld van waar dit nu al goed gaat: Android 3.0 introduceerde de Fragments API. Wat je daarmee kan is een GUI zodanig ontwerpen dat je de schermruimte van zowel smartphones als die van tablets optimaal benut, en vaak zonder concessies te hoeven doen.

Als dit kan, waarom zou dit niet uitgebreid kunnen worden met een manier om GUIs te ontwerpen die geschikt zijn voor de desktop? Om eerlijk te zijn vermoed ik dat dit precies is wat Google vroeg of laat gaat doen met de Android/ChromeOS combinatie.
Het is dus aan de dev. Door de techniek gelijk te zetten kunnen Dev's heel snel de interface aanpassen voor verschillende form factors.

Vergeet niet dat straks de xbox one ook van dezelfde framwork gebruik zal maken. Op een TV zou je de interface ook net even wat anders willen hebben.
Als developer gebruik je tegenwoordig het MVVM patroon voor WP8/Win8 ontwikkeld. Hierdoor kun je de logica en de UI volledig los van elkaar ontwikkelen. Je kunt dan eenvoudig voor ieder device type een andere UI maken in Xaml.
Ik wist niet dat Android zo goedkoop is :) Als een G4 voor 600 euro weggaat lijkt me dat geen optie.

En de 1020 is toch wel de smartphone to beat op het gebied van fotografie :)
Want Android is goedkoper? Ik ben niet zo voor de eenheidsworst. Bij Windows Phone heb je zat verschillende kleuren van toestellen. De enige die eigenlijk komt met een standaard design voor Windows Phone toestellen is Samsung, Nokia, HTC en Huawei in mindere maten, hebben kleurige Windows Phone series. Daarbij is Windows Phone een veel stabieler systeem en heeft het helemaal geen last van fragmentatie.
Daarmee zou Microsoft weer een stapje verder komen bij het samenvoegen van zijn besturingssystemen voor desktops en smartphones. Dat zal gebeuren met 'Windows 9' of hoe de volgende grote release van Microsofts besturingssysteem zal heten, zegt Thurrott.
Betekend dat dan ook dat de lay-outs nog meer op elkaar gaan lijken?
misschien een vraag van een leek, maar zo interpreteer ik het eigenlijk wel.
De layout van Windows 8 en Windows Phone 8 apps wordt nu al bijna volledig met standaard HTML5 en CSS opgebouwd en het is daarmee een fluitje van een cent om zogenaamde responsive layouts te maken zoals dat nu ook al met het overgrote deel van de (goede) websites gebeurt. Open voor de grap eens de website van Mashable.com en verklein je browservenster. Je zult zien dat de website afhankelijk van de schermgrootte de layout aanpast en meer of minder info laat zien. Dezelfde website met dezelfde code toegespitst op grote, kleine, hele grote of zelfs hele kleine schermen. Hierdoor zijn aparte mobiele websites ook niet meer nodig, net zoals aparte mobiele apps dus niet meer nodig zijn :)

Overigens, de ingebouwde Microsoft apps in Windows 8.1 schalen al perfect terug tot telefoongrootte en passen de layout daar dan ook op aan.

Samentrekken van de API's lijkt me een hele goede stap, zo maken ze het ontwikkelen voor Windows 9/Phone 9 wel heel erg interessant voor ontwikkelaars: met één ontwikkelplatform of één app kunnen ze dan een gigantisch publiek bereiken.

[Reactie gewijzigd door Jazzle op 27 september 2013 17:40]

Windows 8 en Windows Phone 8 gebruiken C#/VB.NET en XAML en dus niet CSS en HTML5.
Anoniem: 80466
@Qws27 september 2013 17:52
In feite is de apps SDK in die zin gewoon een soort opvolger van silverlight waarbij XAML is geintroduceerd.
XAML heeft altijd al in silverlight (WPF/E) gezeten. Het grote verschil tussen WPF en Silverlight was vooral de sterk beperkte versie van het .NET framework welke beschikbaar was op WP 7.x. Ook was de binding iets minder krachtig.

Ook op Modern UI hebben nog steeds te maken met een beperkt .NET framework. Echter de belangrijke .NET 4.5 features zijn aanwezig zoals async en await. Als je kijkt naar de System.IO namespace zijn eigenlijk juist alle synchrone methodes verdwenen wat ik een zeer goede verandering vind.

IO kost tijd, dus behoor je ook bestanden asynchroon te benaderen. Soms zijn callbacks (begin/end methods) een beetje overkill, maar daar kun je nu await gebruiken mits de methode als async is gemarkeerd. De compiler doet dan de rest van de methode voor je in de callback plaatsen.

Omdat de WP8 api niet zo heel erg veel afwijkt van de Silverlight WPF/E api, kun je WP 7.x ook zeer eenvoudig omzetten naar WP8 of Modern UI apps. Echter de totale toolkit wel een stuk beter geworden.

Zelf vind ik juist de verscheidenheid aan talen welke ondersteund worden door het .NET framework juist een van de voordelen. Waarbij .NET de verschillende compilers MSIL code aanmaken, doet Google met Android een soortgelijk iets. Maar is plaats van (Java) bytecode, kun je nu bytecode voor de Dalvik runtime terug. Omdat veel programmeurs al bekend zijn met de Java taal, konden ze daardoor ook zeer eenvoudig Android applicaties schrijven.

In de context van dit artikel worden met Windows 8 apps duidelijk de Modern UI (Metro) apps bedoeld en niet de applicaties welke draaien in de classic desktop.

Classic Desktop applicaties worden inderdaad niet geschreven met HTML5, Javascript en CSS. Hoewel men al sinds de eerste Avalon releases men wel de overeenkomsten met HTML/CSS zag..
CSS, JS en HTML5 zijn wel degelijk mogelijk op Windows 8. Als dev kun je een volledige app met alleen deze 3 talen bouwen.

Vele MS apps (zoals mail app) zijn ook op basis van html5 gemaakt :)
Hoe weet je dat de email app op basis van html5 zijn gemaakt? Ik heb dat nog nooit in een statement van Microsoft gezien. Ik zou zelf c# of c++ verwachten ivm performance.
Person, news, mail etc allemaal in HTML geschreven. Als je bv de tool XAMLSpy pakt dan krijg je een lijst met geinstalleerde Windows apps en zie je met welke technologie ze gemaakt zijn.
Apps worden nog steeds gecompileerd. Je kan kiezen voor de c#/xaml approach of de js, css en html approach. Beide wegen zullen in principe dezelfde app opleveren.

Voor Windows Phone kun je alleen kiezen voor c#/xaml.
Hij bedoeld dat windows 8 en WP8 niet met CSS en HTML 5 zijn opgebouwd.
Je kan ook in HTML5 met CSS3 en javascript een app programmeren.

http://msdn.microsoft.com/nl-NL/windows/apps/bg125376
Dat het niet de enige opties zijn klopt, ik had misschien 'kan' ipv 'wordt' moeten gebruiken, maar zowel op Windows 8 als WP8 is het mogelijk om een apps te ontwikkelen waarbij in ieder geval de layout in HTML wordt opgebouwd (op WP8 welliswaar met wat haken en ogen). Op Windows 8.1 zijn in ieder geval de layouts van de Microsoft apps volledig opgebouwd met HTML en CSS, zelfs de Windows Store zelf.
Ik moet nog maar eens zien waar dit strand, het klinkt best leuk maar wat betekent dit voor de gewone computergebruiker.
Windows 8 is al niet al te best opgevangen en Windows 9 gaat dus nog meer de kant op van smartphone os.
Of het smartphone os gaat meer richting tablet en naar mijn mening dus ook iets uitgebreider ;)
Ik vindt het in ieder geval een goede ontwikkeling
API en UI zijn verre van het zelfde. De api is gewoon waar je applicatie tegen aan praat om bijvoorbeeld je netwerkkaart aan te spreken of je bestanden (kort door de bocht). Als jij een file manager wil maken die lijkt op een iPhone, dan kun je dat gewoon doen.

Wat gaat veranderen is dat de missende onderdelen voor Windows Phone erbij komen en de code je dus geen subsets meer hoeft te gebruiken. Hierdoor word het dus makkelijker om apps crossplatform te maken.
Anoniem: 194249
27 september 2013 18:08
Ik ben benieuwd.
Betekend dit dat een API zoals "CreateRemoteThread" ( http://msdn.microsoft.com...s682437%28v=vs.85%29.aspx ) verdwijnt voor Windows, of dat de Windows Phone die krijgt ?
Kon dit niet direct zien, en jij weet het sowieso vast beter.
Maar als dit een WinRT API is, dan ja.
Win32, dan nee.
Hij kan niet verdwijnen in Windows, want Microsoft gaat héél ver om te voorkomen dat oude software niet meer draait. Lees de blog van Raymond Chen maar eens.

Ik denk ook niet dat alle API functies van Windows naar Windows Phone gaan. Daar zit behoorlijk wat Legacy spul bij, die er alleen voor backwards compatibility inzit, maar niet moet worden gebruikt door nieuwe applicaties.

En een functie als CreateRemoteThread() zou natuurlijk toegevoegd kunnen worden, maar altijd NULL retourneren, als de functie niet van toepassing is op een telefoon.
Klinkt goed, dan kunnen mensen voor beide platformen tegelijk ontwikkelen. Ik zou heel graag de javascriptondersteuning van win8 in WP willen zien!
Mooi, want WinRT API komt naar WP8 toe. Er zal vast ook wel een flats uit de WP8 API ook naar WinRT komen, maar zal meer aanvulling zijn op wat WinRT mist wat WP8 al wel heeft.
Niets waarschijnlijk, dit is al enige tijd bekend.

Het is de reden waarom WP8.1 zo lang is uitgesteld, juist omdat ze beide API's naar elkaar recht aan het trekken zijn.
Het is de reden waarom WP8.1 zo lang is uitgesteld
Uitgesteld? We weten niet eens of WP8.1 is uitgesteld. Het is maar omdat mensen een gerucht hadden gelanceerd dat Microsoft weer in oktober/november met een update zou komen, maar dit is nooit bevestigd geweest dat het ook de bedoeling was. Wie zegt dat WP8.1 niet altijd al gepland was voor dan (we weten zelfs dat niet eens zeker)? Als ik een gerucht de wereld in help dat Windows 9 in maart beschikbaar zal zijn, dat gaat viraal en plots duikt de realiteit op dat het pas oktober wordt, is Windows 9 dan uitgesteld? Nu ja, dat terzijde...

Mooi werk van Microsoft als dit volledig op poten staat, eindelijk 1 uniform platform voor PC, tablet, smartphone, console, etc. Het werd tijd dat een bedrijf hier ook eens daadwerkelijk werk van ging maken.
Wat gerucht, wp8.1 stond gelijk met win8.1 in de planning.
ms had gewoon een release schema waarin blue voor zowel wp als win voor q4 2013.
als dat dan ineens q1 2014 word, tja.
wp8.1 stond gelijk met win8.1 in de planning.
Dat weten we dus niet, dus is het een gerucht en kan je niet zeggen dat het uitgesteld is.
Je haalt eea door elkaar.
W8 is toegankelijk gemaakt voor het hele touchgebeuren, NAAST/BOVENOP het gewone Windows dat je al kende.
Het OS is niet naar de telefoon/tablet gegaan, zie het als dat Windows een extra hoofdstuk erbij gekregen heeft, naast de encyclopedie die het al is.
Alles wat je met W7 kon, kan je met W8, en dan nog iets meer. :)

En dan hebben we het hier over de api om apps te schrijven en een store waar apps voor de desktop/pc, tablet en telefoon in staan, wat nu naar elkaar toegetrokken wordt.
Die apps hebben niets met je desktopfunctioneren, je applicaties of programma`s, te maken, behalve dat je apps kan draaien op je desktop.

Als je apps maar niets vindt hoef je die niet te draaien.......nu niet en straks ook niet.

Het enige dat gebeurt is dat de apps van telefoon, tablet en computer/pc nu in één store terecht komen waarbij je waarschijnlijk apps voor zwaardere hardware (pc) niet op lichtere (telefoon) kan draaien maar omgekeerd wel.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee