Microsoft Store accepteert apps voor ARM64-architectuur

De Microsoft Store accepteert voortaan apps op basis van de ARM64-architectuur, waarmee gebruikers van Windows 10 op ARM 64bits ARM-apps uit de winkel kunnen downloaden. De ondersteuning valt samen met de komst van Visual Studio 15.9.

Visual Studio 15.9 bevat nu de sdk en tools waarmee ontwikkelaars ARM64-apps kunnen maken. Zowel Universal Windows Apps als traditionele Win32-programma's kunnen gecompileerd worden als ARM64-varianten. Vervolgens kunnen ontwikkelaars die nu distribueren via de Microsoft Store. Dat meldt Microsoft.

Windows on ARM ondersteunde vanaf de aankondiging eind 2016 lang alleen alleen 32bits ARM-apps, terwijl x86-programma's via emulatie ook alleen in 32 bits draaien. Vanaf mei ondersteunt het OS ARM64-apps en Microsoft gaf toen ook al een early preview vrij van de tools waarmee ontwikkelaars dit soort apps kunnen maken. Het bedrijf benadrukte toen dat het nog niet om officiële ondersteuning ging. Die is er nu wel.

Windows on ARM is de Windows-versie voor systemen met ARM-chips. Microsoft werkt met Qualcomm samen aan zogenoemde Always Connected PC's die zich moeten onderscheiden met lange accuduur en lte-ondersteuning. De verwachting is dat Qualcomm eind dit jaar een nieuwe soc voor laptops aankondigt, die onder de naam Snapdragon 1000 bekendstond, maar wellicht als Snapdragon 8180 uitkomt.

Reacties (29)

[misterbennie]

Waarom zou je niet gewoon naar AnyCPU compileren?
Uiteindelijk zou de software dan op zowel X64 als ARM64 moeten kunnen draaien.

[capsoft]

https://blogs.msdn.micros...rouble-than-theyre-worth/

[misterbennie]

Er zijn inderdaad redenen om niet voor AnyCPU te compileren, maar er zijn ook redenen om het wel te doen. AnyCPU zou gewoon moeten werken.

[Alw4ysFresh]

Jammer dat Microsoft niet zo iets heeft gedaan als Java. Waarschijnlijk zou dat makkelijker zijn.

[Dreamvoid]

Dat hebben ze al, het het .NET

[Alw4ysFresh]

Dus .NET is ook compitabel met andere besturingssystemen en andere CPU architecturen.

[Dreamvoid]

Yep. Het oude Windows Phone/Windows 10 Mobile was op basis van .NET (ARM) en het kan op diverse OSsen draaien ( https://www.mono-project.com/ ).

[Alw4ysFresh]

Maar het werkt niet 100% omdat AnyCPU niet zonder problemen en meer moeite kost.

[Mellow Jack]

Werkt een beetje vergelijkbaar met Java. De basis is prima crossplatform (in het geval van MS is dat .Net core)

Dit betekend helemaal niet dat alle Java applicatie direct crossplatform zijn. Nee je kan alsnog een OS of architectuur afhankelijke libs gebruiken

[Boy]

zolang dat framework op de architectuur werkt, lijkt me wel...

dat is bij Java toch ook niet anders? Daar moet toch ook een VM kunnen draaien op het systeem?

[misterbennie]

Wat heeft Microsoft niet gedaan?
Als je bedoelt dat .NET code niet op verschillende platformen draait, dan hebben ze dat wel gedaan.
Ik heb in het verleden C# op ANYCPU gecompileerd en op mijn Beaglebone Black onder linux gedraaid.
Basale code, maar toch.

[SpiceWorm]

Joh lees je ff in. .net bestaat al ruim 15 jaar.

[Sebazzz]

Dit is wel heel verouderd. Ondertussen is de x64 JIT net zo snel als de x86 JIT.

[Stannieman]

Sneller zelfs dacht ik. Als ik mij niet vergis hebben ze op een gegeven moment de JIT-compiler voor x64 grotendeels (zoniet volledig) herschreven. Met alle ervaring en kennis die ze op dat moment al hadden levert dat bijna per definitie een efficiëntere implementatie op.
De x86 JITter hebben ze gewoon gelaten zoals die was.

De memory overhead blijf je natuurlijk behouden, maar het is idd zo dat de x64 vaak snellere code maakt dan de oude voor x86.

Meer info over de x64 JITter hier: https://blogs.msdn.micros...ion-jit-compiler-for-net/
Is al een oude post maar deze is uiteindelijk in gebruik genomen bij .NET Framework 4.6.

[_Thanatos_]

Je bedoelt .Net ofzo? Dat kan vgs mij al, maar dan heb je ook niet de performance van native code, plus dat je in een (iets) andere taal moet werken. Dus het is wel meer dan even aan andere compiler kiezen.

[misterbennie]

Er is genoeg software in .NET geschreven, dus waarom niet.
En native code kan inderdaad sneller zijn, maar .NET gecompileerd voor 32bits is marginaal sneller (als het al sneller is) dan voor een 64 bits systeem.

[1973booterror]

Apple gebruikt ook al een tijdlang "bitcode"; processor onafhankelijke code welke door Apple als geoptimaliseerd processor afhankelijk aangeboden wordt op de desbetreffende Appstores.

[jctjepkema]

Serieus? Is dat om dan de 32bit naar 64bit overstap te maken? Of is dat om ook MacOS apps op een ARM processor te kunnen draaien, want dat laatste is zover ik weet nog niet mogelijk. Laatstaan MacOS op een ARM.

[1973booterror]

Naar ik begrepen heb is het totaal processor onafhankelijk en merendeel van macOS draait al op ARM-> is namelijk iOS.
Er wordt al lang gesproken dat Apple blijkbaar verschillende macOS versies zelf heeft draaien voor verschillende processors, dit om eventueel snel over te kunnen schakelen naar een andere processor.
Ook in de PowerPC tijd had men al lang een intel versie naast de bestaande versie draaien, daarom was de transitie ook relatief goed gegaan.

Bitcode wordt ook gebruikt voor iOS:

- developer compileert app - wordt bitcode
- bitcode wordt verzonden naar Apple; gecontroleerd
- na goedkeuring staat de app in bitcode op Apple app-servers
- gebruiker download de app; wordt gekeken aan app server kant om wat voor een apparaat het gaat (processor, intern geheugen, retina scherm ja/nee, etc.)
- app wordt geupload naar apparaat van gebruiker in specifiek voor apparaat gecompileerde vorm en met de alleen voor apparaat bestemde media(retina afbeeldingen of niet).

Volgens Apple wordt er altijd gecompileerd aan hun zijde met de nieuwste versies en optimalisaties, lijkt me sterk dat dit on-the-fly gebeurt, maar weet niet wat de interval dan wel is.

[84hannes]

Ik vermoed dat Apple voor hun platformen niet afhankelijk wil zijn van processorfabrikanten. We weten dat ze al van Motorola naar IBM (PowerPC) naar Intel zijn overgestapt, dus een keer van ARM naar MIPS zou niemand mogen verbazen. Daarom is bitcode voor Apple Watch volgens mij zelfs verplicht.

edit:
Maar misschien was bitcode alleen om snel tussen 32-bit en 64-bit te kunnen switchen

[Reactie gewijzigd door 84hannes op 27 juli 2024 02:47]

[Swerfer]

Als je voor de Microsoft Store compileerd, een app package, dan kan je alle gewenste compilers kiezen en in de store komen dan alle versies te staan. Iemand die dan je app uit de store installeert, krijgt dan de juiste versie voor zijn systeem en zal, waar ik tenminste vanuit ga, ARM64 krijgen ipv ARM als de CPU 64 bit accepteerd.

Zie : https://tweakers.net/ext/f/81Edw5IWgzZSvrFkhtGdDVfO/full.png

[Reactie gewijzigd door Swerfer op 27 juli 2024 02:47]

[misterbennie]

Duidelijk, thanks

[Armin]

Waarom zou je niet gewoon naar AnyCPU compileren?

Dat is .Net code, niet voor Native of WinRT.

Het is soms verwarrend inderdaad, want ook bij .Net kun je een voorkeur opgeven betreft platform, maar deze ondersteuning is om C++ code naar Native ARM64 te compileren.

[misterbennie]

Dat maakt het artikel niet echt duidelijk.
Ik ontwikkel alleen maar in .NET in Visual Stdio, dus was een beetje gefixeerd op (duidelijk) het verkeerde

[Stannieman]

Een voorbeeld van waarom dit bij ons het geval is:
We hebben een paar modules waar vrij complexe berekeningen in gebeuren. Deze logica moet gebruikt worden door een serverapplicatie geschreven in Java, een app voor Windows (.NET, WPF) en een oude (legacy) en nieuwe iOS-app (Objective-C en Swift).
De berekening gebeuren allemaal in 1 grote brok, dus de flow is: models vullen met input data, functie aanroepen met die models als parameter, resultaten in andere models terugkrijgen van de functie.

Gezien de complexe en kritische aard van deze berekeningen wil je deze eigenlijk maar 1 keer schrijven en testen. En gewoon voor het gemak is 1x code schrijven opzich ook wel leuk én tijdsbesparend.

Wat wij dus gedaan hebben is deze berekeningen en bijhorende models in C++ schrijven. De module kan dan gebruikt worden door al onze applicaties. Voor elk platform (Java, iOS, .NET) is er een integratie om de models te mappen van en naar native + het aanroepen van de calculatiefunctie. Maar dat houdt dus in dat die code altijd voor een specifieke CPU architectuur gecompileerd wordt.

In het specifieke geval van .NET is het dan het makkelijkste om je app apart voor x86 en x64 te compileren en dezelfde smaak van de C++ module mee te leveren. Een andere optie zou zijn om AnyCPU te gebruiken en at runtime de juiste native library in te laden, maar dat is niet zo praktisch (wat als je toevallig op ARM terecht komt en daar geen native dll voor hebt?).

Qua werk is er een beetje overhead omdat we voor elk platform de integratie moeten maken en onderhouden, maar dat weegt niet op tegen de voordelen van de echte logica zelf maar 1x te moeten schrijven.

[misterbennie]

--------------------
Verkeerd gepost

[Reactie gewijzigd door misterbennie op 27 juli 2024 02:47]

[Calamor]

Hoop altijd nog een keer dat Chrome of Firefox (of variant zoals Waterfox) er in komt. Maar dat blijf denk ik een droom.
Heb een Surface 2 (RT8.1) en helaas kan je er geen Linux op zetten.

[SomerenV]

En dan lees je dat de Surface RT (1 & 2) niet in aanmerking komen voor Linux.