'Redstone 3-update voor Windows 10 introduceert x86-emulatie op arm-processoren'

De Redstone 3-update voor Windows 10 krijgt mogelijk x86-emulatie voor arm-processoren. Dit zou betekenen dat Windows 10-apparaten met dergelijke processoren, zoals mobiele telefoons, dan ook veel Windows-applicaties kunnen draaien, ook in bijvoorbeeld Continuum.

Het gebrek aan x86-ondersteuning op arm-processoren in Windows 10 is een beperkende factor voor de bruikbaarheid van Continuum, zo schrijft Mary Jo Foley van ZDNet. Zij heeft van anonieme bronnen te horen gekregen dat dit struikelblok met ingang van Redstone 3 overwonnen moet zijn. Naar verwachting komt deze update in de herfst van 2017 uit. Vanaf dan moeten gebruikers meer dan alleen UWP-apps kunnen draaien op Windows 10-apparaten met arm-processoren. Het project zou intern Cobalt heten.

Op het moment zit er voor gebruikers van Windows 10-apparaten met arm-processoren niets anders op dan zich alleen te wenden tot Universal Windows Platform. Een alternatief hierop biedt HP bijvoorbeeld in de vorm van de Elite x3, die voor zakelijke gebruikers een streamingdienst ontworpen heeft die x86 apps draait. Ook kunnen gebruikers met een remote desktop-opstelling x86 apps draaien. Emulatie van x86 zou echter wel duidelijk efficiënter zijn dan deze oplossingen. Microsoft en HP, dat vermoedelijk ook betrokken is bij de ontwikkeling, weigeren commentaar tegenover mevrouw Foley.

Reacties (97)

[BugBoy]

x86 emulatie op een ARM processor zal erg veel CPU kracht kosten. Dat zou dus inhouden dat applicaties traag werken en een flink aanslag op de CPU doen. De enige oplossing voor de toekomst lijkt toch universal applicaties te zijn en .NET core.

PS: Ik hoop dat MS het lukt om van Windows Mobile een succes te maken. Een alternatief naast iOS en Android zou zeer wenselijk zijn.

[Reactie gewijzigd door BugBoy op 23 juli 2024 19:34]

[Nitramuse]

Eén ding wat we van MS hebben geleerd het afgelopen jaar is dat hun emulatie-engineers echt wel weten wat ze doen. Kijk maar eens naar de backwards compatability van de X360 naar de One. Dit zou ook teveel kracht kosten en onmogelijk zijn, maar zie! Sommige games draaien zelfs nog beter.

Dus, ik denk dat als MS dezelfde engineers gebruikt, het nog best wel eens iets zou kunnen doen.

[BugBoy]

Een groot verschil vind ik dat de One veel meer computing power heeft dan een 360. Dan ontstaat er ruimte voor emulatie. De gemiddelde telefoon heeft juist minder performance dan een desktop, dus dan wordt het veel lastiger. Daarbij is bij een gameconsole het opgenomen vermogen minder van belang dan bij een telefoon.

[.oisyn]

Een groot verschil vind ik dat de One veel meer computing power heeft dan een 360.

Nee hoor, minder zelfs. Respectievelijk 112 en 115 GFLOPS. Alleen wil het euvel dat die theoretische kracht op een 360 veel moeilijker te halen is, daar heb je hele specialistisch geschreven code voor nodig. De op halve snelheid geklokte x86 in de Xbox One haalt doorgaans veel meer instructions per second wegens betere branch prediction, memory access prediction en out of order execution. De PowerPC heeft belachelijk lange pipelines, dus als je wilt branchen op basis van een resultaat van een berekening dan kost dat behoorlijk wat latency. Ook load-hit-stores (het lezen van een geheugenplek waar je net geschreven hebt, meer info) zijn op de PPC een enorm probleem.

[atlaste]

Helemaal correct.

Overigens denk ik dat 'emulatie' sowieso niet helemaal het goede woord is hier. Microsoft gebruikt vast JIT compilatie onder water; ik kan me niet anders voorstellen.

Wat ook belangrijk is, is dat op een x86 architectuur de simpele (niet-vector / SIMD) instructies best goede performance opleveren. Het zijn vooral de dingen als het emitten van SIMD en register allocation die een JIT complex maken. En de ironie is dat je die beiden waarschijnlijk dus niet echt nodig hebt in dit geval. Als een triviale vertaling mogelijk is zullen ze het vast doen, maar anders dan dat vermoed ik van niet.

Wat dat betreft zou je het ook kunnen vergelijken met .NET. De .NET runtime emit eigenlijk geen SIMD instructies en doet hele basic register allocatie. De reden is daarvan is dat warm-up time (de tijd die het kost om een methode te JIT'ten) in veel gevallen belangrijker is dan runtime (ruwe performance van een method). Voor de nerds, ik vond de JIT code van .NET best interessant om doorheen te bladeren: https://github.com/dotnet/coreclr/tree/master/src/jit .

[D_Jeff]

Ik heb ergens gelezen dat de Snapdragon 800 @2,3 GHz te vergelijken zou zijn met een T5250 (Core 2 Duo, 1,5 GHz).

Daarnaast: Vergis je niet. Niets gaat momenteel zo hard als de SOC's voor mobile.
Daar waar Intel moeite heeft om 8 % prestatiewinst te pakken, halen Qualcomm en Samsung soms 20 - 25 % per jaar.

Vergelijk diezelfde 800 maar.. is bijna al "low-end" in de 2 jaar dat die meedraait

[elmuerte]

Van 50 naar 55kpmh is makkelijker dan van 100 naar 110kpmh terwijl het toch allebei 10% is.

Performance claims zijn niks waard zonder benchmarks.

T5250 is uit eind 2008. Snapdragon 800 2,3 GHz is uit 2014. Dat is toch wel 6 jaar verschil.

[mae-t.net]

Laatste keer dat ik keek hadden processoren geen last van luchtweerstand die exponentieel toeneemt... Op softwareniveau ook geen daarmee vergelijkbare verschijnselen, meestal schaalt dat lineair gegeven dezelfde architectuur.

[Philip Ross]

Er zijn voldoende zaken in een processor die exponentieel moeilijker worden. Denk aan vermogen afvoeren, complexiteit en tegenwoordig vooral interconnects

[Verwijderd]

Ja maar hoe lang geleden is het dat standaard applicaties op x86 al geen profijt meer hadden van extra cpu kracht? Daar moet je ook aardig wat jaartjes voor terug.

Allee dat 3D rendering, development, games en dat soort zaken altijd grotere en snellere machines nodig hebben, maar mensen die dat doen krijgen er van hun bedrijf wel een snelle desktop voor.

Het eerste aanrakingspunt voor Continuüm zal Office-achtigen en Outlook en simpele line-of-business applicaties wel zijn. Als je die goed kan draaien dan vang je al een groot percentage van zakelijke gebruikers.

[Benjamin-]

Echter is de vraag of dat uberhaupt relevant is?

Continuum heeft op dit moment voor veel mensen, weinig toegevoegde waarde. Werk je in een remote omgeving, dan is het echt wel leuk, maar verder kan je telefoon zelf relatief weinig.

Zou je de kracht van zo'n C2D hebben, dan kan je opeens ongelooflijk veel draaien. Nee het is geen powerhouse, maar dat is in veel gevallen ook niet nodig. En laten we eerlijk zijn, heb je zoveel kracht nodig, waarom probeer je dat dan uberhaupt op een telefoon?

Zou MS via emulatie zoveel kracht uit een nieuwe Snapdragon kunnen halen, dan zitten ze heel erg goed.
Of dit ook het geval zal zijn, en of het er ook werkelijk wel zou komen (Android en iOS app emulatie is er ook nog steeds niet), dat is de vraag, maar zou het er komen, dan kunnen ze hier zeker op de zakelijke markt wel een gigantische inhaalslag maken.

[gaurdian]

Volgens Daniel Rubino van Windows Central ontwikkelt Microsoft deze functie voor reference boards met de snapdragon 830. Daar is nog niet veel van bekend, behalve dat die natuurlijk weer een stuk krachtiger wordt dan de 820. De 800 is alweer van twee jaar geleden geloof ik. Ik zie het nog wel gebeuren zo!

[jeroentje710]

De snap dragon 820 zou vergelijkbaar zijn met een x box 360.
Het kom van reddit en is dus niet erg betrouwbaar. Maar het is voor mij niet ondenkbaar dat wat we tien jaar terug in een console stopte nu in een smartphone past.

Reddit treat

[kidde]

De gemiddelde telefoon heeft juist minder performance dan een desktop, dus dan wordt het veel lastiger.

Opent dat dan niet juist de geruchten voor een Microsoft (Surface?) tablet draaiende op een Snapdragon 835 en Windows 10?

[Zer0]

Leuk voorbeeld, maar de CPU van de X360 is in basis een RISC (Reduced Instruction Set Computing) CPU, en laten die nu relatief makkelijker te emuleren te zijn op een in basis CISC (Complex Instruction Set Computing) CPU zoals gebruikt in de Xbone.
Andersom emuleren is een stuk lastiger omdat je voor één CISC instructie vaak veel meer RISC instructies nodig hebt, wat de snelheid beïnvloedt. De emulatie-laag is dus een stuk complexer, waardoor een ARM CPU nooit de snelheid van een gelijkwaardige x86 CPU zal halen. Neem daarbij het feit dat de meeste ARM CPU's veel minder prestaties bieden dan x86 CPU's vanwege het feit dat ze meer op zuinigheid dan rauwe prestaties gericht zijn, en je kunt concluderen dat de engineers en developers een flinke kluif zullen hebben aan deze missie.

[PPie]

Andersom emuleren is een stuk lastiger omdat je voor één CISC instructie vaak veel meer RISC instructies nodig hebt, wat de snelheid beïnvloedt

Sinds de Pentium Pro is de x86 in feite een RISC processor met een CISC -> RISC converter...
Tevens: Je hoeft niet iedere keer de conversie te plegen. Kijk naar JIT in de Java VM en javascript in de browser.

[Zer0]

Sinds de Pentium Pro is de x86 in feite een RISC processor met een CISC -> RISC converter..

Dat klopt op zich, maar die CISC->RISC vertaling wordt in de hardware gedaan, meestal een stuk vlotter dan om dat in software te doen. (Die software moet tenslotte ook gebruik maken van CPU cycles)

[Dreamvoid]

Daar komt nog bij dat inmiddels met ARMv8 het nauwelijks meer een RISC instructieset kan kan noemen, er zijn met de jaren steeds meer complexe instructies bijgekomen.

Door de jaren heen is processor design steeds meer toegegroeid naar het principe 'CISC aan de voorkant' (voor efficienter geheugengebruik) en 'RISC aan de achterkant' (de compute units).

Ik verwacht dan ook dat die x86 emulator op Windows vooral een geheugenvreter zal worden.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 19:34]

[gabba25]

Als het zo makkelijk was, waarom heft Sony dan geen bc naar ps3?

[.oisyn]

Omdat de SPU's van de cell architectuur nauwelijks goed te emuleren valt. Daar zit nou eenmaal een behoorlijke hoeveelheid aan rekenkracht, die op de PS4 gewoonweg niet beschikbaar is.

In termen van Gflops, dit zijn de getallen:

Xbox One: 112
Xbox 360: 115
PS4: 102
PS3: 230

Zou zeggen gigaflops ook niet alles (zo is de x86 véél beter in generieke code wegens branch en memory prediction, kortere pipelines, out of order execution, etc), maar het lijkt me duidelijk dat de cell architectuur, die toch wel breed werd ingezet omdat de GPU een beetje ondermaats was, roet in het eten gooit voor PS3 emulatie.
En emulatie op de GPU is praktisch onmogelijk, daar is ie niet generiek genoeg voor.

[Reactie gewijzigd door .oisyn op 23 juli 2024 19:34]

[atlaste]

maar het lijkt me duidelijk dat de cell architectuur, die toch wel breed werd ingezet omdat de GPU een beetje ondermaats was, roet in het eten gooit voor PS3 emulatie.

Ik twijfel. Gflops zeggen niet zo veel in dit geval vanwege de cell architectuur.

Een 8-core AMD CPU kan best een hoop SIMD werk verzetten. En de reden dat Sony de cell architectuur heeft verlaten is omdat in de meeste games de cell architectuur (vanwege branches!) ongeschikt bleek. Als het eenvoudige SIMD is kan het prima op de GPU. Het zou me niet verbazen als bottom line de effecten elkaar opheffen.

Het zal vast niet voor alle games gaan werken, maar op zich denk ik dat het best mogelijk moet zijn. Het is alleen absoluut niet simpel om te bouwen... Wat dat betreft zou ik liever op het XBox emulatie team werken

Ander puntje dat denk ik veel relevanter is, is dat Microsoft gewoon een hoop meer ervaring heeft in-huis. Denk aan Hyper-V, de .NET JIT en de vele honderden projecten die het niet hebben gehaald, waarvan ik inmiddels de naam ook alweer ben vergeten.

[Reactie gewijzigd door atlaste op 23 juli 2024 19:34]

[.oisyn]

En de reden dat Sony de cell architectuur heeft verlaten is omdat in de meeste games de cell architectuur (vanwege branches!) ongeschikt bleek.

Volgens mij had het missen van een branch predictor weinig met die beslissing te maken. Het is vooral heel lastig om er generieke game code in te laten werken, omdat je effectief moet dealen met een expliciete cache: je kunt niet direct lezen en schrijven van en naar main memory, dat moet je schedulen met DMA transfers naar een zeer geringe lokale buffer van 256kB. Dat maakt de inzet van de SPE's voor de meeste zaken relatief lastig, en is het vooral nuttig voor specialistische toepassingen. Toepassingen waar je, zeker tegenwoordig met async compute, ook vaak gewoon de GPU voor kunt inzetten.

De reden waarom ik denk dat het lastig is om SPU code te converteren naar compute shaders is door de hele opzet van de SPE. Juist om dat je expliciet asynchrone memory transfers moet opzetten en ondertussen ander werk kunt doen, vertaalt dit zich niet makkelijk naar shader operaties. Bovendien heeft een GPU effectief natuurlijk een ontzettend veel bredere SIMD architectuur. Door daar SPU code op te gaan uitvoeren gooi je heel veel computational power weg. Ik vraag daarom ook af of ze er wel snel genoeg voor zijn.

[Reactie gewijzigd door .oisyn op 23 juli 2024 19:34]

[atlaste]

Volgens mij had het missen van een branch predictor weinig met die beslissing te maken. Het is vooral heel lastig om er generieke game code in te laten werken, omdat je effectief moet dealen met een expliciete cache [..]

Hmm, ik begreep juist dat de prepare-to-branche instructies die ipv. branch prediction zouden moeten werken (en je compiler mag emitten) niet echt goed bleken te werken in de praktijk (en dat voor de DMA transfers wel redelijk standaard oplossingen zijn inmiddels). Met expliciete async DMA transfers kan je proberen te werken met de AVX registers (als je er voor een beperkt stukje code toevallig genoeg hebt), maar in algemeen zin ontkom je er dan idd niet aan om de GPU te gebruiken.

En dan raak je een goed punt met emulatie via shaders. Vraag me wel af in hoeverre dat echt een probleem is: GPU's zijn een stuk sterker geworden dus je mag ook best een hoop computationele power weggooien. Met 5x zoveel gflops en 4x zoveel bandbreedte op de GPU zou het me niet verbazen als dat kan - je mag immers 75% van de kracht weggooien om het nog te laten draaien. Zeker ben ik er overigens helemaal niet van, ik denk dat het heel close gaat worden... then again, dat was het voor de XB1/XB360 ook.

[.oisyn]

Leuk om hier trouwens eens op niveau over te kunnen discussieren . Mag ik vragen wat je doet?

[atlaste]

Wederzijds

Sure, in een nutshell, ik bouw tegenwoordig aan een database engine in mijn eigen bedrijf (Nubilosoft). Is nog een WIP, maar er draaien al wel een paar klanten op; compatibility met bestaande systemen is best veel werk... Samenvattend besteed mijn dagen met zo veel mogelijk performance uit een machine drukken. Hiervoor CTO bij een bedrijf dat zoekmachines en web crawlers maakt, beetje hetzelfde werk maar dan anders.

Jij?

[.oisyn]

Game development, zie profiel . We ontwikkelen technologie en doen ports voor andere partijen. Pas nog de PS4 versie van Rise of the Tomb Raider afgerond. Optimization is dus ook een groot deel van mijn werk.

[kidde]

Maar - als ik het goed begrijp - CISC processors zetten toch via micro-code en een decoder 'complexe' CISC-instructies intern (dus in de CPU-hardware zelf) om naar RISC-instructies?

Het enige wat je dan nodig zou hebben, is een softwarematige decoder die je niet in de CPU maar in de 'emulator' stopt, om hetzelfde resultaat te bereiken. Zal iets trager zijn, maar lastig toch niet als je weet hoe de AMD64-decoder werkt? ARMv8-A heeft ook meer registers lees ik dan AMD64, dus dat zou ook allemaal goed moeten gaan.

Ellende is wel dat X86 ook nog 'ouderwetse' ondersteuning biedt voor de 16-bit programma's van eind jaren '80 of zo, het lijkt me dat je al die oude meek niet wil meenemen in een emulator.

[.oisyn]

Eigenlijk maakt het geheel niets uit. Sowieso is het hele RISC vs CISC verhaal tegenwoordig een wassen neus, want onder water is een typsiche x86 implementatie ook gewoon RISC. Het komt er in feite dus louter op neer hoe uitgebreid je instructieset is, maar de vertaalslag is in principe gewoon beide kanten op te maken, zolang je maar over de juiste primitieven beschikt (atomaire operaties laten zich bijvoorbeeld nauwelijks goed emuleren)

[Reactie gewijzigd door .oisyn op 22 juli 2024 13:48]

[--Andre--]

Zat i386 emulatie niet traditioneel in non-i386 NT builds? Dus dit lijkt me niks nieuws voor Microsoft.

[MSalters]

De DEC Alpha had inderdaad een i386 emulator, FX!32. Was alleen niet van Microsoft, maar van DEC.

[gabba25]

Dit wilde ik net tikken, maar je was me net voor. De xbox 360 backwards comp. werkt uitstekend. Je merkt niet eens dat je in een emulatie draait.

Dit maakt continuüm wel zeer interessant. Ik denk dat dit ook wel iets waar we heen gaan. Telefoons worden steeds krachtiger. Je telefoon docken en direct aan het werk. Ik heb zin in 2017

[Nactive]

Ik zou toch wel verwachten dat de ARM instructie sets nog redelijk mapt op de x86 instructie set. Een groot deel van de instructies zal wel overeen komen.

Dat komt het erop neer dat er een soort van JIT compiler tussen zal zitten. Over het algemeen zijn JIT compilers niet tergend traag en kunnen veel trukken met uitgestoken worden indien deze goed geoptimaliseerd wordt.

Ik wil dus nog wel eerst benchmarks zien voor ik dit zou afstempelen als een zeer zeer inefficiënte oplossing.

[BugBoy]

Problematischer wordt het voor gecompileerde code (naar assembly). Daarbij kun je niet eenvoudig instructies mappen. Code alignment en andere geheugen-layout wordt dan ineens van belang. Dat is echt wel lastig, maar MS heeft er wel de nodige ervaring mee. Hoop dat het ze lukt...

[mae-t.net]

Verwachten doe je alleen als je het niet zeker weet. Ik weet het helaas ook niet tot in detail, maar de instructiesets zitten fundamenteel best wel anders inelkaar. Mappen is dan misschien niet het goede woord. Ik verwacht op mijn beurt dat het nog best een leuke klus is maar beter te doen dan andersom (de ARM instructieset is flexibeler).

[DCK]

Toen Mac OS X van PowerPC naar x86 switchte werkten geemuleerde PowerPC-apps best prima, als je niet al teveel verwachtingen had van de applicatie. De meeste utilities werkten zonder problemen, en zelfs complexe PowerPC-apps als Office 2004 draaide redelijk op high end iMacs.

Laat het nu net zo zijn dat (in benchmarks) de high end iMac uit 2007 net zo snel benchmarkt als een high-end telefoon van nu.

Gegeven dat veel applicaties (Office, web browser) native zullen draaien, Microsoft gebruik kan maken van binary translation, en veel applicaties afhankelijk zijn van native draaiende .NET en Direct3D-libraries en denk ik dat dit een prima user experience wordt. Intel gebruikte ook een ARM-emulator/binary translator op x86 Android-telefoons, en die konden bv. gewoon native geschreven games zonder veel problemen spelen.

[Verwijderd]

Het zou technisch wel een prestatie zijn, maar ik vraag me af welk probleem het nou precies oplost. Men richt zich duidelijk op de zakelijke markt.

De veronderstelling is dus dat die nog veel x86 apps draaien. Dat klopt, en dat doet men doorgaans op een laptop danwel desktop, en Windows 10 zal W32 apps naar verwachting nog 10, misschien wel 20 jaar blijven ondersteunen.

Dus gaat het specifiek om mobiel en continuum. Gaat het zakenleven nou massaal met een W10 phone (die veel gebruikers misschien niet eens willen) en dock installaties zitten prielen om iets werkend te krijgen wat allang werkt op een normale laptop, welke helemaal geen probleem is om mee te nemen? Moet je daarvoor je hele bedrijf ombouwen?

En dit nog even los van het feit dat de desktop stervende is. Vrijwel alles is al naar het web verhuisd en naar de cloud, er blijft maar weinig op de desktop over.

Zoals gezegd, wellicht een grote technische prestatie, maar een doorbraak die nuttig is? Nah.

[Croga]

Ik zou een moord doen om mijn laptop thuis te kunnen laten.....

Helaas heb ik mijn nieuwe telefoon aangeschaft in de tijd dat de 950 net uit was en een fortuin kostte. Als ik nu zou moeten kiezen zou ik onmiddelijk een 950 met dock halen. En in plaats van een grote tas met laptop mee te moeten sjouwen zou m'n telefoon in m'n linkerzak en m'n dock in m'n rechterzak gaan.

Plots zou ik niet meer hoeven kiezen tussen iedere week op en neer vliegen of ruimbagage mee nemen. Ik zou gewoon m'n cabin bagage kunnen vullen met kleding in plaats van electronica. Scheelt me al snel een paar uur per week; of aan inchecken, of aan extra vluchten.

Ik zou me ook nooit meer zorgen hoeven maken of ik m'n presentatie wel bij heb. Het ding staat op m'n telefoon; natuurlijk heb ik die bij. Of m'n laptop voeding.... m'n telefoon werkt ook gewoon op een 2A universele USB voeding dus een keer m'n voeding vergeten is geen enkel probleem.

Nee, al met al zie ik zeker een sterke case voor Continuum, zeker als het volledig Win32 gaat. Ik zou er dan sterk over denken alsnog die 950 aan te schaffen, ondanks dat min Nexus 5X prima voldoet.

[Verwijderd]

Er zijn natuurlijk altijd (extreme) gevallen te bedenken waarbij het voordeel buitensporig is, maar ik denk meer in algemene termen.

De meeste mensen reizen zeer korte afstanden met een laptop. Die laptop, volledige kracht mobiel, heeft ook voordelen, bijvoorbeeld kunnen werken in een trein, maar ook een vliegtuig. Of je moet naar een klant, of naast een collega zitten waar geen extra dock is.

Al met al is voor veel mensen een laptop een zeer kleine last tegenover heel veel voordelen. Daarom denk ik dat het een probleem oplost wat er niet is, tenzij de hele wereld uit docks bestaat, maar dat is niet zo.

[Croga]

De meeste mensen reizen zeer korte afstanden met een laptop. Die laptop, volledige kracht mobiel, heeft ook voordelen, bijvoorbeeld kunnen werken in een trein, maar ook een vliegtuig. Of je moet naar een klant, of naast een collega zitten waar geen extra dock is.

Je realiseert je dat het dock waar we het hier over hebben nauwelijks groter is dan de telefoon zelf? Je dock heb je dus gewoon altijd bij je, telefoon en dock bij elkaar zijn nogsteeds niet een kwart van het formaat of het gewicht van een laptop.

Al met al is voor veel mensen een laptop een zeer kleine last tegenover heel veel voordelen.

Klopt. Heb je overigens de "laptops" al gezien die je via USB-C aan je telefoon aan kunt sluiten? Weegt niets aangezien er nauwelijks hardware in zit en tovert je Continuum telefoon om in een volwaardige laptop. Mocht je toch die laptop nodig hebben......

Al met al geeft Continuum je vooral één heel belangrijk ding wat een laptop je niet geeft: Keuze mogelijkheden. Met een 950 kun je kiezen om te werken alsof het een desktop PC is, je kunt kiezen om te werken alsof het een laptop is, je kunt kiezen om te werken alsof het gewoon een telefoon is.

[Verwijderd]

"Je realiseert je dat het dock waar we het hier over hebben nauwelijks groter is dan de telefoon zelf? Je dock heb je dus gewoon altijd bij je, telefoon en dock bij elkaar zijn nogsteeds niet een kwart van het formaat of het gewicht van een laptop."

Waarbij je tig dingen vergeet: een dock heeft geen scherm. Je kunt dus niet fatsoenlijk mobiel werken. En je hebt niet de accu capaciteit of de rekenkracht op mobiele wijze beschikbaar. Een laptop heeft dat allemaal wel.

[Croga]

waarbij je tig dingen vergeet: een dock heeft geen scherm. Je kunt dus niet fatsoenlijk mobiel werken. En je hebt niet de accu capaciteit of de rekenkracht op mobiele wijze beschikbaar. Een laptop heeft dat allemaal wel.

En zoals al vermeld; als je dat persé nodig hebt dan koop je er een "laptopdock" bij; een scherm/toetsenbord/trackpad/accu combo die je via USB-C aan kunt sluiten op de telefoon en plots heb je wél een scherm en accu.

Overigens zijn mobiele CPUs tegenwoordig aardig krachtig aan het worden. Je zult vergelijkbare processing power hebben als in een Macbook. En dat is meer dan genoeg voor een mobiele laptop gebruiker.

Zoals gezegd: Het geeft je opties. Je krijgt één apparaat wat je op dezelfde manier kunt gebruiken als 4 andere apparaten zonder dat je die 4 apparaten nodig hebt.

[Verwijderd]

"En zoals al vermeld; als je dat persé nodig hebt dan koop je er een "laptopdock" bij; een scherm/toetsenbord/trackpad/accu combo die je via USB-C aan kunt sluiten op de telefoon en plots heb je wél een scherm en accu."

Handig zeg. Bij elkaar lijkt het wel gewoon een laptop.

[Wvdlinden1]

https://youtu.be/aag1P4OwA3s

[Verwijderd]

Wat moet ik met dat filmpje?

[mavaros]

Uw laatste stukje tekst slaat prima op het filmpje.

[r2504]

Je hoopt dat het lukt voor Windows Mobile... ik mag dan hopen dat je een Windows phone hebt, of geef je het platform zelf ook geen kans en zit je gewoon op Android of iPhone af te wachten tot de rest het doet ?

Moesten wat meer mensen de stap hebben gezet ipv. te zeuren over de app-gap dan hadden we nu misschien een mooi alternatief.

PS. Ik blijf ondertussen nog wel even volharden (en van die app gap heb ik nog steeds geen last).

[yoranpower]

App gap bestond vroeger ook echt wel, en was toen ook wel een reden voor vele mensen hoor. Veel apps waren alleen te vinden als 3rd party apps en dus kan snappen dat mensen daarom geen Windows Phone namen.

Ik ben zelf ook recentelijk overgestapt op een android device, maar dit is puur omdat Microsoft dit jaar weinig aan zijn phone divisie doet. Als gewoon wat meer fabrikanten Windows toestellen maken zou het misschien ook wat aantrekkelijker worden weer een nieuwe te nemen. Hopelijk mag ik over een jaartje dit device weer inruilen voor een WP device.

[PeterKer]

Ik zit in hetzelfde schuitje...ik ben enorm fan van het Windows OS en op de desktop schittert Windows 10 echt. Maar Mobile krijgt gewoon nog te weinig aandacht. En met mijn oude hardware en nog niks nieuws aan de horizon ga ik over naar Android, maar als er een Surface Phone uitkomt met een sterk continuum ben ik weer terug. Ik geef gelukkig niks om snapchat en dat soort apps, dus heb van appgap eigenlijk geen last.

[yoranpower]

Misschien leuk detail om te weten dan, HP en Microsoft werken aan een nieuw Windows 10 Mobile product dat voor consumers gericht is. Beetje als de HP X Elite, maar met de snufjes van de Lumia! Dus als je nog niet klaar bent om naar android te gaan is dit een leuke optie voor rond februari/maart 2017.

[barta123]

Volledig met je eens, maar ik denk dat Microsoft (nu met Satya Nadella aan kop) alleen met een product gaat komen dat de markt zal veranderen. Daar waar Surface dat ook heeft gedaan... Ik begon een jaar geleden met een Surface 3, (2GB RAM) die ik nooit verwachtte veel te gaan gebruiken. Wat denk je? Ik gebruikte het ding zo veel dat ik recentelijk een Surface Pro 4 heb gekocht. Wat een geweldig product! (als digitaal labjournaal op een laboratorium & om aantekeningen te maken tijdens college)

Qua OS vind ik W10M stukken bruikbaarder dan Android, stabieler is het inmiddels ook zeker wel (sprekende over een Xperia met Android 6.0 als input). Ik houd mijn vingers gekruist en wacht met enig optimisme af wat Panos Panay als extra telg van de Surface (Surface Phone aka Panos Phone) gaat brengen...

De komst van de Surface Studio heeft volgens mij ook menigeen verbaasd!

[Reactie gewijzigd door barta123 op 23 juli 2024 19:34]

[BugBoy]

Mijn vriendin heeft een Windows Phone (640XL), omdat die voor haar prima voldoet.Hele fijne telefoon. Ik kan geen Winddows Phone gebruiken, omdat er gewoon teveel applicaties niet voor beschikbaar zijn (DJI, KNAB, FlitsMeister, ...). Ook mijn Wahoo fitness devices worden niet ondersteunt. Daarbij worden een aantal bedrijfsmatige applicaties alleen maar op iOS/Android geleverd.

Microsoft heeft het grotendeels aan zichzelf te danken. Met WM6.5 heeft Balmer nog de iPhone uitgelachen. Foute inschatten en dat kan, maar het heeft wel heel erg lang ingezien om tot inkeer te komen. Google was er sneller bij met aanpassingen aan Android...

[r2504]

Heb je de betreffende bedrijven laten weten dat je een Windows Mobile app wou ?

Android had in het begin ook geen apps... soms moet je in iets geloven (en bedrijven afstraffen die geen app willen ontwikkelen in plaats van ze achterna te lopen).

[BugBoy]

Onze bedrijfsapps gaan echt neit gebeuren. Kan gewoon echt niet uit en het zou een beetje onzin zijn dat ons bedrijf gaat verliezen om WP te willen ondersteunen.

KNAB heeft het in hun backlog staan (al jaren), FlitsMeister heeft de ondersteuning net gestopt en DJI heeft alleen een out-dated applicatie. Ondanks dat ik het graag zou zien slagen snap ik wel dat een bedrijf geen investeringen doet die zich waarschijnlijk niet terugverdienen. Marktaandeel van WP is erg laag en dalende.

Microsoft heeft het grotendeels zelf verprutst. Te arrogant in het begin en te laat ingezien dat het met WM de verkeerde kant opgaat.

[r2504]

Voor mobile only apps is het een ander verhaal... maar voor apps die ook bruikbaar zijn op een tablet/laptop/desktop is het toch een compleet ander verhaal dankzij UWP al blijken bedrijven daar ook de nodige weerstand te bieden.

Maar inderdaad... de schuld ligt grotendeels bij Microsoft zelf.

[BugBoy]

Ik ben zelf al ruim 20 jaar professioneel Windows ontwikkelaar. Het duurt gewoon een tijdje voordat de overstap gemaakt wordt. In het begin was het C+Win32. Dat verschoof langzaam naar C++/MFC en dat ging weer langzaam richting .NET/WinForms. Daarna kwam .NET/WPF, maar door de opkomst van HTML5 is er ook een deel verschoven naar webapplicaties (en nu ook nog Electron based).

UWP is weer iets nieuws, maar beperkter dan .NET/WPF waardoor veel bedrijven toch in dat laatste blijven hangen. Daarbij is de markt nu veel diverser (WPF, HTML5 en allerlei andere mobile systemen). Om eerlijk te zijn snap ik wel dat de gemiddelde programmeur onderhand verward is.

Een ander punt vind ik het een risico om UWP te gaan ontwikkelen. Je hoort ook dat Windows Mobile minder aandacht heeft en als daar de stekker uit gaat, wat heeft dat dan voor consequenties voor UWP? Met Silverlight heeft MS ook plotseling de stekker eruit getrokken. Dat heeft een aantal bedrijven heel veel pijn gedaan. Dat je daarna kiest voor een open architectuur (bijv. gebaseerd op Javascript) i.p.v. een eigen MS oplossing snap ik ook wel.

[barta123]

Ik denk dat Satya Nadella toch wel een iets andere (en betere) visie heeft op wat Mobile moet zijn, Microsoft heeft volgens mij nooit de maatstaf bepaald met hardware producten. Maar kijk eens naar de Surface-reeks (die met de komst van Satya Nadella onder invloed van Panos Panay) die in mijn ogen toch echt wel geslaagd zijn...

[Verwijderd]

En ik heb Microsoft als native developer de rug toegekeerd vanwege net core en uwp, teveel xml, dependencies en garbage collection. Na tomcat en Java tuning ben ik in het algemeen klaar met garbage collection. In mijn geval zijn er nieuwe problemen en inefficienties geïntroduceerd door het probleem van slordige programmeur die niet snapt wat 'ie doet te verergeren. Ik hoop vurig dat er een performance label met CO2 uitstoot en milieuvervuiling op software komt en proportioneel belast wordt zodat we de besparingen op arbeidsuren kunnen afzetten tegen de werkelijke kosten. Ik ben niet tegen abstractie, maar vindt garbage collection in Java en net erg slecht, en nog slechter dat Microsoft zijn eigen alternatief voor Java heeft gemaakt dat praktisch is beperkt tot het Windows platform (ja, niet in theorie). Als het cross platform moet en kan niet in Html5/nodejs, dan Java, maar net voegt als middenmoot niks toe. Alle tooling is bloatware.

[MSalters]

Lol, klagen over bloatware en Garbage Collection, en dan Node.js (Javascript) noemen. Hint: er is een goede reden dat je in Javascript geen malloc/free calls hebt.

[.oisyn]

Je hebt wel new en delete

[Wolfos]

Andersom werkt in ieder geval prima. Je kan via Bluestacks Android apps draaien op een x86 tablet, zelfs als deze alleen voor ARM gecompileerd zijn. Met de snelheden van hedendaagse ARM processoren zou het me niet zoveel verbazen als de meeste (niet te zware) applicaties op volle snelheid zouden draaien.

[raro007]

ik heb liever dat linux op de desktop een succes woord..

[TheMaurice]

Inderdaad.. ik verbaas me er soms over dat er zo weinig support voor zoiets moois is. Iets door de community gemaakt, open-source, in plaats van een grote winst-gerichte corporatie.

[Verwijderd]

Dat heeft de community aan zichzelf te danken, met zijn tienduizend distros, waarbij er geen enkele gebruiksvriendelijk is voor de massa.

Ubuntu doet een poging, maar heeft nog steeds niet de "polish" van een consumenten OS. Linux fanaten vinden het natuurlijk geweldig dat alles open is en aan te passen, maar daar heeft een normale gebruiker niets aan.

Wat Linux naar mijn mening nodig heeft is een distro die in de buurt komt van OSX. Een super goed OS onder de motorkap (Linux is superieur aan Windows), met daarbovenop een hele mooie, goed afgewerkte UI.

Maar helaas, Linux is en blijft voor hobbyisten.

[jaquesparblue]

jij denkt dat de bedrijven achter distros als Ubuntu, Red Hat of Suse niet op winst gericht zijn?

Ander business model, maar wel degelijk bedrijven die gewoon voor de winst gaan.

[bazs2000]

Mooi? Zeker, gaat het gebeuren? Misschien ooit al zal het eerdere een gezonde mix zijn dan een volledige overstap.

Vergeet niet dat er evengoed support op gegeven moet worden, applicaties geschreven moeten worden etc. Op de lange termijn zal het kostenplaatje er hetzelfde uitzien als wanneer er alleen Windows zou worden gedraaid.

Op de korte termijn zullen de kosten zelfs nog hoger uitvallen (bouw van applicaties, support, scholing, etc).

Jij gelooft erin, dat is heel goed alleen is jouw verwachting niet heel realistisch.

[Wolfos]

Kijk eens naar het proces dat vereist is om grafische drivers te installeren op Linux. Dan snap je wel waarom het niet aanslaat bij de massa.

[HgnX]

Dit wordt een steeds kleiner probleem in de toekomst. Arm wordt krachtiger.

[Loller1]

Redstone 2 en 3 lijken Continuum op smartphones beide een heel stuk bruikbaarder te gaan maken. Voor Redstone 2 wordt Continuum al een echte desktop omgeving met meerdere vensters, snap een eigen startmenu, etc. Als Microsoft dit voor elkaar krijgt met Redstone 3 zijn we daadwerkelijk aan het punt gekomen waar je smartphone je PC kan vervangen. Al is dat maar alleen voor casual users.

[Timoo.vanEsch]

en business clients/management clients.
Mensen die hun LT vooral gebruiken voor emails, powerpoints en simpele spreadsheets.

[Swerfer]

Die kant zal het zeker op gaan en vergeet ook niet dat je in continuum prima kan connecten met een remote desktop/server, en je printer veel overige devices worden ook al rechtstreeks door W10M ondersteund. Je telefoon kan nu al een volwaardige thin-client zijn...

[brick5492]

Iemand met enige technische kennis hierin een idee hoe ze dit zouden doen? Ik ben zeer benieuwd hiernaar, maar me lijkt dit heel erg onbruikbaar toch? X86 emulatie op ARM zorgt er bij bijvoorbeeld Bochs op Android voor dat je Windows XP in een halfuur kan booten op de nieuwste Android flagships, hoe zouden ze dit ooit zo goed kunnen optimaliseren?

[BugBoy]

Schot voor de boeg... De onderliggende AP en kernel zijn wellicht wel native beschikbaar, dus ze hoeven alleen de applicatie zelf te emuleren. Dat kan al een hoop schelen. Een applicatie bestaat vaak uit APP + API + KERNEL. Bij een volledig OS emulatie moeten alle drie lagen worden geemuleerd. In dit geval is het (mogelijk) alleen de APP laag. Vooral een kernel laag emuleren is erg CPU intensief, omdat je ook drivers moet virtualiseren.

[MSalters]

Ook .Net kan native draaien. UWP gebruikt de onderliggende .Net CLR, maar die CLR kan in principe alle .Net code draaien. De belangrijkste UWP beperking is dat niet alle libraries toegankelijk zijn, maar dat is een keuze.

[BugBoy]

Dat is slechts ten dele waar. UWP is gebaseerd op .NET core en die kan inderdaad op ARM werken. Het tradionele .NET framework (dat vrijwel alle applicaties nog gebruiken) is x86 only. Kleine delen van de .NET library zijn zelfs in assembly geschreven of leunt erg sterk op de interop laag.

[MSalters]

.Net framework, de x86 variant is eigenlijk alleen maar x86 vanwege de incidentele call naar een native library. Dat deel kun je perfect emuleren; alls IL code in .Net Framework is portable.

[.oisyn]

Bochs is een ontzettend slecht voorbeeld, want dat is een typische interpreter die gewoon instructie voor instructie bepaalt wat er gedaan moet worden. Als een functie meerdere keren wordt aangeroepen, dan worden de instructies van die functie ook meerdere keren geïnterpreteerd.

Een goede emulator past een vorm van JIT toe waarbij hele lappen code worden vertaald naar en geoptimaliseerd voor het doelplatform. Het voordeel is dat je dat maar 1 keer hoeft te doen (of typisch wordt er eerst snel een ongeoptimaliseerde versie gemaakt, en als blijkt dat een bepaald stuk code vaak wordt aangeroepen wordt hij alsnog geoptimaliseerd). Deze vertaalslag kan worden opgeslagen, en uiteindelijk heb je dus gewoon te maken met een "native" applicatie.

Ik kan me ook best voorstellen dat deze resultaten worden gedeeld, of dat bijvoorbeeld cloud computing wordt ingezet om de initiele vertaalslag te maken. Veelgebruikte apps zijn dan gewoon al een keer vertaald, en dan is het een kwestie van de binary downloaden.

Verder heeft BugBoy natuurlijk een heel belangrijk punt: de vertaalslag gaat alleen over de applicatie, niet over het gehele OS. De API calls kennen al gewoon een native ARM implementatie.

[Reactie gewijzigd door .oisyn op 23 juli 2024 19:34]

[Peetz0r]

Ik neem aan dat ze niet het hele OS emuleren, maar enkel losse applicaties. En het zal niet meteen om de zwaarste applicaties gaan.

Verder, performance van het booten zit voor een groot deel in storage en geheugen. Dit is in telefoons wel vaker traag. En XP is zelf ook al niet al te efficient. Ik denk dat Microsoft hier wel iets werkbaars van weet te maken, maar we zullen zien.

[spNk]

Ik durf mijn hand er voor in het vuur te steken dat storage van een moderne smartphone vele malen sneller is dan storage uit het XP tijdperk hoor, daar zal het echt niet aan liggen.

[Gomez12]

Simpel : door het niet te doen... Door gewoon een Arm (XP) windows 10 te hebben.

Het kost giga-veel performance om directx te emuleren omdat die dicht op de hardware zit en gigantisch veel doet. Maar een applicatie oid hoeft maar heel weinig directx-calls te doen.

Waar een directx veel moeite moet doen om een scherm wit te krijgen (in principe moet elke pixel wit worden), daar hoeft een app slechts tegen directx te zeggen : wit scherm.

Oftewel het kost veel performance om directx te emuleren, terwijl de app zelf helemaal niet zoveel performance vraagt.

[MSalters]

Ehm, zo werkt DirectX ook niet hoor. DirectX is een GPU schil, die vertaalt het gewoon naar een NVidia of AMD commando, of nu misschien OpenGL. "Wit scherm" is gewoon "wit texture, 1x1 pixel, oprekken naar 1680x1050"

[--Andre--]

Voor zover ik weet staat Microsoft het nog steeds niet toe om 3rd party ARM executables uit te voeren. Waarom ze dat niet toestaan? Zou toch veel beter presteren dan i386 executables op een ARM chip te draaien dmv emulatie?

[.oisyn]

Die twee zaken hebben compleet niets met elkaar te maken. Ik neem even aan dat je met "3rd party executables" eigenlijk bedoelt applicaties buiten de store om installeren (want in de store staan ook gewoon 3rd party applicaties). Dat kan gewoon, dan moet je je telefoon in developer mode zetten (dat kan iedereen) en dan kun je applicaties "sideloaden" zoals dat heet.

Maar het gaat hier helemaal niet om zomaar wat applicaties die gecompileerd worden voor ARM. Het gaat om het beschikbaar maken van de gehele win32 bibliotheek aan applicaties die door de jaren heen is gemaakt. Natuurlijk komen daar geen ARM versies van.

[Reactie gewijzigd door .oisyn op 23 juli 2024 19:34]

[Peetz0r]

Een alternatief hierop biedt HP bijvoorbeeld in de vorm van de Elite x3, die voor zakelijke gebruikers een streamingdienst ontworpen heeft die x86 apps draait. Ook kunnen gebruikers met een remote desktop-opstelling x86 apps draaien. Emulatie van x86 zou echter wel duidelijk efficiënter zijn dan deze oplossingen.

Dat is natuurlijk compleet afhankelijk van hoe goed de emulatie werkt en hoe snel de cpu is enerzijds, en hoe snel het netwerk is en hoeveel capaciteit je rdp/terminal/streaming-server heeft anderzijds.

Natuurlijk heb je straks de keuze uit beide oplossingen, dat lijkt me het beste voor iedereen

[Ayyylias]

Nu nog continuum op de L930

[warhamstr]

Waarom op zo'n oude telefoon?

[Ayyylias]

Zijn er nog redelijk wat die het toestel gebruiken (inclusief mij)
En omdat het kan ;D, het zal vast niet perfect zijn(in de zin van snelheid) maar het is iets leuks om te hebben en om mee te spelen

[warhamstr]

Gaat zviw nooit gebeuren door missende hardware.

[Ayyylias]

later bleek deze hardware niet nodig te zijn

[synoniem]

Heeeeel lang geleden deed Digital iets vergelijkbaars met X86 applicaties voor de DEC Alpha processor, namelijk eenmalig binair converteren van X86 naar Alpha. Na die eenmalige conversie was de snelheid van de geconverteerde programma's over het algemeen goed te doen. Aangezien de DEC Alpha via Digital bij HP terecht is gekomen zou mij het niet verbazen als ze deze techniek nu weer van stal gehaald heeft.

[xalvo]

Ik hoop van harte dat dit meer dan een gerucht is. Ik gebruik nu zelf sinds een half jaar een Windows Phone en ik vind het een verademing.
Als dit gerucht waar is krijg ik ook weer wat meer hoop op een derde grote speler op de mobile os markt. Dat Microsoft inmiddels zijn mobile development team tot een 20-30 man beperkt schijnt te hebben gaf namelijk niet bijzonder veel hoop voor de toekomst die ik het OS toe wens naar aanleiding van mijn huidige ervaring er mee.

[ardvark99]

Wat er niet wordt vermeld in dit artikel, is dat de ondersteuning waarschijnlijk op ARM64 wordt gebouwd. http://www.windowscentral...-mobile-get-x86-emulation

Nu is W10M nog 32 bits, maar in januari of februari werd het al bekend dat er ook een 64 bits W10M gaat komen (http://www.windowscentral...pport-windows-10-redstone). En waarschijnlijk kan je niet de standaard x86 applicaties draaien, maar zullen ze geconverteerd moeten worden naar UWP met bijvoorbeeld de Desktop App Converter van Microsoft.

De komende Redstone builds gaan in ieder geval veel beloven voor Continuum. En naar mijn mening wordt de kracht van UWP nog te veel onderschat door bedrijven. Met een app verschillende devices ondersteunen.

Edit: Links toegevoegd.

[Reactie gewijzigd door ardvark99 op 23 juli 2024 19:34]

[sjun]

Ik wacht wel ff totdat er gewone x86 massaler processors in een telefoon gestopt worden. Eigenlijk had ik dat dit jaar al verwacht. Vanaf dat moment is het ook direct gedaan met de appgap en kunnen telefoons met een volwaardig OS worden uitgeleverd. Microsoft en Linux zullen direct op de wagen springen maar Apple zal vast zo lang mogelijk haar verkreupelde IOS willen uitmelken in plaats van met een MacOS telefoon te komen.

Niettemin voor wie nu al een Lumia 950, HP Elite X3 of andere Windowsequivalent heeft is het goed nieuws.

[Reactie gewijzigd door sjun op 23 juli 2024 19:34]