The 64-bit browser in Windows x64

With the delivery of RC 1 of Windows Server 2003 & Windows x64 Client last month, we shipped not one but two browsers with the OS:  a 32- and 64-bit version of IE6 for Windows Server 2003 SP1/x64.

We had to make a choice with the 64-bit client as to which browser, the 32-bit or 64-bit, would be the default. Compatibility, performance, and interoperability all played a part in our decision, but ultimately our decision was swayed by the lack of 64-bit native controls. We found that in our own every day use of the 64-bit client, the 64-bit browser was difficult to use because web sites hadn’t authored common controls for 64-bit clients. So for now, users who run the 64-bit client will be running the 32-bit browser.

Going forward, it’s important for control vendors to start taking the 64-bit OS seriously. When Longhorn ships, I personally think it would be a shame if we had to make the same decision again. I encourage all control authors to take a look at the various 64-bit capable compilers and make sure that their web sites handle browsers of various bitness as easily as, say, they handle different browsers.

That said, the 64-bit browser is available in the 64-bit client. Here's a list of which version of our browser gets launched and under which circumstances: 

UI entry points that invoke 32-bit IE:

 - Pinned “Internet” slot at top of Start menu
 - “e” on desktop (Internet shell namespace)
 - “Set Program Access & Defaults” default web browser
 - Start menu All Programs shortcut to 32-bit IE labeled as “Internet Explorer (32-bit)”
 - Quick launch bar
 - File associations

UI entry points that invoke 64-bit IE:

 - Start menu All Programs shortcut to 64-bit IE labeled as “Internet Explorer (64-bit)”

Non-UI entry points:

 - In-proc COM servers follow the bitness of the invoker
 - API (i.e. ShellExecute() ‘iexplore.exe’) will invoke 32-bit IE
 - Out-of-proc programmable COM servers (i.e. a host app that CoCreates CLSID_Internet Explorer) will by default follow the bitness of the invoker. Clients have the ability to modify this behavior by passing one of two new dwClsContext flags to CoCreateInstance().  CLSCTX_ACTIVATE_32_BIT_SERVER and CLSCTX_ACTIVATE_64_BIT_SERVER tell COM to prefer the LocalServer32 registration in the 32-bit or 64-bit side of the registry, respectively.

Almost all of these defaults can be changed by users or administrators by toggling switches in the registry. We’ll get a complete list of those registry keys published soon and when they’re up we’ll let you know where they are.


Comments (23)
  1. Anonymous says:

    What specific advantages does running the 64bit browser have over running the 32 bit browser (on a 64-bit platform)?

    How does the performance compare?

    Are there capabilities that only exist at the 64-bit level? Does IE need more than 2GB of memory in some circumstances?

  2. Anonymous says:

    What about explorer.exe? I’m assuming that there’s only going to be a 64-bit version of Explorer, thus typing in internet URLs in the explorer.exe address bar could be considered an "entry" into 64-bit Internet Explorer.

    Also if there’s only a 64-bit Explorer.exe, then lots of shell extensions will have to be redeveloped as 64-bit as well, correct?

    [To Johan: With 32-bit IE today, you eventually hit a limit of how many IE windows you can have open… maybe a 64-bit IE, along with the underlying 64-bit window manager, will alleviate this.]

  3. Anonymous says:

    <p class="firstinpost">I am, in general, a fan of Microsoft. While I tend to think that their corporate policies are, in the words of many of my geek friends <i>teh suck</i>, the products they make tend to have more useful features/higher usability th…

  4. Anonymous says:

    Why do web site authors need to know about Win32/64?! They are just providing HTML, CSS, JavaScript, etc…

    Nah! You’re talking about that "ActiveX" thing, right? OK, nevermind…

  5. Anonymous says:

    @minghong: My feeling too. (I may have misunderstood something though.)

  6. Anonymous says:

    "I encourage all control authors to take a look at the various 64-bit capable compilers and make sure that their web sites handle browsers of various bitness as easily as, say, they handle different browsers."

    Of course, those of us that actually develop with different platforms and browsers in mind can reap this benefit of standards based web development already, because we don’t use browser specific technology such as Active-X.

    Yet another reason Microsoft just doesn’t "get it".

    Speaking of, how’s the increased standards support comming?

  7. Anonymous says:

    Why don’t you just drop support for ActiveX?

    Its a horrible concept and implementation, and even people addicted to Microsoft lock-in will be switching to .Net controls which ( unless you are more incompetent that you seem) shouldn’t have any trouble.

    Why on earth would you provide a non .Net upgrade path for such a deadend technology?

    (Of course, not being idiots, you could recognise certain CreateObject calls and replace those with a standard compliant implementation. IE XmlHttpRequest, for idiots not using object detection.)

    The only benefit to ActiveX in IE is the possibilty that web standards can be implemented by third-parties, eg a canvas tag could be implemented according to the WHATWG recommendation.

    Or maybe the whole of Gecko should just be pulled in as an ActiveX control : this could make web design a lot nicer for everyone.

  8. Anonymous says:

    @rjw. Sweet suggestion. (The last one.) Would that really be possible?

  9. Anonymous says:

    "maybe the whole of Gecko should just be pulled in as an ActiveX control : this could make web design a lot nicer for everyone."


  10. Anonymous says:

    This comment box should have quick-comment buttons like:

    [Fix PNG] [Add CSS2] [Add XHTML] [Dump ActiveX]

    So, 4 clicks from me.

  11. Anonymous says:

    "I encourage all control authors to take a look at the various 64-bit capable compilers and make sure that their web sites handle browsers of various bitness as easily as, say, they handle different browsers"

    Of course, if they can handle different browsers then they can handle different ‘bitness’ because they’ll not be using any ActiveX which is the only reason why 64bit won’t work for all sites.

    If we ever needed any proof that bringing activex to the web was a bad idea then this is it.

    I’m sure the idea of people producing activex controls that only worked on Windows seemed a good idea for platform lock in at the time, it’s obvious that the person who thought of this idea never thought of the fact that we’d eventually be using 64bit CPU’s.

    For the sake of backwards compatibility I think we may never see the 64bit IE as the default and making the user have to choose between the 32 and 64 bit version of IE wouldn’t be user friendly.

    If you ever switched to the 64bit version and activex controls stopped working then I could imagine some people would take the opportunity to write things in a cross browser manner rather than using ActiveX which would do us all the world of good.

  12. Anonymous says:

    To Johan: 32-bit IE running on the 64-bit IE has comparable performance to the 32-bit browser on the 32-bit OS. I don’t have specific perf data to release at this time; I’m sure it will become available after WS03SP1 ships.

    The functionality between the 32-bit and 64-bit browsers are identical from a feature standpoint (both have the pop-up blocker for example). Of course a native 64-bit app has direct access to more memory etc and the 64-bit browser can/will take advantage of that.

    As for apps requiring >2 GB memory, I’ve seen customer apps built on IE that require 2 GB or more of memory. Obviously these are very specific vertical apps, but they exist. The 64-bit IE version of IE will definitely help address any scalability concerns that those customers have.

    To Jonathan: The shell runs native 64-bit. If you navigate in-place to a web site from a shell view you’ll navigate in the 64-bit browser. This does mean that folks will have to author their shell extensions (or recompile) for 64-bit.

    To Dave: There are other ways to offer binary extensibility in IE (not just with ActiveX) and I would be surprised if all those mechanisms wouldn’t be impacted somehow by the switch to 64-bit.

    To everyone else: I’m happy to reply / converse with anyone who asks constructive questions.


  13. Anonymous says:

    Active X and other IE-only technologies aside, how much of an inpact does 64-bit have on cross-platform technologies like most Javascript and DOM?

    The reason why I ask is because I have a script that takes a traditional 24-bit (3 Channel) color value and calculates its complementary value. It works great for that. But when I expanded it for a 32-bit (4 Channel) color value, it gets fouled up. To be specific, the container variable overflows at 2^31.

    I wonder how a 64-bit browser will handle this scenario.

  14. Anonymous says:

    snowknight: it sounds like you’re using a signed variable when you need an unsigned one?

  15. Anonymous says:

    "snowknight: it sounds like you’re using a signed variable when you need an unsigned one?"

    What technique do you know of to control data types in JavaScript? I’d be quite interested…

    Aside from that, preliminary testing indicates that 2^31 should not overflow (i.e. simply assigning the raw value to a variable and using alert() to show it).

  16. Anonymous says:

    Jim & Aankhen: Sorry, I miswrote. Its been a few months since I worked on this script. Whenever, I try to work on the variable, thats when it overflows. Try this:

    var testvar = 2147483648;

    document.write(testvar + "<br />");

    testvar = ((testvar & 4278190080) >> 24);


    I’ve already gotten this solved, but its more of a workaround than a fix.

  17. Anonymous says:

    I wonder do you have examples of how a developer would provide the correct version of a control to an IE client. I presume we would be able to detect whether a client was 32bit or 64bit separately to the browser version (6.0 for example).

    It would be great if these examples additionally showed the upgrade path for developers wanting to supply .net plugins with the Framework (which will hopefully sidestep the 64bit issue).

  18. Anonymous says:

    Perfect don’t change that , this is actually an advantage of the 64 bit edition. I don’t want activeX component on web site because they are dangerous.

  19. Anonymous says:

    ROTFLOL… do any of you use the Marcromedia Flash plugin?

  20. Anonymous says:


Comments are closed.

Skip to main content