Microsoft: Intels Windows 8-claims zijn misleidend

Microsoft is van mening dat de recente opmerkingen van Intel, waarin zij stelden dat de ARM-versies van Windows 8 geen legacy-applicaties kunnen draaien, niet kloppen met de feiten. De opmerkingen zouden misleidend zijn.

Tijdens een bijeenkomst van Intel voor beleggers claimde de chipfabrikant dat de ARM-versie van Windows 8 geen oudere Windows-applicaties kan draaien. Volgens Intel zouden er bovendien vier verschillende versies voor ARM verschijnen, omdat bepaalde socs speciale aanpassingen zouden vergen. Bovendien zouden deze versies onderling niet compatibel zijn. De Windows 8-versie voor x86-chips zou, dankzij een 'Windows 7-modus', juist wel legacy-applicaties aankunnen.

Microsoft heeft in een reactie aan The Register laten weten dat de opmerkingen vanuit Intel 'niet kloppen met de feiten' en bovendien misleidend zijn. Het softwarebedrijf heeft echter niet meer details gegeven over zijn plannen voor het ARM-platform.

De softwaregigant maakte op de CES in januari bekend dat het bedrijf Windows 8 geschikt zou maken voor ARM-hardware. Het OS zou zich zo beter kunnen positioneren op de tabletmarkt. Tot nu toe heeft Microsoft drie partners genoemd die ARM-hardware produceren: Nvidia, Qualcomm en Texas Instruments.

Reacties (60)

Ik heb zo'n vermoeden dat ze beiden deels gelijk hebben. ARM kan geen x86 code native draaien, laat staan dat het x86 met allerlei extenties als MMX, SSEx, 3DNow!, EM64T, AMD64 etc native kan draaien.

In het verleden had ik een DEC Multia (Alpha 21064) die Win NT 4.0 voor Alpha draaide. Een VB6 applicatie die op een x86 machine naar native code was gecompileerd draaide met geen mogelijkheid op die Alpha. Andersom van hetzelfde laken een pak.

Compileren naar zgn. p-Code bood enigszins een tussen oplossing, maar ook dat was niet vlekkeloos.
Gelukkig was VB6 broncode (zeker zonder API referenties) vrijwel 1-op-1 te porteren.

.Net zal prima werken op beide platforms, maar ik verwacht niet dat echt oude Win32 applicaties native kunnen draaien op Windows 8 voor ARM. Er zijn al genoeg Win32 applicaties die sinds XP-x64 niet zonder een boel gehannes met compatibiliteitsinstellingen en eventuele VMs gewoon draaien.
En dan laat ik problemen met installers die de OS versie niet snappen even buiten beschouwing. Dus de applicatie werkt wel, maar de installer geeft een foutmelding in de trant van "This program requires Windows XP" of "To install this program on a server, please buy an enterprise license", omdat de installer denkt dat XP-x64 een Win2003 Server is. Oudere installers geven nog al eens de foutmelding dat ze niet compatibel zijn met Windows NT.

Echte native compatibiliteit verwacht ik dan ook niet van MS, dus daar zal Intel wel gelijk in hebben. Virtuele compatibiliteit daar is MS de laatste paar jaar goed in geworden.
Al laat MS VPC echt nog wel te wensen over, met name op het gebied van GPU abstractie. Een P2-350 met een GF2GTS (AGP) en 2x Voodoo 2 in SLI (PCI) die gewoon 98SE draait is toch echt meer compatible dan wat MS VPC neerzet.

Wat véél mensen blijkbaar vergeten is dat Microsoft in 2004 Virtual PC hebben uitgebracht, iets dat ze ook al in Windows Vista en in Windows 7 hebben geïntegreerd. Met deze software welke ooit eerst voor de Mac is ontwikkeld zullen ze zonder problemen x86 software op een ARM infrastructuur kunnen emuleren. Zelf zul je er weinig van merken dat deze software op de achtergrond draait. Ze hoeven zoals VMWare niet alles te emuleren, daar zit veel verschil in, tevens is Virtual PC helemaal met de kern geïntegreerd waardoor de performance véél en véél hoger zal zijn, dus ga het niet met elkaar vergelijken want dat is niet mogelijk!

Tuurlijk zal de performance van x86 software lager zijn op een ARM structuur dan op een x86 structuur, maar een ARM structuur kies je ook niet voor Performance, dus niet voor je zeer zware programma's maar om lang met een accu te doen. Je zult de minder zware software dus met gemak op je ARM netbook of tablet met gemak kunnen draaien.

Tevens zal zoals vele al hebben aangegeven .NET code die volledig bestaat uit managed code zonder problemen draaien op ARM software zonder emulatie, daarvoor is het .NET framework volledig geport naar .NET. .NET code wordt niet naar machine code gecompileerd, maar naar IL-language en wordt het bij het eerste gebruik op een systeem pas naar machine code gecompileerd. Code die niet volledig uit managed code bestaat zal wel moeten worden geëmuleerd, omdat geheugen adressen niet meer overeen komen. Maar dit zal niet anders aanvoelen als bij gebruik van 32bit software op 64bit windows systemen, ook dan zit er emulatie tussen en dat zal niet anders zijn op ARM. Je hoeft in je project manager van je .NET omgeving alleen maar aan te geven in welke modussen de software mag runnen, als je daar alleen 32bit aangeeft dan wordt die op ARM automatisch geëmuleerd net zoals op 64bit.

Dus don't worry, trust Microsoft!

Virtual PC heeft misschien wel een goede performance door hardware virtualization, maar het blijft een virtual machine, net als VMWare. Overigens support VMWare ook hardware virtualization, dus of die langzamer is weet ik niet. In Virtual PC draait dus een compleet ander OS waardoor het niet echt een oplossing is voor het draaien van legacy applications.

Photoshop bijvoorbeeld zal niet soepel draaien via emulatie maar er zijn tal van kleine apps die zeer weinig performance nodig hebben. Paint zal prima te emuleren zijn in tegenstelling tot photoshop (al zal paint als een van de eerste dingen naar native arm code zijn omgezet ).

Met deze software welke ooit eerst voor de Mac is ontwikkeld zullen ze zonder problemen x86 software op een ARM infrastructuur kunnen emuleren. Zelf zul je er weinig van merken dat deze software op de achtergrond draait. Ze hoeven zoals VMWare niet alles te emuleren, daar zit veel verschil in,

Je zult altijd moeten transleren en emuleren wanneer je code voor een andere processor architectuur wilt draaien als bv arm op x86 of andersom. Daar heb je dus altijd een behoorlijke performance degradatie. Direct op de hardware uitvoeren is niet mogelijk wanneer de instructieset daarvoor ontbreekt.

offtopic:
Je spreekt jezelf overigens tegen door eerst te stellen dat ze goed kunnen emuleren en vervolgens aan te geven dat ze niet hoeven te emuleren

De Windows 8-versie voor x86-chips zou, dankzij een 'Windows 7-modus', juist wel legacy-applicaties aankunnen.

dat de ARM-versies van Windows 8 geen legacy-applicaties kunnen draaien, niet kloppen met de feiten

De eerste quote weerlegt de tweede quote toch helemaal niet? Ik ben inderdaad wel benieuwd hoe MS denkt x86 programma's te draaien op een ARM windows.

Microsoft is de kampioen van backward-compatibility.
MS-DOS beleefde zijn laatste versie rond 1990, maar Windows XP had nog steeds ondersteuning. Ik geloof dat het bij Vista pas ophield.

Nu was MS-DOS was gebaseerd op de 8086 processor, dus alle MS-DOS programmas zijn gecompileerd voor de 8086 instructieset. Vanaf de 80386 veranderde een hoop in het geheugenbeheer (geen paging segmentering meer) en dus ook in de instructieset, maar Microsoft bouwde in de diverse Windows-versies een emulator van zowel MS-DOS als de onderliggende 8086 processor.

Die truc is vaker uitgehaald: de Itanium-versie van Windows had een emulator voor x86-programma's. Deze was nogal langzaam, waardoor het niet zo'n succes werd. En de x64 versie van Windows kan ook software gecompileerd voor de 32-bits versies draaien.

[Reactie gewijzigd door Free rider op 19 mei 2011 14:31]

Al deze emulatoren zitten voor het belangrijkste deel niet in windows maar in de processor. De emulator voor de 16 bits real mode(8086) zit als de virtual real mode nog steeds in alle x86 processors. Het enige punt is dat je vanuit de long mode(x64) er niet meer naar toe kan switchen. Het laten vallen van 16-bit support is dus geen keuze van MS maar eentje van AMD (als bedenker van de long mode). Elke x86 processor start trouwens nog steeds netjes op in de echte 16-bits real mode.

In de eerste itaniums zat ook hardware emulatie voor x86 maar nadat intel een software emulator (de IA-32 Execution layer) gebouwt had die betere performance gaf als de hardware oplossing hebben ze de hardware support geschrapt (maar ook de software oplossing kwam dus van intel).

Ook het uitvoeren van 32-bit code in long mode is gewoon iets wat door de processor wordt ondersteund en niet door windows. Dit is nog een stuk makkelijker omdat dit vrijwel puur een subset is van de x64 instuctie set.

MS blijft wel kampioen backward-compatibility maar niet om de redenen die jij noemt, dit is allemaal compatibility die ze gratis gekregen hebben van intel en AMD waar ze alleen nog een schilletje om heen moesten leggen zodat je als gebruiker er bij kan. Ok ze moesten er ook wel voor zorgen dat al deze programmas met elkaar en met windows kunnen samenwerken (WOW en WOW64) maar dat zijn een windows emulators(eigenlijk al teveel eer) geen processor emulators.

Ik moet nog zien hoeveel van de verhalen van MS en intel waar is, de waarheid zal ongetwijfeld in het midden liggen. Het is maar zeer de vraag in hoeverre MS een emulator voor x86 kan bouwen, voor de basis (alles tot 486) hebben ze in ieder geval geen patent licenties nodig omdat die patenten verlopen zijn. Maar voor alles daarna kan ik me goed voorstellen dat er toch echt licenties van Intel en AMD nodig zijn. Al hoewel het ook weer de vraag is in hoeverre patenten op hardware van toepassing zijn op een pure software oplossing. Over de performance van zo'n emulator maak ik me wat minder zorgen zeker als je een soort van JIT converter bouwt dan doe je eigelijk hetzelfde als wat intel in z'n processor doet: CISC naar RISC vertalen.

[Reactie gewijzigd door jmzeeman op 20 mei 2011 01:36]

Ik begreep het eerst verkeerd, omdat je het een beetje ongelukkig verwoordde. De 8086 had geen paging, de 80386 wel. Alleen las ik het alsof het omgekeerd was

Excuses, ik had wat termen door elkaar gehaald. Ik bedoelde de 8086 geheugensegmentering.
http://en.wikipedia.org/wiki/X86_memory_segmentation

8086 werkte met Segment:Offset paren, en daarmee programmeren was een drama. Als het maar even kon zorgde je ervoor dat een object (array, bitmap, ...) nooit groter mocht zijn dan 64 KB, de problemen waren anders nauwelijks te overzien.

XP had een dos die niet volledig compatibel was met MS/PC-DOS. En het is pas in de 64bit versie dat 16 bit compatibeliteit is verdwenen.

Tja moet je beter quoten, nu weerlegt de eerste quote de 2de wel:

Tijdens een bijeenkomst van Intel voor beleggers claimde de chipfabrikant dat de ARM-versie van Windows 8 geen oudere Windows-applicaties kan draaien.

Microsoft heeft in een reactie aan The Register laten weten dat de opmerkingen vanuit Intel 'niet kloppen met de feiten' en bovendien misleidend zijn.

Oftewel Quote 2 zegt dat quote 1 incorrect is... Ik geloof MS eerder dan Intel immers gaat het hier om een product van MS en is Intel niet blij met ARM natuurlijk

Dus ja wat MS te zeggen heeft over hun eigen software weegt bij mij zwaarder dan een partij die juist niet zit te wachten op die software die komt

[Reactie gewijzigd door watercoolertje op 19 mei 2011 11:01]

In die tweede quote geeft MS geen enkel argument WAAROM de uitspraken van Intel niet kloppen. Mischien hebben ze wel gelijk maar totdat ze met een verantwoording komen is het een lege uitspraak.

In mijn 1e quote geeft MS wel een reden waarom Windows 8 backwards compatible is, maar die uitspraak geldt alleen voor x86 chips en niet voor ARM (waar het bij Intel's uitspraak om ging).

Misschien een soort emulator ?

Een soort Rosetta zoals destijds voor OSX. Overigens zie ik ook wel mogelijkheden voor een soort JIT compiler voor x86 code. Als je x86 als bytecode ziet zou je het opnieuw kunnen compileren.

Ontwikkelaars kunnen dus weer opgelucht adem halen...
Moet er niet aan denken om voor 1 platform (de tablet) 4 verschillende versies te moeten maken.

Zowel Microsoft als Intel zijn geen objectieve bronnen omtrent dit onderwerp. Intel voelt de hete adem van ARM in de nek en het bedrijf uit Redmond heeft geen behoefte aan negatieve berichtgeving over Windows 8.

Op de consumentenmarkt zie ik echter geen rooskleurige toekomst voor Windows 8-tablets. Tablets worden doorgaans gebruikt voor 'relaxed' gebruik op de bank, in de trein enz. Waarbij men vooral even wil surfen, mail wil controleren of de tijd wil doden met tijdverslinders als Angry Birds e.a.

Microsoft heeft altijd een erg volledig pakket geboden met Windows-releases. Maar laten we wel wezen, zitten we daar echt te wachten op een tablet? Ik verwacht dat de voorkeur uitgaat naar operating systems zoals Android, iOs en eventueel W7.5 Mango. Deze operating systems maken geen gebruik van de resources die je toch niet (vaak) zult gebruiken op een tablet, maar bieden wel snelheid en een geweldige gebruikerservaring.

Voor de zakelijke markt zijn er wellicht toepassingen te verzinnen voor een tablet met een volwaardig besturingssysteem. Maar ik verwacht dat daar de voorkeur blijft hangen voor thin & light laptops. Deze bieden doorgaans ook een lange accuduur, portability en hebben ook het voordeel van een fysiek toetsenbord.

ARM architectuur is rockend genoeg om na een paar jaartjes ontwikkelen in een desktop X86 te vervangen. Misschien 10 jaar, maar ondersteuning in Windows 8 is wel een dealmaker.

Niet alleen aan tablets denken En trouwens, waarom zou Win8 niet exact dezelfde schill kunnen krijgen als b.v. WP7? De shell en het O/S zijn 2 totaal verschillende dingen, vergeet dat niet.

Als je ziet dat er vele mensen toch een tablet met Win7 kopen terwijl dat alles behalve vlot werkt met een tablet, kan je stellen dat er zeer veel mensen zitten te wachten op een lightweight ARM Windows 8 ja.

Krijg je meteen het platform waar het grootst aantal ontwikkelaars voor beschikbaar is.

Windows 8 krijgt ook 2 shells mee, eentje die redelijk gaat lijken op windows 7 naar alle waarschijnlijkheid (er zullen wel aanpassingen zijn zoals de ribbon interface in windows explorer etc.) en de zogenaamde metro GUI die speciaal voor touch screens is ontwikkeld en zaken van windows phone 7 overneemt. Van de metro gui is nog erg weinig bekend maar neem maar aan dat er ontzettend van onderzoek ingepompt word.

Heb jij dan inside informatie dat je weet hoe Windows 8 op tablets gaat werken? En dat dat volgens jou blijkbaar niet relaxed kan zijn?

Voor AMD hoef je toch ook geen verschillende apps te schrijven...dit is denk ik meer drivers en OS gerelateerd. Intel is zeker bang omdat de snelle ontwikkeling van ARM. Dit jaar dual-cores en begin volgend jaar quad cores... in een smart-phone.

Voor Windows 8 ARM moet er opnieuw gecompileerd worden.. net als de 32bit/64bit versie. Daarnaast verwacht ik een legacy virtualisatie.

Het aanpassen van de interface ben ik het meest benieuwd naar hoe die op iPad / Android 3.1 gaat lijken of dat ze een hele unieke interface en ontwikkel platform gebruiken net als met Windows Phone 7 met Silverlight/ Xna. Aan de gelekte screenshots te zien gaat het meer de unieke kant op.

[Reactie gewijzigd door Hyperik op 19 mei 2011 11:20]

Die vergelijking die je hier trekt gaat helaas niet zo makkelijk op. De desktop cpu's die AMD maakt, maken gebruik van de Intel x86 instructieset. Intel heeft de x86 instructieset ontwikkeld en gepatenteerd, met als gevolg dat andere bedrijven zoals AMD, VIA, etc daar licentiegelden voor moeten betalen. Dat is natuurlijk een bijzonder vervelend probleem, gezien windows standaard gebouwd wordt op een x86 architectuur. Als AMD dan een eigen architectuur ontwikkelt die niet compatibel is, dan werkt ineens windows niet meer. Een cpu bouwen waar grote OS's niet op draaien is niet zo rendabel, dus bedrijven als AMD zijn wel verplicht om een licentie te nemen op intel's x86 architectuur. Bovendien is het ontwikkelen van een nieuwe architectuur bijzonder complex, tijdrovend en kostelijk. Nu Microsoft ineens ondersteuning gaat bieden voor ARM cpu's, die niet gebruik maken van die befaamde x86 architectuur, komt Intel's positie een stukje in gevaar. Logisch dus dat Intel van zich af gaat bijten.
Overigens is het wel goed dat er eindelijk een frisse wind gaat waaien, want eigenlijk is de x86 architectuur flink verouderd en zouden er veel efficientere systemen ontwikkeld kunnen worden. De extensies zoals x86-64/IA-64 bouwen direct voort op het achterhaalde x86 systeem, met alle inefficiencies van dien. Ook ondersteuning voor visualisatie, security etc zouden mogelijk efficienter kunnen in nieuwe architecturen.


Bronnen:
ARM achitecture: http://en.wikipedia.org/wiki/ARM_architecture
ARM instruction manual: http://www.arm.com/miscPDFs/14128.pdf
Intel x86 developers manual: http://www.intel.com/products/processor/manuals/
x86 en de core I7: http://computertotaal.nl/...ng-onder-de-motorkap.html

Men heeft het met Itanium geprobeerd en men heeft gefaald. X86 zal nog niet zo snel verdwijnen

Men heeft het met Itanium geprobeerd en men heeft gefaald. X86 zal nog niet zo snel verdwijnen

Maar Itanium was dan ook compatible met zichzelf.

Het aardige dan Windows 8 is dat het zichzelf "compatible emuleert" op een ARM. (van wat ik begrepen heb)

Dat heeft intel toch zelf ook gedaan door de waanzinnig geoptimaliseerde compiler voor de Itanium te ontwikkelen die X86-64 ´emuleerde´.

Zolang als X86-64 als front end voor de processor functioneert die vervolgens intern allang niet meer zo functioneert blijft het een nuttige instructieset die vrij gemakkelijk als interface naar zelfs exotische architecturen als VLIW of meer gewone Risc instructies kan dienen. Een X86 processor is een front end voor een zwaar geoptimaliseerde RISC processor.

Processor architectuur en instructieset zijn de facto ver ontkoppeld van elkaar.

AMD maakt dan ook x86 compatibele CPU's, ARM CPU's zijn niet x86 compatibel.

Ik bedoelde inderdaad de x64 dat AMD uitvond, de x86 is inderdaad al ''meer'' compatible met andere x86. Maar hoe dat ook is dit de grootste moeite voor MS en ARM-chip partners. Voor ontwikkelaars recompile en interface aanpassingen.

"x64" is niks meer dan een uitbreiding op x86, daarom heet het ook eigenlijk geen x64, maar x86-64 of AMD64.

Ik denk niet dat Ontwikkelaars zich hier zo druk over hebben gemaakt, ik denk dat de meeste toch wel hadden aangevoeld dat Microsoft hier wel een oplossing voor zou hebben zoals ze altijd al hebben. Legacy is het belangrijkste waar Windows opdraait, zonder Legacy waren de meeste al lang overgestapt op andere besturingssystemen, of in iedergeval lekker zwevend geweeest.

Intel probeert zijn x86 platform te beschermen tegen de opmars van ARM?

tsja niet onverwacht, ik vond het bericht al erg negatief vanuit intel
en natuurlijk probeert intel zijn eigen inkomen te beschermen en ARM's inkomen af te nemen met de next gen atoms, daar is het concurrentie voor...

ik nam de uitspraak dus ook met de spreekwoordelijke korrel zout,
en nu wordt dus gedeeltelijk bevestigd dat de informatie inderdaad niet volledig/incorrect is, kortom laten we eerst maar eens wachten tot er echte informatie vrijkomt,
maar het blijft een "vieze" actie van intel, en vraag me af of ze niet vele NDA's hebbeng ebroken hiermee...

al hoop ik dat er inderdaad geen 4 versies voor verschillende ARM's komt, dat zou toch wel erg zonde zijn.

Ik denk dat de waarheid in het midden ligt. .NET "recente" applicaties zullen wel draaien. Maar een Willekeurige WIn32 applicatie op ARM.
Als ik een Willekeurige win32 pak zal deze het ook niet altijd op windows 7 werken.
Ik heb een hele cd stapel met niet meer werkende win32 games. (gelukkig is er wine)

Tenzij ze x86 code in een soort VM gaan draaien.

VM gaat niet omdat daar de CPU Native is. emuleren gaat wel Maar de vraag is wat de performance wordt. Zeker als er SSE3 3D instructies worden uitgevoerd. Ben je als ARM processor (een gereduceerde instructie set) lekker lang mee bezig.

En als Office en IE Arm native zijn dan is dat al een groot voordeel voor MS ten opzichte van de concurrentie.

Ik ken niet alle Office en IE concurenten Maar de meeste openSource concurrenten zijn gewoon ARM compatible

[Reactie gewijzigd door daft_dutch op 19 mei 2011 15:09]

Apple heeft het gedaan met de switch van PPC naar Intel. Mogelijk zal MS iets gelijkaardigs proberen voor ARM. Een compatbiliteitslaag.

Er was voor de overgang van PPC naar X86 helemaal geen compatibiliteits laag.

Mac apps bevatte gewoon 2x de code: een voor PPC en een voor X86. Er bestaan nog steeds Apps die de PPC code slopen uit PPC compatible apps zodat je die ruimte bespaart als je het niet nodig hebt.

Je vergeet dan wel rosetta. De compatibily laag die er inmiddels uitgesloopt is sinds 10.6

Het zit er nog steeds in bij 10.6 hoor. Ik draai nog genoeg PPC binaries op mijn MBP uit juli 2010. Het is wel zo dat het er niet meer standaard in zit, je zult het moeten installeren vanaf de installatie DVD.

Nee, wat jij bedoelt zijn universal binaries: een binary met zowel PPC code als X86 code. Dacht jij dat Adobe bij de release van de eerste X86 mac meteen een universal binary uitgebracht heeft? Nee, kijk eens hier: http://www.apple.com/nl/rosetta/

Dan moet je wel heel veel pech hebben. Stak onlangs nog een cdtje van het spel G-Police (nog bij mijn voodoo2 gekregen) in m'n dvd-drive en die installeerde en speelde gewoon zoals het moest. Onder Windows 7 64bit (ultimate).

maar het blijft een "vieze" actie van intel

Niet dat Intel vies is van vieze acties.

Maar het kan natuurlijk ook op foute aannames gebaseerd zijn, want MS moet wel x86 code vertalen naar ARM code, het zal sowieso vast vertragend werken.
En op zeker zullen niet alle programma's werken op een ARM CPU, sommige programma's praatten direct met de CPU, denk bv video encoder.

Maar in het algemeen zal voor de meeste programma's die weinig CPU kracht nodig hebben, ARM niet zo een probleem zijn.

Tenzij ze x86 code in een soort VM gaan draaien.

En 3 keer raden wie er eigenaar is van die x86 code.

Blijft over dat ook in een VM de snelheid langzamer zal zijn, x86 hardware zal normaal altijd sneller zijn dan x86 via software op andere hardware draaien. Als het even snel of sneller zou zijn op andere hardware dan was er geen x86 meer.

Blijft het van MS een slimme zet vinden dat ze ook andere cpu's gaan ondersteunen, op die manier maken ze het ander osén weer een stuk moeilijker.

En als Office en IE Arm native zijn dan is dat al een groot voordeel voor MS ten opzichte van de concurrentie.

Dat x86 apps wat minder snel zijn is iets wat op den duur niet meer relevant is als ze vervangen worden door Arm apps of een zelfde structuur als OSX had ten tijde van de overstap PPC -> x86.

Denk niet dat dat geld voor vertaalde x86 code, maar alleen voor hardware.

Want als je die redenering volgt zouden er geen programma gebruikt kunnen worden zonder licentie te betalen aan Intel

Vier verschillende HAL´s is toch zo´n drama niet? Had NT ook toen het nog op Mips etc. moest draaien.

Het zal wel mevallen. In het ergste geval zul je all je DLLs and exe's 2x moeten compileren(Zoals dat nu al het geval is voor 32 en 64 bit). Het lijkt me dat Windows 8 voor ARM en x86 exact hetzelfde is behalve de processor. Windows 8 heeft ook geen 32 bit versie meer dus uiteindelijk zul je net zoveel versies hebben als nu. Nu is het 32/64 bit en straks is het ARM/x86 CPU. Weinig verschil lijkt me.

Helaas zit het net iets complexer: Bij ARM SoC's zitten de "video-kaart, geluidskaart, a/v codec" allemaal samen met de CPU op hetzelfde chipje. Wat leveranciers doen, is één enkele driver leveren voor heel het zwikje.

En eigenlijk wil je dat als MS helemaal niet; je wil een losse driver voor de video-kaart, losse driver voor de geluidskaart enz.

Want nu is het zo dat je per SoC een 'driverpakket' aangeleverd krijgt (vandaar vermoedelijk "4 versies"). Dat is te vergelijken met:
-Dell levert een alles-in1 driver voor hun PC's,
-HP levert zo'n driver voor hun PC's,
-Acer levert zo'n driver voor hun PC's enz.
maar ondanks dat HP, Dell en Acer misschien deels dezelfde hardware hebben, wisselen ze niets uit.

Als je zodoende 10 driverpakketjes hebt, zijn dat eigenlijk veel te veel drivers; omdat veel SoC's dezelfde componenten (geluidskaart/ videokaart) hebben.

Het enige wat hierbij een punt kan zijn, is dat de verschillende ARM versies afwijken op functionaliteit die in de huidige versie van Windows typisch niet in DLLs geïmplementeerd en afgezonderd is (maar gewoon intern in de programma's wordt gebruikt). Als je die verschillen dus via een API enzo wil afschermen zal er (weeral) één en ander in Windows moeten veranderen. Per definitie gaat bestaande code geen gebruik maken van die nieuwe APIs.

Was idd al een vreemde waarschuwing van Intel. Als deze waarschuwing van de maker van het besturingssysteem was gekomen, Microsoft in dit geval, dan was het al betrouwbaarder geweest.

Hoe weet Intel nu exact wat Microsoft voor ogen heeft. Misschien bouwen ze wel iets als Rosetta in, wat Apple destijds ook voor OSX gedaan heeft toen ze van PPC overstapten op Intel. En daarnaast bestaan er nog frameworks als .NET en Java.

Rosetta was een emulator, om ppc code te draaien op krachtige x86 (core2 volgens mij) desktop processors. Wat microsoft in deze situatie zou moeten doen is complexe x86 instructies, inclusief uitbreidingen als sse etc. emuleren op een veel simpelere ARM processor, die elke instructie uit de win32 om moet zetten in een handvol arm instructies. Het zal vast werken, maar soepel zal het nooit gaan.

Waarom vier verschillende Windows' als een andere HAL volstaat? Of is dat makkelijker gezegd dan gedaan?

Wat Microsoft betreft volstaat een andere HAL ja, maar als de 3rd party native applicaties ook van de specifieke ARM instructiesets gebruik willen maken, moeten die voor elke ARM versie gecompileerd worden (bij een .NET / Java app gebeurt dit vanzelf).

Als je nu een game hebt die (intern) van SSE3 / 3DNow, whatever wil gebruik maken, dan moet daar ook specifiek een code-path voor voorzien worden.

Het lijkt me dat als Microsoft WoW64 goed kan laten werken voor x64 <-> x86, ze dan ook een vergelijkbare oplossing (W64oWARM ?) zouden kunnen gebruiken om ARM te kunnen bedienen lijkt me.

[Reactie gewijzigd door ocf81 op 19 mei 2011 13:24]

Zal Photoshop werken als Windows toch Legacy op ARM gaat draaien? Ik weet niet of Photoshop direct tegen de processor praat of niet, maar aangezien het een groot programma is, zowel in de zin van digitale grootte als competitieve grootte.. Zou wel iets zijn voor Adobe om hun producten daarmee zo snel mogelijk te maken, maar is dit ook t geval?