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.

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

Reacties (90)

[Ackermans1973]

Wat MS met Windows 8 wil is 1 OS voor allerlei verschillende hardware, desktop PC, tablet, GSM (Windows Phone 8?) en embedded.

Natuurlijk een briljante zet, het scheelt een berg schrijf en ontwikkelwerk, voor bedrijven die het afnemen ook, en wat ik verder zie, is dat het OS flexibeler zal zijn dan Windows 7 als het inderdaad dus op deze manier wordt opgebouwd.

Microsoft kan hiermee wel eens een heel grote slag slaan. Want een app ontwikkeld voor Windows 8 is ook op die manier multi-inzetbaar. Als office er komt in Windows 8 (SoC) versie,dan moet dat dus ook op Windows Phone 8 draaien, plus de Win8 tablets, waarbij onderling linken via de cloud voor ongekend flexibel werken zal zorgen.

Neem daarbij, alle Designed for Windows 8 (SoC) software zal diezelfde uitwisselbaarheid hebben. Open de Windows 8 appstore en deploy de software die je koopt meteen via de cloud naar je werknemers over de hele wereld. IDEAAL.

[Verwijderd]

Microsoft loopt wat dit betreft nog steeds 15 jaar achter op Linux!

[Ackermans1973]

Ja, en dat voelen ze ook heel goed he??? Wat is het marktaandeel Windows ook weer?? 92%...

[batteries4ever]

Tja, op zich een leuk idee, maar tot dusverre zijn de resultaten van MS voor alles buiten de desktop ronduit teleurstellend geweest.
MS had de smartphonemarkt zo omstreeks 2003 voor het oprapen, maar dat hebben ze grondig verstierd. Met name dus door bij de UI niet genoeg te differentieren tussen desktop en phone, tablet, whatever. Apple heet daar dankbaar gebruik van gemaakt!

Dit gaat alleen werken als de UI flexibel is t.o.v. kleine schermpjes, touch-technology goed ondersteund, ook met trage hardware nog acceptabel functioneert enz......... eerst zien en dan geloven!

[jip_86]

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

[g4wx3]

volgens mij gaan die VEEEEEEL te traag zijn, om dat logge windows vooruit te krijgen

[Verwijderd]

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).

[Verwijderd]

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.

[Verwijderd]

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 Verwijderd op 25 juli 2024 18:52]

[xyp]

[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...

[PPie]

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

[xyp]

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...

[MSalters]

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.

[michel2506]

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.

[Dreamvoid]

Hierdoor zullen een hoop lekken die in windows kunnen zitten, niet direct ook in de ARM versie opduiken.

Nee, er komen nieuwe lekken bij. En een simpele recompile voor ARM van alle libraries fixt niet automatisch je bugs.

[MSalters]

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.

[mkools24]

Dat maken ze dan wel goed met een GPU die 400W gebruikt

[Hyperik]

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.

[Reactie gewijzigd door Hyperik op 25 juli 2024 18:52]

[Xesxen]

Dan hebben we weer een OS voor op de HD2

[Hyperik]

Windows 8 op de HD2 yeah

Of op elke Android / symbian telefoon op aarde, Starcraft 2

[QQ2]

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?

[terror538]

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)

[QQ2]

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

[ReneX]

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.

[Soldaatje]

Er zal wel gewoon een speciale tablet versie van W8 komen die wel goed draait.

[Marc Rademaker]

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.

[-Vasa-]

Leuk idee, maar ik ben benieuwd hoeveel ontwikkelaars bereid gaan zijn al hun bestaande applicaties te hercompileren voor deze tragere architectuur.

En voor sommige projecten zal er dan altijd een vertraging zijn tussen wanneer iets beschikbaar is voor x86_32(/64) en wanneer datzelfde beschikbaar zal zijn voor ARM.

[Umbrah]

Het zal wel meevallen, veel is al .net en/of managed code. Misschien niet voor alles, maar in ieder geval wel veel. Laat MS dan maar zorgen voor een directX library die hetzelfde werkt. Als je een keer de tijd over hebt: probeer C# plus XDA eens, er zit daar een demo/tutorial platform game in. Natuurlijk wel ERG rudimentair, maar hij is qua code identiek voor zune, xbox en Windows, waar de dpi en target framerate voor de zune en de controls de enige verschillen zijn.

[terror538]

ik denk dat de ontwikkelaars die applicaties maken die interessant zijn om op arm te draaien dit wel zullen doen. Het meeste van de software (en zeker het wat oudere spul) is helemaal niet zo interessant om op je mobiel te kunnen draaien.
En voor de rest: open source

[Verwijderd]

Dus dezelfde Windows 8 die ik straks op mijn pc draai draait precies hetzelfde ook op mobiele telefoons?

[Marc Rademaker]

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 25 juli 2024 18:52]

[dmystic]

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

[humbug]

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.

[Blokker_1999]

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.

[MSalters]

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+.

[.oisyn]

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.

[Antipater]

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.

[kidde]

Vermoedelijk met emulator, of 'vooraf'-software-vertaler.

[DieDubbelJoe]

Maar ja, een trage processor én emulatie; dan wordt het verschil met native x86 wel hééél groot

[Biersteker]

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.

[Verwijderd]

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?

[svenk91]

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.

[Verwijderd]

In de trent van windows CE of windows home basic/premium?

[TheSiemNL]

Of IOS 4.2 op een iPhone 3g. Wat is dat traag.

[Hyperik]

Tablets hehe

[tweeny]

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?

[Caelorum]

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.

[MSalters]

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.

[analog_]

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 25 juli 2024 18:52]

[terror538]

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.

[Verwijderd]

Als MS nog enigszins wil meespelen op de moderne hardware-markt, die gedomineerd wordt door Smartphones & tablets dan kunnen ze nog 'n beetje marktaandeel terugsnoepen.

Al denk ik wel dat ze de strijd op voorhand verloren hebben, aangezien Apple & Google al 'n te grote voorsprong hebben. Vooral Android is aan 'n ongekend snelle opmars bezig. Zowat iedere fabrikant van betekenis heeft nu minimaal 1 Android produkt in z'n programma zitten. Om nog maar te zwijgen over de gigantische aantallen goedkope Chinese smartphones & tablets met Android, die nu al op de markt zijn & zullen komen in de nabije toekomst.

[Relief2009]

MS kan heel goed concurreren. Niks liever dan al je Windows Programma's op je tablet kunnen gebruiken zonder dat je elke 2 uur moet opladen.

De UI moet dan echt geschikt zijn voor tablets.

[dpj789]

dit maakt gelijk het nvidea bericht van net duidelijk

[Cergorach]

Laat dit nu het eerste nieuws zijn van de CES waarbij ik daadwerkelijk iets heb van "WOW! Wat interessant!". Ik ben erg benieuwd!