Microsoft toont hoe emulatie x86-programma's op ARM-versie Windows 10 werkt

Microsoft heeft in een screencast laten zien hoe emulatie van x86-software op Windows 10 met ARM-processors zal gaan werken. De eerste laptops en 2-in-1's met ARM-processors komen voor het einde van het jaar uit, zegt Microsoft.

Microsoft geeft de uitleg in een dertien minuten durende video die het bedrijf tijdens zijn ontwikkelaarsconferentie Build online heeft gezet. Voor de demonstratie gebruikt Microsoft een testapparaat van Qualcomm, een zwart kastje met daarin een systeem op basis van de Snapdragon 835-soc. Dat is de nieuwste high-end soc van de Amerikaanse processormaker.

Microsoft gebruikt voor de emulatie dezelfde Windows-on-Windows-laag als voor de emulatie van x86-software op 64bit-systemen. Omdat de emulatie van x86 op ARM-processors niet in hardware kan, zoals bij x64-processors, gebruikt Microsoft iets dat het Compiled Hybrid Portable Executables noemt. Dat zijn dll's met daarin ARM-code. Die code slaat het systeem op in het geheugen om snel te kunnen gebruiken. Daarnaast zit er een softwarematige emulator in het systeem.

Alle UWP-apps uit de Windows Store draaien uiteraard native op het ARM-systeem, omdat die onafhankelijk van processorarchitectuur zijn geschreven. Ontwikkelaars van zowel UWP- als x86-software hoeven niets te doen om hun programma's te laten werken op de komende ARM-hardware met Windows 10.

Microsoft noemt het ARM-systeem Windows 10 Pro in de systeemeigenschappen. Het bevat ook functies die in de normale versie van Windows zitten, zoals Hello, Cortana en domeinbeheer. Microsoft kondigde de ARM-versie van Windows 10 in december vorig jaar aan.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (109)

[Martinspire]

Er zijn eigenlijk 2 vragen die beantwoord moeten worden:

1) Kan het überhaupt?
2) Is het dan ook bruikbaar

Iets zegt me dat ze straks nummer 2 vergeten. Sure, ARM processoren worden sneller en sneller, maar je hebt er weinig aan als je nog tot 2020 moet wachten voor het een beetje bruikbaar is. En de Tweaker zal misschien wel genoegen nemen met wat traagheid, de consument en het bedrijfsleven echter niet. Die verwachten dan een laptop (of mobiel) die snel genoeg is om alles normaal te draaien. Kan dat niet, dan faalt het enorm.

[Reactie gewijzigd door Martinspire op 23 juli 2024 03:07]

[.oisyn]

De x86 code wordt JIT getranslate naar ARM code en opgeslagen. Er is geen enkele reden om aan te nemen dat dat heel traag zou zijn in de dagelijkse praktijk (wellicht de eerste keer dat je iets opstart), anders dan de gebruikelijke verschillen in hardware karakteristieken tussen ARM en x86.

De mythe dat instructie emulatie traag is komt denk ik voort uit oude game console emulators, maar die emuleren doorgaans instructie voor instructie en voeren dan uit wat de instructie doet, ipv een blok van instructies te vertalen naar geoptimaliseerde machinecode. (Plus natuurlijk het feit dat die emulators ook nog eens de hardware van de video en audio chip moeten emuleren in software). Wat MS hier doet is eigenlijk gewoon vergelijkbaar met Java bytecode en .Net IL^*. Zij hebben daar natuurlijk door .Net en Xbox 360 emulation een hoop ervaring mee. En dan is de Xbox 360 extra lastig omdat dat een big endian platform is waardoor alle standaard datatypes omgekeerd in het geheugen staan tov x86.

^* Ik zal de "Java = traag" opmerking maar vast even voor zijn: nee, Java is niet traag. Wat je doorgaans als traag ervaart is de implementatie van de UI, maar dat ligt aan de implementatie

[Reactie gewijzigd door .oisyn op 23 juli 2024 03:07]

[Anoniem: 80910]

Volgens mij is het verschil heel simpel:
qua instructieset wordt normaliter in "fast cache" op de cpu gezet. Deze instructieset is niet aanwezig in arm. Wat doet windows: Deze zet deze instructieset (emulatie) in het extended geheugen. Dit is langzamer dan de "fast cache" maar als een applicatie deze slechts enkele keren aanroept is het nog steeds snel, als deze frequent wordt aangeroepen dan zal het vanwege emulatie iets langzamer zijn dan native (lees het verschil tussen "fast cache" & extended memory wat bij ddr4 geloof ik op 15000MB/sec ligt (dus ik denk dat arm & snel geheugen dit probleem oplost voor de meeste applicaties simpelweg omdat het snel genoeg is (die paar msec.))

Daarnaast heb ik vroeger in Java geprogrammeerd (10 jaar geleden). Simpel voorbeeld: een button in UI. De ene keer kreeg ik binnen een paar msec. een alert met clicked, echter soms duurde dit ook een paar seconden. Dat lag echt wel aan java en niet aan mijn code...

[Reactie gewijzigd door Anoniem: 80910 op 23 juli 2024 03:07]

[.oisyn]

Je hebt het hier over verschillen in hardware. Natuurlijk is een ARM CPU langzamer dan een gemiddelde moderne x86 desktop CPU. Net als dat een Intel Atom ook langzamer is dan een i7. Dat heeft niets met emulatie te maken.

En wat Java betreft, ik had het over de implementatie van de UI in de Java libraries. Swing is bijvoorbeeld een ontzettend bloated UI framework wat enorm geabstraheerd is. Niet over het feit dat dat aan de code van de applicatie zelf ligt (al kan dat natuurlijk net zo goed). Jouw conclusie kun je uit jouw test helemaal niet trekken, want je hebt geen informatie over wát er nou speciek traag was.

Overigens was het in het verleden ook nog eens zo dat de HotSpot VM van Java niet standaard was bij de consumer installaties ervan. Die had je alleen bij de 64 bist server edities (geloof ik). Geen idee wanneer de switch is gemaakt, maar kan best dat jij daar 10 jaar geleden ook tegenaan liep.

[Reactie gewijzigd door .oisyn op 23 juli 2024 03:07]

[rjmno1]

Het heeft ook te maken hoe het geprogrammeerd is die arm processor met die windows erop is weer andere koek.
Denk eraan dat dit geheel helemaal niks te maken heeft wat we thuis gebruiken.
We zitten allemaal achter onze amd of intel processor met hardware wat microsoft al jaren gebruikt.Deze arm processor werkt heel anders, het geheugen word heel anders aangesproken,je kunt het niet vergelijken met een gewone pc.
Maar ik vind het wel een slimme stap van microsoft omdat het besturingssysteem ook deze computers en onderdelen ondersteunt, en dat het allemaal maar mooi draait, geloof me maar dat er wel wat programeer uurtjes erin zit voordat ze dit werkend hebben gekregen. En omdat sommige programma's het toch doen (winzip) kan ik alleen maar positief noemen.
Ga zo door microsoft.

[.oisyn]

Deze arm processor werkt heel anders, het geheugen word heel anders aangesproken,je kunt het niet vergelijken met een gewone pc.

Eigenlijk is dat helemaal niet zo. Natuurlijk, de karakteristieken verschillen. De x86 is zeer goed in memory access- en branch prediction, wat op andere platforms doorgaans een stuk minder is. De bottlenecks gaan dus op andere punten liggen - waar je op de PC misschien voornamelijk ALU of instruction bound was, ga je nu memory bound zijn. Vooral ongeoptimaliseerde code runt op een x86 vaak beter dan op een andere architectuur. En laten we wel wezen, het gros van de applicaties is idd ongeoptamaliseerd.

Maar het is ook weer niet zo dat alles echt substantieel anders is, of dat je op de ARM anders zou programmeren dan op een x86. Ik heb tijdens mijn werkzaamheden behoorlijk wat verschillende architecturen de revu zien passeren, inclusief ARM, maar programmacode blijft gewoon dezelfde programmacode, en het is vrij zeldzaam dat je voor specifieke optimalisaties de boel ineens heel anders gaat benaderen.

[batjes]

NT doet al het spreken met de hardware. Het OS als in, Windows, doet hier niets mee. Hoe het geheugen aangesproken wordt zal Windows en de applicatie die hier op draait, een rotzorg wezen. Hoe het draw X, doe zus, start dat, kopieer dat daarheen, sluit dit en al die win32 calls vertaald, zal de applicatie ook aan zijn achterste oxideren.

MS heeft de X86 > ARM transitie laag al een paar jaar klaar liggen. Het was voornamelijk de rest van het OS verder klaar maken om fatsoenlijk op de zwakste hardware te kunnen draaien en wachten tot de ARM CPU's die sterk genoeg waren de markt in kwamen.

Er zitten genoeg programmeeruurtjes in, de grondbeginselen hiervoor zijn al antiek. NT is opgebouwd om dit soort zaken te ondersteunen. Maar de eerste echte stappen hiertoe werden door MS dacht ik na Windows 7 gezet.

Nu ze met Windows 10, eigenlijk alle antieke stukjes Windows eindelijk vervangen en opgeschoont hebben, de hardware eindelijk bij is. Zien we langzaam wat meer tot waar toe NT in staat is. Echt interessant om te zien hoe iets wat 20 jaar geleden in gang is gezet, nu eindelijk eens zo ver begint te komen.

[freaky]

Zal enigszins samenhangen met wat je doet. Nieuwe Intel CPU's hebben bijv. instructies die x265 aanzienlijk versnellen. Dat kan niet anders dan (aanzienlijk) trager zijn op een CPU die dat soort functionaliteit simpelweg niet heeft.

[.oisyn]

Maar die applicaties werken net zo goed niet op oudere x86 CPU's, dus dat is niet echt een eerlijke vergelijking.

[freaky]

Goed punt, maar wel lastig. Wellicht dat ze nog terug kunnen vallen op SSE instructies bijv., dan er is nog wel wat versnelling met wel minder dan met de genoemde functie maar potentieel nog steeds aanzienlijk meer dan op RISC instructieset.

Het is heel erg code/compiler afhankelijk.

[Jerie]

Hmm ik dacht juist dat o.a. ARM en POWER beide konden: https://en.wikipedia.org/wiki/Endianness#Bi-endianness
Ben ook opzeker ARM tegengekomen die in big endian mode gebruikt werkt.

[.oisyn]

Hmm ik dacht juist dat o.a. ARM en POWER beide konden

Maar x86 kan alleen little-endian, en de PowerPC in de Xbox360 was iig geconfigureerd om big endian te zijn (en ik denk dat die uitvoering ook niet anders kan, anders hadden ze 'm echt wel little endian gemaakt om meer compatible te zijn met de PC). Er moet dus hoe dan ook een conversiestap plaatsvinden in het geval van Xbox 360 emulatie op de Xbox One.

[Reactie gewijzigd door .oisyn op 23 juli 2024 03:07]

[Jerie]

Je vragen zijn wel praktisch, maar te extreem.

1) Kan het überhaupt?

Ja, en het kan al tijden, met bijvoorbeeld Qemu. Een betere vraag is: "Kan het efficient genoeg?" HVMs zijn tegen de 100% efficient. Maar dit?

2) Is het dan ook bruikbaar

Bruikbaar hangt van meer af dan de efficientie. Het hangt ook af van backwards compatibility, de gebruikersvriendelijkheid van een eventuele UI.

Bruikbaar is het uiteindelijk zeker. De hardware in mid-end en zelfs low-end telefoons is goed genoeg om ook een x86-32 applicatie zoals Office te draaien. Uiteindelijk zal een consument z'n PC de deur uit kunnen doen en gewoon z'n spelcomputer, tablet, of telefoon aan een beeldscherm + toetsenbord kunnen hangen met een volledige W10 (of opvolger) omgeving. Een betere vraag is: "Wanneer is dit bruikbaar?"

Idealiter wil je een seamless drop-in replacement met een efficientie die nagenoeg 100% is. Volgens mij is het hele doel van dit filmpje om juist te bewijzen dat dit kan, inclusief roadmap.

[Reactie gewijzigd door Jerie op 23 juli 2024 03:07]

[ard1998]

1) ja, het kan. alles kan geemuleerd worden.
2) ik verwacht een paar implementatiefouten in de vroege fases (waarin de normale consument als ongewenste tester mag spelen) maar ik dank dat het ooit goed bruikbaar zal zijn maar altijd achter zal lopen op x86(_64)

[rhuijben]

Windows voor Itanium werkte met emulatie op dezelfde manier, want toen bleek de software oplossing beter te werken dan de minimalistische hardware oplossing die Intel in de eerste generatie hardware gebouwd had.

[bbob]

Ik verwacht weinig fouten, ze zijn hiet denk ik al jaartje mee bezig dus de meeste fouten zullen er wel uit zijn.

Wat ik me eerder afvraag is of dit op alle arm cpu's gaat werken of alleen snapdragon 835

[Swerfer]

Als je de demo van Photoshop hebt gezien, dan lijkt het behoorlijk bruikbaar. Niet voor professionals voor continu bewerking, maar voor de momenten waarop je net even die ene foto wil bewerken. Ik denk dat je meer moet denken aan niet CPU-intensieve applicaties moet denken, onder andere Office, en eenvoudige games. Nu gaat Microsoft Office waarschijnlijk helemaal porten naar ARM, maar er zullen genoeg (bedrijfsmatige) applicaties zijn die prima draaien in een emulator.

[Martinspire]

Ik ga er voor het gemak vanuit dat de demo's worden gegeven op hele snelle ARM processoren. Bovendien vind ik het opvallend dat ie voor de Photoshop demo ineens niet meer de andere applicaties open heeft staan. En WoT is nou niet bepaald een zware game. Een 7 jaar oude machine kan die game vloeiend spelen.

We zullen zien hoe bruikbaar het is, maar ik blijf voorlopig sceptisch.

[Swerfer]

Ik ga er voor het gemak vanuit dat de demo's worden gegeven op hele snelle ARM processoren.

Zoals je in de demo kan zien is het een Qualcomm Snapdragon 820 op 1.59 GHz. Het is dus niet eens de nieuwe 835. En zoals ik al zei, simpele games. Je moet natuurlijk niet top games verwachten.

Het hele doel van Windows on ARM is ook de lange accuduur. Daarvoor is ARM beter dan Intel. Als je voor een device een lange accuduur verwacht, dan ga je niet gamen en niet CPU-intensieve applicaties draaien.

[klakkie.57th]

ik denk er ook zo over .
Ik zoek echt een use-case, voor dit soort emulatie.
Zelfs mijn laatste generatie I7 laptop met 20GB en SSD heeft het al moeilijk met pdf/dwg/visio/large excel... en dat is niets speciaals als je het mij vraagt.

maar goed als het kan , al blijf je wel gebonden aan UWP apps only en zoals ik hier lees ook nog eens uit de app-store of zou dit laatste optioneel zijn ?

[SunnieNL]

thinclients, telefoons die draadloos naar een groot scherm volledige apps kunnen draaien. Tablets die langer meegaan dan 3 uur maar toch veel kunnen en niet beperkt worden door een store.

Als jou laptop met 20gb geheugen en een i7 trouwens moeite heeft met een pdf zou ik er heel snel mee teruggaan naar de winkel.

[r2504]

Windows on ARM is dan ook geen vervanger van Intel based hardware... louter een alternatief. Mensen die dus power nodig hebben zullen nog steeds voor Intel blijven gaan, terwijl iemand anders die dit niet nodig heeft nu wel een dag kan werken op een kleine batterij.

[bbob]

Het heeft ook puur met snelheid te maken. De snelste arm cpu kun je volgens mij nog steeds niet vergelijken met een snelle intel/amd desktop cpu.

Neemt niet weg dat arm cpu's steeds sneller worden en nu voor emulatie en windows 10 geschikt zijn voor de meeste gebruikers. Photoshop is intensief maar wordt niet door de massa gebruikt.

[Vexxon]

Ik denk dat je je daar niet zoveel zorgen om hoeft te maken.

Het is uiteraard niet helemaal hetzelfde, maar met de backwards compatibility van de Xbox 360 op de Xbox One heeft MS wel ervaring met emulatie.
Die 360 games die ik op die manier speel werken perfect op de xbox one.

[tweaknico]

Ja dit kan, en ja het werkt.
Jet is jaren geleden ook gedaan voor AXP processoren waarop WIndows liep.
(FX86, van Digital Equipment Corp.) daarmee kon standaard windows x86 software gedraaid worden op AXP's, en langzamer hand werden alle noodzakelijke onderdelen omgezet. (en opgeslagen, voor later hergebruik). Eerste startup was merkbaar trager, maar na verloop van tijd geen verschil merkbaar.

[Anoniem: 343906]

ARM processoren hebben wel degelijk voordelen bij servers ten opzichte van Intel processoren. Om die reden is Microsoft ook begonnen met het porten van Windows naar ARM. Dat er ook voor individuele consumenten voordelen aan vast kunnen zitten is voor Microsoft volgens mij niet meer dan een niet te missen bijkomstigheid.

https://www.bloomberg.com...atening-intel-s-dominance

[Rudie_V]

x86 emulatie op ARM. Uhm, waarom niet gewoon een x86 cpu gebruiken? Hoeveel verschil zit er nu tussen een x86 en ARM CPU als je het verbruik gelijk zou trekken, want dat is natuurlijk de reden waarom x86 op mobiele apparaten nog niet echt handig is, maar hoe groot is dat verschil nu nog dan?

[Relief2009]

Het hele punt is juist zuinigheid en goedkopere producten. Windows op ARM zorgt ervoor dat je passief gekoelde chips kunt gebruiken welke nog eens goedkoper en zuiniger zijn dan een Intel Chip.

Basically, bespaart het fabrikanten zoals Samsung en Asus veel geld omdat ze geen seperate Windows Intel tablets hoeven te ontwikkelen.

[Reactie gewijzigd door Relief2009 op 23 juli 2024 03:07]

[Rudie_V]

Intel heeft ook x86 chips die passief gekoeld kunnen worden. Je heb ook low power mobile x86 die maar iets van 2 Watt verbruikt. Helaas is het vinden van het verbruik van ARM chips wat lastig om daar cijfers over te krijgen.

Basically, bespaart het fabrikanten zoals Samsung en Asus veel geld omdat ze geen seperate Windows Intel tablets hoeven te ontwikkelen.

Of je nou een ARM tablet of x86 tablet moet ontwerpen, wat maakt het verschil volgens jou? Bovendien maken veel fabrikanten al tablets met windows 10, dus eentje met iets anders energiezuinige x86 is niet zoveel moeite volgens mij, niet meer dan een ARM tablet ontwerpen.

Enige punt is volgens mij nog steeds het verbruik van x86 in mobiele toepassingen. Maar ik ga mij afvragen hoeveel verschil er zit tussen een x86 applicatie op ARM met emulatie of x86 native op een energiezuinige x86 chip.

Het is jammer voor microsoft dat intel de energiezuinige mobiele CPU's op een laag vuurtje heeft gezet, omdat intel maar geef voet aan de grond kreeg in de mobiele apparaten sector.

[Anoniem: 343906]

Consumentenproducten liggen niet ten grondslag aan deze Windows op ARM maar Azure met datawarehouses. Het gaat Microsoft primair om de servers, consumentenproducten zijn slechts een bijkomstigheid.

[kingofkamikaze]

Maar zal dit ook op Windows IoT voor de Raspberry Pi draaien?

[84hannes]

Met alle respect voor de Raspberry Pi: dat ding is niet gebouwd voor snelheid. Als ik gewoon via de command line een paar packages wil installeren dan merk ik al hoe traag dat gaat t.o.v. van mijn eerste generatie i3 desktop. Een geoptimaliseerde GUI als Kodi werkt ook niet echt snel. Ik denk niet dat je de eindgebruiker lastig wilt vallen met Office of Photoshop(!) op een Raspberry Pi die x86 emuleert.

[kingofkamikaze]

Ik hoef ook niet meteen battlefield1 te kunnen spelen, maar lichte applicaties zou hij moeten kunnen trekken toch?

[ard1998]

Ik denk dat het haalbaar is op een pi3, hoelang ze applicaties niet zwaarder zijn dan word of een browser. (Overkloks niet meegerekend)

[84hannes]

niet zwaarder zijn dan word of een browser

Gamen en foto/videobewerking daargelaten denk ik dat een Browser het zwaarste is dat op een normale PC draait. Niet voor niets zijn alle grote browsers in C/C++ geprogrammeerd. Ze moeten beeld renderen, javascript uitvoeren, communiceren, databases aanmaken en gebruiken, plaatjes en filmpjes weergeven... Een browser draaien vanaf je Raspberry Pi is met ARM-code al niet erg snel, via emulatie zou ik het niet eens willen proberen. En waarom zou je ook, Alle grote browsers bestaan ook in ARM versies.

[Sleurhutje]

Waarom zou je voor een IoT device x86 willen draaien? De toepassingen die je maakt voor IoT zijn ontwikkeld in de omgeving die het beste past bij de RPi. Ik denk niet dat Microsoft de intentie heeft om de RPi om te bouwen naar een Mini-PC.

[valvy]

Windows IoT is geen windows dat je kent van de desktops. Het heeft namelijk geen apps.

De pi heeft zoiezo vrij zwakke processor. En x86 emuleren heb je speciale hardware nodig van quallcom.

Zoiezo kun je gewoon een linux desktopje draaien op de pi wat soepel draait.

[Eeki]

Windows IoT kan UWP apps draaien.

[Triogap]

Windows 10 IoT Core heeft wel degelijk apps. In principe kan hij alle UWP apps aan. Hierbij moet wel de kanttekening gemaakt worden dat Windows 10 IoT Core een heel basale UI stack heeft. Maar zelfs het gebruiken van een scherm met daarop apps is gewoon mogelijk.

[kingofkamikaze]

Ik zit zelf ook nog altijd met een linux server. Maar soms kom je wel eens een kleine windows-only applicatie tegen die je zou willen kunnen draaien op een low-power platform.

[jetspiking]

Jammer om dit te horen, ik had na voorgaande nieuwsberichten juist heel veel gehoopt op de Surface Phone... Komt deze uberhaupt wel?

Enige van Microsoft waar ik "hyped" voor ben...

[Ramon]

Hoe kan je nou hyped zijn voor iets waar je geen idee van hebt of het überhaupt bestaat, en als het al bestaat geen idee hebt wat het precies inhoudt of voor jou gaat betekenen?

[cracking cloud]

er waren geruchten dat Microsoft een telefoon met x86 emulatie zou gaan uitbrengen, waarschijnlijk is dat wat @jetspiking bedoelt.

[Ramon]

Dat zou kunnen, maar dan vind ik het raar dat 'ie "jammer om te horen" zegt als iemand een artikel over een filmpje plaats waarin uitgelegd wordt hoe die x86 emulatie werkt

[jetspiking]

Aangezien het niet over de Skurface Phone gaat maar over laptops in dit artikel

[jetspiking]

Aangezien er geruchten van zijn dat de telefoon .exe programmas kan draaien.

Dan kan ik er toch gewoin "hyped" voor zijn?

[alt-92]

Als je denkt dat je dan willekeurig welke win32 executable/setup op je telefoon kan draaien ga je erg teleurgesteld zijn.

[jetspiking]

Het draait toch in principe gewoon in een soort van emulator? Bedoel je qua performance of qua dat Microsoft applicaties compatibel moet maken?

[Croga]

Omdat het hele idee van een nieuwe serie telefoons van microsoft mij al enthousiast maakt.

überhaupt het gerucht dat er zoiets als een Surface phone in ontwikkeling is doet mij sterk hopen dat het waar is.

[ard1998]

De surface lijn is een lijn voor tablets met eventueel een toetsenbord eraan vastgekoppeld (dat wij hybride of twee in een noemen) hieron leek het mij al onwaarschijnlijk dat er een surface phone zal komen.

[Croga]

Uhhuh.....
Je weet dat de eerste Surface van Microsoft een interactieve tafel was?
Je weet ook dat er televisies (met ingebouwde computer en videoconferencing opties) in de Surface lijn uit gekomen zijn?

Surface is gewoon de naam die Microsoft geeft aan hun huidige generatie hardware, omdat daar een focus zit op "wat er op het scherm gebeurt" en directe interactie daarmee. Het is zeker niet gelimiteerd tot tablets, hybrids en convertibles. De naamgeving is dan ook geen reden om te denken dat er geen Surface phone komt.

[maxplanck]

Die tafel hebben ze met het uitkomen van de Surface (tablet
) een andere naam gegeven en is dus geen onderdeel van de surface lijn.

[Yaz]

PixelSense is toen de naam geworden. Eerste generatie was erg gaaf. Geen multi-touch scherm maar camera's (onder de glas plaat) die detecteerde wat erg gebeurde op het scherm. "Scherm" kon daardoor ook herkennen wat en welk apparaat er bijvoorbeeld op neergezet werd om zo specifieke interactie aan te bieden.

De 2e generatie (zoals stond/staat bij de 2e maasvlakte experience center) is een "gewoon" multi-touch scherm van Samsung met een een deel van de technieken uit de eerste serie.

De originele Surface (met details over hoe het gemaakt is, toffe video): https://www.youtube.com/watch?v=SRU3NemA95k

De Sur40 (2e generatie): https://www.youtube.com/user/MSPixelSense/videos

[ard1998]

Dan heb ik mijn informatie vast uit een verkeerde bron, bedankt voor de informatie

[Blokker_1999]

Want de book, laptop en desktop zijn verroken tablets? De Surface lijn bevat high end apparaten die als showcase dienen voor de ideeën die MS heeft.

[vosManz]

Correctie, de Surface lijn is geen lijn voor enkel tablets. De lijn bevat ook laptops (de Surface Book, en de onlangs aangekondigde Surface Laptop), een all-in-one (de Surface Studio), en een interactief whiteboard (Surface Hub). Een Surface Phone zou hier dus zomaar tussen kunnen passen.

https://en.wikipedia.org/wiki/Microsoft_Surface

(edit: spuit11, reactie van Bokker_1999 niet gezien)

[Reactie gewijzigd door vosManz op 23 juli 2024 03:07]

[Wallus]

Volgens mij richt de build conferentie zich hoofdzakelijk op software. Ik meen ergens eind deze maand is er een surface 'iets' waar nieuwe hardware aanbod komt.

[StefanJanssen]

23 mei word een presentatie in Sjanghai gegeven met waarschijnlijk de aankondinging van een een nieuw surface product.

[Richh]

Voorgaande nieuwsberichten? Je bedoelt alle geruchten en onofficiele dingen die eigenlijk dus nooit zijn aangekondigd?
Intel zou een x86-chip maken die in een smartphone zou kunnen en dat was de basis van het Surface plan. Die SoC is geannuleerd en sindsdien zijn er geen officiële berichten geweest over de Surface Phone.

Ik moet het allemaal nog zien, dit kan ook de basis zijn voor een nieuw onderdeel van Windows Phone natuurlijk.

[Reactie gewijzigd door Richh op 23 juli 2024 03:07]

[bapemania]

Wat niet is kan nog komen, dit was een "Build" event, niet het Surface event dat op 23 Mei gepland staat. #hoopdoetleven

[jetspiking]

Ik heb nooit ergens last van... Waarschijnlijk ben je aangemeld bij Windows Insider waardoor je onstabiele Fast Ring builds krijgt. Ik zou dit even nakijken.

[JvdHoudt]

Nope, release preview ben ik bij aangemeld. 100% zeker.
Bewust gekozen niet voor fast of slow te gaan om dit soort fratsen te voorkomen, maarja wat is het verschil...

[jetspiking]

Welke Windows Phone heb je als ik vragen mag?

[JvdHoudt]

930 met versie 10.0.15063.297 (fout is begonnen bij de officiele CU .251 geloof ik?).

[Vexxon]

Wel grappig dat je iets draait op een toestel die niet officieel ondersteund wordt en dan de schuld bij iemand anders legt.

[JvdHoudt]

Tuurlijk leg ik de schuld bij MS, ze zijn het ook schuld.
Ze geven zelf aan (ergens in een artikel op windowscentral.com te vinden) dat toestellen als de 930 de update kunnen downloaden via de Release Preview echter gaan ze geen feature updates meer pushen naar het toestel. Echter draait het toestel de update beter dan menig toestel die de update legaal krijgen.
God mag weten wat de gedachte van MS is hierbij.

Mooi hoe je zo'n simpel softwarematig probleem gaat afschuiven op het beste stukje hardware dat gemaakt is voor de hele Windows Mobile reeks. Hield jij ze ook de hand boven het hoofd bij de release van de 950? Ik heb tal van deze toestellen uitgeleverd, en stuk voor stuk hebben ze random reboots.

De geschiedenis van Windows Mobile laat weldegelijk zien dat ze er bij het bedrijf een potje van maken. Ze laten de community keer op keer vallen en weigeren om een consitent OS te maken.

Helaas zijn er nog steeds mensen die de roze zonnebril op hebben en dit niet zien.

[Chinco]

Maar mijn 1520 draait dan ook als een zonnetje op de CU. Daar wordt je bril ook roze van.

Voor de rest ben ik het wel mer je eens. Nadella heeft duidelijk de visie op mobile van Balmer in de prullenbak gegooid. Met z'n iPhone op zak i.p.v. een Windows Phone. Overloper.

Edit: ik vraag mij eigenlijk af in hoeverre oudere SoCs zouden presteren. In hoeverre het technisch mogelijk zou zijn om Windows 10 ARM te combineren met Continuum. Er zitten al de apps voor telefoongebruik in CU en het OS is nagenoeg helemaal responsive. Dat is toch wel mijn droom, dat mijn HP Elite X3 (mijn andere telefoon) dat gaat doen. Volgens mij kan het technisch, de testen vorig jaar waren met SD820, als ik het goed heb.

[Reactie gewijzigd door Chinco op 23 juli 2024 03:07]

[i7 930]

tsja, wordt ook niet officieel ondersteund door MS op een 930. Dus zullen er een aantal bugs in zitten. Mijn 950 doet het prima onder een insider versie op CU.

[jetspiking]

Zoals @i7 930 aangeeft ligt het inderdaad eraan dat jouw Windows Phone niet officieel ondersteund wordt.

[ArnieNFW]

Photoshop staat in het plaatje genoemd als X86 emulated process. Ik ben benieuwd hoe de user ervaring zal zijn van deze vrij cpu intensieve programmas.

[ard1998]

gewoon het zelfde, maar dan iets langzamer. er zullen vanzelf wel chips die dit harde werk aankunnen. Het zou overgens wel fijn zijn als ze ook een aanegeven welke processoren de minimaal vereisde rekenkracht hebben om deze applicatie vloeiend te draaien.

[rjberg]

Hoe zit het eigenlijk met de gpu? Die werdt ook voor photoshop gebruikt.

Om maar te zwijgen over games.

[ard1998]

De gpu hoef niet geemuleerd te worden omdat het net als de desktop gpu's graphics kan produceren met de OpenGL API of vulkan API. Hierdoor behouden gpu instructies de zelfde uitvoersnelheid waarbij de cpu uitvoersnelheid van de oorspronkelijke instructie langzamer word door de vertaling van de x86(_64) instructieset naar ARM. Met een goede mobiele gpu zal er dus op dat vlak geen probleem zijn.

[Spekkie88]

Maar daar zit dan ook gelijk het probleem...
De meeste ARM SoC's ondersteunen inderdaad OpenGL ES en tegenwoordig ook Vulkan.
Maar hoeveel x86 software maakt gebruik van OpenGL (laat staan ES) en Vulkan?
Voor zover ik weet maken verreweg de meeste programma's die iets met je GPU doen gebruik van DirectX...

En dan wordt het ineens een heel ander verhaal...

[The Zep Man]

Maar hoeveel x86 software maakt gebruik van OpenGL (laat staan ES) en Vulkan?
Voor zover ik weet maken verreweg de meeste programma's die iets met je GPU doen gebruik van DirectX...

Als de open-source community DirectX (inclusief Direct3D) open-source kan implementeren in de vorm van Wine op systemen zonder DirectX, dan kan Microsoft zeker iets soortgelijks in Windows.

[Spekkie88]

Dat zal me ook niets verbazen, maar het ging me hierom:

De gpu hoef niet geemuleerd te worden omdat het net als de desktop gpu's graphics kan produceren met de OpenGL API of vulkan API. Hierdoor behouden gpu instructies de zelfde uitvoersnelheid

Maar dat zal voor de meeste x86 programma's mijn inziens dus niet opgaan...

[kwakzalver]

Niet alles zoal draaien op de arm emulator. 100% is/lijkt me onhaalbaar.
Maar als een heel groot deel werkt op de emulator is het doel bereikt en toegang tot het mobiele platform immens verbreed.
En die apps die niet werken en populair zijn zullen wel een update krijgen door de bouwer.

Vergelijk het maar met Chrome.
Google propt er een paar standaarden doorheen op zijn browser waardoor sommige websites niet meer goed werken.

• De standaard gebruiker klaagt over de websites.
• De Tweaker stapt over op een andere browser.
• En een paar website builders past hun site aan.

En dat laatste is wat Google wilt. (HTML5 en geen java....)

[dakathefox]

Google propt er een paar standaarden doorheen op zijn browser waardoor sommige websites niet meer goed werken.

Wat een onzin. Standaarden zijn door de industrie overeengekomen en helpen het om de gebruikerservaring te stroomlijnen. Of wil je terug naar de tijd van de propriety-oplossingen van Microsoft (ActiveX) of Adobe (met het lekker onveilige en brakke flash).

Als je als industrie overeenkomt dat er een nieuwe standaard moet zijn, dan moet je je daar ook aan houden. Ook Microsoft heeft zich daar aan gecommitteerd. Dan moet je niet Google verwijten dat het een er een standaard doorheen drukt, want Microsoft zit er ook gewoon bij.

[kwakzalver]

Dat is dus geen verwjt aan Google. Een droge constatering.

Google forceert (met zachte hand) een evolutie naar een nieuwe standaard. En dat is prima.
Vraag eens af hoeveel sites nu https gebruiken? Een samenloop van Letsencrypt en Google is wel de booster geweest voor deze ontwikkeling.

Ook Microsoft pushed de ontwikkeling op dezelfde wijze. De nieuwe standaarden ondersteunen in de Arm omgeving. En het oude ballast niet meer meenemen.
Dat houdt de ARM emulator optimaal in gebruik en via een omweg worden zo veel meer apps die gewild zijn geupdate naar een nieuwe (veiliger) standaard.

[halofreak1990]

De meeste x86 programma's gebruiken gewoon DirectX, wat sowiezo ondersteund wordt door Windows op ARM.

[Spekkie88]

Ja, maar dus niet zonder emulatie...

[Johan9711]

Hoezo niet? MS kan toch gewoon de DirectX API in Windows 10 voor arm implementeren?

[.oisyn]

maar het ging me hierom:

Die quote zet je denk ik op het verkeerde been. Hardware ondersteuning van een graphics API heeft voornamelijk te maken met features. Vulkan en Direct3D, maar ook OpenGL hoewel in een enorm veel mindere mate, hebben een basis featureset die de hardware moet ondersteunen. Maar het blijven gewoon geabstraheerde API's, en de basis featureset voor Vulkan en Direct3D 11/12 is niet heel verschillend. In de praktijk ondersteunt elke moderne GPU alle benodigde features, en dus kun je voor elke GPU een Vulkan of Direct3D implementatie maken.

Uiteraard heeft Microsoft gewoon een Direct3D implementatie voor de ARM architectuur, dus een geëmuleerde x86 applicatie kan gewoon snel van de GPU gebruik maken.

[Bliksem B]

Dan moet de soc wel direct x ondersteunen. Zover ik weet ondersteunen arm socs die niet. Al zullen ze wel vergelijkbare instructie sets delen.

Open gl en vulkan moet dus geen probleem zijn, direct x kan nog wel eens voor problemen zorgen.

[halofreak1990]

Microsoft vereist al sinds mensenheugenis dat fabrikanten die Windows willen leveren op een ARM device zorgen dat de SoC DirectX ondersteunt.

[rjberg]

Wine draait alleen op x86/amd64

[TrekVogel]

Snapdragon 835 ondersteunt gewoon DirectX 12 dus dat is geen probleem. Er zijn meer Arm socs die dat doen.

[Spekkie88]

Ow echt? Was ik nog niet eerder tegen gekomen
Thanks voor de info.

Inderdaad en al lang terug ook blijkt (D3D 9.0c in de adreno 2xx series)... Nooit geweten!
Al wordt OpenGL (non ES) blijkbaar niet meer ondersteund...

[Reactie gewijzigd door Spekkie88 op 23 juli 2024 03:07]

[NC83]

Windows mobile draait gewoon D3D11 en D3D12 hoor en geen GL, GL is uit windows gesloopt.

[DigitalExorcist]

Mwah. Nintendo gebruikt de Tegra X1 voor de Switch, en die draait games uitstekend. Voor ARM-computertjes zou ik me dus niet te druk maken over de games, die lopen écht wel fatsoenlijk.

Als je GTA 5 in 4K met alle detail aan wil zetten koop je maar gewoon een échte x86 met een dure videokaart

[WienerBlut]

Ik denk dat dit heel goed is voor embedded applicaties! Alle SoC's hebben tegenwoordig ARM en ondersteuning voor virtualisatie... 1 SoC, 2 OSen... Windows voor een GUI of legacy en Linux voor services.

[hottestbrain]

Ook gewoon windows voor de Linux services... Bash on windows draait als een trein.

[WienerBlut]

Dat kan natuurlijk ook Zelf heb ik er nog niet veel ervaring mee, maar ik heb goede berichten gehoord! Zeker uitproberen dus!

[KonradV]

Zou hiermee nou toch (eindelijk) eens hoop zijn voor mensen die jaren geleden een Microsoft Surface RT gekocht hebben, en daarmee opgescheept zitten met (enorm beperkte) Windows RT? Helaas heeft het apparaat maar 2 GB RAM, dus dat zal vast wel beperkingen opleveren...

[SinergyX]

Nee, de RT heeft nooit een upgrade gekregen naar Win10, kans dat de x86 nog op Win8 gaat komen is vrij klein.

[Chinco]

Die kans schat ik ook in op ergens tussen nihil en nul, maar in theorie opent het een weg naar een Windows 10 update.

[Spekkie88]

Wat ik me wel afvraag is of dit ook gaat werken op andere (oudere) ARM chips?
Is dit bijvoorbeeld geschikt voor alle ARMv8 SoC's? En werkt dit bijvoorbeeld ook op ARMv7?
Of het vooruit te branden is is een ander verhaal, maar het lijkt me toch tof als je bijvoorbeeld een android kastje om kan toveren naar volledig windows 10

[Relief2009]

Nee. Snapdragon 835 zal de eerste chip zijn waarop Windows 10 zal draaien. Ik denk dat oudere chips niet krachtig genoeg zullen zijn voor Win10.

[DeeJay1965]

Kan ik m'n Lumia2520 dan ook weer uit de kast halen?

[RangedNeedles]

Is dat nu niet net het hele punt van dit nieuwsartikel? Uitleggen dat het blijkbaar wel mogelijk is?

[RobinJ1995]

x86 !== x86_64

[.oisyn]

x86 is de generieke term voor alle x86-based architecturen en afgeleiden daarvan, dus ook x86-64, en betekent dus absoluut niet louter de 32-bits uitvoeringen ervan.

[voxilla]

Helaas worden enkel 32-bit x86 geemuleerd, en niet 64 bit x64 code.

Alle ARM apps in de store zijn ook 32-bit, terwijl het ARM OS 64 bit is.

Het lijkt er ook sterk op dat enkel ARM UWP native op het OS draaien, en dat het bevoorbeeld niet mogelijk is om win32 applicaties, te hercompileren naar ARM.

Edit native ARM win32 lijkt toch een mogelijkheid.

[Reactie gewijzigd door voxilla op 23 juli 2024 03:07]

[nexhil]

Als je de video gewoon van het begin tot het eind kijkt dan heb je je antwoord.

[pe0mot]

Ik zie dat mijn vraag geholpen heeft.
Het artikel had een schrijffout toen ik het las, en de video was nog niet zichtbaar.

Schijnbaar is het stellen van een vraag een reden om -1 te geven bij dit selecte gezelschap. Complimenten boys, de juiste houding om elkaars fouten te beoordelen!

[nexhil]

Het is je vergeven pe0mot

[pe0mot]

Dank is weer groot.