CES: Nieuwe Windows-versie ondersteunt ARM-architectuur
Microsoft heeft tijdens de CES bekend gemaakt dat de volgende Windows-versie gedraaid kan worden op de ARM-architectuur. Momenteel is Windows voor desktops en dergelijke feitelijk nog gelimiteerd tot de x86-architectuur.
Dat betekent onder andere dat Snapdragon-soc van Qualcomm en de Hummingbird-soc van Samsung in de toekomst gebruikt kunnen worden in combinatie met het nieuwe Windows-besturingssysteem. Microsoft gaat woensdagnacht demonstreren hoe de aankomende Windows-versie draaide op zowel x86- als ARM-hardware, waarbij er gebrowset wordt in Internet Explorer, filmpjes worden bekeken en Office wordt gedraaid.
Soc's op basis van de ARM-architectuur zijn over het algemeen langzamer dan x86-varianten, maar ook stukken zuiniger. Op dit moment kan Windows 7 op een tablet enkel gebruikt worden in combinatie met x86-cpu's. Door de nieuwe Windows-versie van ARM-ondersteuning te voorzien, zijn tablet-fabrikanten niet langer gelimiteerd tot x86-cpu's en kunnen er dus Windows-tablets komen die langer meegaan op een acculading. Samenvallend met Microsofts aankondiging hield Nvidia een persconferentie, waarin het Project Denver aankondigde. Nvidia wil een soc ontwikkelen op basis van de ARM-architectuur, die snel genoeg is voor gebruik in desktop-pc's.
Microsoft heeft het in zijn aankondiging over ondersteuning voor system-on-a-chip, oftewel soc's. Daarmee worden onder andere de nieuwe chips van zowel Intel als AMD bedoeld, die over zowel een cpu als een gpu beschikken. Veel interessanter is echter het feit dat ook soc's op basis van de ARM-architectuur ondersteund zullen worden door de nieuwe Windows-versie.
Reacties (90)
Dus, toch. Hier zullen Samsung en Qualcomm met de Hummingburid en Snapdragon wel blij mee zijn. Voor AMD en Intel is er iig werk aan de winkel 
volgens mij gaan die VEEEEEEL te traag zijn, om dat logge windows vooruit te krijgen
Dat maken ze dan wel goed met een GPU die 400W gebruikt 
Gewoon Windows 8 met waarschijnlijk aangepaste UI voor arm tablets.
Hier al een mooi voorbeeld van een Tablet app. (en wp7)
Must SEE video!!!!!!:
http://www.flickr.com/windows7/
dus Grafische Silverlight geoptimaliseerde apps.
Hier al een mooi voorbeeld van een Tablet app. (en wp7)
Must SEE video!!!!!!:
http://www.flickr.com/windows7/
dus Grafische Silverlight geoptimaliseerde apps.
[Reactie gewijzigd door Hyperik op donderdag 6 januari 2011 08:42]
Als je heel veel eyecandy, allerlei achtergrondprocessen en het preloaden van DLLs uitzet, dan moet het te doen zijn. Vergeet niet dat de mobiele devices van tegenwoordig evenveel rekenkracht hebben als een Pentium2/Pentium3 machine. Daar kon ook Windows op draaien mits je het geheugenmanagement en de diskcaching goed instelde.
Ik weet alleen niet of je er blij mee moet zijn om Windows op een tablet of telefoon te draaien die via GSM direct aan het internet hangt. Regel nummer 1 is nog altijd dat je Windows nooit direct aan internet moet hangen. Alle lekken die in de x86 versie zitten zullen ook in de ARM versie zitten.
En dan ontbreekt er natuurlijk nog heel veel software. Microsoft en ook Borland (denk aan BorlandC en Delphi) zullen met goede cross-compilatie tools moeten komen als er nog geen ARM desktop systemen beschikbaar zijn die krachtig genoeg zijn om een flink programma in een redelijke tijd te compileren. Hercompileren is bovendien niet eenvoudig als software slecht geschreven is. Bijvoorbeeld: een x86 staat toe een 32 bits getal unaligned te lezen (dus van een adres dat geen veelvoud van 4 is) en daar wordt nog weleens gebruik van gemaakt. Met een ARM lukt dat niet dus zal de compiler (best case) in geval van twijfel de potentieel 32 bits aktie opbreken in 4 akties van 1 byte met de nodige schuifinstructies (dat wordt dus rete-traag).
Ik weet alleen niet of je er blij mee moet zijn om Windows op een tablet of telefoon te draaien die via GSM direct aan het internet hangt. Regel nummer 1 is nog altijd dat je Windows nooit direct aan internet moet hangen. Alle lekken die in de x86 versie zitten zullen ook in de ARM versie zitten.
En dan ontbreekt er natuurlijk nog heel veel software. Microsoft en ook Borland (denk aan BorlandC en Delphi) zullen met goede cross-compilatie tools moeten komen als er nog geen ARM desktop systemen beschikbaar zijn die krachtig genoeg zijn om een flink programma in een redelijke tijd te compileren. Hercompileren is bovendien niet eenvoudig als software slecht geschreven is. Bijvoorbeeld: een x86 staat toe een 32 bits getal unaligned te lezen (dus van een adres dat geen veelvoud van 4 is) en daar wordt nog weleens gebruik van gemaakt. Met een ARM lukt dat niet dus zal de compiler (best case) in geval van twijfel de potentieel 32 bits aktie opbreken in 4 akties van 1 byte met de nodige schuifinstructies (dat wordt dus rete-traag).
De compiler aligned het 32-bits getal gewoon en laat een gat vallen Dat is rete-snel
Het kost alleen iets meer geheugen. En er zijn programmeurs die deze (interne data) structuren een op een naar een bestand schrijven. En dat is dus fout.
Het kost alleen iets meer geheugen. En er zijn programmeurs die deze (interne data) structuren een op een naar een bestand schrijven. En dat is dus fout.
Kijk in een gemiddeld C / C++ programma eens hoe vaak er een void of char pointer wordt doorgegeven die eigenlijk een pointer naar een struct is of een array met 16 of 32 bits elementen. In die gevallen KAN de compiler geen gat laten vallen en moet de compiler er rekening mee houden dat de pointer geen veelvoud van 4 is!
[Reactie gewijzigd door ncoesel op donderdag 6 januari 2011 09:29]
[dit is ook een reactie op de post hieronder van MSalters]
Ik denk dat jullie een aantal dingen door elkaar aan het halen zijn, vermoedelijk omwille van een onvoldoende kennis van het ARM-platform. ARM heeft wel degelijk geen enkel probleem met het inladen van getallen/data van eender welk geheugenadres.
Bijvoorbeeld, de instructie
LDR r0, [r1]
gaat vanaf geheugenadres dat in r1 zit 32-bits laden en die in r0 steken. Hierbij is er geen enkele limiterende factor op het adres in r1. Dat mag wijzen naar gelijk welk adres, ook indien het geen veelvoud van 4 is.
Wat jullie wilden zeggen is dat ARM niet rechtstreeks 32-bit immediate values kan inladen in een register (omdat het een RISC-instructieset is). Wat je in ARM dus niet kan doen (en op Intel wel) is iets in de genre van:
MOV r0, #0xdeadbeef
Op ARM zou je het inladen van die constante inderdaad moeten opsplitsen in meerdere instructies, met in het slechtste geval een totaal van 4 instructies.
Dit is echter zelden een probleem voor twee redenen:
- immediate values worden niet heel veel gebruikt in code (omdat de meeste getallen en adressen ofwel berekend worden ofwel uit het geheugen geladen worden)
- de immediate values die vaak gebruikt worden zijn kleine getallen als 0, 1, -1 of flags alla 0x100000. Deze getallen kunnen allemaal met één enkele instructie in een register geladen worden.
Daarnaast moeten jullie je niet zo blind staren op het aantal instructies (dat is een beetje hetzelfde als zeggen dat de ene computer sneller is dan de andere "omdat die meer megahertz heeft"). Instructies kunnen meerdere clockcycles nodig hebben om uitgevoerd te worden, dus een betere metriek om de snelheid van code te meten is uittellen hoeveel clockcycli een algorithme nodig heeft ipv. hoeveel instructies het uitvoert. ARM-instructies gaan typisch minder cycli nodig hebben dan Intel-instructies, aangezien de ARM-instructies vaak ook eenvoudiger zijn. Je hebt dus wel evenveel of meer instructies nodig om hetzelfde te bereiken, maar het eindresultaat is niet per sé dat dit trager is...
Ik denk dat jullie een aantal dingen door elkaar aan het halen zijn, vermoedelijk omwille van een onvoldoende kennis van het ARM-platform. ARM heeft wel degelijk geen enkel probleem met het inladen van getallen/data van eender welk geheugenadres.
Bijvoorbeeld, de instructie
LDR r0, [r1]
gaat vanaf geheugenadres dat in r1 zit 32-bits laden en die in r0 steken. Hierbij is er geen enkele limiterende factor op het adres in r1. Dat mag wijzen naar gelijk welk adres, ook indien het geen veelvoud van 4 is.
Wat jullie wilden zeggen is dat ARM niet rechtstreeks 32-bit immediate values kan inladen in een register (omdat het een RISC-instructieset is). Wat je in ARM dus niet kan doen (en op Intel wel) is iets in de genre van:
MOV r0, #0xdeadbeef
Op ARM zou je het inladen van die constante inderdaad moeten opsplitsen in meerdere instructies, met in het slechtste geval een totaal van 4 instructies.
Dit is echter zelden een probleem voor twee redenen:
- immediate values worden niet heel veel gebruikt in code (omdat de meeste getallen en adressen ofwel berekend worden ofwel uit het geheugen geladen worden)
- de immediate values die vaak gebruikt worden zijn kleine getallen als 0, 1, -1 of flags alla 0x100000. Deze getallen kunnen allemaal met één enkele instructie in een register geladen worden.
Daarnaast moeten jullie je niet zo blind staren op het aantal instructies (dat is een beetje hetzelfde als zeggen dat de ene computer sneller is dan de andere "omdat die meer megahertz heeft"). Instructies kunnen meerdere clockcycles nodig hebben om uitgevoerd te worden, dus een betere metriek om de snelheid van code te meten is uittellen hoeveel clockcycli een algorithme nodig heeft ipv. hoeveel instructies het uitvoert. ARM-instructies gaan typisch minder cycli nodig hebben dan Intel-instructies, aangezien de ARM-instructies vaak ook eenvoudiger zijn. Je hebt dus wel evenveel of meer instructies nodig om hetzelfde te bereiken, maar het eindresultaat is niet per sé dat dit trager is...
Het voorbeeld om een 32-bit constante te laden kan door de compiler opgelost worden door de constante als 32-bit waarde aan het einde van de functie te zetten en deze waarde dan pc-relatief te laden.
Zo dus:
...
LDR r0, [pc+x] -> Wijst naar constante '#0xdeadbeef' in de code
<meer instructies>
<nog meer instructies>
#0xdeadbeef
Zo dus:
...
LDR r0, [pc+x] -> Wijst naar constante '#0xdeadbeef' in de code
<meer instructies>
<nog meer instructies>
#0xdeadbeef
Klopt, maar dan heb je een extra geheugenaccess nodig (en die constante gaat niet in de cache staan, want ARM heeft een aparte data- en instructie-cache...). Aangezien de meeste constanten in één of twee instructies geladen kunnen worden (zonder geheugenaccess) zal dat sneller zijn dan het laden van de constante uit het geheugen...
Ik heb meer dan eens de Win32 documentatie en headers gelezen. Er zijn een groot aantal plaatsen in de Win32 API waar getallen opzettelijk niet aligned zijn, en in de headers wordt de compiler dan expliciet verteld (#pragma pack) om 1-byte alignment te doen. Dat is iets langzamer op de x86, maar heel veel langzamer op de ARM. Concreet betekent dat dat de Win32-ARM API aangepast zal moeten worden en structure-wise niet compatible is met Win32-x86.
Dit is natuurlijk niet helemaal waar, ik durf zelfs te beweren dat de voor de ARM versie in principe minder code nodig is, aangezien voor voor deze architectuur weinig tot geen rekening gehouden hoeft te worden met legacy programma's die je op de x86 /x84 windows versie wel hebt.
Hierdoor zullen een hoop lekken die in windows kunnen zitten, niet direct ook in de ARM versie opduiken.
Over het ontbreken van software en het nodig hebben van goede cross compilers heb je natuurlijk gelijk.
Hierdoor zullen een hoop lekken die in windows kunnen zitten, niet direct ook in de ARM versie opduiken.
Over het ontbreken van software en het nodig hebben van goede cross compilers heb je natuurlijk gelijk.
Nee, er komen nieuwe lekken bij. En een simpele recompile voor ARM van alle libraries fixt niet automatisch je bugs.Hierdoor zullen een hoop lekken die in windows kunnen zitten, niet direct ook in de ARM versie opduiken.
Je mist het probleem. Er zijn hele stukken code in Windows die alleen dienen om defecte x86 programma's te laten runnen. Zo bevat bijvoorbeeld de eerste SimCity een bug, waardoor het crashte op Windows. Microsoft heeft een workaround gemaakt in Windows, maar dat soort hacks zijn niet de best geteste stukken. Al dat soort code kan nu met een "#ifdef _M_X86" geskipt worden voor de ARM build. En omdat die code dus nooit in de ARM build komt, geldt dat ook voor alle bug erin.
Dan hebben we weer een OS voor op de HD2 
Windows 8 op de HD2 
yeah
Of op elke Android / symbian telefoon op aarde, Starcraft 2
yeahOf op elke Android / symbian telefoon op aarde, Starcraft 2
Dus dezelfde Windows 8 die ik straks op mijn pc draai draait precies hetzelfde ook op mobiele telefoons?
Ik denk dat de interface wel wat zal verschillen, maar in theorie moet het dus mogelijk zijn. De demonstratie, die pas over 4-5 uur plaatsvindt, zal nog wel wat meer duidelijkheid brengen.
[Reactie gewijzigd door Marc Rademaker op woensdag 5 januari 2011 23:24]
Oftewel ik zal:
1. Een rete traag os op mijn telefoon hebben?
of
2. Een zo snel os dat een SSD weinig toevoegd?
En hoe zit het dan met dingen als Virtual machines en DirectX?
1. Een rete traag os op mijn telefoon hebben?
of
2. Een zo snel os dat een SSD weinig toevoegd?
En hoe zit het dan met dingen als Virtual machines en DirectX?
Verwacht dat er meerdere versies gaan komen, met aangepaste interface. Tevens zal de gpu veel meer gebruikt gaan worden voor dingen als de interface denk ik. Een SSD voegde zowiezo al weinig toe aan zaken die processorkracht nodig hebben, juist mobile devices zitten al langer op flash geheugen met zijn lagere acces times.
In de trent van windows CE of windows home basic/premium?
Of IOS 4.2 op een iPhone 3g. Wat is dat traag.
maar hoe zit dat dan met de programma's? want hier staat dat ze office hebben kunnen gebruiken, en gebrowsed wordt in IE, maar zijn dat dan ook de enige dingen die kunnen draaien? aangezien voor zover ik weet alles gerecompiled moet worden voor ARM, dus misschien behalve .net, aangezien dat in een virtuele machine(verkeerd verwoord geloof ik maar ik hoop dat er gesnapt wordt wat ik bedoel) draait, waardoor het waarschijnlijk niet zo moeilijk moet zijn om dat te draaien.
Maar als alle normale programma's het niet doen, krijgen ze hetzelfde probleem als de smartbooks, en als ze het verkeerd aanpakken, door het uit te brengen als gewoon windows 8 en vervolgens een hoop software niet ondersteund, krijgen ze imagoschade a la windows vista schaal, en dan is het waarschijnlijk best wel gedaan met ARM, want dan heeft iedereen(die geen verstand heeft van technologie) een naar idee bij ARM, namelijk dat niks daarop werkt
Maar als alle normale programma's het niet doen, krijgen ze hetzelfde probleem als de smartbooks, en als ze het verkeerd aanpakken, door het uit te brengen als gewoon windows 8 en vervolgens een hoop software niet ondersteund, krijgen ze imagoschade a la windows vista schaal, en dan is het waarschijnlijk best wel gedaan met ARM, want dan heeft iedereen(die geen verstand heeft van technologie) een naar idee bij ARM, namelijk dat niks daarop werkt
Klopt, native x86 programma's gaan echt niet zomaar draaien op een ARM Windows. Net zoals een x64 app niet op een 32-bits Windows draait. Die zullen eerst opnieuw gecompileerd moeten worden.
Overigens zei je het goed, .Net (de CLR) is een VM.
Overigens zei je het goed, .Net (de CLR) is een VM.
Vermoedelijk met emulator, of 'vooraf'-software-vertaler.
Maar ja, een trage processor én emulatie; dan wordt het verschil met native x86 wel hééél groot
Andersom net zo hard, Android x86 draait ook nog bagger op veel snelere hardware. Maar uiteindelijk moet het wel komen, alleen de software ontwikkeling word wat anders.
Klopt, elk programma heeft een recompile nodig, behalve spul dat alleen via .Net / Java of andere, niet natively compiled talen draait. Soms is er ook meer nodig dan een hercompilatie, als er machine-specifieke instructies in het programma of een van de afhankelijkheden zijn opgenomen. Die moet dan opnieuw geprogrammeerd worden.
De gemiddelde gebruiker zit dan inderdaad met een probleem, want alle downloads die voorheen gewoon werkten in windows zullen het nu niet meer doen en dat is natuurlijk niet te begrijpen. Ik vraag me dan trouwens af of arm hier wel de schuld van krijgt, dat zal toch eerder windows 8 zijn lijkt me.
Het is natuurlijk ook nog maar helemaal de vraag of ms een desktop windows 8 zomaar in de schappen gaat leggen voor de consument. Dat Windows 8 erop draait wil niet zeggen dat het op desktop machines te koop zal zijn.
De gemiddelde gebruiker zit dan inderdaad met een probleem, want alle downloads die voorheen gewoon werkten in windows zullen het nu niet meer doen en dat is natuurlijk niet te begrijpen. Ik vraag me dan trouwens af of arm hier wel de schuld van krijgt, dat zal toch eerder windows 8 zijn lijkt me.
Het is natuurlijk ook nog maar helemaal de vraag of ms een desktop windows 8 zomaar in de schappen gaat leggen voor de consument. Dat Windows 8 erop draait wil niet zeggen dat het op desktop machines te koop zal zijn.
Recompilen is niet veel meer dan een knopje selecteren in Visual Studio. Dat is dus niet direct het probleem. Misschien dat Microsoft ook de universal binary strategie van Apple overneemt en je dus 1 pakket krijgt dat op alles te installeren is.
Probleem is natuurlijk wel dat niet alle software die nu uit is een update krijgt naar een AMD versie, maar voor courante software zou dat geen probleem moeten zijn. Daarnaast is het niet zo dat Microsoft nu opeens x86 de rug toekeert. Het is meer de (zoveelste) poging om naast x86 ook een andere architectuur te ondersteunen. Of dat aanslaat? De vorige keren is het niet echt een succes geworden... Alles hangt dus af van de software ontwikkelaars maar het is goed dat Microsoft weer eens aantoont dat als er een alternatief is zij niet te beroerd zijn andere hardware te ondersteunen.
Probleem is natuurlijk wel dat niet alle software die nu uit is een update krijgt naar een AMD versie, maar voor courante software zou dat geen probleem moeten zijn. Daarnaast is het niet zo dat Microsoft nu opeens x86 de rug toekeert. Het is meer de (zoveelste) poging om naast x86 ook een andere architectuur te ondersteunen. Of dat aanslaat? De vorige keren is het niet echt een succes geworden... Alles hangt dus af van de software ontwikkelaars maar het is goed dat Microsoft weer eens aantoont dat als er een alternatief is zij niet te beroerd zijn andere hardware te ondersteunen.
ik denk niet dat er een universal binary zal komen. Dat maakt de programmas een heel pak groter en dat wil je net niet als je iets ontwikkeld voor embedded devices met beperkte opslag capaciteit.
Wat softwaremakers wel kunnen doen is de software bundellen bij aankoop, maar het zou me niet verbazen als er zijn die 2 keer hopen geld te verdienen.
Wat softwaremakers wel kunnen doen is de software bundellen bij aankoop, maar het zou me niet verbazen als er zijn die 2 keer hopen geld te verdienen.
Dat valt stiekem best mee. De echte code (dus niet resources, bitmaps, fonts, vertalingen, ...) is zelden meer dan een paar megabyte. Als dat verdubbelt heb je nog steeds geen probleem. Vergeet niet dat Win8 pas in 2012 komt, dus dan heb je op elke Win8 telefoon 4GB+.
Tablets hehe
dit maakt gelijk het nvidea bericht van net duidelijk
Laat dit nu het eerste nieuws zijn van de CES waarbij ik daadwerkelijk iets heb van "WOW! Wat interessant!". Ik ben erg benieuwd!
Ik ben werkelijk verbaasd hierover. Dit noem ik een baanbrekende strategische move. Gaat het Wintel tijdperk dan werkelijk afgesloten worden? Ik had wel door dat MS geirriteerd was door de matige performance van Intel in de tablet cpu's, maar dit noem ik nogal een wijziging. Erg benieuwd! Bijv die EEE tablet met losse cradle van ASUS icm win7 op een arm cpu. Of die dual core :-)
Top tijden! Ik wacht nog even met kopen. (dat heb ik al jaren geroepen trouwens - hou ik nooit lang vol)
Top tijden! Ik wacht nog even met kopen. (dat heb ik al jaren geroepen trouwens - hou ik nooit lang vol)
Windows 8 komt pas in 2012, dus koop gerust nu :-)
Yup. Maar Microsoft moet ook wel, willen ze meedoen in pad-race. Nog een belangrijke rede is dat ARM zelf helemaal geen chips maakt. De ARM core is feitenlijk een ontwerp voor een chip (RTL code), die door Qualcom, Nvidea, Apple (A4) en vele anderen, worden gebruikt om er een processor van te maken. Daardoor kunnen ze er van alles aan toevoegen. Het is net als open-source systemen als Linux en Android, iedere fabrikant kan het kneden tot iets dat hun ontwerp het beste past.
Die flexibiliteit van de ARM core, is mischien wel net zo belangrijk als de performance per watt. Wie weet, zal intel ook ooit een ontwerp van hun chips vrij geven?
Die flexibiliteit van de ARM core, is mischien wel net zo belangrijk als de performance per watt. Wie weet, zal intel ook ooit een ontwerp van hun chips vrij geven?
De ARM core is gepatenteerd, de vergelijking met open-source klopt dus niet echt Een computerarchitectuur vergelijken met een besturingssysteem is ook niet echt juist.
Een computerarchitectuur vergelijken met een besturingssysteem is ook niet echt juist.Voor ARM moet je een licentie kopen, dus je kunt het al niet vergelijken met OSS
Onzin, open source heeft niets met licenties te maken! Het gaat erom dat het 'ontwerp' beschikbaar en openbaar is. Dus boeken zijn open source maar mag je (meestal) niet kopiëren. Microsoft bijvoorbeeld heeft ook code onder bepaalde licenties die het verbieden verder te distribueren etc.
Doorgaans is het zo dat als iets open source is en de source is makkelijk te verkrijgen, dat je dan makkelijk illegaal aan de code kan komen ook als de licentie dit verbiedt.
In het geval van ARM zullen fabrikanten dat niet zo snel doen denk ik. Op x86 kan je ook een licentie nemen, maar kennelijk is dat zo lastig / onaantrekkelijk dat alleen AMD en VIA er een redelijk aantal van produceren, dus daar is weinig concurrentie vergeleken met ARM, waar 100+ fabrikanten een licentie op hebben en maken.
Doorgaans is het zo dat als iets open source is en de source is makkelijk te verkrijgen, dat je dan makkelijk illegaal aan de code kan komen ook als de licentie dit verbiedt.
In het geval van ARM zullen fabrikanten dat niet zo snel doen denk ik. Op x86 kan je ook een licentie nemen, maar kennelijk is dat zo lastig / onaantrekkelijk dat alleen AMD en VIA er een redelijk aantal van produceren, dus daar is weinig concurrentie vergeleken met ARM, waar 100+ fabrikanten een licentie op hebben en maken.
En wat is het verschil tussen Linux en BSD unix....juist de licentie.
Open source is juist de lecentie.
Open source is juist de lecentie.
het is niet zo dat iedereen een licentie kan nemen op x86, AMD en Intel hebben contracten afgesloten waardoor ze van elkaars technologieën gebruik mogen maken, via heeft ook nog een licentie, maar intel geeft echt geen licenties meer weg, ze vonden al dat AMD hem in moest leveren doordat ze niet meer zelf de CPU's maakten, dus denk maar niet dat je zomaar als bedrijf(hoe groot het bedrijf ook is) een x86 cpu kan gaan maken
Arm heeft het Intellectueel eigendom op de core. Andere fabrikanten kunnen deze in licentie nemen en uitbreiden.
Dit is erg mooi voor ‘kleine’ elektronica fabrikanten. Snel een zuinige 32bits processor naar eigen wens temaken met compilers en besturing systemen en andere tools.
Dit is erg mooi voor ‘kleine’ elektronica fabrikanten. Snel een zuinige 32bits processor naar eigen wens temaken met compilers en besturing systemen en andere tools.
Ik heb het vermoeden dat dit het domste is wat ze de laatste jaren hebben gedaan.
Want 1 het is een groot en log OS en 2 mensen kopen straks een tablet met windows 8 willen daar hun software op installeren en dat kan niet!
Voor mijn gevoel hadden ze beter WP8 kunnen aan passen en dat op de tablet uit brengen. Dat is klein licht en volledig touch.
Maar we zullen moeten afwachten hoe dit uitpakt.
Een andere optie is natuurlijk dat ze windows 8 ARM speciaal voor servers en desktops gaan uitbrengen en niet zo zeer voor tablets, maar dat is nu nog afwachten.
Want 1 het is een groot en log OS en 2 mensen kopen straks een tablet met windows 8 willen daar hun software op installeren en dat kan niet!
Voor mijn gevoel hadden ze beter WP8 kunnen aan passen en dat op de tablet uit brengen. Dat is klein licht en volledig touch.
Maar we zullen moeten afwachten hoe dit uitpakt.
Een andere optie is natuurlijk dat ze windows 8 ARM speciaal voor servers en desktops gaan uitbrengen en niet zo zeer voor tablets, maar dat is nu nog afwachten.
Ik weet niet. Ik zit nu bijv op een atom met win7 starter. Gaat als een speer. Kan daar meer dan genoeg apps op draaien, w.o. powerp, excel, ff, iron, ie, allemaal naast elkaar. En Phone7 (mocht ik even vasthouden van een maat van me ;-) ) is ook erg gelikt, dus misschien maken ze iets tussen beide werelden in? Dus Phone7++ of Win7Starter--.
Iemand enig idee of dat mogelijk is?
Iemand enig idee of dat mogelijk is?
Ze kondigen dit wel aan maar het duurt minstens 1 jaar voordat het op de markt komt.
Op zich knap dat ze het nog steeds kunnen en dat de kernel van Windows inmiddels niet vol zit met x86 specifieke zaken (vroeger had je ook windows voor Alpha en Itanium) maar als ze dit willen inzetten voor tablets begrijp ik MS echt niet. Hoewel het formaat van X86 machines Windows Tablets niet echt helpt is het in mijn ogen niet primair het gewicht dat het probleem is. De Windows UI werkt gewoon niet zo lekker met input anders dan Muis en keyboard. Ik dacht dat Windows Mobile dat wel had bewezen.
Zelfs de standaard Android interface, die zich toch wel bewezen heeft op mobiele telefoons, werkt voor tablets niet goed. Vandaar dat Google met 3.0 wezenlijke weizigingen in de UI heeft doorgevoerd. Ik dacht dat Microsoft daarom ook WP7 met een heel andere interface had ontwikkeld. Combineer dit met Microsofts courier ideeen en Microsoft zou een interessante oplossing hebben.
Begrijp me niet verkeerd voor mediacenters, topset boxen en zuinige PC's is dit interessant maar voor tablets?
Zelfs de standaard Android interface, die zich toch wel bewezen heeft op mobiele telefoons, werkt voor tablets niet goed. Vandaar dat Google met 3.0 wezenlijke weizigingen in de UI heeft doorgevoerd. Ik dacht dat Microsoft daarom ook WP7 met een heel andere interface had ontwikkeld. Combineer dit met Microsofts courier ideeen en Microsoft zou een interessante oplossing hebben.
Begrijp me niet verkeerd voor mediacenters, topset boxen en zuinige PC's is dit interessant maar voor tablets?
Er zal wel gewoon een speciale tablet versie van W8 komen die wel goed draait.
Juist, ik gok zo dat Microsoft zich met name richt op het verbeteren van de user interface en de bijbehorende bediening voor tablets met de nieuwe Windows-versie. Want dat is inderdaad een van de heikele punten van W7 op een tablet.
waarom niet voor tablets ?
zolang het besturings systeem lekker vlot, niet te log en vooral niet in de weg zit maakt het tegenwoordig niet zo heel veel meer uit welk systeem er draait. Zeker op tablets zijn applicaties iets meer portabable omdat ze bijvoorbeeld in Java geschreven zijn.
Het lijkt me juist een zeer groot voordeel dat ze voor ARM een versie maken, alle zooi die in windows zit om legacy X86 sheit te ondersteunen mag er uitgesloopt worden en het zou dus (theoretisch) een stuk stabieler en sneller kunnen draaien (relatief gezien)
zolang het besturings systeem lekker vlot, niet te log en vooral niet in de weg zit maakt het tegenwoordig niet zo heel veel meer uit welk systeem er draait. Zeker op tablets zijn applicaties iets meer portabable omdat ze bijvoorbeeld in Java geschreven zijn.
Het lijkt me juist een zeer groot voordeel dat ze voor ARM een versie maken, alle zooi die in windows zit om legacy X86 sheit te ondersteunen mag er uitgesloopt worden en het zou dus (theoretisch) een stuk stabieler en sneller kunnen draaien (relatief gezien)
Theoretisch heb je gelijk maar deWindows Kernel is al sinds jaar en dag platform onafhankelijk (vandaar dat er vroeger releases voor DEC en Alpha waren), aangezien ring 0 kernel het enige is dat een BSOD kan triggeren vermoed ik niet dat dit veel voor stabiliteit gaat doen.
Bovendien wat is niet 'in de weg mag zitten'? De UI voor een tablet is iig wezenlijk anders dus je meot als app developer sowiezo twee UIS maken en hem voor twee platformen compileren (of via .net/silverlight platform onafhankelijk maken) en dan bied Win8 op tablets ook geen echt voordeel. Ook kan Win8 op ARM geen echte legacy ondersteuning bieden dus dat gaat enorm verwarrend worden.
Ik begrijp de move echt niet, maar goed, wie weet zit ik er naast
Bovendien wat is niet 'in de weg mag zitten'? De UI voor een tablet is iig wezenlijk anders dus je meot als app developer sowiezo twee UIS maken en hem voor twee platformen compileren (of via .net/silverlight platform onafhankelijk maken) en dan bied Win8 op tablets ook geen echt voordeel. Ook kan Win8 op ARM geen echte legacy ondersteuning bieden dus dat gaat enorm verwarrend worden.
Ik begrijp de move echt niet, maar goed, wie weet zit ik er naast
Kleine correctie; De Alpha (AXP) processor was van DEC
Deze Alpha AXP werd ondersteund in de 1e NT release (3.1), net zoals de Power PC architectuur.
1 van de uitgangspunten van WIndows NT was een (CPU) platform onafhankelijk OS te maken (wens van Bill Gates, die zich niet aan intel wilde ophangen) met een specifieke HAL voor het platform - vandaar veel C en weinig assembler code.
Deze Alpha AXP werd ondersteund in de 1e NT release (3.1), net zoals de Power PC architectuur.
1 van de uitgangspunten van WIndows NT was een (CPU) platform onafhankelijk OS te maken (wens van Bill Gates, die zich niet aan intel wilde ophangen) met een specifieke HAL voor het platform - vandaar veel C en weinig assembler code.
Wil dit zeggen dat elk programma opnieuw moet worden geschreven voor de ARM versie? En in dat geval moet het toch ook mogelijk zijn om programma's in x86 mode te emuleren?
Ik neem aan dat dat voor een deel van de applicaties wel zal gelden. Daarentegen zal waarschijnlijk het overgrote deel van de .NET gebasseerde applicaties het allemaal nog wel doen, mits ze een ARM .NET CLR hebben gemaakt.
Wat zo te zien wel is gebeurd aangezien Office (== .NET applicatie voor een deel, dacht ik) al draait.
Wat zo te zien wel is gebeurd aangezien Office (== .NET applicatie voor een deel, dacht ik) al draait.
Er is al een ARM .NET CLR, al jaren - voor Windows CE. Maar die is dus wel degelijk in staat om de .NET MSIL naar ARM assembly te compileren. Deze zal natuurlijk iets aangepast moeten worden, om tegen de reguliere Win32 API te linken. Ook wil je dat de de nieuwe ARM architectuur extensies in ARM Cortex gebruikt worden, floating point werk is anders pijnlijk, maar er is dus al een werkbare basis.
Inderdaad een baanbrekend nieuwsbericht. Ben toch benieuwd wat de gevolgen zullen zijn. Goede zet van MS!
Wow, dit is vragen om geport te worden naar een schandalige hoeveelheid andere devices. Ben benieuwd hoe ze dat aangaan pakken aangezien ARM toch wel structureel anders in elkaar zit. Met name of we nu ook terug meerdere binaries krijgen per architectuur of dat ze iets creatiefs gaan bijklussen. Dit is niet de eerste keer trouwens: NT draaide al op Alpha, MIPS en PowerPC. Voor 2000 was er een beta die op alpha draaide maar vanaf dan werd er enkel nog IA-64 (itanium) ondersteund naast x86 en x86-64.
[Reactie gewijzigd door analog_ op woensdag 5 januari 2011 23:35]
als ik het goed heb (bron: oa .: http://e2e.ti.com/support.../f/42/p/29945/104162.aspx )
zijn tot nu toe de meeste nieuwe arm instructiesets backwards compatible geweest met die daarvoor, als we eruit van mogen gaan dat dat in de toekomst ook zo is dan zal er dus niet voor iedere nieuwe arm versie opnieuw gecompileerd moeten worden.
zijn tot nu toe de meeste nieuwe arm instructiesets backwards compatible geweest met die daarvoor, als we eruit van mogen gaan dat dat in de toekomst ook zo is dan zal er dus niet voor iedere nieuwe arm versie opnieuw gecompileerd moeten worden.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
