Microsoft brengt Internet Explorer 10 voor Windows 7 uit

Microsoft heeft Internet Explorer 10 voor Windows 7 uitgebracht. De browser was al beschikbaar in Windows 8, maar heeft nu ook zijn weg gevonden naar Windows 7. Vista en XP worden niet ondersteund. Windows XP kreeg al geen update naar Internet Explorer 9.

Om Internet Explorer 10 te kunnen draaien is minimaal Service Pack 1 op Windows 7 vereist. Er zijn twee uitvoeringen van de browser te downloaden; een 32bit- en een 64bit-editie. Opvallend is dat de 64bit-download niet twee verschillende browsers installeert. Voorheen werden er op 64bit-edities van Windows aparte 32bit- en 64bit-versies van Internet Explorer geïnstalleerd.

Volgens taakbeheer worden er bij het starten van IE10 op een 64-bit versie van Windows 7 twee iexplore.exe-processen gestart: een 32bit-browserscherm en een 64bit-'Internet Explorer 10 Manager'. Voor iedere volgende tab start de browser een nieuw 32bit-proces op. Via een registertweak kunnen browserschermen ook in 64bit modus werken. Als add-ons geen 64bit ondersteunen, kan dit volgens Microsoft echter tot compatibiliteitsproblemen leiden.

Internet Explorer 10 biedt volgens Microsoft betere ondersteuning voor html5 en css 3. Ook kan de browser beter omgaan met touchbediening. De browser is dan ook vooral ontwikkeld met het oog op gebruik in het op touch-georiënteerde Windows 8.

Reacties (153)

Waarom veranderd mijn hele Windows thema als ik IE10 installeer?!
Net nu ik weer vertrouwen krijg in IE gebeurt er dit, ongelofelijk!


Edit1
Aero Peek blijkt eruit te liggen door IE10
Het ergste is nog dat dit probleem al bekend was!
(recovery terug naar IE9 blijkt bij mij niet te helpen)

Ik wordt hier zo moe van, werkelijk waar.
Nu maar hopen dat ze snel met een fix komen,
voordat ik mezelf opvreet van frustratie.

Alle suggesties zijn welkom


Edit2
@Carsten
Gelukt, bedankt voor de tip!

Nu hoop ik dat de update niet elke
keer terugkomt via Windows Update.


Edit3
Hij is terug!
En zo krijg je hem permanent weg.

[Reactie gewijzigd door Mative op 28 februari 2013 18:13]

Je moet de volgende windows update even deinstaleren: KB2670838 en daarna is je aero weer terug!

Zie ook: http://answers.microsoft....86-4ca8-b28e-b2deb619a5b1

[Reactie gewijzigd door Carsten op 27 februari 2013 02:05]

Ik draaide al een tijdje IE10 om mee te testen. Het viel mij op dat er een opacity glitch van heb ik jou daar in IE10 zit. Het ligt niet aan de code want de andere browsers hebben daar geen last van (ook eerdere versies van IE niet). Het kan voorkomen tijdens een slideshow of in en uit faden met jQuery (dus heeft te maken met opacity).

Tot mijn grote verbazing zit dit probleem er nog steeds in. Kom er net achter dat er een verband bestaat uitfaden en iets ophalen via ajax. Bijvoorbeeld bij een slideshow en er wordt een plaatje opgehaald en terggelijktijd uitfaden dan krijg je de glitch (van heb ik jou daar). De glitch ziet er uit als witte knipperende vlakken, afhankelijk van hoe snel je uitfade (of iets infade). Is het plaatje eenmaal binnen dan komt het niet meer voor, alhoewel.....soms weer wel..... Je kunt het bijvoorbeeld zien op deze website: http://www.meezingeninrotterdam.nl/
Klik op het vergrootglaasje in het menu en zie het gebeuren.....

Dus ben benieuwd of ik nog meer tegenkom. Wel vind ik de nieuwe aanpak van MS een verademing. Ben al gestopt met het volledig ondersteunen van niet HTLM5 en CSS3 browsers als IE7 en IE8 en dat scheelt een hoop werk, alhoewel, je moet de bezoeker wel vertellen waarom het er minder goed uitziet.

[Reactie gewijzigd door codebeat op 26 februari 2013 23:48]

Ik snap niet zoveel van de technische dingen die je schrijft, maar het doet me denken aan de effecten die ik krijg bij het tikken van teksten in een reactieveldje voor een blog o.i.d.; de tekst corrupt volledig af en toe, en de weergave flikkert. Niet constant, maar wel herhaaldelijk. Ik heb daar alleen last van in IE10 (onder Win8); onder Win7 heb ik nog niet getest. Helemaal lekker werkt die browser dus inderdaad nog niet. Een en ander kan natuurlijk met de achterliggende grafische architectuur te maken hebben; misschien kunnen veel van dit soort problemen in drivers van grafische kaarten opgelost worden.

[Reactie gewijzigd door Buggle op 27 februari 2013 10:48]

Geen probleem hier (Win8 en IE8 desktop)

Nog steeds geen WebGL-ondersteuning, ondanks ANGLE: https://code.google.com/p/angleproject/ (binnenkort geschikt voor Direct3D 11).

MS heeft (imho terecht) beargumenteerd dat WebGL erg onveilig is. Het geeft vrijwel directe hardware access, met alleen de driver als veiligheid optie. Drivers zijn echter niet met het veiligheidsoogpunt ontworpen, waardoor het dus heel goed kan dat dit problemen geeft wanneer websites hier toegang to hebben. DirectX is een betere optie aangezien dat als een extra laag vormt.

Zie: http://blogs.technet.com/...l-considered-harmful.aspx

[Reactie gewijzigd door EvilWhiteDragon op 26 februari 2013 15:48]

Ook directx zou vermoedelijk niet echt veilig zijn als je dat direct kon aanspreken vanaf een internetpagina.

Dan spreek je nog steeds alleen DirectX aan, en niet de low-level OEM drivers zoals dat nu blijkbaar bij WegGL gebeurt.

Dan spreek je nog steeds alleen DirectX aan, en niet de low-level OEM drivers zoals dat nu blijkbaar bij WegGL gebeurt.

Met alle respect, maar waar haal je die onzin vandaan? WebGL is een Javascript API bovenop OpenGL ES 2. De browser heeft hier volledige controle over en kan dus alles controleren. Bovendien maken Chrome en Firefox op Windows gebruik van ANGLE, dat OpenGL ES 2 implementeert via Direct3D 9 (en binnenkort is het ook klaar voor Direct3D 11). ANGLE is open source en veiligheidsproblemen kunnen zeer snel aangepakt worden. Dat zijn dus heel wat lagen tussen WebGL en de driver! Bovendien heeft Microsoft volledige controle over de Direct3D-laag.

En ze beschikken ook over WARP, een software-implementatie van Direct3D 11 met redelijke prestaties. Ze hoeven dus niet eens de GPU te gebruiken. Chrome heeft SwiftShader om op terug te vallen.

De browser heeft hier volledige controle over en kan dus alles controleren

Dat is echter niet waar.
WebGL kan gebruikt worden om binaire data naar de grafische kaart te sturen. Daar kan de browser vrijwel niets aan controleren anders dan de grootte van de hoeveelheid data.

Door die WebGL functionaliteit kan via bijvoorbeeld een lek in een grafische driver van nVidia, Intel of AMD worden geexploiteerd.
Iets wat nu vrijwel ommogelijk is omdat de data die aan de grafisch drivers wordt aangeboden door de browser wordt gegenereerd en niet rechtstreeks van het internet wordt opgehaald.

Probleem is dat het nog jaren zal duren voor het interessant wordt voor malwarebouwers en dan zijn er mogelijk al honderden miljoenen apparaten met een lekke grafische driver exploiteerbaar via webgl en zullen die niet altijd makkelijk te updaten zullen zijn.

WebGL kan gebruikt worden om binaire data naar de grafische kaart te sturen. Daar kan de browser vrijwel niets aan controleren anders dan de grootte van de hoeveelheid data.

Compleet fout. De data zit vervat in Javascript-objecten en de browser kan elke bit daarin controleren voordat het doorgestuurd wordt naar OpenGL ES 2. En in ANGLE kan dat nog een tweede keer gebeuren voordat de data wordt weggeschreven in Direct3D buffers.

Door die WebGL functionaliteit kan via bijvoorbeeld een lek in een grafische driver van nVidia, Intel of AMD worden geexploiteerd.

Geef eens een mooi voorbeeld van zo'n "lek" (en ja, bereid je er maar op voor dat ik zal bewijzen dat het even makkelijk te dichten valt als gelijk welk ander lek).

De browser kan wel elke bit controleren maar alleen als er iets te controleren valt.
En dat is waar het lastig is. Je kunt binaire grafische data niet controleren omdat er niks aan te controleren valt.
Dit heeft in het verleden ook tot stapels lekken geleid in bijvoorbeeld rendering elementen voor gifs en jpegs. Maar die elementen kon Microsoft zelf nog makkelijk patchen en zodra de exploit bekend was konden die bestanden de volgende dag al door malware scanners worden gedetecteerd,
Het niet kunnen controleren van inkomende data leidt nu nog steeds tot bergen lekken in bijvorobeeld PDF's en flashobjecten. De browser kan de data van de PDF of het flashobject wel bit voor bit controleren maar heeft geen infomatie of die data correct / veilig is. Toch is het nog mogelijk voor bijvoorbeeld malwarescanners om bijvoorbeeld PDF's te scannen op bepaalde malware patronen.

Bij data voor grafische drivers is het echter nog problematischer. De binaire malware data hoeft daarbij niet in een los (door malwarescanners scanbaar) bestand zoals een PDF te worden worden geupload maar kan volledig in een script worden samengesteld in een binair weggl data-element zodat het vrijwel ondetecteerbaar is. Verder zijn grafische driver moeilijker te updaten. in bijvoorbeeld een mobieltje vereist het een firmwareupdate en de meeste telefoons krijgen momenteel nooit een firmwareupdate of slecht 1 keer ooit

Misschien als malwarescanners de data tussen browser en grifische driver zouden kunnen scannen dat er dan een vergelijkbare beveiliging zou zijn maar dat is niet erg realistisch denk ik.

[Reactie gewijzigd door Anoniem: 80466 op 26 februari 2013 17:08]

De browser kan wel elke bit controleren maar alleen als er iets te controleren valt.

Dus je geeft toe dat je volledig fout was. Zeer nobel.

Je kunt binaire grafische data niet controleren omdat er niks aan te controleren valt.

Tuurlijk wel. Je kan bijvoorbeeld controleren dat de range van een index buffer binnen de grenzen van de vertex buffers vallen. Noodzakelijk voor de veiligheid, maar geen enkel probleem. Ook herschrijven we in ANGLE de shaders om binnen de grenzen van de constant buffers te blijven. Wederom geen probleem.

Dit heeft in het verleden ook tot stapels lekken geleid in bijvoorbeeld rendering elementen voor gifs en jpegs.

Alarm! Laat ons GIFs en JPEGs dan afschaffen!

Neen, dat is duidelijk niet de gewenste oplossing. Evenmin moeten we WebGL aan de kant schuiven omdat er zich lekken zouden kunnen voordoen. Dat is zo voor elke vooruitgang, en die lekken moeten gewoon gedicht worden. Er is niks in WebGL dat niet tot op de laatste bit gecontroleerd kan worden.

WebGL is veel beter afgebakent dan bijvoorbeeld ActiveX, waar Microsoft wel ondersteuning voor biedt. Flash maakt gebruik van ActiveX in Internet Explorer, en Flash ondersteunt Stage 3D, wat op zijn beurt gebruik maakt van Direct3D. Dus zeer bizar waarom Microsoft geen WebGL-ondersteuning zou willen aanbieden met behulp van ANGLE.

...kan volledig in een script worden samengesteld in een binair weggl data-element zodat het vrijwel ondetecteerbaar is.

Nogmaals onzin. Het wordt in z'n totaliteit door de WebGL API ontvangen. Hoe je het samenstelt in Javascript maakt geen zier uit.

Verder zijn grafische driver moeilijker te updaten.

Ja, en? Da's geen beveiligingsprobleem. Nogmaals, alles wordt gecontroleerd in de WebGL-laag.

De compositie maakt ook gebruik van de GPU. Dus gebruikers moeten sowieso een relatief stabiele driver hebben.

[Reactie gewijzigd door Anoniem: 77640 op 26 februari 2013 19:13]

Mwa, voor Firefox 8 was het nog mogelijk om een screenlogger te maken die de GPU buffer scande. Bij het alloceren van geheugen werd het oude geheugen niet gewist en daardoor kon het beeld van wat op het scherm van de gebruiker gerenderd werd dus gevonden worden.
Zelf heb ik wel eens met WebGL lopen kloten. Onder windows wil de driver nog wel eens vastlopen waardoor windows de driver moest herstarten. Onder linux gebeurde dit ook. Wat er precies vast liep weet ik niet helemaal, maar volgensmij de X server waardoor je die moest herstarten (rebooten was vaak simpeler)

Het is allicht weer een jaar verder en de boel zal allicht hier en daar wat verbetert en stabieler zijn, maar de argumenten die Microsoft aandraagt zijn wel degelijk gegrond. WebGL is gewoon niet heel veilig, ook al kan je er zeker leuke dingen mee doen.

Mwa, voor Firefox 8 was het nog mogelijk om een screenlogger te maken die de GPU buffer scande. Bij het alloceren van geheugen werd het oude geheugen niet gewist en daardoor kon het beeld van wat op het scherm van de gebruiker gerenderd werd dus gevonden worden.

Ja, en dat lek werd heel snel gedicht.

Ook simpele JPEG-ondersteuning kan zo'n lek bevatten door hergebruikt geheugen niet te wissen. Het punt is dat WebGL niet inherent onveiliger is. Er is niks dat oncontroleerbaar is.

Onder windows wil de driver nog wel eens vastlopen waardoor windows de driver moest herstarten. Onder linux gebeurde dit ook. Wat er precies vast liep weet ik niet helemaal, maar volgensmij de X server waardoor je die moest herstarten (rebooten was vaak simpeler)

Da's jammer, maar niet een probleem veroorzaakt door de browser. De browser moet wel zorgvuldig controleren wat er naar de GPU verstuurd wordt, maar als de GPU crasht bij perfect geldige data en commando's dan zit jij met een onstabiel systeem. Ook browsers die geen WebGL-ondersteuning bieden maken gebruik van de GPU voor de compositie!

Als jij een SSD hebt met een brakke driver, moet de browser daar dan ook rekening mee houden? Neen, er is duidelijk een afbakening van de verantwoordelijkheden. WebGL an sich valt veilig te ondersteunen. Als er daarbuiten nog problemen voorkomen, is dat een taak voor NVIDIA, AMD, Intel, etc.

...de argumenten die Microsoft aandraagt zijn wel degelijk gegrond. WebGL is gewoon niet heel veilig, ook al kan je er zeker leuke dingen mee doen.

Je moet goed onderscheid maken tussen de verschillende lagen. Je kan niet WebGL "niet heel veilig" noemen omdat jouw grafische driver crasht. Hetzelfde kan dan voorkomen bij eenvoudige compositie-taken, of een game kan je systeem crashen. Jouw systeem is in zijn geheel onbetrouwbaar zo lang je geen betere driver hebt, en dat kan je dus WebGL niet kwalijk nemen. Da's louter een API, en alles wat heen of weer gestuurd wordt kan gecontroleerd worden, minstens even goed als gelijk welke andere API die op gecontroleerde wijze functionaliteit beschikbaar maakt.

Trouwens, Microsoft is hypocriet: DOS vulnerability in Silverlight 5's 3D. Ook via Stage 3D in Flash is de GPU bruikbaar voor 3D rendering in de browser. Blijkbaar volgen ze dus hun eigen argumenten niet.

Why Microsoft and Internet Explorer need WebGL

Ja, en? Da's geen beveiligingsprobleem. Nogmaals, alles wordt gecontroleerd in de WebGL-laag

Dat is dus juist niet zo.
De inhoud van de binaire data kun jen iet controleren en de range van een buffer controleren door de browser die weggl implementeert klinkt wel veilig maar is in feite zinloos als het lek pas getriggerd wordt bij de grafische driver software.

In de webgl laag kan je enkel controleren dat de data voldoet aan de in webgl opgelegde beperkingen maar in webgl kun je niet controleren hoe de data door de grafische driver wordt verwerkt.

Bij normale rendering van webpagina's wordt de data voor de grafische drivers door de browserengine zelf gegenereerd en niet vanuit het internet aangeleverd. Bij WebGL gebeurt dat in feite wel en komt er door dde browser ruwe binaire data vanaf het internet tot bij de grafische drivers doorgeleverd die slechts beperkt is gecontroleerd.

De inhoud van de binaire data kun jen iet controleren...

"De browser kan wel elke bit controleren maar alleen als er iets te controleren valt."

Jouw woorden. En ja het klopt dat je moet weten waar je op aan het controleren bent, maar nu je woorden terugdraaien en zeggen dat de binaire data niet te controleren valt is pure onzin.

En dat gezegt zijnde, geldt het voor elke web-API dat je moet weten wat er moet gecontroleerd worden, om het veilig te maken. Een lek kan zich praktisch overal voordoen, maar als we daarom alle vooruitgang in technologie moesten tegenhouden zou het web maar een kale plek zijn. WebGL kan veilig ondersteund worden, want alles valt te controleren.

En ja, je systeem zou kunnen crashen als je grafische driver onstabiel is. Maar hoe is dat de schuld van WebGL? Dit is niet anders dan een probleem in het besturingssysteem dat uitgebuit wordt totdat het opgelost is. Er is duidelijk een afbakening van verantwoordelijkheden. Je browser kan niet anders dan er vanuit gaan dat de rest van je systeem zich in bruikbare toestand bevindt. Zelfs voor de eenvoudigste taken is dat een noodzakelijke aanname. Het feit dat grafische drivers doorgaans het minst betrouwbaar zijn, moet niet als excuus gebruikt worden om NVIDIA / AMD / Intel voor altijd slechte drivers te laten schrijven.

Trouwens, de browsers hebben wel degelijk blacklists en/of whitelists voor bepaalde driver-versies, om problemen heel snel te beheersen. Dus het is niet dat ze je aan je lot overlaten als je kwetsbaar zou zijn.

In de webgl laag kan je enkel controleren dat de data voldoet aan de in webgl opgelegde beperkingen maar in webgl kun je niet controleren hoe de data door de grafische driver wordt verwerkt.

Dat kan je net zo min voor de CPU. Kijk maar naar de TLB bug in AMD's eerste Phenom CPU. Die kon in theorie ook misbruikt worden om een systeem te doen crashen. Moeten browsers daar dan ook rekening mee houden? Is elke API onveilig zo lang we niet huis aan huis gaan om Phenom chips te patchen?

Neen, natuurlijk niet. Dus je kan ook WebGL niet de schuld geven van elk driver / firmware / hardware-probleem! Wat hier van belang is, is dat WebGL een ondoordringbare laag is waar alles te controleren valt dat een voor de rest stabiel systeem zou kunnen schaden. Dat is de vereiste die aan elke API wordt opgelegd voordat we die als 'veilig' bestempelen.

Bij normale rendering van webpagina's wordt de data voor de grafische drivers door de browserengine zelf gegenereerd en niet vanuit het internet aangeleverd.

Nogmaals onzin. Ten eerste, de compositie-engine (die ook in Internet Explorer van de GPU gebruik maakt) bepaalt niet de layout van de pagina. Die wordt in de pagina zelve aangeleverd of gegenereerd; data afkomstig van het internet dus. Ten tweede, de browser heeft even veel controle over die data bij zowel gewone compositie als bij WebGL. Het is niet de webpagina die de OpenGL (ES 2) of Direct3D commando's geeft, dat doet de bowser zelve door vertaling van WebGL commando's naar de onderliggende API.

Bij WebGL gebeurt dat in feite wel en komt er door dde browser ruwe binaire data vanaf het internet tot bij de grafische drivers doorgeleverd die slechts beperkt is gecontroleerd.

Larie. Zelfs de shaders worden tot op het kleinste detail gecontroleerd. Ze worden zelfs volledig geparsed en de AST wordt opnieuw uitgeschreven als ESSL, GLSL of HLSL. Niks wordt zomaar van de webpagina aan de grafische API overgedragen.

Met alle respect, maar waar haal je die onzin vandaan?

Met alle respect, die onzin haal ik uit het artikel waar EvilWhiteDragon naar linkte. Of het ook zo is: geen idee, vandaar mijn blijkbaar te subtiele gebruik van het woord "blijkbaar".

Ah, onzin gehaald uit een onzin-artikel, het is je vergeven.

Beter leesvoer: Microsoft's WebGL claims bashed by own employee.

Het geeft vrijwel directe hardware access, met alleen de driver als veiligheid optie.

Vrijwel alle browsers maken nu reeds gebruik van de GPU voor de compositie. Je kan een standaard webpagina schrijven die het de GPU en driver zéér lastig maken en mogelijks doet crashen. En hetzelfde geldt ook voor de CPU. Meerdere worker threads in Javascript, en je systeem reageert nog nauwelijks. "Directe hardware access" is een zeer relatief iets.

DirectX is een betere optie aangezien dat als een extra laag vormt.

Hoezo? WebGL gebruikt OpenGL ES 2, wat net zoals Direct3D een grafische API is en dus een "extra laag". Bovendien is de vertaling van WebGL naar OpenGL ook een extra laag waar alles gecontroleerd kan worden. En tot slot, ANGLE implementeert OpenGL ES 2 bovenop Direct3D!

Allemaal prima, maar een alternatief bestaat niet.
Hun verhaal kwam op mij over als een flauw excuus. WebGL is zeker wel veilig te krijgen.
Microsoft wil geen GL, ze willen DirectX. Ook strategisch gezien is het voor Microsoft onaantrekkelijk om 3D te supporten in de browser omdat ze dan een makkelijk alternatief geven om te werken in een ander OS. Want tsja.. waarom zou je Windows 8 kopen als alles toch al in de browser draait?

En over het maken van 3D in WinRT:
Zelfs 't maken van een simpele interface in WinRT is nog steeds veel te lastig en nauwelijks compensatie voor 't missen van de WebGL standaard.
Ze hebben een DirectX toolkit, maar die is C++ georienteerd en veel te technisch voor wat de meeste developers willen. XNA is eruit geschopt, waarom weet ik niet.
Er zijn wel .NET initiatieven als SharpDX en ANX, maar dat is allemaal third-party..

Overigens is Google de enige die een beetje goed bezig is. Hoewel... WebGL werkt nog niet in de mobiele Chrome. Het is echter wel mogelijk om via FireFox WebGL te draaien in android.

En Apple lijkt overigens sterk op Microsoft wat betreft WebGL ondersteuning. Van hun verwacht ik niet zoveel.

Eigenlijk zijn alle drie zwak bezig. Maar er is hoop: Zowel Chrome als Firefox lijken binnen afzienbare tijd WebGL ondersteuning te geven op alle platforms!

Dan moet Microsoft z'n pijlen niet richten op WebGL. Het is hun eigen software die ze blijkbaar niet vertrouwen.

Google vertrouwt het blijbaar wel, en ze hebben niet eens controle over Direct3D. Ze zorgen gewoon dat hun WebGL naar OpenGL ES 2 vertaling veilig is, en sponsoren ANGLE waardoor ze ook daar heel snel kunnen ingrijpen.

Microsoft heeft niet twee maar drie lagen software om te zorgen dat het veilig is...

WebGL is geen standaard, dus laat het er maar netjes uit.

WebGL is wel degelijk een standaard.
https://www.khronos.org/registry/webgl/specs/1.0/

WebGL is wél een standaard. Het is echter geen noodzakelijk onderdeel van de HTML5-standaard. HTML5-implementaties zonder WebGL-ondersteuning zijn dus perfect standaard, maar dat betekent niet dat WebGL zelf geen standaard zou zijn.

Browsers die wel WebGL-ondersteuning aanbieden, wijken geenszins af van de standaard.

EDIT: bedoeld als reactie op Loller1.

[Reactie gewijzigd door Anoniem: 77640 op 26 februari 2013 17:56]

Je bedoelt die standaard die nog steeds niet definitief is? dan is het dus ook nog geen standaard..

Een standaard wil niets anders zeggen dan dat de meerderheid het erover eens is om iets op een bepaalde manier te doen. Of dat een officiele of definitief gepubliceerde 'standaard' is zegt daar niet zoveel over. Ja, de kans wordt vergroot dat alle implementaties uiteindelijk hetzelfde zijn/kunnen zodra er een officiële standaard is met het label definitief, maar in de praktijk zegt dat niet zoveel.
Sterker nog, je ziet heel vaak dat dergelijke standaarden juist implementaties in de praktijk volgen, of zelfs dat de implementaties in de praktijk zo'n standaard volledig links laten liggen om wat voor reden dan ook.

In zekere zin had je bijvoorbeeld ten tijde van IE5/6 gewoon bepaalde dingen die MS erdoor gedrukt had; dat was dan 'de standaard'. Hetzelfde geldt voor DOC(X) dat is ook 'de standaard'.
In de (OV) telematica heb je bijvoorbeeld TPEG wat nu al bijna een decennium de standaard is, maar zo goed als geen enkele reizigersapplicatie gebruikt het. Zelfde geldt voor navigatiesystemen; TPEG is intermodaal. Het blijft allemaal het hopeloos beperkte en verouderde RDS-TMC gebruiken.
Aan de productiekant heb je tegenwoordig het europawijde standaard SIRI voor de uitwisseling van real-time timetables in het OV, maar die wordt ook practisch nergens echt gebruikt. In Duitsland zijn ze allemaal bezig met VDV, waar SIRI op gebaseerd is, maar uitegerekend in de USA zijn de eerste pure SIRI implementaties onderweg - terwijl de standaard alleen op Europa gericht is!

Jawel, een standaard in progess is nog steeds een standaard. Zoals HTML5 ook een standaard is die nog niet af is maar wel al deels geimplementeerd is in browsers, en volop gebruikt wordt door ontwikkelaars.

Je bedoelt die standaard die nog steeds niet definitief is? dan is het dus ook nog geen standaard..

WebGL 1.0.1 is af. WebGL 1.0.2 zit in z'n ratificatie-periode. WebGL 1.0.3 is in beta. En hoewel dit nog niet bevestigd is, zou het kunnen dat er een WebGL 2 op komst is op basis van OpenGL ES 3.

WebGL is dus wel degelijk definitief. Dat men nog druk bezig is met het verfijnen en uitbreiden van de specificatie wil niet zeggen dat het niet al een standaard is. Nogmaals, 1.0.1 is af en zal niet meer veranderen.

En zo zorgt Microsoft er altijd voor dat er een sleur in technologie komt en de browsers weer eens niet vooruit gaan. Het is gelukkig niet meer IE die bovenaan staat. Anders zag het web er veel somberder uit.

Dat hebben ze anders wel met IE6 gedaan, en toen was het ook niet goed.

ik denk dat ik nog even lekker bij ie9 blijf.
alles is instant en kan dus niet sneller worden en verder heeft ie10 het ook geen nieuwe features.
dus waarom ugraden als alles goed werkt en zeg niet beveiliging ik heb namelijk in de afgelopen 10 jaar maar 2x een virus of spyware gehad wat niet door mezelf kwam maar door een fout in de browser en dat was snel opgelost dus security is overrated speciaal omdat de fixes vaak pas komen als het al te laat is.
en 150 of 250 ms in een benchmark wie intereseerd dat nou het voeld als instant en dat is wat boeiend is.

Geen nieuwe features? Niet direct zichtbaar voor bezoekers wellicht, maar onder de motorkap ondersteunt IE10 veel beter HTML5 en CSS3 waardoor ontwikkelaars betere sites kunnen bouwen, en die zullen dan voor de verandering een keer ook echt werken in IE. Daarnaast is de browser veel sneller.

leuk betere html5 ondersteuning maar hoeveel word dit nou gebruikt.
mjn nieuwe videokaart ondersteund straks tesselation ook beter maar zolang games het niet gebruikt is het geen feature.

Juist de hoofdreden dat HTML5 nog niet ten volle gebruikt kan worden is Internet Explorer. Dat nu ook Internet Explorer aan boord is, is alleen maar goed nieuws, dus HTML5 gebruik zal toenemen.

Waarom updaten scheelt straks weer een update met windows update, verder werkt ie10 gewoon goed onder windows 8 en de test versie onder windows 7 dus waarom niet.
Verder met goed bedoel ik die 1ne keer in een maand dat ik ie een keer open

Wellicht voor betere compatibiliteit? Beetje de hoofdreden om een browser te updaten naast de bugfixes - zeker ie.

Je kan niet op IE9 blijven zitten, tenzij je die tool gebruikt om de IE10 update te blokkeren of Windows Update hebt uitgeschakeld. IE9 gebruikers zullen de IE10 update namelijk automatisch geïnstalleerd krijgen.

Ik heb IE 10 al enige tijd getest en mijn bevindingen zijn niet al te positief. Het is wel weer een aardige stap vooruit ten aanzien van IE 9.0. Maar het valt me op dat er nog steeds niet goed omgegaan wordt met bepaalde web elementen. Sterker nog, sommige webelementen worden niet eens ingeladen waardoor het af en toe kansloos is met IE 10 op sommige webpagina's.

Ik ben zelf overgestapt op Chrome nu, niet omdat ik wou, maar omdat ik geen andere keus had (Firefox is voor ontwikkelaars imo, en de rest is niet benoemswaardig in mijn ogen)

Je bedoelt dat de betreffende website zich gewoon niet netjes aan de 'standaard' houdt.. vergeet ook niet dat op dit moment 'HTML5' nog steeds niet definitief is en nog veel vendor-prefixen gebruikt worden.. Webdevelopers beginnen zelf juist erg lui te worden door hun sites niet te testen meer op andere browsers want ze denken dat hun favoriete browser Chrome HTML5 perfect de standaard ondersteund (THINK AGAIN)..

Maar het valt me op dat er nog steeds niet goed omgegaan wordt met bepaalde web elementen. Sterker nog, sommige webelementen worden niet eens ingeladen waardoor het af en toe kansloos is met IE 10 op sommige webpagina's

Welke webelementen?
Geef eens een wat voorbeelden voorbeeld uit de praktijk van de webpagina's die je bedoelt

Ik weet niet exact hoe het betreffende element heet. Als ik bij www.battle.net inlog en vervolgens via een HTTPS site gelinked wordt naar een RSA token popup scherm blijft de inhoud leeg. Dat element dus.

Waarschijnlijk zijn zulke dingen het probleem:
<!--[if IE]>
of te wel, de website houdt rekening met oude IE browsers, en heeft daarvoor andere css, of andere javascript. Bij IE10 hoeft dat vrijwel niet meer, en verpest je alleen de layout daarmee.

Nope, IE10 heeft geen conditional comments meer

Vanwege bugs op 1 website vind jij een browser dus slecht?

Waarom zou Firefox enkel voor ontwikkelaars zijn? Integendeel, recente versies van Firefox focussen zich heel erg (imo té) hard op "de gemiddelde gebruiker" en verliest de power user uit het oog.

is deze browser veel sneller?

Test het zelf gewoon even uit:
http://www.webkit.org/perf/sunspider/sunspider.html
http://ie.microsoft.com/testdrive/Performance/PenguinMark/
http://ie.microsoft.com/t...brotExplorer/Default.html

Bedankt! Ik heb het getest met SunSpider 0.9.1

IE10 = 167.4ms
Opera 12.14 = 259.8ms
Safari 5.1.7 = 315.0ms
FF 19 = 282.5ms
Chrome 25 = 216.0ms

Wat een verschil!

Ik scoor met sunspider FF18 : 145ms.
Tweede run 157,6ms.

Is nogal een verschil met jouw score? Waar ligt dat aan?

De machine waarop je de test uitvoerd heeft ook invloed.

Geen idee. Ik heb een FX-6100 met 12GB DDR3 en Samsung 830 SSD met een 120Mbit zakelijke ziggo abbonement. Volgens speedtest een ping van 5ms en 119.8 down en 9.8 up.

Ik heb wel FF19 en geen FF18. Mijn IE10 is 64-bit.

[Reactie gewijzigd door Lisadr op 26 februari 2013 17:43]

Je moet de verschillende browsers op dezelfde machine draaien.

Dus de resulaten van IE10 op PC1 niet vergelijken met die van Firefox op een andere PC.

Dus tot nu toe zijn enkel Lisadr's scores relevant (voor benchmarking; geen idee of deze testen enige real-world relevantie hebben natuurlijk).

[Reactie gewijzigd door Armin op 26 februari 2013 19:39]

ter aanvulling

ik heb ook de SunSpider 0.9.1 test gedaan

Opera 12.12= 160,7ms
Opera 12.14= 157,3ms
IE9 32-bits = 625,9ms
IE9 64-bits = 622,8ms
safari 6.0.2 (osx-versie): 290,6ms

[Reactie gewijzigd door dennisdennis12 op 26 februari 2013 16:27]

Heb ook getest en haal met sunspide 0.9.1 :
Total: 100.5ms (ie10)
Total: 135.1ms (chrome laatste iets met 25 geloof ik)

Andere test gebruikt Futuremarks Peacekeeper, en IE is inderdaad sneller, maar kan kennelijk minder:

Palemoon 19.0.1 64-bit
http://peacekeeper.future...key=6jqM&resultId=3012300
1102
HTML5 Capabilities 5/7

IE 10 64-bit
http://peacekeeper.future...key=6jqZ&resultId=3012326
2618
HTML5 Capabilities 3/7

Beide natuurlijk gedraaid zonder add-ons en dergelijke draaiend.

Ik heb heel veel add-ons op mijn browsers draaien, echter begrijp ik je palemoon score niet. Btw.. Opera rocks met jouw voorgestelde testorgaan ...


palemoon 15(score 2219): http://postimage.org/image/es85sn74j/
ie10(score 2614): http://postimage.org/image/ver5bdrdz/
opera(score 3414): http://postimage.org/image/qj41xj6yt/

Sunspider is tegenwoordig een heel, heel erg slechte test om de performance van een browser te testen. Allereerst zijn de uitvoeringstijden zó kort, dat de compiletijd een significante invloed hebben (wat natuurlijk minder boeit bij echte webapps). Ten tweede is Sunspider ontworpen om wat berekeninge te doen, maar dan het resultaat te negeren. Dit triggert in IE dead code elimination, maar vertelt niets over uitvoeringstijd.

Ik snap je reactie niet helemaal, hij onderbouwt toch waarom hij Sunspider niks vindt?

Ook al ben ik vóór IE, en zeker niet anti-Microsoft, is het testen van een webbrowser waarbij 2 van de 3 voorgestelde tests door MS zelf aangeboden wordt niet heel objectief...

Die tests geven geen radicaal andere cijfers dan de niet-Microsoft tests, dus is dat echt een ramp?

Datzelfde kun je ook over WebKit's sunspider en Google's V8 benchmark zeggen.
IE10 is snel ... verder maakt iedereen een benchmark met de punten die voor hen belangrijk zijn.

Hij ziet er visueel net als vroeger niet snel uit, maar je merkt een heel groot verschil met de vorige versie van IE wanneer je surft.

krijg je deze versie via automatische updates of moet je hem zelf installeren?

Je kunt hem handmatig installeren. Vaak komt hij later alsnog als optionele update, maar dat duurt vaak iets langer. Als je hem nu meteen wilt, zul je hem zelf moeten installeren.

Nou, gaat me meer om mijn klanten. Ik heb een systeem wat gebouwd is met ondersteuning op basis van IE9. Er zijn geen afspraken gemaakt dat we het systeem constant up-to-date houden voor latere Internet Explorer versies.

Als IE10 nu automatisch geinstalleerd word, dan werkt het systeem mogelijk niet correct meer en heb ik een klant aan de telefoon hangen

Dan zou ik in actie komen, want over een aantal maanden is het dus mogelijk dat 'ie met een automatische update binnenkomt. Tenzij je automatic updates hebt uitgeschakeld op dat systeem natuurlijk.

Ben inmiddels al de nodige mensen aan het aanschrijven.

Om hem gewoon te updaten uiteraard en als er iets niet werkt dat door te geven

Als je de release preview geinstalleerd hebt is het een important update, en wordt 'ie dus (met standaard Windows Update instellingen) automatisch geinstalleerd. Anders is het een optionele update en moet je 'm dus zelf selecteren binnen Windows Update voordat hij geinstalleerd wordt.

Blijkbaar wordt 'ie overigens in de komende maanden wel in steeds meer gebieden als "important" gemarkeerd, wat ertoe zou moeten leiden dat hij over een paar maanden wel automatisch binnenkomt, mocht je hem dan nog niet hebben.

[Reactie gewijzigd door Anoniem: 478159 op 26 februari 2013 16:19]

Internet Explorer 9 gebruikers zouden hem normaal gezien automatisch moeten krijgen, net als IE10 PP gebruikers.

Heh, de 64bit versie bevat alleen de 64 bit versie, maar als IE opgestart wordt, worden er zowel een 32bit als een 64bit variant opgestart?

Het lijk me niet zinvol een 64 bits versie te gebruiken van IE.
Die is vermoedelijk trager en neem veel meer memory in beslag.

Pale Moon test ik vaak op snelheid, en de 32bitter is een stuk sneller dan de 64bitter. Bij alle versies.

IE32 heb ik niet getest, maar het zou me inderdaad niet verbazen als hetzelfde verhaal opgaat.

Houd je hier dan ook rekening mee?

Benchmarks invariably perform their tests in "tight loops", which means a small bit of code that is looped through rapidly many times. If properly calibrated (meaning looping through it without performing anything to get a "reference" value) this kind of tight loop can quite efficiently measure how well a specific, single instruction is executed. This is, however, not the kind of behavior you'd encounter when browsing webpages, where you would normally have a large number of different instructions one after the other. Testing in tight loops may therefore not give you any sort of conclusive result; it can only be seen as an indication of what overall browser speed could be if not influenced by other factors.

This also brings me to testing 32-bit and 64-bit browsers against each other. Because of these tight loops and functions in a browser usually not using 64-bit address space or big variables, the benchmarks won't specifically test what a 64-bit browser is strong at. Tight loop testing also brings in another factor: because a 64-bit processor uses twice as large registers, you are inherently pushing twice as much data through your hardware. Tight loops are specifically sensitive to the amount of data that is passed to and from the processor, and you should always take this into account when comparing test results between a 32-bit and 64-bit browser. You can expect 64-bit browsers to score (quite a bit) lower than their 32-bit counterparts; this doesn't mean that the browser is slower, though, just that the test isn't measuring the full capacity of the browser.

[Reactie gewijzigd door Buggle op 27 februari 2013 08:51]

En waarom vermoed je dat?

Pointers groter & Object alignment leiden tot cache pollution. Kans is vrij groot dat 64 bits niet sneller is dan 32 bits. Nog los ervan dat de browser ook vaak op input wacht van de gebruiker en dan is het zowiezo lood om oud ijzer welke versie je gebruikt.

x86-64 heeft twee keer zo veel registers (16 i.p.v. 8, waarvan twee doorgaans gereserveerd voor de stack). Ondanks een beetje extra geheugengebruik is 64-bit x86 code daarom vaak sneller dan 32-bit.

Wel, op een 64-bit van Windows 7, kan je zelfs de 32-bit niet installeren.

Je hebt twee links, de 32-bit link en de 64-bit link.

Eerst de 32-bit link geprobeerd, programma zegt me, dus IE, dat OS niet ondersteund wordt, met de 64-bit geen enkel probleem

En zo te zien gaat hij erg rap hier

Sinds IE9 heb ik weer veel vertrouwen in Internet Explorer. Windows 7 en IE9 zijn bij mij altijd stabiel. Kijken hoe IE10 is.

Ik draai IE10 al een tijdje op Windows 7 en ik moet zeggen dat deze uitermate goed werkt en minder compatibiliteitsissues heeft laten zien dan vorige versies. Ik heb nogal wat consoles geopend, dagelijks, die nogal kieskeurig zijn qua browsers, maar IE10 is mij op geen enkel moment tegengevallen.

Mijn eerste indruk is dat het heel snel is en dat ie minder moeite heeft met zware websites. Daarnaast ben ik erg blij dat IE10 zelf automatisch kan upgraden!

Misschien onder de motorkap een stuk beter idd. Echter vind ik de tabs nog steeds lelijk en niet ruimte efficient allemaal. Die adresbalk "naast" de tabs vind ik ongebruiksvriendelijk. Zelf vind ik, en dan niet kijkend naar de render engine en alles toch Chrome wel de meest lekkerste werken qua UI.

Daarom is er dan ook al sinds IE9 RC een optie om de tabbladen er onder te weergeven...

Die adresbalk "naast" de tabs vind ik ongebruiksvriendelijk

Je weet dat je die tabs ook onder de adresbalk kunt plaatsen?

Ik moest zelf erg wennen aan de integratie van zoeken en adres. Ik vind het nog steeds een beetje kunstmatig, maar het is inderdaad wel efficienter qua ruimte. Op een tablet pakt die integratie wel goed uit, maar op de desktop minder naar mijn smaak.

Mijn ervaringen met IE10 onder windows 8 zijn anders wel erg gemixt. Hij is beduidend sneller dan IE9, maar ik merk toch wel echt vaak compatibiliteitsproblemen. Een voorbeeld wat ik me nu zo kan bedenken is wat er gebeurde toen ik de timer van mijn router probeerde in te stellen (een Vodafone Easybox die in Duitsland uitgeleverd worden). In plaats van de gewoon bij één entry de tijd te veranderen zat ik ineens met een waslijst aan rare tijden, die zelfs in 113:563 u ofzo erin stonden. Ik ben uiteindelijk bijna een uur bezig geweest al die overbodige entries eruit te halen. Dat ging voorheen met alle browsers die ik heb gewoon vlekkeloos. Ik heb ook al redelijk vaak de compatibiliteitsmodus aan moeten doen voor websites. Ik hoop in ieder geval dat dit zich wat gaat stabiliseren: ik kan me voorstellen dat developers nog niet zo de haast inzien een browser te ondersteunen die pas net uit is en niet echt een grote userbase heeft. Dat verandert nu hij ook voor Windows 7 beschikbaar is.

[Reactie gewijzigd door Buggle op 27 februari 2013 08:38]

Hmm raar, ik heb een helemaal up-to-date Windows 7 x64 installatie, en toch download 'ie nog "required updates" tijdens de installatie.

Maar top dat 'ie er eindelijk is, webdevelopers kunnen dan nog iets langer met Windows 7 blijven rondlopen zonder testmachine met 8.

Dit zijn meestal nog updates die na de laatste patch ronden zijn uitgebracht of niet door Windows Update worden geïnstalleerd omdat de software die ze gebruikte (hier IE10) toch niet op de machine stond.