Intel: Windows 8 zal nooit legacy-apps draaien

Intel waarschuwt dat Windows 8 voor ARM-processors, waarvan mogelijk vier verschillende versies zullen uitkomen, geen legacy-software kan draaien. Ook kan er volgens de chipfabrikant fragmentatie in de Windows-markt ontstaan.

Volgens Intel-ceo Paul Otellini zullen bedrijven die de ARM-versies voor Windows 8 bouwen, miljarden dollars kwijt zijn. Otellini stelde tijdens een bijeenkomst voor analisten dat er niet slechts één ARM-versie van Microsofts besturingssysteem op de markt zal komen, maar dat er vier verschillende versies zullen verschijnen. Dit is volgens de Intel-baas nodig, omdat Windows op verschillende ARM-chips en -socs moet kunnen draaien.

Microsoft heeft nog geen informatie vrijgegeven over de ARM-chipsets die ondersteuning krijgen. Volgens Intel zal de Windows 8-versie voor x86-processors, dankzij een Windows 7-compatibility mode, ook oudere software kunnen draaien, terwijl vooral de ARM-versies voor tablets niet met legacy-Windows-applicaties overweg kunnen. Overigens zal Windows 8 voor ARM wel op x86-machines kunnen draaien.

Intel gaf ook meer informatie over de plannen voor het integreren van nieuwe beveiligingslagen in zijn processors. De chipfabrikant wil in het derde kwartaal aanvullende software van het onlangs ingelijfde McAfee op de markt brengen om deze beveiligingsfeatures te kunnen gebruiken. Volgens Intel werken de beveiligingssystemen op een lager niveau dan OS-code, waardoor malware beter zou kunnen worden bestreden.

Reacties (173)

Is dit niet een probleem dat grotendeels door het .NET framework kan opgevangen worden?
Microsoft brengt vast wel de nodige tools op de markt om je applicatie pijnloos te porten naar ARM.

[Reactie gewijzigd door boe2 op 18 mei 2011 09:59]

Het "probleem" is de Windows-kernel, en die is niet in .NET geschreven. Daarom moeten er kennelijk vier Windows versies komen, als we Intel moeten geloven.

Op zich natuurlijk totale nonsens van Intel; Linux heeft maar 1 kernel, 1 versie dus, en die draait op talloze verschillende SoC's. Dezelfde kernel draait zelfs op verschillende architecturen; dus de Linux-kernel voor x86 is grotendeels hetzelfde als voor ARM.

Probleem voor Microsoft is alleen, dat ze waarschijnlijk de SoC-boeren niet zover kunnen krijgen code / API's onderling te delen, om te voorkomen dat code gedupliceerd wordt.

Bij Linux is dat ook een probleem, maar omdat het open source is kunnen 'anderen' dat herkennen (bijv 2 SoC's die dezelfde broncode voor de DSP gebruiken, en leveranciers die 'hun' gelijke code dus twee keer in de Linux-kernel proberen te krijgen), en het probleem voor de SoC-boeren proberen oplossen. Kennelijk heeft MS er een stuk meer problemen mee.

Vier SoC's lijkt me overigens erg mager; Linux biedt momenteel al ondersteuning voor veel meer dan 4 ARM-SoC's. Er zijn er immers meer dan tien (populaiere) op de markt; dus als MS er maar 4 ondersteunt lopen ze achter op de concurrentie.

En de tweedeling tussen 32bit en 64bit heeft de markt ook miljarden gekost, dus de pot verwijt hier de ketel. Groot voordeel is dat bedrijven als Google/Facebook (die overigens geen Microsoft-software draaien) miljarden kunnen besparen op de stroomrekening als ze overstappen van x86 op ARM.

[Reactie gewijzigd door kidde op 18 mei 2011 10:18]

Op zich natuurlijk totale nonsens van Intel; Linux heeft maar 1 kernel, 1 versie dus, en die draait op talloze verschillende SoC's. Dezelfde kernel draait zelfs op verschillende architecturen; dus de Linux-kernel voor x86 is grotendeels hetzelfde als voor ARM.

Om Linux op al die verschillende SoC's te kunnen draaien moet je in veel gevallen wel een custom kernel builden, en als je gebruik wilt maken van bepaalde hardware eigenschappen van een specifieke SoC (wel/geen VFP, wel/geen NEON, wel/geen extra DSP hardware, armv6/armv7, etc) zelfs je hele userland. Check voor de grap maar eens de git repositories van OpenEmbedded uit (een soort gentoo-achtige distro builder voor embedded systemen), dan kom je er snel achter dat 'even een Linux distro voor ARM builden' niet zo makkelijk is als je het doet lijken, er zijn zoveel verschillende varianten. Voor zo'n beetje elke bekende ARM SoC bevat OpenEmbedded getweakte build profielen, en zelfs met het juiste build profiel voor de juiste hardware gaan bij nieuwere versies van packages vaak builds kapot of krijg je runtime problemen omdat er nog meer getweakt moet worden om te zorgen dat GCC geen ongeldige ARM code voor jouw systeem genereert (gcc+ARM is sowieso altijd al een probleemkindje geweest).

Dat dit met Linux allemaal nog te doen is, is juist omdat je het zelf kan recompilen en zo allerlei verschillende versies kunt bouwen. Microsoft kan dit met Windows niet doen, in ieder geval niet voor desktop/consumenten Windows (bij Windows CE hebben ze het probleem op een vergelijkbare manier opgelost, daar bouw je als integrator je eigen versie van, maar die draai je dan ook alleen op je eigen hardware). Van zoiets als 'Windows voor ARM' wordt verwacht dat je het op je systeem kunt klappen en dan vrolijk alle Windows applicaties voor ARM kunt draaien.

Vier SoC's lijkt me overigens erg mager; Linux biedt momenteel al ondersteuning voor veel meer dan 4 ARM-SoC's. Er zijn er immers meer dan tien (populaiere) op de markt; dus als MS er maar 4 ondersteunt lopen ze achter op de concurrentie.

Zo makkelijk is het dus niet

http://ldn.linuxfoundatio...y/what%E2%80%99s-with-arm

[Reactie gewijzigd door johnbetonschaar op 18 mei 2011 10:41]

Maar aan de andere kant draait bijv Android op tientallen verschillende kernels en toch draaien de bovenliggende programma's prima. Natuurlijk komt dit door de dalvik engine maar is een "Process virtual machine" niet mogelijk in Windows (of is dit gewoon enorm lastig/vertragend?)

Die "dalvik engine" is een Java VM. Java is geen native code, maar wordt door de VM geïnterpreteerd. Ieder platform met een werkende JVM kan dus die applicaties draaien zonder aanpassingen. We hebben het hier echter voornamelijk over native code. Dat is dus code die direct door de processor heen moet, en daar zul je wel degelijk tegen de verschillen tussen cpu's aan gaan lopen, ook al praat je tegen libraries aan.

MS heeft hiervoor .Net, maar daar heb je natuurlijk alleen wat aan als de developers dan 100% .Net apps gaan maken. Volgens mij staat .Net het ook toe om gemixte software te schrijven, wat dus al weer niet uitwisselbaar is tussen platformen. Om het nog maar niet eens te hebben over het hele scala aan software dat geschreven is in native code, waaronder het grootste deel van het portfolio van MS zelf.

Dalvik is geen JavaVM, maar is een VM net zoals JavaVM en de .NET VM.
Dalvik kan niks met Java byte code. Alleen maar omdat de input van de Dalvik compiler Java byte code is maakt Dalvik nog geen Java.

Dalvik is een Java-kloon, die inderdaad net genoeg van Java VM afwijkt om geen Java genoemd te worden (en centjes aan Sun/Oracle te betalen), maar iedereen die ermee gewerkt heeft kan je vertellen: het is gewoon Java. Walks like a duck, quacks like a duck...

[Reactie gewijzigd door Dreamvoid op 18 mei 2011 13:40]

Volgens mij staat .Net het ook toe om gemixte software te schrijven, wat dus al weer niet uitwisselbaar is tussen platformen

Oooh oke dit wist ik niet (heb vrij weinig ervaring met .net) Dus thanks!

Om het nog maar niet eens te hebben over het hele scala aan software dat geschreven is in native code, waaronder het grootste deel van het portfolio van MS zelf.

Dit is iets wat je altijd wel zal hebben toch? Is het dan niet voordeliger om die oude ellende te emuleren oid en verder de rest te droppen? Zo kan je eindelijk een keer opnieuw beginnen en al de native MS applicaties omzetten Het is wel veel werk maar zal ook wel wat stabiliteit en snelheid opleveren als ik het goed heb. (mijn programmeer kennis gaat niet verder dan php dus vandaar dat het mij niet helemaal duidelijk is)

Zoals elmuerte al zegt: niet waar.

Dalvik kan geen Java bytecode draaien en een JVM kan geen Dalvik bytecode draaien.

Je kan wel voor beide platformen in Java programmeren, maar de bytecode is anders.

Sorry maar dit slaat een beetje de plank mis. Als je kijkt naar Linux distributies (Ubuntu, Debian) voor ARM dan zie je dat ze een grote gemene deler kiezen die voor veel platforms werkt. Windows voor ARM zal ongetwijfeld op dezelfde manier werken. Zelf compileren van code is helemaal niet nodig.

Kijk eens naar het PC platform. Hoeveel varianten zijn er daar van? Iedere PC configuratie is anders en niet te vergeten de vele instructieset extensies. En toch kun je Windows XP net zo makkelijk op een Pentium 1 installeren als op een i7 950 zonder dat je WIndows opnieuw hoeft te compileren.

Het doel van Openembedded (en diverse andere tools) is om een minimale Linux bij elkaar te compileren voor embedded targets met weinig opslagruimte. Met de komst van goedkope SD kaartjes die 2GB of meer kunnen opslaan is de noodzaak om een minimale distributie te maken nagenoeg verdwenen.

[Reactie gewijzigd door ncoesel op 18 mei 2011 11:42]

En toch kun je Windows XP net zo makkelijk op een Pentium 1 installeren als op een i7 950 zonder dat je WIndows opnieuw hoeft te compileren.

Klopt, maar alleen omdat een i7 compatible is met een Pentium 1, en je daarnaast nog afhankelijk bent van recente drivers. Maar denk maar niet dat een applicatie SSE kan gebruiken op het moment dat daar geen support voor in de kernel zit, want die moet die state namelijk gaan preserven tijdens taskswitches. En om die support toe te voegen zal de kernel opnieuw gecompileerd moeten worden.

Sorry maar dit slaat een beetje de plank mis. Als je kijkt naar Linux distributies (Ubuntu, Debian) voor ARM dan zie je dat ze een grote gemene deler kiezen die voor veel platforms werkt.

Sorry, maar ik denk dat je niet zo veel ervaring hebt met Linux op ARM of wel? Er is niet eens een 'standaard' Ubuntu of Debian release voor ARM, en zelfs de 'grootste gemene deler' versies van die distros (die verre van bruikbaar zijn voor serieuze toepassingen en de gemiddelde huis-tuin-en-keuken computeraar echt niet zomaar geinstalleerd krijgt) draaien maar op een heel beperkt aantal ARM systemen, en dan niet eens al te best. De debian ARM versie gebruikt bijvoorbeeld zelfs softwarematige floating point emulatie omdat niet alle ARM chips een floating point unit hebben. Dit is natuurlijk geen optie voor een volwaardige Windows 8 voor ARM versie.

Ook is OpenEmbedded absoluut niet alleen maar om minimale Linux distributies te maken, daar is het inderdaad zeker handig voor, maar neem eens een kijkje in de machine configuration directories:

http://cgit.openembedded....mbedded/tree/conf/machine

Elk van die profielen is noodzakelijk om uberhaupt een werkend ARM systeem voor een bepaald stuk ARM hardware te kunnen bouwen, en dan is de bovenstaande lijst alleen nog maar de git mainline, er zijn nog vele branches voor hardware die nog niet goed genoeg ondersteund wordt.

Zelf compileren van code is helemaal niet nodig.

Het punt was dan ook niet dat je geen ARM distro of ARM Windows versie kunt maken die je zonder compileren aan de praat krijgt, het punt is dat het nog lang niet makkelijk is om een breed ondersteund ARM OS op te zetten dat op meer dan een handjevol verschillende ARM systemen werkt. Natuurlijk gaat Microsoft geen Windows 8 versie uitbrengen waar je zelf je kernel moet compileren, maar om aan hun eigen standaarden van kwaliteit en gebruiksgemak te voldoen zullen ze zich in de eerste instantie toch echt moeten beperken tot een aantal ARM subplatformen die voldoende hardware aan boord hebben en generiek genoeg zijn.

De bewering dat Linux 'zomaar' op 'alle' ARM hardware kan draaien en het voor Microsoft dus een eitje moet zijn om Windows 8 voor ARM te ontwikkelen is gewoon onjuist, daar ging mijn reactie over.

Edit @ncoesel:
Je vergeet een hele berg andere blocks die kunnen verschillen tussen SoC's van dezelfde ARM generatie, of het ARM11 of Cortex A8/A9 is zegt in principe helemaal niet veel meer dan de ondersteunde basis instructireset. Een ARM SoC kan wel/geen NEON hebben, wel/geen extra DSP blocks (die vanuit userland gebruikt kunnen worden maar waar meestal wel een bridge in de kernel voor nodig is), sommige SoC's laten bewust hele elementaire dingen weg (denk aan controllers voor subsystemen die niet gebruikt worden), sommige SoC's communiceren met randhardware via GPIO pins, andere via een extra controller (denk aan TWL op OMAP) enzovoorts.

Verder gaat het natuurlijk niet alleen maar om de CPU, maar ook om de manier van booten, welke boot loader gebruikt wordt, welke boot media wel/niet ondersteund worden,
enzovoorts. Voor ARM hardware is niet eens echt een soort gestandaardiseerde BIOS of iets dergelijks, bijna elke fabrikant gebruikt zijn eigen oplossingen. Een linux distro die ik op mijn OMAP3xxx voor BeagleBoard bouw, gaat simpelweg niet zomaar werken op een Gumstix Ovi met vergelijkbare CPU, ook al zijn de binaries uitwisselbaar. Met een hoop gedoe kan je een heel eind komen, maar voor elk nieuw stuk ARM hardware moet je weer opnieuw beginnen om de boel werkend te krijgen.

Overigens lijkt het alsof je in de veronderstelling ben dat ik denk dat het niet mogelijk is om een goed doortimmerde ARM versie van Windows te maken die op veel verschillende ARM hardware werkt, maar dat is niet mijn punt. Mijn punt is dat het niet mogelijk is om een Windows voor ARM te maken die zomaar overal op draait, en dat Microsoft niet anders kan dan een subset van gangbare ARM hardware te pakken, en een aantal verschillende, specifiek aangepaste versies van Windows maken die een zo breed mogelijke set hardware ondersteund. Daarbij gaat het niet alleen maar om drivers, dat is een vrij eenvoudig probleem, maar om die hardware verschillen die niet in een driver kunnen worden opgelost. Het lijkt er ook op alsof Microsoft precies dit gaat doen, en een aantal verschillende ARM Windows versies uit te brengen, die op applicatieniveau waarschijnlijk wel compatible zullen zijn (bijvoorbeeld met behulp van universal binaries en dergelijke).

Vergelijkingen met x86 zijn trouwens useless, omdat de verschillen tussen x86 CPU's veel kleiner zijn, er regelmatig een nieuwe ondergrens wordt getrokken voor software (geen MMX of SSE? helaas doetnie, etc), en vooral: omdat al die x86 chips samen met gestandardiseerde PC hardware op een moederbord met een gestandaardiseerd BIOS, gestandaardiseerde bus interfaces, etc. worden geprikt.

Het is niet voor niks dat er eigenlijk geen enkel OS bestaat dat out-of-the-box op heel veel verschillende stukken ARM hardware te installeren is, zonder kernels te hoeven recompilen of handmatig allerlei dingen te moeten customizen. Als je nog steeds denkt dat het probleem even overzichtelijk is als Windows op x86 dan zie ik graag een link naar je van een ander OS dat het tegendeel bewijst. Vooralsnog denk ik dat 95% van de ARM hardware op software draait die zeer specifiek is aangepast voor de hardware.

[Reactie gewijzigd door johnbetonschaar op 19 mei 2011 14:56]

Ik heb vrij veel ervaring met Linux op embedded systemen (o.a. ARM). Je kunt de moderne ARM platforms vrij simpel indelen: ARM11 of CortexA8/A9. En dan met floating point of zonder floating point. Dat geeft 3 verschillende mogelijkheden want de Cortex heeft altijd floating point omdat een moderne computer zonder FPU kansloos is. Oudere ARM systemen zullen niet interessant zijn vanwege gebrek aan performance en gebrek aan RAM.

Het is niet lastig om dat tijdens het installeren uit te zoeken of generiek op te lossen (zoals met floating point emulatie in de kernel als er geen FPU is). Verschillen in de hardware los je op door voldoende drivers mee te leveren.

Voor zover ik weet stelt Windows tijdens het installeren een HAL samen voor je PC. Een dergelijke constructie kan MS ook voor Windows op ARM optuigen.

dat 'even een Linux distro voor ARM builden' niet zo makkelijk is als je het doet lijken

Dat het makkelijk zou zijn, zijn uw woorden en niet de mijne; ik heb dat niet gezegd. Uit de praktijk weet ik idd. hoe rot voor een ander platform compileren is. En of bepaalde support in de kernel of "userland" zit is natuurlijk arbitrair en eigenlijk ook irrelevant; waar het om gaat is dat de zaken die u noemt:

-niet in .NET geprogrammeerd zullen worden; dus .NET gaat het probleem niet oplossen,
-deze zaken allemaal bij elkaar in een enkele kernel code-boom gestouwd kunnen worden; zodat er van meerdere versies geen sprake hoeft te zijn.

De truc is om als je vier losse bomen hebt, het voor elkaar te krijgen dat ze de stam en takken delen, want dan heb je geen vier losse bomen meer nodig. Bij de Linux-kernel wordt hieraan hard gewerkt, maar wie Intel gelooft; vermoedt het bestaan van vier 'losse' Windows bomen.

Immers: Support geven voor 10 verschillende desktops die grotendeels dezelfde hardware hebben, is niet zo ontiechelijk moeilijk. Microsoft doet dit al jaren voor 1000'en verschillende desktops; lukt prima.

Tenzij de makers van die 10 desktops allemaal code voor hun eigen kernel die alleen met hun eigen desktop werkt aan Microsoft geven, dan heeft Microsoft werk aan de winkel. Maar dat is niet omdat het moeilijk is; gewoon omdat het een enorme zooi is die moet worden opgeruimd.

Vergeet niet dat Windows voor NT5 ook versies had voor andere CPUs dan x86. MS heeft daar dus echt wel ervaring mee gehad, alleen lagen in die tijd de zaken wat anders mbt "native" apps.

Kans bestaat dat achter de schermen MS gewoon is door blijven ontwikkelen, net als Apple waarschijnlijk al sinds ze met OSX bezig waren al een x86 versie ervan hadden. Zelfs al is het maar een bij project en niets officieel geweest.

Vraag me wel af of een x86 emulator op een arm cpu bruikbaar kan zijn.

[Reactie gewijzigd door Amorac op 18 mei 2011 12:35]

Het probleem is dat je het hebt over de Linux broncode tegenover een binaire distributie van de Windows kernel. Er is vast ook maar 1 Windows kernel codebase zijn waaruit 4 verschillende ARM versies worden gecompileerd. Dit werkt bij Linux niet anders. De linux kernel moet ook gecompileerd worden voor verschillende targets.

Als je het hebt over kernels dan is zelfs de code niet cross-platform, aangezien een kernel direct werkt met de platform-specifieke zaken van het systeem. Denk aan interrupts die afgehandeld moeten worden, memory management en paging dat op elk platform weer anders werkt, etc. Dat is niet simpelweg even de sourcecode van de kernel pakken en hercompileren voor een ander platform.

[Reactie gewijzigd door .oisyn op 18 mei 2011 10:55]

In het geval van Windows heeft Microsoft daarvoor een Hardware Abstraction Layer gemaakt. Die verbergt dergelijke hardware specifieke zaken voor de kernel en drivers.

De vraag is wat een 'codebase' is.

Linux heeft momenteel verschillende 'takken' voor verschillende SoC's, die je kan beschouwen als losse bases. De truc is om 'gelijkende' takken bij elkaar te zoeken en weg te abstraheren / isoleren om de boel meer behapbaar en beter onderhoudbaar te maken. Maar hieruit blijkt wel hoe het bij MS waarschijnlijk gaat:

Iedere SoC ontwikkelaar levert voor zijn en alleen voor zijn SoC een enorme bult code. Zijn er 10 SoC-makers, dan zijn dat 10 code-bases die samen onbeheersbaar zijn. Daar gaat het om: Hoe goet is men bij Linux / MS in staat, die ontwikkelaars van concurrerende bedrijven te laten samenwerken, code te laten delen en gebruikmaken van dezelfde API's. Van nature is dat bij Linux (door de licentie) makkelijker dan voor Microsoft.

Apple heeft voor de transitie van PPC naar x86 de emulator Rosetta geklust, die veel oude PPC software kon draaien bovenop een 32-bit x86 kernel. Apple heeft vier kernels voor OS X (PPC 32 bit, PPC 64 bit, x86 32 bit, x86 64 bit) en dat hebben weinig mensen ooit gemerkt, applicaties praten toch voornamelijk tegen de hogere libraries aan. Microsoft kan zoiets ook doen met een x86 emulator voor ARM. De vraag is of ze dat willen - er is veel meer legacy software die evt niet werkt, en MS heeft al jaren de gewoonte om verschillende versies van hun OS te verkopen.

[Reactie gewijzigd door Dreamvoid op 18 mei 2011 10:48]

Vergeet niet dat het .NET Framework ook geport moet worden. Microsoft heeft bijvoorbeeld al 'problemen' gehad om een goede 64-bit (x86-64) JIT te maken voor .NET. De CLR is misschien nog te porten, maar het JIT onderdeel van de CLR zal moeten worden herschreven voor ARM.

Overigens, als je C# code pointers gebruikt is het mogelijk dat bepaalde dingen op een ARM platform niet helemaal vanzelfsprekend meer zijn en je code dus kan falen. Dit heeft onder andere te maken met de grootte van bepaalde primitieve types (zoals integers en floats) en de endianess van een platform.

En dit allemaal los van het feit dat niet alles (volledig) in .NET geschreven is. Bijvoorbeeld, Exchange Server is in .NET geschreven maar de storage engine is weer in native code geschreven. Windows Explorer is volledig in native code geschreven.

Maar sowieso krijg ik bij dit nieuwsbericht wel een beetje WC-eend gevoel. De andere WC-reiniger gaat niet werken, blijf bij ons!

Ik neem aan dat (bijvoorbeeld) het Compact Framework (of de CLR gebruikt in WP7 zelfs) toch al een JIT-implementatie voor ARM bevatten.

Dit heeft onder andere te maken met de grootte van bepaalde primitieve types (zoals integers en floats)

De CLR definieert de grootte van die types, en vrijwel elk hedendaags 32 of 64 bits platform heeft mogelijkheden om 8-, 16-, 32- en 64-bits integers en 32- en 64-bits floats uit te lezen / weg te schrijven, dus dit lijkt me niet echt een issue.

Vergeet niet dat het .NET Framework ook geport moet worden. Microsoft heeft bijvoorbeeld al 'problemen' gehad om een goede 64-bit (x86-64) JIT te maken voor .NET. De CLR is misschien nog te porten, maar het JIT onderdeel van de CLR zal moeten worden herschreven voor ARM.

Microsoft heeft al ervaring hiermee hoor... het .NET Compact Framework (op Windows CE) en het .NET Micro Framework. En onlangs nog Silverlight op Windows Phone 7.

Het probleem met de 64-bit JIT compiler zat hem volgens mij in het feit dat een JIT compiler code genereert (data) en deze dan vervolgens als native code moet laten uitvoeren. Iets wat het Windows 64-bit platform over het algemeen niet zo'n goed idee vindt .

Dit bericht klinkt bij mij een beetje in de oren alsof Intel zich zorgen maakt om hun marktpositie en daarom maar vast een eerste steek uithaald naar ARM om mensen maar te ontdoen van hun ideeën om over te stappen op ARM.

Microsoft brengt zelf nog geen details uit maar Intel weet al precies hoe het zit? Komt in mijn oren niet echt geloofwaardig over.

Natuurlijk ziet intel dit niet graag. MS is de dominante OS leverancier en die status willen ze natuurlijk behouden. MS pakt het dus heel slim aan door windows ook geschikt te maken voor niet x86 Hardware.

Voor Intel zal dit zeker verlies van marktaandeel kunnen betekeken. Hoewel de overstap van windows software naar arm niet snel zal zijn zullen er uiteindelijk oplossingen komen, dus op de lange termijn zal een beetje softwaremaker een arm en x86 versie uitbrengen.

Van MS is dit een slimme move, voor intel kan het wat minder zijn. Alles zal echter afhangen van de prijzen en snelheid van een cpu en onderschat intel ook niet op dat gebied.

Helemaal niet zo gek gedacht. Intel wil juist een deel van de mobiele markt veroveren met behulp van Atom-processors en Meego.

Yup, Intel ziet al jaren dat er aan hun "monopolie" wordt geknabbeld, eerst door de X86 licenties en de mededingings besluiten daarover waardoor het "Pentium" tijdperk ten einde kwam en om die doorn in hun zijde genaamd AMD ten onder te krijgen besloten ze toen: hey, Itanium! Het is waar dat Itanium een aantal problemen van 32 bit oploste, maar het creëerde weer nieuwe problemen. Ik was zelf verbaast destijds toen Microsoft aankondigde dat ze een AMD64 versie van Windows gingen ontwikkelen. Wintel was ineens haast AMDows geworden! Intel was er snel bij om AMD64 te implementeren in de vorm van EMT64, Intel64, X86-64 of X64 (of hoe ze hun overigens legale kopie van AMD64 ook noemden), maar Itanium is vervolgens een stille dood gestorven (de afgehakte staart kronkelt nu nog na trouwens, de laatste stuip komt er echter aan) op de niche-servermarkt.

Toen Mobile Devices groot begonnen te worden was Intel helemaal zuur, ze hadden in 2006 hun eigen ARM productenlijn (http://en.wikipedia.org/wiki/Xscale) definitief helemaal aan Marvell verkocht. Dang. Dan maar Atom. En toen kondigde Microsoft aan eenzelfde stunt uit te voeren waarmee ze ook de Itanium hebben "dood" gekregen (in ieder geval op de desktop): Windows ontwikkelen voor het niet-Intel platform.

Eigenlijk heb ik een beetje met ze te doen. AMD zit wel veilig met hun GPU en components markt (hoewel ze eventueel vast ooit nVidia wel zullen nadoen door ook met een ARM-pje te komen), en dat zijn beide markten waar Intel niet echt sterk op zijn als het op Mobile devices aankomt.

Nah, zo slecht doet MS het niet. Ze hebben UI's wel een beetje door en zullen de "post-PocketPC" fase niet over doen. Natuurlijk een paar zakelijke niche tablets, maar de rest zal meer op Surface of Phone7 voet poten wat allemaal degelijke solide software is. Ik zie het echt nog wel gebeuren dat Windows 8 een "dual mode" heeft, naast de klassieke UI voor muis/toetsenbord ook een "tablet" mode wat een mix is tussen Windows Phone 7 en Surface. Ontwikkeling voor beiden is in WPF/XNA/Silverlight/.Net; portable en érg fijn!

Leuk stukje, maar wel een aantal onwaarheden.

1 - Itanium was nooit bedoeld voor de desktop markt, de chip is daar qua transistor aantal gewoon te groot voor.

2 - Gezien AMD de eerste x64 processor voor de desktop markt klaarhad, veel eerder dan dat Intel hier mee bezig was. Was het zeer logisch dat Microsoft deze ging ondersteunen.

3 - De kans dat AMD in de ARM markt is zeer onwaarschijnlijk. Ze hebben hier al in gezeten (tenminste ATi dan) en hebben dit afgestoten twee jaar nadat intel dezelfde move had gemaakt.

AMD ziet (net als Intel) toekomst in de ultra-low-power x86, de opvolger van de Brazos zou al zeer geschikt moeten worden voor tablets, en een latere variant misschien (net als Atom) voor smartphones.

4 - Intel speelt ook op heel wat meer markten als alleen processors, ze zijn ook een sterke speler in de flash markt, netwerkapparatuur, etc.

5 - Windows voor ARM is absoluut geen doodsteek voor x86, en ook echt niet zo bedoeld door Microsoft. Microsoft ziet een markt waar ze nu niets verdienen, namelijk: tablets en smartbooks (hoewel ik betwijfel dat smartbooks ooit aan zullen slaan), dit is de grootste reden voor een ARM Windows variant.

Echter komt het overgrote deel van Microsoft verdiensten uit het zakenleven: Windows licenties voor grote bedrijven. Tenzij deze massaal overgaan naar ARM (wat ik eerlijk gezegt niet direct zie gebeuren want meerdere hardware platforms ondersteunen is een hoop werk, en hier hebben IT afdelingen doorgaans geen zin in), zal de focus voorlopig toch op x86 blijven.

[Reactie gewijzigd door knirfie244 op 18 mei 2011 12:08]

1 - Itanium was nooit bedoeld voor de desktop markt, de chip is daar qua transistor aantal gewoon te groot voor.

Het is wel degelijk ooit de bedoeling geweest dat de Itanium-architectuur de positie van de x86-architectuur zou overnemen op de desktop. Ik heb er in 1999 nog een post over gebakken. Het zou volgens Intel toen tien jaar gaan duren voordat 64bit mainstream zou worden op de desktop. Uiteindelijk is dat wel gebeurd maar niet met IA-64.

Echter komt het overgrote deel van Microsoft verdiensten uit het zakenleven: Windows licenties voor grote bedrijven. Tenzij deze massaal overgaan naar ARM (wat ik eerlijk gezegt niet direct zie gebeuren want meerdere hardware platforms ondersteunen is een hoop werk, en hier hebben IT afdelingen doorgaans geen zin in), zal de focus voorlopig toch op x86 blijven.

Meh. Die afwijkende hardware is niet eens zo interessant als factor, wat wel interessant is dat je dan ook andere formats (tablets/pads/thinclients) die tot nu toe niet met de al aanwezige middelen zoals voor x86 desktop/servers beheerd kunnen worden (denk aan AD, GPO's, SystemCenter familie) dan opeens wel als managed devices in je service kunnen worden opgenomen.

Ja met .NET kan je applicaties schrijven die redelijk OS onafhankelijk zijn, met Java trouwens ook.
Toch hebben dit soort applicaties nooit echt voet aan de grond gekregen op de desktopmarkt, op een paar uitzonderingen na. Want een native app is toch altijd wat sneller en vloeiender dan eentje die in een platformonafhankelijk framework geschreven is.

VOlgens mij onderschat jij de hoeveelheid .Net applicaties.

Met Relief2009, .NET is zo uitgebreid, zo compatibel (qua development t.o.v. WIN32) en zo snel (qua performance t.o.v. WIN32) dat de enige reden om windows applicaties niet in .NET te maken is dat de programmeur er niet vertrouwd mee is.
De enige reden om windows applicaties in legacy te ontwikkelen i.p.v. in CLI (lees .NET) is dat het drivers zijn.

In de praktijk is de grootste reden nog steeds omdat mensen liever zeggen dat ze (slechte) C++ schrijven dan (goede) C#.

Ja... maar .NET kan ook gewoon (nou ja, bijna gewoon) in C++. Dan kom je op het gebied van managed/unmanaged. Pure .NET applicaties zijn volledig managed, wat C++ in pricipe niet is. Daarom zijn er voor .NET enkele uitbredingen op C++ gemaakt, zodat unmanageable code (bijv. malloc/free of geheugen pointers) vervangen kunnen worden door manageable constructies (die er al lang waren in de vorm van new/delete).

Ik zou er helemaal niet rouwig om zijn als Win8 geen unsafe/unmanaged code meer toe staat [u]behalve[/b] in een sandbox/VM, waar dus veel performance verlies is, en dus vermeden moet (en makkelijk kan) worden.

Dat gaan de game devs vreselijk vinden, want die willen allemaal native code, close-to-the-metal - alles om de uiterste uit de hardware te trekken. Ten kosten van stabiliteit en security, dat wel. En niet alleen games - waarom denk je dat alle browsers nog steeds native code zijn? OK, bestaande codebase, maar vooral doordat de gebruiker een Java/.NET browser genadeloos van zijn systeem flikkert omdat het trager is dan IE/FF/Safari/Chrome, en niemand durft het aan uit angst marktaandeel te verliezen. Android begon ook met het nobele idee dat alle apps in de Dalvik VM draaien, maar heeft overhaast toch maar native code toegelaten, want anders vond iedereen dat het zo traag was tov de iPhone. Alleen bij Blackberry is native code nog een vies woord en zijn alle apps (en het grootste deel van het OS zelfs) grondig afgeschermd in een Java VM. En je ziet bij elk nieuwsbericht weer de klachten: slome apps, geen games.

[Reactie gewijzigd door Dreamvoid op 18 mei 2011 13:53]

punt, - maar dan wachten we tot ie9 - dan heeft iedereen kans om genoeg aan de engine te sleutelen om het alsnog te doen, want unmanaged code ano 20nn dat moet toch beter kunnen zou je denken...

Het klinkt zo idealistisch om alles naar "managed code" om te zetten. Klinkt heel veilig, en mooi. Voor een beheer of business applicatie, is .NET/Java heel geschikt, omdat daar meer ontwikkelgemak betekend dat er beter gebouwd wordt, en het performanceverlies ligt prima binnen de marges. Dit geld echter niet voor kerntaken van het OS of handheld apparaten. De praktijk is namelijk dat het alle "managed" zaken een belasting zijn op je geheugenallocator en CPU cycles.

"Managed" talen missen een aantal low-level zaken, en dat heeft de volgende effecten:

• Alle objecten (hoe tijdelijk dan ook) liggen voor langere tijd versnippert op de heap.
• Data kopiëren vereist een hoop losse acties; voor ieder object apart.
• de geheugenallocator moet actief zoeken naar lege ruimte, tussen deze grotere berg objecten.
• de garbage collector moet later weer uitzoeken wat opgeruimd kan worden.

Dit is een gegeven van "managed" talen, in ruil voor meer programmeergemak. Het geeft echter ook een performanceverlies en stijging in geheugengebruik, wat je niet altijd voor lief kan nemen. Zeker niet op een handheld apparaat of kern-OS taken.

Het voordeel van C++ code is, dat na het verlaten van een functie alle tijdelijke objecten (op de stack) weer opgeruimd zijn. Daarnaast kan je in C++ een object "inlinen"; alle inhoud zit dan achterelkaar in 1 geheugenblok. Dat kopieert snel, en ruimt snel op. Hierom blijft C/C++ veel toegepast in applicaties waarbij geheugen en performance belangrijk zijn.

Als praktijkvoorbeeld: Bij Google draaien ze een Git server in Java, en na veel moeite blijft de performance 2x onder die van puur C liggen. Voor details, zie: http://marc.info/?l=git&m=124111702609723 Verder kan het niet; de grens is daar aardig opgezocht.

[Reactie gewijzigd door YaPP op 18 mei 2011 20:57]

Het klinkt zo idealistisch om alles naar "managed code" om te zetten. Klinkt heel veilig, en mooi. Voor een beheer of business applicatie, is .NET/Java heel geschikt, omdat daar meer ontwikkelgemak betekend dat er beter gebouwd wordt, en het performanceverlies ligt prima binnen de marges. Dit geld echter niet voor kerntaken van het OS of handheld apparaten. De praktijk is namelijk dat het alle "managed" zaken een belasting zijn op je geheugenallocator en CPU cycles.

Misschien nog belangrijker voor embedded toepassingen: In C/C++ heb je als programmeur een veel grotere mate van controle over hoe je geheugen gebruikt wordt en over de indeling van je data. Vooral als je maar 4MB aan geheugen tot je beschikking hebt en er bijvoorbeeld gebruik gemaakt wordt van memory-mapped I/O, dan is het vooral nuttig om te weten (en te kunnen beïnvloeden) welk geheugen er gelezen en geschreven wordt.

Daar staat natuurlijk tegenover dat je als C/C++ programmeur meer op je tellen moet passen en alles zelf bij moet houden. Als je dan code schrijft alsof je met managed code werkt (wat soms IMO enige luiheid met zich meeneemt) dan gaat het geheid fout omdat je programma geheugen gaat lekken of over zijn eigen stack of objecten heen gaat lopen schrijven. Again, iets wat je in een embedded omgeving met MMIO (vooral als dat nog andere zaken aanstuurt) al HELEMAAL niet wil hebben.

Ben ik niet eens, voor bijvoorbeeld games geeft het toch een voordeel omdat je het geheugenmanagment liever zelf wil doen i.v.m. performance (je wil niet wachten tot de GC langskomt om die 1GB aan loze textures weg te gooien). Voor niet performance intensitive applicaties ben ik het wel enigszins met je eens.

Dan programmeer ik graag op mbo-niveau. Dan houd ik namelijk meer capaciteit over voor waar het echt om gaat, namelijk maken wat de klant wil. Ik ben software-ontwikkelaar, en dat is véél meer dan programmeur alleen.

Alhoewel ik het op zich met je eens ben dat talen als java en C# sneller zijn voor software ontwikkeling, ben ik geen voorstander van studenten alleen leren programmeren in een vendor-specifieke taal. Er is al genoeg MS op deze wereld. Door verse programmeurs alleen te leren programmeren voor 1 specifiek platform houdt je kunstmatig een ongewenst monopolie in stand. Als je studenten leert programmeren in C++, kunnen ze zichzelf ook wel C# aanleren als ze perse Windows-only willen gaan.

maar vervolgens leer je ze wel omgaan met... libdit libdat libzus en niet met libgpl libbsd en libapache-mit dus hoewel vendor lock-in de stap van C# naar java of een van de opensource talen is echt niet substantieel anders bovendien kun je altijd nog kijken naar mono als je ECHT onzinnig bezig wilt gaan.

verder is een opmerking als C++ want anders ben je geen echte ict-er natuurlijk het domste wat je ooit kunt zeggen... dan heb je niets maar dan ook NIETS begrepen van wat er in het echte leven gevraagt wordt... bovendien zijn dat dezelfde koorbalprogrammeurs die liever buggy-ass-hell crapware schrijven in een taal, en voor een arch waar ze niets van snappen... dan de gemiddelde MBO'er - want DIE mbo'ers die het daadwerkelijk tot programmeur schoppen hebben vaak een veel langere en practischere weg achter de rug en staan veel realistischer tegenover wat goede software maakt...

Maar C# is helemaal niet Windows only. Sterker nog, F-Spot en Banshee twee zeer populaire pakketten voor de Gnome desktop zijn (grotendeels) geschreven in C#!

Wij werken hier op de universiteit met C# en java. Het is echt jaren geleden dat ze nog C++ gebruikten.

En wij werken op de universiteit met C++ en java. C++ is nog altijd veelgebruikt, en is vooral niet microsoft afhankelijk. Probeer maar eens C# te schrijven op een mac of linux, dat is toch maar prutswerk ze dan.

Weet niet op wat voor scholen jij komt maar op alle HBO en WO opleidingen die ik ken wordt C# of Java onderwezen, of beide. Ook op de grote universiteiten in de VS. Juist omdat C# en Java een schoolvoorbeeld zijn van hoe je goed object georiënteerd moet programmeren. Uiteraard komt C++ ook nog voor maar naar mijn idee wordt dit op scholen juist steeds meer uitgefaseerd.

Maar dit ligt niet aan C# persé, maar meer aan het soort applicaties wat erin gemaakt wordt, door MBO-niveau programmeurs. Dit zijn veelal vervangers voor applicaties die eerder in VB geschreven waren en nu op een zelfde manier, maar met een andere taal ontwikkeld worden. VB.net is in die kringen ook populair.

Wat een onzin. Een taal is heeft geen niveau, je kan doodsimpele applicaties maken in C en enorm complexe systemen in C# of Python. Bij mij op de universiteit wordt C++ alleen gebruikt bij een mastervak game-engines maken, ze hebben het zelfs vervangen door Microsoft XNA met C# bij de bachelorvakken.

Voor het leren en de eerste projecten gebruik je Java, maar al vanaf het tweede jaar mogen groepen studenten het zelf bepalen in goed overleg (ikzelf heb bijvoorbeeld een project in C# gedaan, een ander groepje in Python)

Precies. Mensen denken bij .net echt nog aan de oude versies die gewoon slecht waren, ondertussen zijn we een aantal versies verder en is het gewoon een heel goed pakket.

De oudere versies van .net waren dus slecht? Kan je dat eens onderbouwen?

1.0 en 1.1 waren niet echt lekker en consequent in namespaces. De CLR van 1.0 en 1.1 zijn helemaal op de schop gegooid.

2.0 en de latere uitbreidingen 3.0 en 3.5 (want dat zijn libs die nog steeds op de CLR 2.0 werken) zijn een stuk prettiger coden.

Tot 1.1 was het vrij nutteloos omdat je aan jouw zijde niet veel vrijheid had en aan de kant van de gebruiker was er geen kat die het framework had geïnstalleerd.
Het framework in je installer implementeren of je gebruiker laten downloaden was ook niet zo leuk want dat is nog uit de tijd toen weinigen breedband hadden. Het was gemakkelijker om .NET niet te gebruiken dan wel.


Wat .NET wel goed heeft gedaan is hoe ze over de meeste zaken dachten en pas dan uitbrachten. Bij Java 1.0, 1.1, 1.2, 1.3, ... moest je telkens je projecten gaan hertesten en gegarandeerd ging er iets niet meer werken. Dan moest je je projecten updaten of je klanten allerhande verschilende java versies laten bijhouden.
Een van de redenen waarom mensen zo snel van Java naar .NET zijn gesprongen.

Het .NET framework is er wel enorm op vooruit gegaan in 2.0 (en opnieuw in 4.0). Onder andere generics in 2.0 en veel van de standard library is verbeterd.

De enige reden om windows applicaties in legacy te ontwikkelen i.p.v. in CLI (lees .NET) is dat het drivers zijn.

Kortzichtig en onwaar. Als je het laatste greintje performance wilt, ga je niet voor .NET.

en dan aankomen met software dat niet naar je 3e core schaalt, en waar je 8gb ram voor nodig heb, terweil we 5 jaar terug het zelfde al konden met 1gb ...

laten we eerst maar eens zorgen dat de trent weer 'efficient' programmeren wordt, als we dat weeer kunnen (in .net) - mag er dan pas weer gekeken worden naar iets anders... want voorlopig is lui-heid DE defactor standaard in ict-land op het gebied van programmeren.

laten we eerst maar eens zorgen dat de trent weer 'efficient' programmeren wordt, als we dat weeer kunnen (in .net) - mag er dan pas weer gekeken worden naar iets anders... want voorlopig is lui-heid DE defactor standaard in ict-land op het gebied van programmeren.

Dan moeten de programmeurs maar weer eens leren om te programmeren en zien hoe een computersysteem in elkaar steekt. Ik ben zelf nog in Turbo Pascal 5.5 op een 386 aan de slag geweest, en dan loop je op je gemakje uit te zoeken waar die 'exception 13' dan vandaan komt die je programma naar de DOS-prompt laat crashen.

Tegenwoordig wordt er zoveel gebruik gemaakt van frameworks dat het niet meer leuk is en dat programmeurs ervan uit aan het gaan zijn dat er overal wel een framework voor is. Programmeren wordt dan het bij elkaar mixen van tools en frameworks met de nodige hoeveelheid (door de programmeur geschreven, gebrekkig) plakband, met het idee 'als het maar werkt'. Gewoon een paar extra objecten declareren, daar weer wat leuke dingen mee doen en de garbage collector ruimt de boel toch wel weer een keer op. Zonder in de gaten te hebben wat er onder de motorkap gebeurt.

Analoog aan de echte wereld: Als je je avondeten gekookt achter de kiezen hebt, laat je dan de hele rotzooi ook in de keuken en op tafel slingeren? Want vrouwlief ruimt het wel weer op? Ik ben benieuwd hoelang je huwelijk dan stand zal houden.

.Net kan nooit sneller zijn dan goed geschreven native code. Al is het alleen al omdat als .Net perfect zou zijn, en de native code ook, dan zouden dezelfde instructies uit worden gevoerd en dan zijn ze dus net zo snel. De voornaamste reden die ik me kan bedenken waarom .Net sneller zou kunnen zijn, is omdat er maar weinig goed geschreven code bestaat, en de voorgebakken .Net functies allicht sneller kunnen zijn dan wanneer een prutser hetzelfde in elkaar probeert te zetten in native code.

Maar m'n punt was, dat stellen dat .Net zo snel is, getuigd van weinig inzicht in programmeren, aangezien snelheid voornamelijk afhangt van de skills van de programmeur, en niet van de taal. Zolang .Net geen overtuigende reden biedt om een nieuwe taal voor te willen leren, blijven C++ programmeurs daarom lekker C++ programmeren.

Een andere reden om juist geen .Net te gebruiken is platform onafhankelijkheid. En dan heb ik het niet over verschillende Windows versies, zoals de MS-definitie van deze luidt, maar over het gebruiken van dezelfde codebase op zowel Windows als OS X als Linux, maar ook makkelijk te porten naar mobiele platformen, die steeds belangrijker worden. .Net is leuk voor Windows-only tooltjes, maar in deze tijd, waarin vooral op mobiel gebied teveel platformen door elkaar heen worden gebruikt, is het programmeren in een vendor-specifieke taal nauwelijks goed te praten.
En ja, ik weet dat er Mono bestaat, maar ik heb er nog nooit 1 MS .Net app op draaiende gekregen, dus zoveel vertrouwen heb ik niet in de platform onafhankelijkheid hiervan.
Waar je de term "compatible" vandaan haalt zou ik niet weten, want naar mijn weten heb ik geen enkel apparaat wat een MS .Net app zou kunnen draaien.

Snel gaat niet enkel om executie van het programma maar om de gehele life cycle. Als jij morgen onder een auto ligt, gaat je opvolger plots als je code voor ogen krijgen en moet hij zich daar asap op kunnen inwerken.
In de praktijk zal dit gemakkelijker verlopen met C#/VB/F#/... waardoor ze tijd overhouden om naar de begrafenis te gaan.

En een ontwikkelaar die geen nieuwe taal wil verkennen is natuurlijk geen gedreven ontwikkelaar.

Of juist nog niet uitgekeken op zijn taal...dat je niet iets nieuws wil leren omdat je huidige taal voldoet , en er nog meer uit te halen / puzzelen is en daardoor gedeclassificeerd wordt als niet gedreven is botweg nogal lomp om te stellen....

Ik zei dan ook niet leren maar verkennen.

Andere talen bekijken is zeer nuttig omdat je dan de breedte van je kennis beter wordt. Je moet niet altijd de diepte van je kennis willen verbeteren.

Redenen voor c++ programmeurs om c# te leren programmeren:

Garbage collection. (Daardoor geen last meer van memory leaks.)
Uitgebreide framework class library die voorkomt dat je zelf het wiel uit moet vinden.

Reden om in c++ te blijven programmeren:
Sneller, maar voor de meeste applicaties voldoet de snelheid van een .net applicatie.
Platform onafhankelijkheid, maar windows is zo wijdverspreid dat je met een windows programma een heel eind komt.

Je vergeet één belangrijk onderdeel en dat is de JIT compiler. Bij een klassiek C/C++ programma wordt op voorhand de code naar machinecode vertaalt. Bij het .Net framework zal de JIT compiler de IL-code (byte-code zeg maar) on-the-fly vertalen naar machinetaal. Het voordeel is dat de JIT compiler weet op welke CPU de code draait, en dus CPU specifieke zaken kan gebruiken. OOk de runtime omgeving is belangirjk voor de JIT compiler.

Hoeveel programma's op je eigen PC zijn .NET? Bij mij zijn dat er maar weinig.

Ik zie anders een hoop installers langs komen die ook .net 3.5 of een andere versie mee installeren, of op z'n minst vragen

Volgens mij was er voor bepaalde games ook .Net nodig. Niet omdat de game in .Net geschreven is, daar is .Net naar mijn mening niet zo heel geschikt voor (je wilt in games toch iedere extra fps eruit persen), maar omdat een launcher of hulptooltje in .Net geschreven is. Onder Windows merk je daar niet zoveel van, maar als je een game onder Wine aan de gang probeert te krijgen is die .Net launcher toch maar een vervelend ding...

.NET 2.0 werkt toch inmiddels wel onder Wine?

Geen wine voor nodig, met mono werkt het ook best goed.

Dat klopt maar heel vaak gaat dit dan alleen om de installer zelf die het gebruikt!

Hoeveel zakelijke programma's draai jij? De ERP systemen ed zijn een belangrijke factor in bedrijf omgevingen en als die eenmaal het voordeel van ARM zien dan zal de consumenten markt na een tijdje wel volgen.

Dit staat los van de uiteindelijke werking van ARM aangezien we daar nog weinig over kunnen zeggen

Alleen tweakers.net

Enkele bekende programma's: Paint.NET, alle OSS projecten, ASP.NET (webservers), veel business software, zijn er nog redelijk wat hoor!

Ook populair voor kleine business tooltjes e.d. omdat het sneller op te zetten is dan je gemiddelde C++ oid applicatie, en door de goede tools, language features en library (relatief veel "dom werk" kan gemakkelijk met de .NET library gedaan worden terwijl dat bij Java niet in de library zit en je al snel Apache Commons gaat gebruiken e.d.) ook sneller dan Java.

genoeg kleine en minder kleine tooltjes, skype zou heel goed binnen afzienbare tijd geport kunnen worden naar .net nu MS het heft in handen heeft ... en men met QT (nokia) niet er op lijkt te schieten...

DAT zou trouwens wel DE verbetering zijn waar ik op zat te wachten voor skype... dat, en goede voorzetting van de 'skype-server-api' voor de alternative ossen (zoals linux).

die qt gui bij skype was toch al 10x niks..

maar ik gebruik dagelijks een paint.net, en regelmatig cdburnerXP mediaportal, en volgens mij werken de producten van autodesk ook op .net..

en natuurlijk het MicroSe framework

en natuurlijk het MicroSe framework

hehe, toch gewoon een fenomeen op t.net.

Mijn lach van de dag weer gehad. :-)

Want een native app is toch altijd wat sneller en vloeiender dan eentje die in een platformonafhankelijk framework geschreven is.
Dit kán zo zijn, maar is (helaas voor de jongens die hun uitdaging halen aan het doorgronden en schrijven van syntactisch ingewikkelde C++ code) geen waarheid als een koe.

De crux zit hem in het feit dat er een abstractielaag wordt gebruikt (de JVM in het geval van Java) en het dus mogelijk is dat programmas nog geoptimaliseerd worden nádat ze gecompiled zijn. Aan het begin had Java bijvoorbeeld een hele primitieve garbage collector en interpreted code (en was dus niet vooruit te branden), maar tegenwoordig zijn simpele programma's dankzij JITC niet trager dan native code (los van de opstarttijd, maar die ene seconde aan het begin maakt natuurlijk niet zoveel uit als je een programma een kwartier gebruikt) en draait bijvoorbeeld de garbage collector in een aparte thread (waardoor single threaded applicaties soms toch meer dan 50% cpu tijd kunnen halen op een dual core machine). En het leuke is dat deze optimalisaties ook gewoon werken op programma's die gecompiled zijn toen deze technieken nog helemaal niet gebruikt werden.

Bij talen als C++ hoef je echt niet te verwachten dat je gecompilede programma uit 1998 de hardware uit 2020 efficient kan gebruiken (tenzij je het opnieuw compiled met een moderne compiler, als dat lukt), terwijl dat bij dit soort VM talen wel degelijk het geval is.

Bij talen als C++ hoef je echt niet te verwachten dat je gecompilede programma uit 1998 de hardware uit 2020 efficient kan gebruiken (tenzij je het opnieuw compiled met een moderne compiler, als dat lukt), terwijl dat bij dit soort VM talen wel degelijk het geval is.

Jouw binary uit 1998 draait ondertussen toch op geen enkel systeem meer. Om die code nog te laten draaien zul je een nieuwe moeten bouwen, en nieuwe native compilers staan ook niet stil. Ook C code valt nog sneller te maken door gewoon een betere compiler te gebruiken, net zoals een betere JVM jouw oude java app sneller doet laten draaien.

[...] waardoor single threaded applicaties soms toch meer dan 50% cpu tijd kunnen halen op een dual core machine [...]

Inderdaad, de crux van de zaak: slecht geschreven C++ programma's doen het slechter dan Java/C# programma's waar even veel moeite in is gestoken. In veel situaties is dit inderdaad het enige dat er toe doet.

Bij talen als C++ hoef je echt niet te verwachten dat je gecompilede programma uit 1998 de hardware uit 2020 efficient kan gebruiken [...] terwijl dat bij dit soort VM talen wel degelijk het geval is.

Java 1.0 bytecode efficiënt draaien op een huidige JVM? Ik dacht het niet.

On-(main-)topic:
Ach ja, het grootste deel is een kwestie van hercompileren. Lijkt misschien vreemd op het Windows/x86 platform, maar is best wel acceptabel in het algemeen.

Java 1.0 bytecode efficiënt draaien op een huidige JVM? Ik dacht het niet.
Goed, je hebt natuurlijk meerdere lagen van optimalisatie en je zult frontend optimalisaties en optimalisaties die mogelijk worden door uitbreidingen van je intermediate language natuurlijk ook niet mee kunnen pakken in het geval van de VM talen, maar de backend (hardware afhankelijke) optimalisaties kun je in het geval van VM talen wel degelijk meepakken door gewoon een nieuwere/andere VM te installeren.

In het specifieke geval van Java 1.0 kan het natuurlijk best dat je tegen deprication van de standard library aanloopt, of dat je qua frontendoptimalisaties of het feit dat je werkt met een subset van de huidige intermediate language tegen harde bottlenecks aanloopt. Maar dat is op zich niet zo heel belangrijk voor de discussie native code vs. intermediate code met een VM.

En toch zijn vrijwel alle zakelijke apps geschreven in deze talen

Zolang de system calls in W8 hetzelfde blijven hoef je alleen je programma maar te hercompileren lijkt me. Dan is een high-level framework als .NET niet eens nodig.

Zolang de system calls in W8 hetzelfde blijven hoef je alleen je programma maar te hercompileren lijkt me. Dan is een high-level framework als .NET niet eens nodig.

Ik geloof juist niet dat Intel het had over hercompileren. Maar dat ze met het 'draaien van legacy apps' bedoelen dat je op een ARM-Windows machine straks een x86 .EXE aan kunt klikken en je krijgt gelijk voor je neus wat je wil hebben. Dat dat niet zomaar gaat werken, no shit, Sherlock.

Met voldoende mate van virtualisatie en emulatie moet het trouwens geen probleem zijn. Mac OSX heeft hetzelfde trucje geflikt met Rosetta, waardoor je zonder problemen PowerPC binaries op een x86 kan draaien.

Ik weet het fijne niet maar het is Intel die dit zegt dus ik neem het met een korrel zout

snap niet waarom je zo gedownmod wordt, want je hebt toch zeker een punt
intel's belang is dat mensen bij x86 blijven, en wat bad press over windows 8 op ARM doet hen dus goed (al kan het best backfiren...)

hoedanook als het klopt wat intel zegt is dit wel jammer, zeker als er verschillende versies van het OS zijn voor verschillende versies van de chips, ik hoop dat dat niet klopt en dat het dan meer is als windos home premium/professional/ultimate oid maargoed.
en over de backwards compatibility het is aldan niet onverwacht dat men niet ineens pc software kan draaien op een ARM (ik heb nooit verwacht dat dat zou kunnen de performance cost zou mogelijk wel erg groot zijn ivm de lagere instructions per clock voor ARM... maar het blijft jammer,

desalniettemin als er 1 platform komt om voor te developen vanaf het moment dat W8 uit is is dat ook een vooruitgang.

overigends zie ik niet ec

Hmm, een beetje overdreven

Maar Paul zegt toch ook niet dat er helemaal geen prog's gaan draaien, maar dat Lagency spul niet draait.
Nee dat is logisch, daarom heet het ook lagency!

.Net is inderdaad de juiste keuze om CPU onafhankelijk te schrijven. Ten minste voor Windows omgeving.

Daarom durft MS nu ook met een andere CPU ondersteuning te komen.

In het verleden hebben ze natuurliijk ook Windows voor PowerPC en Alpha gehad en nu ook nog steeds voor ia64 (Itanium).
Maar als je geen .Net applicaties maakt maar bijv. C(++) dan moet je alles recompilen en ook alle CPU specifieke code er uit halen.

Java geeft het zelfde idee, maar ik wet niet hoe snel Java er voor Windows ARM komt en ik denk ook dat .Net vele malen sneller is.

Java geeft het zelfde idee, maar ik wet niet hoe snel Java er voor Windows ARM komt en ik denk ook dat .Net vele malen sneller is.

Denken is niet voldoende ... benchmarks helpen meer: http://kingrazi.blogspot....t-vs-java-benchmarks.html

Het feit dat zowat iedereen zal zeggen dat apps met Java trager zijn dan .NET, zegt al genoeg dat benchmarks hiervoor geen nut hebben.

Feit: de applicaties zijn trager. Niet omdat ze noodzakelijk trager zijn, maar wel omdat ze trager voelen.

ARM heeft hardwarematige Java-versnelling (Jazelle).

Windows ondersteunt dat blijkbaar niet, dus beetje lomp om te zeggen dat Java trager is omdat Microsoft in gebreke blijft: Het probleem is hier Microsoft en niet Java.

Vooralsnog zijn er helemaal geen java-applicaties die op Windows op ARM draaien, dus lijkt me een beetje voorbarig daar nu al dingen over te roepen.

Zover mij bekend maakt MS geen Java dus dat Java voor Windows evt hardware versnelling niet ondersteund is niet hun fout.

Ik denk dat Open office straks wel een mooi voorbeeld kan zijn hoe Java op W8 Arm gaat presteren.

Wat noemt men hier 'legacy', alle software ouder dan Windows 8? Bij legacy-software denk ik zelf namelijk meer aan het Windows NT-tijdperk, 16-bitsapplicaties, etc.

Als het goed is, en je echt alleen van het framework gebruik maakt (zoals MS dat ook graag wil dat je doet), dan zouden je 'nieuwe' .NET applicaties gewoon moeten draaien.

Legacy betekent vooral pre-.NET code. Ik gok meer op de emulator als oplossing voor dat (of WINE natuurlijk)

Tuurlijk gaat Intel zulke dingen roepen, want ze zien het niet zitten dat Windows op non-x86 gaat draaien. Dat betekent voor hun minder verkoop.

Verder kun je door gebruik te maken van een Marketplace (wat MS ook gaat doen) consumenten het veel makkelijker maken. Consumenten hoeven zich geen zorgen meer te maken over welke software wel of niet werkt op ARM.

MS altijd top of the line tools, dus ik verwacht dat ontwikkelaars straks gemakkelijk hun software kunnen recompilen.

Verder is Intel alleen maar angst aan het zaaien. In de winkel zul je alleen de normale W8 vinden. W8 voor arm zul je nooit los kunnen kopen dus ik zie het probleem niet.

[Reactie gewijzigd door Relief2009 op 18 mei 2011 10:08]

Bij bijv. Android is het OS voorgeinstalleerd, alle apps zijn platform-onafhankelijk, dus geen probleem.

Bij Windows/ARM is het OS voorgeinstalleerd, alle nieuwe apps zullen vast platformonafhankelijk zijn, dus ook geen probleem, lijkt het.

Alleen Windows heeft allemaal oude applicaties die niet zijn voorgeinstalleerd, en niet platform onafhankelijk zijn, dat zal 't probleem wel zijn.

Dat voor x86 geoptimaliseerde software niet zal gaan werken lijkt me evident.

Maar deze waarschuwing is niet nobel, immers Intel eet een goede boterham dankzij Windows en heeft miljarden geïnvesteerd en nieuwe technologie op stapel om verdere vendor lock-in te promoten. Een echte concurrerende platform zitten ze niet op te wachten.

Windows-for-ARM kan in een paar jaar in miljoenen hardware appliances zitten en die hebben allemaal een afschrijvingsperiode van een paar jaar. Als die appliances bevallen zal Intel dat maar moeilijk kunnen terug veroveren.

Intel heeft zelf ervoor gezorgd dat ze geen energie zuinig platform voor appliances heeft die momenteel meetelt.

Ik denk ook dat ze tegen beter weten in dit roepen, want er zijn maar een beperkt aantal partijen (lees: gecontracteerde Intel afnemers) die de markt voor Windows-for-ARM kan negeren. Immers veel andere keus heb je niet. (apple, android, wm7 die vanzelf gaat verdwijnen)

ps: Windows-4-arm kent ook geen legacy problemen, het lijkt me sterk dat Microsoft alles waar ze rekening mee moesten houden op x86 platform hier ook gaan inbouwen, want dan krijg je zoveel overhead dat platform niet zal kunnen slagen. Het zou weleens de meest efficiënte OS kunnen worden van Microsoft met beste prijs/prestatie verhouding.

[Reactie gewijzigd door totaalgeenhard op 18 mei 2011 10:32]

Wat weerhoud Intel om zelf ARM chips te gaan bakken?

Dan graven ze hun eigen graf.

Ze moeten dan licentie nemen op ARM.

Hier een achtergrond verhaal:
http://nl.hardware.info/r...sor-technologie-licenties

[Reactie gewijzigd door totaalgeenhard op 18 mei 2011 11:38]

Ze hebben daar echte concurrentie. de x86 markt is van Intel, de enige fabrikant die een beetje tegengas kan geven is AMD. Gaan we naar ARM kijken hebben ze opeens met heel wat meer concurrenten te maken, met veel meer ervaring van de architectuur.

Het lijkt erop dat Microsoft zijn greep op de markt aan het verliezen is. Ze hadden tientallen jaren het grote voordeel op de concurrentie dat er een enorme software base bestond die alleen op het 'Wintel' platform draaide.
Maar nu met de komst van smartphones, tablets en de opkomst van ARM dreigt dit voordeel voor Microsoft verloren te gaan.

Ik begrijp niet precies waarom MS de greep op de markt aan het verliezen is.

Op het gebied van x86 hebben ze nog steeds geen fatsoenlijke concurrentie en x86 blijft de komende jaren nog steeds onverminderd populair.

Door W8 ook voor ARM geschikt te maken breiden ze hun markt juist uit. Ik denk dat heel veel consumenten wel een tablet willen hebben van W8 met een gebruiksvriendelijke touch-interface.

Simpel: Er worden meer smartphones dan Windows computers verkocht, en er worden veel meer ARM-chips verkocht dan x86 chips.

Linux(kernel) werkt momenteel veel beter op al die ARM-chips dan Windows. En open-source programma's - die veelal te vinden zijn voor Linux - zijn makkelijker te porten naar ARM dan de gesloten "3d party legacy programma's" voor Windows.

Kortom: Mensen kopen wel een nieuwe telefoon, maar geen nieuwe desktops. De ontwikkeling van smartphones / ARM gaat immers ook veel sneller dan bij desktops / x86; dus omdat desktop-ontwikkeling traag gaat kopen mensen geen nieuwe desktop. Bovendien gaan desk/laptops langer mee dan smartphones lijkt me.

Dus MS bijft het desktop-monopolie behouden, maar ze gaan veel minder winst maken. Omdat desktops 'verdien-technisch' gewoon steeds minder interessant worden. En minder belangrijk.

Tevens kunnen ze consumenten niet meer 'insluiten' met Microsoft-only technologieen, omdat consumenten dan gaan klagen dat 'die vieze Microsoft-troep' niet samenwerkt met hun iPhone / PlayBook / Android-tablet / Kindle of wat dan ook; omdat MS geen monopolie heeft op mobiele OS'en worden ze gedwongen open standaarden te gebruiken. Zoals bijv. HTML5; en eerder al OOXML. Dan moeten ze concurreren op basis van hun producten (wat ze met SMB / legacy office-formaten niet hoefden omdat ze concurrenten konden dwarsbomen).

En concurreren op producten, daar kunnen ze veel minder winst op maken dan dat mensen afhankelijk zijn van hun producten. Want als er concurrenie is, kan je klanten niet uitmelken. Doordat jouw office-suite de enige is die .doc kan maken/bewerken/openen (en enigszins 't zelde voor IE/SMB/Exchange protocol) kan je 70% winstmarge kan hebben. Maar die tijd is voorbij; buitensporige winstmarges behoren snel tot het verleden bij MS.

Met als gevolg een downgrade door Goldman Sachs, investeerders die dus weglopen, dalende beurskoersen, sprake van opsplitsing (wederom GS), druk op het management, bezuinigingen, ontslagrondes (die twee komen nog), braindrain, megalomane overnames en alle andere zaken die erop wijzen dat ze de greep op de markt verliezen.

[Reactie gewijzigd door kidde op 18 mei 2011 10:33]

Welk stukje van W8 voor ARM heb je gemist? MS stort zich straks massaal op de markt van smartphones en tablets.

Zeg ik toch: Dan moeten ze gaan concurreren op producten, en gebruikmaken van open standaarden; dus gaan ze minder winst maken.

Apple is met hun gesloten ecosysteem waanzinnig succesvol, en Google met open standaarden ook - we hebben de afgelopen 20 jaar gezien, of je nou open of gesloten spul maakt, het boeit je klanten uiteindelijk geen bal - het gaat ze om het eindprodukt.

x86 blijft de komende jaren nog steeds onverminderd populair.

ARM is al marktleider op de tabletmarkt. En bij smartphones moet je heel goed zoeken om een x86 cpu te vinden ..

Ik denk dat heel veel consumenten wel een tablet willen hebben van W8 met een gebruiksvriendelijke touch-interface.

Tot ze er achter komen dat hun Windows software van hun desktop daar niet op draait ..

Tot ze er achter komen dat hun Windows software van hun desktop daar niet op draait ..

Maar draait MacOS software wel zomaar op de iPhone en iPad dan? Zo vreemd is het toch niet dat niet zomaar alle software te gebruiken is op andere hardwareplatforms.

Overigens zal het bovendien nog wel even duren voor ARM ook voet aan de grond heeft op desktopgebied. En belangrijker: Voor telefoons en tablets wil je over het algemeen niet zomaar desktopsoftware draaien.

Maakt toch niet uit. Voor hun tablet gebruiker ze de .exea (of whatever) en voor de desktop .exe.
De meeste mensen gebruiken toch een setup en daar kan je beide versies insteken.

Met de opkomst van markets zullen die zien op welk platform ze worden uitgevoerd en de juiste versie installeren.

Ms had juist niet veel zin om die markt te volgen. De eerste netbooks waren ook Linux maar de fabrikanten bleven zagen dat Ms een versie moest uitbrengen voor de netbookjes. Onvoorbereid werd dat dan xp/vista/win7 starter welke enkel een paar restricties kregen en aan halve prijs werden verkocht aan de OEM's.

Nu gebeurd weer hetzelfde met de snelle opgang van ARM. Alleen is Ms zich deze keer wel aan het voorbereiden dat ze Windows vertalen en ze dus een echt gespecialiseerde versie kunnen verkopen.
Het aantal Android tablets zal drastig dalen wanneer Windows 8 opduikt. Afhankelijk hoe de klanten die Windows 8 op hun mobiele apparaten lusten, zal je Android zelfs zien verdwijnen buiten enkele nichemerken.

Android heeft de miljarden van Google achter zich, die gaat echt niet zomaar weg. De nieuwe wereld is Apple vs Google vs Microsoft, op bijna alle gebieden van de ICT, van telefoons tot tablets tot PC's, van cloud diensten tot OSsen. Langzaamaan heeft ieder van die 3 zijn "lege plekken" in zijn produktgamma ingevuld. De rest kijkt toe of rommelt in de marge.

Ware het niet dat Android een inferieur product is en dus makkelijk weg kan vallen.

Android heeft namelijk een grote zwakte, het wordt door Google gemaakt en daarna willen verkopers hun eigen extensies erop maar nu is het product niet meer compatibel met Google's versie.
Zolang Google dit op de slechte manier toelaat waar het OS en de GUI in elkaar verstrengeld zitten, zal Android enkel theoretisch veilig kunnen zijn. In de praktijk kan je echter geen snelle updates naar je klanten brengen.

Ms werkt al 20jaar met een Windows die OEM's aanpassen maar waar Ms wel wekelijks hun rondje updates op kan toepassen. En Apple verbiedt alles en iedereen om iets aan te passen, waardoor ze ook geen updateconflicten hebben.

En als Google hun beleid verandert - wat ze momenteel doen - is heel dat probleem opgelost. Wen er maar aan: Android op smartphones gaat zowiezo niet weg, en voor tablets komt Chrome er ook nog eens bij.

Tevens passen telco's wel op telefoons met Windows Mobile te verkopen, als daarop Skype geintegreerd is. Als T-Mobile, Vodafone, Sprint et.all. geen Windows Mobile willen verkopen, is het Windows Mobile dat verdwijnt; en niet Android.

Als de telco's hun geld steeds meer op data willen verdienen, dan hoeft dat helemaal geen probleem te zijn.

Geef eens bronnen... Naar mijn mening is Android gewoon netjes compatible maar willen de fabrikanten eerst nog even hun eigen software testen voordat ze het uitbrengen.
Dit is eigenlijk exact hetzelfde als Apple doet alleen Apple heeft maar 1 fabrikant en dat zijn ze zelf waardoor de lijnen iets korter zijn. Ook moet Android aangepast worden op de hardware aangezien de drivers niet standaard bijgeleverd worden. (zie ook de snelheid van de updates voor custom roms)

Dit is niet iets slechts want dit gebeurd ook onder Windows (alleen Windows is zoverre gesloten dat je minder kan doen).

Het is een filosofie en zeker geen slechte omdat het is verzonnen met een monopolie positie in het achterhoofd. Op deze manier hebben ze vrijwel al het gezeik wat MS heeft gehad in 1 klap voorkomen (bijv de IE ellende). Apple volgt op dit moment een strategie die niet past bij een monopolist, verzin zelf maar even wat Apple allemaal moet gaan veranderen zodra iOS een monopolie positie heeft. Ditzelfde geldt voor desktops, maak van osX de marktlijder en binnen 5 tot 10 jaar heeft osX dezelfde "problemen"

Android heeft namelijk een grote zwakte, het wordt door Google gemaakt en daarna willen verkopers hun eigen extensies erop maar nu is het product niet meer compatibel met Google's versie.

Dat is aangepakt in 3.x
En tja, compatibility gebruiken in een discussie over microsoft..

[Reactie gewijzigd door blouweKip op 18 mei 2011 12:19]

Alles is eindig, dus ook Microsoft, Apple en alles wat je nu voor "zeker" acht.

Ben het eens met Relief2009 hieronder, dat het verlies op de markt wel mee lijkt te vallen. Ik denk dat alle grote bedrijven van meerdere walletjes mee willen eten, zo ook Microsoft. Dat ze keuzes maken die niet iedereen begrijpt/overziet is dan het gevolg.

Nou daar zit je dan als bedrijf met al je software: In één klap niks meer waard. Ik denk dat bedrijven die overgestapt zijn naar WIN7 nu wel zes keer achter hun oren zullen krabben voor men overgaat op ARM-architectuur om WIN8 te kunnen gebruiken. Want denk aan al die kantoor-suites (MSOffice Enterprises dan wel Corporates), Technische Applicaties (Autodesk) enz. Al die licenties die opnieuw aangekocht moet worden. En gratis varianten kun je wel vergeten want de migratie met ODF is nou niet bepaald soepel te noemen.

In het artikel staat dat de ARM/WIN8 geen legacy ondersteuning heeft/krijgt met de Applicaties, maar al die databases dan? De Gegevens die bedrijven aanmaken en onderhouden? Is dat dan ook waardeloos geworden of kan men die nog steeds blijven gebruiken... vraag ik me af.

Je gaat natuurlijk geen autocad op een ARM systeem van nu draaien.. De reden dat Microsoft de ARM versies is gaan ontwikkelen is vooral het gebruik op tablets en embeded systemen.

Nog niet. Ik zie niet in waarom dat in de toekomst niet zou kunnen met de performancewinsten die ARM architecturen de afgelopen jaren hebben geboekt.

maar al die databases dan?

Databases draaien meestal op een server. Ik zie nog niet zo snel ARM servers verschijnen dus dat probleem valt wel mee.

[Reactie gewijzigd door Left op 18 mei 2011 10:13]

Hmm ik dach dat de ARM versies van Windows juist interessant waren voor tablets en servers. Servers hebben eigenlijk maar een lage CPU last (vandaar ook de vitrualisatie beweging) maar wel een warmte probleem en daar kan de ARM architectuur flinke voordelen brengen.

De huidige ARM cpu's zijn idd juist interessant voor lichte router/webserver-achtige toepassingen, en niet voor databases.

ARM servers worden de toekomst (als x86 zo traag vooruit blijft gaan). Daarna zal het ook voor desktops/laptops gebeuren (opnieuw als Intel de markt blijft verstikken).

Je doet alsof W8 volledig overgaat op ARM. Lees je in gast.

Er komt ook gewoon een x86 versie van Windows 8 waar dus wél alle 'legacy' applicaties op zullen kunnen draaien.

De titel van dit bericht is gewoon weer telegraaf-achtig, "ARM-versie Windows 8 zal geen legacy-apps kunnen draaien' was beter geweest.

Intel die tegen concurerende architectuur ARM aan het schoppen is, de angst zit er goed bij ze in.

Maar wel 1 punt, ARM is niet native x86, dus oudere applicaties kunnen een probleem hebben als er buiten de winapi om is geprogged in assembler. Wat op zich voor ARM weer een puntje kan zijn om eens te denken aan misschien virtualisatie.

Virtualisatie zit al in de Cortex-A15 die volgend jaar op de markt zou moeten komen. En het lijkt me dat Microsoft bezig is aan een manier om oude Windows-programma's te draaien op ARM; door middel van een emulator o.i.d. Want waarom anders heeft MS een instructieset-licentie op ARMv7?

Windows CE/Windows Phone?

En waarom heb je dan een licentie op de instructieset nodig? Google, RIM en HP hebben die toch ook niet (vziw)?

Ik denk dat het allemaal wel mee zal vallen met de problemen die dit eventueel kan gaan veroorzaken. Apple heeft enkele jaren geleden ook een overstap gemaakt en dat heeft ze geen windeieren gelegd.

Persoonlijk denk ik dan ook dat het een goede keuze zal zijn om niet standaard legacy software te ondersteunen, maar desnoods via een compatibility-mode. Microsoft kan dan meer ingrijpende vernieuwingen doorvoeren in haar OS wat, mits goed uitgewerkt, alleen maar positief is voor de consument.

Verschil is wel dat van PowerPC naar Intel toen een 4x winst te behalen viel. Daarmee konden ze de (ongeveer 4x) vertraging van dynamische software vertaling (Rosetta) onder het tapijt moffelen totdat er native applicaties waren.

Van Intel naar ARM is eerder een 10x verlies in performance in goede gevallen.

Het is wel interessant om dit machtsspelletje te zien. MicroSoft probeert Intel tot consessies te dwingen, bijvoorbeeld lagere inkoopsprijzen of hardware wijzigingen die goed zijn voor hun eigen kas. Dus af en toe dreigt MicroSoft naar een andere partij te stappen. De afgeknepen partij begint daarna met alle mogelijke trucs die stap te ondergraven, zodat hun onderhandelingspositie weer wat gunstiger wordt.

Uiteindelijk vervalt dat hele ARM product natuurlijk. Hooguit wat embedded gebruik, om de schijn op te houden van een marktwerking, maar dit komt nimmer nooit niet op de desktop voor de massa.

Ik vermoed dat er deze keer toch wel een ARM versie van komt. Vooral de energiezuinigheid van de ARM heeft een voordeel voor bijvoorbeeld tables, en das een markt waar Microsoft graag in wil stappen (en persoonlijk mis ik ze daar ook wel).

Energiezuinigheid is steeds minder een issue: iedereen produceert al bijzonder efficiente processoren. Wanneer Windows 8 uiteindelijk uitgerold gaat worden is energiegebruik nog veel minder een bepalende factor.

Je hoeft er niet al te veel theorieen op los te laten. Microsoft is gewoon een softwareboer, die zijn producten op de meest gebruikte cpu's wil draaien. Ze zijn geen cpu bakkers, en hebben weinig belang bij om exclusief aan 1 architectuur te hangen. Hoe moet MS nou weten wat uiteindelijk beter is? Dus zijn ze flexibel. Is x86 de beste, dan bouwen ze voor x86. Doet ARM een gooi naar de desktop? Gewoon een Windows versie voor ontwikkelen, en kijken hoe het gaat. Hebben ze bij Itanium en DEC-Alpha ook gedaan (alleen braken die architecturen juist niet door).

[Reactie gewijzigd door Dreamvoid op 18 mei 2011 14:05]

Logisch van Intel om te zeggen, zij willen natuurlijk dat iedereen gewoon x86/x64 SOC's blijft kopen bij hun ipv over te stappen op goedkope ARM chips.
Ik denk dat het nog wel meevalt, maar we moeten maar zien. MS kan ook altijd nog kiezen maar 1 soort ARM SOC's te ondersteunen.

Wij van Intel adviseren Intel processors.

Otellini stelt, en Intel vindt, maar wat raak. Eerst officele berichten voordat we er wat over kunnen zeggen.