AWS

It sounds like Microsoft is going to deliver one more developer preview of Internet Explorer (IE) 9 before it rolls out the first public beta of its next-generation browser in September. View the full article

In this week's (late) mailbag, about my home swap this year in Europe, how you can tell if you have the new Hotmail, the best way to copy email messages from one service to another, about the phone functionality in Windows Phone, when will Exchange ActiveSync for Hotmail ever arrive, and photo sync in Windows Live Photo Gallery 2011. View the full article

While Microsoft’s mult-touch capabilities (and lack thereof) are in the news daily, the company’s speech engine and algorithms don’t often merit a mention. At the SpeechTEK conference in New York City on August 3, Microsoft officials attempted to explain what the Redmondians have coming in the voice recognition and synthesis space — without going so far [...] View the full article

Sure, Microsoft is selling almost one million copies of Windows 7 every day, but many of those sales are to consumers with new PCs. The big question for this release is business deployments. So nine months after Windows 7 arrived, how is Microsoft's latest OS faring with its biggest customer base? Pretty darn well, as it turns out. View the full article

Bulletin Severity Rating:Critical - This security update resolves a publicly disclosed vulnerability in Windows Shell. The vulnerability could allow remote code execution if the icon of a specially crafted shortcut is displayed. An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. View the full article

In the latest episode of the Windows Weekly podcast, Tom Merritt and I discuss Microsoft's record quarterly revenues, Windows Phone's best features and worst omissions, the return of the Slate PC, cheaper new Kindles, Microsoft's security tie-up with Adobe, and the proposed Google/Yahoo deal in Japan. We also held a live listener Q and A. View the full article

The latest Platform Preview Build includes two great interoperable features for working with the DOM – DOM Traversal and Element Traversal. These features provide web developers with simple, flexible, and fast ways of traversing through a document using the same markup across browsers. These features come in the form of flat enumeration, simplifying the DOM tree to an iterative list, and filtering which enables you to tailor the set of nodes you traverse. These features work with the same markup across browsers – you can try out any of the code here in the IE9 platform preview and other browsers. Without these features, finding an element of interest on a page requires you to do one or more depth-first traversals of the document using firstChild and nextSibling. This is usually accomplished with complex code that runs slowly. With the DOM and Element Traversal features, there are new and better ways of solving the problem. This blog post is a primer and provides a few best practices to get you on your way. I’ll start with Element Traversal, since it’s the simplest of the interfaces and follows familiar patterns for enumerating elements in the DOM. Element Traversal is essentially a version of DOM Core optimized for Elements . Instead of calling firstChild and nextSibling, you call firstElementChild and nextElementSibling. For example: [color= #0000ff]if[/color] (elm.firstElementChild) { elm = elm.firstElementChild; [color= #0000ff]while[/color] (elm.nextElementSibling) { [color= #008000]// Do work...[/color] } } This is faster and more convenient, saving you the trouble of having to check for text and comment nodes when you’re really only interested in elements. DOM Traversal is designed for much broader use cases. First, you create a NodeIterator or a TreeWalker. Then you can use one of the iteration methods to traverse the tree: [color= #0000ff]var[/color] iter = document.createNodeIterator(elm, NodeFilter.SHOW_ELEMENT, [color= #0000ff]null[/color], [color= #0000ff]false[/color]); [color= #008000]// This would work fine with createTreeWalker, as well[/color] [color= #0000ff]var[/color] node = iter.nextNode(); [color= #0000ff]while[/color] (node = iter.nextNode()) { node.style.display = [color= #006080]"none"[/color]; } The codepath above iterates through a flat list of all nodes in the tree. This can be incredibly useful since in many cases you don’t care whether something is a child or sibling of something else, just whether it occurs before or after your current position in the document. A big benefit of DOM Traversal is that it introduces the idea of filtering, so that you only traverse the nodes you care about. While nodeIterator only performs flat iterations, TreeWalker has some additional methods, like firstChild(), that let you see as much or as little of the tree structure as you want. The SHOW_* family of constants provides a way to include broad classes of nodes, such as text or elements (like SHOW_ELEMENT in the earlier example). In many cases, this will be enough. But when you need the most precise control, you can write your own filter via the NodeFilter interface. The NodeFilter interface uses a callback function to filter each node, as in the following example:

The August 2010 edition of my print magazine column looks at the Windows Server 2008 R2 and Windows 7 SP1 Public Beta, Windows Server vNext in 2012, Windows 2000 EOL, Small Business Server "7" and "Aurora", HTML 5 and the future, Microsoft Communications Server (MCS) "14", and Windows InTune. View the full article

I've gotten a lot of email about the recently released Window 7 Service Pack 1 (SP1) Beta, which is interesting because this update doesn't add a single meaningful new end user feature to Microsoft's popular new Windows version. Due in Q1 2011, Windows 7 SP1 is essentially just an update rollup, one that doesn't change the system's user experience at all. Here's what the install process is like. View the full article

With the success of Apple's iPad, the PC industry is going slate crazy. HP has two types of slate PCs on tap, one based on Windows 7 and one on WebOS. And Microsoft is going to carpet-bomb the market with different kinds of Windows, just to see what sticks. There's just one problem: Customers have already voted against Windows on slates. Why are we doing this again? View the full article

In this week's mailbag, whether you should buy a Zune HD or wait and see what happens, Windows Phone 7 tasks/to-do functionality, the HP slate returns (but was it ever gone?), Windows and product key types, Windows Phone 7 and Media Center interaction, and whether it's really going to take all summer for Microsoft to roll out the new Hotmail. View the full article

With Windows Phone 7, Microsoft is starting over from scratch with a deeply innovative new mobile platform that makes Apple's iPhone and Google's Android look tired by comparison. But in its rush to get Windows Phone to market quickly, is Microsoft releasing an unfinished product? And how fast will the software giant fill in the gaps? View the full article

You can download a fix for your problem here. DivX Support

In the latest episode of the Windows Weekly podcast, Leo and I discuss the Windows Phone technical preview in some detail, a zero-day Windows shortcut vulnerability, Xbox 360 Kinect pricing and bundles, and a new low-end Xbox 360 console. View the full article

The Reliability Monitor is well-hidden in Windows 7, but can be very useful if you want to find out what's going wrong with your PC. In addition to identifying the exact causes of reliability issues, it can often deliver fixes for those problems and, if not, alert you when such a fix does become available. View the full article

Available as an optional download, Windows Live Essentials 2011 is an application suite that includes a number of new versions of classic Windows applications, including Windows Live Mail, Photo Gallery, Messenger, Movie Maker, Family Safety, and more. And the 2011 version, currently in beta, is the best yet. View the full article

The real innovations in Windows Phone are seen in its interface, and its ability to connect so seamlessly with third party services and present the results not in siloed, iPhone-style app prisons, but inside of cohesive, panoramic experiences. The effect is breathtaking, and it's groundbreaking, and it's and something you have to see to fully appreciate. View the full article

When we first introduced our plans for Internet Explorer Platform Previews we said that “developers and people interested in standards and web development can try out new platform functionality and provide early feedback.” We are now getting such feedback on a daily basis and are using it to improve IE9. However, sometimes the impact of the feedback extends beyond just IE9. Here is the story of how some recent feedback regarding the third IE9 Platform Preview resulted in a correction to the new ECMAScript 5th Edition (ES5) standard for JavaScript. The ES5 standard became official in December 2009 and the third IE9 Platform Preview is the first widely distributed implementation of some subtle details of the ES5 specification. ES5 was designed to be highly compatible with existing websites and the Ecma International TC39 technical committee worked to avoid any non-security related changes that might break existing JavaScript code. However, perfection generally does not exist in the world of software so with the third IE9 Platform Preview we were very interested to see if any ES5-related compatibility problems with existing sites would show up. Soon after releasing this platform preview, we received reports that some web-apps that use the jQuery framework did not work correctly in the preview. We tracked the problem to a specific jQuery API method that in some cases passed a caller provided value to Object.prototype.toString without first checking if the value was null or undefined. Specifically, some calls to this jQuery method: isFunction: function( obj ) { return toString.call(obj) === "[object Function]"; }, failed with an exception: “TypeError: Object expected”. Further analysis showed that toString in the above code was the built-in method Object.prototpe.toString and that the failures occurred when isFunction was being called with undefined as its argument. Why does an exception occur in IE9 and not in previous versions of IE or other browsers? It is because the third IE9 Platform Preview in standards mode actually conforms to the ES5 specification for Object.prototype.toString. According to the prior editions of the ECMAScript specification, calling any built-in method using null or undefined as the this value passes the “global object” (in browsers this is the DOM window object) to the method as its this value.

Lost In Translation “Web design is 95% typography”. So much of the content produced and consumed on the web is text yet designers and users have been confined to a set of compatible fonts available across client operating systems. Escaping this typographical island has involved everything from cross-browser CSS workarounds, graphics-based solutions and even plug-ins, with trade-offs ranging from extra storage and bandwidth to reduced accessibility. As a result, typefaces have too often been one of the first casualties of the translation from Photoshop design mock-up to live web page. Not The Same CSS Solving this challenge required an interoperable CSS syntax to describe font resources. While IE added support for CSS2’s @font-face rule as long ago as 1997, the differences between this earliest of implementations and the far more recent ones supporting CSS3 Fonts have given rise to CSS design patterns built to ensure the same rule works for all users. A notable example is the bulletproof @font-face syntax developed by Paul Irish from Google, et al. But crafting a cross-browser @font-face declaration turned out to be half the problem. No Common Web Font Format Internet Explorer’s @font-face implementation supports EOT (Embedded OpenType) fonts, a compressed font encoding submitted to the W3C in 2008. Following WebKit’s lead in 2007, Mozilla and Opera added support for raw TrueType and OpenType fonts. Raw fonts work well if your fonts’ end-user license (EULA) allowed you to serve them from your web server. While this is true for many free fonts, this is not the case for the vast majority of commercial fonts. Web authors are thus effectively cut off from the richest font catalogs available. If they choose EOT they are able to license a number of commercial fonts for web use but only IE renders them. This leaves a challenge for the industry. The major browsers support two incompatible solutions and commercial font EULAs are generally incompatible with one of them.

The network plays a crucial role in the overall performance of a web browser. The best way to improve network performance is to minimize the volume of network traffic by using HTTP compression and taking advantage of the browser cache. We’ve made a tremendous number of improvements to the way that Internet Explorer 9 caches content to ensure that as many resources as possible are loaded from the cache. This post describes those improvements which are now available in the third IE9 Platform Preview which was released last month. Understanding Caching Let’s start with a quick refresher on how caching works in browsers. At a high level, web browsers make two types of requests over HTTP and HTTPS—conditional requests and unconditional requests. An unconditional request is made when the client browser does not have a cached copy of the resource available locally. In this case, the server is expected to return the resource with a HTTP/200 OK response. If the response’s headers permit it, the client may cache this response in order to reuse it later. If the browser later needs a resource which is in the local cache, that resource’s headers are checked to determine if the cached copy is still fresh. If the cached copy is fresh, then no network request is made and the client simply reuses the resource from the cache. If a cached response is stale (older than its max-age or past the Expires date), then the client will make a conditional request to the server to determine whether the previously cached response is still valid and should be reused. The conditional request contains an If-Modified-Since and/or If-None-Match header that indicates to the server what version of the content the browser cache already contains. The server can indicate that the client’s version is still fresh by returning HTTP/304 Not Modified headers with no body, or it can indicate that the client’s version is obsolete by returning a HTTP/200 OK response with the new version of the content. Obviously, conditional requests result in better performance than unconditional requests (because the server need not retransmit the entire file if the client’s version is fresh) but the best performance is obtained when the client knows that the version in its cache is fresh and the conditional revalidation can be avoided entirely. Extremely Long-Life Cache Headers While RFC2616 recommends that servers limit freshness to one year, some servers send Cache-Control directives specifying a much longer freshness lifetime. Prior to IE9, Internet Explorer would treat as stale any resource with a Cache-Control: max-age value over 2147483648 (2^31) seconds, approximately 68 years. With Internet Explorer 9, we now accept any value up to 2^63 for the max-age value, although internally the freshness interval will be truncated to 2^31 seconds. Vary Improvements The HTTP/1.1 Vary response header allows a server to specify that a fresh cached resource is valid for future reuse without server revalidation only if the specified request headers in the later request match the request headers in the original request. For example, this enables a server to return content in English with a Vary: Accept-Language header. If the user later changes their browser’s Accept-Language from en-US to ja-JP, the previously cached content will not be reused, because the Accept-Language request header no longer matches the request header at the time that the original English response was cached. With Internet Explorer 9, we’ve enhanced support for key Vary header scenarios. Specifically, IE9 will no longer require server revalidation for responses which contain Vary: Accept-Encoding and Vary: Host directives. We can safely support these two directives because: All requests implicitly vary by Host, because the host is a component of the request URL. IE always decompresses HTTP responses in the cache, making Vary: Accept-Encoding redundant. Like IE6 and above, IE9 will also ignore the Vary: User-Agent directive. If a response contains a Vary directive that specifies a header other than Accept-Encoding, Host, or User-Agent (or any combination of these) then Internet Explorer will still cache the response if the response contains an ETAG header. However, that response will be treated as stale and a conditional HTTP request will be made before reuse to determine if the cached copy is valid. Redirect Caching Internet Explorer 9 now supports caching of HTTP redirect responses, as described by RFC 2616. Responses with Permanent Redirect status (301) are cacheable unless there are headers which forbid it (e.g. Cache-Control: no-cache) and those with Temporary Redirect status (302 or 307) are cacheable if there are headers which permit it (e.g. Cache-Control: max-age=120). While this significantly improves performance, web applications that are misconfigured might not work as expected after this change. For example, we’ve found a few commonly-visited sites that use a pattern which looks like this: > GET / HTTP/1.1 < 301 Redirect to /SetCookie.asp > GET /SetCookie.asp HTTP/1.1 < 301 Redirect to / The site’s goal is to have the homepage determine if the user has a cookie set, and if not, send them to a page that sets the cookie. The problem is that the server has chosen a 301 for this task, and a 301 is cacheable. Hence, IE will simply redirect between these two cached redirects on the client (never again contacting the server) until the user gets bored and closes the browser. Notably, any version of IE would hit a redirect loop in the scenario above if the user had disabled cookie storage for the site in question. If your site makes use of redirects, you should ensure that it is configured to avoid redirect loops by ensuring that any redirect that relies upon side-effects (e.g. testing or setting a cookie) is marked uncacheable. HTTPS Caching Improvements A few months ago, I mentioned that Internet Explorer will not reuse a previously-cached resource delivered over HTTPS until at least one secure connection to the target host has been established by the current process. This can cause previously-cached resources to be ignored, leading to unconditional network requests for content that was already in the local cache. In IE9, the unnecessary cross-host HTTPS requests are now conditional requests, so the server can simply return a HTTP/304 Not Modified response for unchanged content. While a round-trip cost is still incurred, significant performance improvements are gained because the server does not need to retransmit the entire resource. Back/Forward Optimization For IE9, we’ve made improvements so that clicking the back and forward buttons results in faster performance. RFC2616 specifically states that a browser’s Back/Forward mechanisms are not subject to cache directives: History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents. In previous versions of Internet Explorer, when the user navigated back or forward, IE would check the freshness of resources if they had been sent with the must-revalidate cache-control directive, and in numerous other circumstances depending on how recently the resource was downloaded. In IE9, the INTERNET_FLAG_FWD_BACK flag behaves as described on MSDN, and IE will not check the freshness of cached resources when the user navigates Back or Forward. As a result of this optimization, Internet Explorer 9 can perform far fewer conditional HTTP requests when navigating with Back and Forward. For example, the following table shows the improvement when going Back to a typical article on a popular website: IE8 IE9 Improvement Back/Forward Navigation Request Count: 21 Bytes Sent: 12,475 Bytes Recv: 216,580 Request Count: 1 Bytes Sent: 325 Bytes Recv: 144,617 Request Count: -20 (-95%) Bytes Sent: -12,150 (-97.4%) Bytes Recv:-71,963 (-33.3%) Now, I mentioned that we ignore caching directives when navigating back and forward, so alert readers may be wondering why IE9 still makes one request when clicking Back on this site. The reason is that IE will not commit to the cache any uncacheable resource. An uncacheable resource is one delivered with a Cache-Control: no-cache directive or with an Expires date in the past or an Expires date not later than the Date header. Therefore, the browser is forced to redownload such resources when the user navigates Back and Forward. To improve performance and enable a resource to be reused in Back/Forward navigation while still requiring revalidation for other uses, simply replace Cache-Control: no-cache with Cache-Control: max-age=0. Unlike the other improvements in described in this post, back/forward optimizations are not visible in the Platform Preview build because it does not have a back button. Heuristic Cache Improvements Best practices recommend that web developers should specify an explicit expiration time for their content in order to ensure that the browser is able to reuse the content without making conditional HTTP requests to revalidate the content with the server. However, many sites deliver some content with no expiration information at all, relying upon the browser to use its own rules to judge the content’s freshness. Internet Explorer allows the user to configure what should happen when content is delivered without expiration information. Inside Tools > Internet Options > Browsing history > Settings, you will see four options: http://ieblog.members.winisp.net/images/EricLaw_CachePerfImprovements_1.png These four options have the following behavior: Every time I visit the webpage Any resource without explicit freshness information is treated as stale and will be revalidated with the server before each reuse. Every time I start Internet Explorer Any resource without explicit freshness information is validated with the server at least once per browser session (and every 12 hours thereafter in that session). Automatically (Default) Internet Explorer will use heuristics to determine freshness. Never Any cached resource will be treated as fresh and will not be revalidated. These options only control the browser’s behavior when content is delivered without expiration information; if the content specifies an explicit policy (e.g. Cache-Control: max-age=3600 or Cache-Control: no-cache) then the browser will respect the server’s directive and the options here have no effect. In earlier IE versions, the Automatic Heuristics were simple and only affected cached images, but IE9 improves the heuristics to match RFC2616’s suggested behavior: if the response does have a Last-Modified time, the heuristic expiration value SHOULD be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%. If Internet Explorer 9 retrieves a cacheable resource which does not explicitly specify its freshness lifetime, a heuristic lifetime is calculated as follows: max-age = (DownloadTime - LastModified) * 0.1 If a Last-Modified header wasn’t present in the server’s response, then Internet Explorer will fall back to the “Once per browser session” revalidation behavior. As a result of the improvement to heuristic caching, Internet Explorer 9 can perform far fewer conditional HTTP requests when reloading many pages. For example, the following table shows the improvement when revisiting a typical article on a popular website: IE8 IE9 Improvement Revisit in new browser session (PLT2) Request Count: 42 Bytes Sent: 26,050 Bytes Recv: 220,681 Request Count: 2 Bytes Sent: 1,134 Bytes Recv: 145,217 Request Count: -40 (-95.3%) Bytes Sent: -24,916 (-95.6%) Bytes Recv: -75,464(-34.2%) The Caching Inspector in Fiddler will show you when a response expires, based on the headers provided on that response. For instance, here’s what you see for a response which contains an ETAG and Last-Modified header, but no expiration information: http://ieblog.members.winisp.net/images/EricLaw_CachePerfImprovements_2.png Other Networking Improvements In this post, I’ve enumerated the improvements in Internet Explorer’s caching code that help ensure web sites can make the most efficient possible use of the network. Of course, web developers should continue to follow best practices and specify their desired cache behavior using the Expires and Cache-Control headers, but even sites that fail to do so will load more quickly in IE9. In a future post, I’ll describe other improvements we’ve made to the IE9 Networking Stack to further improve page load times. -Eric Lawrence http://extremetechsupport.com/data/MetaMirrorCache/ddc4c99020411b28ae9a1cbd6711d029._.gif View the full article

Bulletin Severity Rating:Important - This security update resolves a privately reported vulnerability. The vulnerability could allow remote code execution if a user opened an attachment in a specially crafted e-mail message using an affected version of Microsoft Office Outlook. An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. View the full article

Bulletin Severity Rating:Critical - This security update resolves two privately reported vulnerabilities in Microsoft Office Access ActiveX Controls. The vulnerabilities could allow remote code execution if a user opened a specially crafted Office file or viewed a Web page that instantiated Access ActiveX controls. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. View the full article

Bulletin Severity Rating:Critical - This security update resolves a publicly disclosed vulnerability in the Canonical Display Driver (cdd.dll). Although it is possible that the vulnerability could allow code execution, successful code execution is unlikely due to memory randomization. In most scenarios, it is much more likely that an attacker who successfully exploited this vulnerability could cause the affected system to stop responding and automatically restart. View the full article

Bulletin Severity Rating:Critical - This security update resolves a publicly disclosed vulnerability in the Windows Help and Support Center feature that is delivered with supported editions of Windows XP and Windows Server 2003. This vulnerability could allow remote code execution if a user views a specially crafted Web page using a Web browser or clicks a specially crafted link in an e-mail message. The vulnerability cannot be exploited automatically through e-mail. For an attack to be successful, a user must click a link listed within an e-mail message. View the full article

A few weeks ago, we talked about the performance characteristics of our Flickr Explorer sample. We showed how hardware acceleration benefits real world scenarios such as browsing photos, and how easily web developers can build these types of applications. Recently, we released a new set of demos alongside the third IE9 Platform Preview. Today we’re going to discuss the Amazon Shelf concept application (also see the companion Channel 9 video). Much like Flickr Explorer, Amazon Shelf is written using standard HTML, CSS and Javascript. Amazon Shelf also incorporates a key new HTML5 feature – the canvas element. Canvas is an incredibly powerful way to draw directly to the screen using simple Javascript API calls. When you launch Amazon Shelf, you’re shown a list of the top selling books from Amazon. This data is retrieved using the Amazon Product Advertising API. You can search for specific books, browse, and “open” books to view detailed information and customer reviews. This demo uses common patterns that you find across many interactive web applications and games. There is one main loop that updates the books and other objects on the screen, and performs simple hit testing to support interacting with the elements on the canvas. http://ieblog.members.winisp.net/images/Seth_Amazon_1.png Canvas, like all graphics in IE9, is fully hardware accelerated by default. When IE9 users browse to a website that uses canvas, IE will automatically leverage the full capabilities of the PC to provide a great experience with levels of performance not possible with today’s browsers. Using IE9, Amazon Shelf is generally able to maintain a responsiveness of 60 frames per second, which is considered realtime. Today’s browsers are only able to achieve framerates of 1-8fps which is a small fraction of the performance provided by IE9. We recently blogged about using the Windows Performance Tools to analyze browser performance. Using these tools, we’ve taken some measurements of loading Amazon Shelf in the top browsers available today. We used the same hardware and methodology discussed in the past. Let’s look at the CPU and GPU activity graphs to better understand how the demo performs in these browsers. Note: Internet Explorer 8 is not included in this comparison since it does not support the Canvas element. First up is Chrome 5. Chrome is able to update the screen once every 0.99 seconds, yielding a frame rate of about 1 FPS during the bookshelf load animation. This results in a very slow, choppy experience. One core on this dual core machine is fully utilized, and the GPU is not employed by the browser at all. http://ieblog.members.winisp.net/images/Seth_Amazon_2.png Here are the results for Safari 5. During the load animation, Safari does not attempt to render the scene at all, resulting in an effective 0 frames per second. Again, one core on the CPU is fully utilized and the GPU remains untouched. http://ieblog.members.winisp.net/images/Seth_Amazon_3.png Next up, Firefox 4 Beta. We used Minefield 4.0b2pre nightly for this analysis. Again, our tests ran this latest nightly build of Firefox (like all the others) in the default configuration. This means hardware rendering with the GPU was not enabled in Firefox. Here are the results for Firefox. The animation is rendered properly, and the screen is updated twice every .25 seconds, yielding a frame rate of about 8 FPS. http://ieblog.members.winisp.net/images/Seth_Amazon_4.png Finally, let’s take a look at Internet Explorer 9 Platform Preview 3. We see that IE9’s full usage of the GPU results in a steady, smooth frame rate of 60 FPS. The CPU handles the task without any trouble and rests frequently while the GPU renders Amazon Shelf to the screen. http://ieblog.members.winisp.net/images/Seth_Amazon_5.png There is a meaningful difference in the experience when running the demo in IE9 compared to other browsers. Check out Amazon Shelf on www.ietestdrive.com to see for yourself. We’d like to thank Amazon for their help in putting this demo together, and embracing the new GPU powered, standards based markup enabled by Internet Explorer 9. Our team can’t wait to see what other graphically rich experiences web developers armed with hardware accelerated Canvas will dream up! Seth McLaughlin Program Manager for IE Performance http://extremetechsupport.com/data/MetaMirrorCache/6b81e9037eb9533781e89da867d17670._.gif View the full article