Coffeehouse Thread

16 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Why is IE9 not built on the CLR?

Back to Forum: Coffeehouse
  • User profile image
    DevJunkie111

    Can anyone explain why IE9 is not a .Net application? 

  • User profile image
    vesuvius

    The same reason that Windows  or Office is not. They have spent many years in developing the browser, and C++ gives the lower level control you typically want in a browser.

     

    If you look at a lot of the browsers that have become popular (Firefox/Chrome) all are written in C++

  • User profile image
    AndyC

    Because the vast majority of IE is a component that can be hosted inside other processes and those processes do not necessarily want to take a large dependencie on the CLR for very little benefit (and in some cases, i.e. CLR 1.0/1.1 apps, wouldn't be able to if they wanted).

  • User profile image
    DevJunkie111

    AndyC said:

    Because the vast majority of IE is a component that can be hosted inside other processes and those processes do not necessarily want to take a large dependencie on the CLR for very little benefit (and in some cases, i.e. CLR 1.0/1.1 apps, wouldn't be able to if they wanted).

    Technically I think that a clr based browser would work just as well; and perform just as well. If it did not then it would push the CLR team to make a better runtime. 

    The discussion about legacy investment and when to change that is a business decision. I think Jason Zander and VS team require kudos for writing thier UI in .Net. I think that overall this was a big win, we got a better UI but more importantly we got a lot of feedback to the WPF and CLR teams about improving things. Which benefited everyone!

    I think that if IE were written on the CLR we would get a lot of benefit in this sense. And the innovation in the browser would drive the evolution of the CLR. And when javscript needs a runtime we could use the CLR to build it perhaps?

    And I would say the same about the office folks! The enormous investment in COM is holding back innovation. 

    Windows I do not know, perhaps that is a lost cause. Maybe someday we would have a CLR based OS? 

    Remember we have challenges like switching to taking advantage of multi cores and GPUs that we could all share and use if we built on the CLR and developed good libraries to represent all the innovation. All the algorithms and innovation at the core of IE is opaque and unavailable; conversely the innovation on the CLR and from the community is not available to the IE team. 

     

  • User profile image
    W3bbo

    Why do so many people have an obsession with the CLR? It's a nice platform, I'll agree, but I just don't think it's right that somehow everything must be written on top of it. There are more platforms than the CLR all with their strengths and weaknesses: I still wouldn't choose the CLR for a fast, high-performance, low-latency desktop application.

  • User profile image
    Bass

    It would be a lot of work for very little (or any) benefit. CLR apps can interop with C/C++ code anyway, as you may already see, you can embed a web browser control into most .NET-based GUIs.

  • User profile image
    brian.​shapiro

    vesuvius said:

    The same reason that Windows  or Office is not. They have spent many years in developing the browser, and C++ gives the lower level control you typically want in a browser.

     

    If you look at a lot of the browsers that have become popular (Firefox/Chrome) all are written in C++

    Firefox's interface isn't in XUL ?

  • User profile image
    brian.​shapiro

    W3bbo said:

    Why do so many people have an obsession with the CLR? It's a nice platform, I'll agree, but I just don't think it's right that somehow everything must be written on top of it. There are more platforms than the CLR all with their strengths and weaknesses: I still wouldn't choose the CLR for a fast, high-performance, low-latency desktop application.

    It was originally part of the Longhorn vision. The idea was that apps based on a managed code API would be preferable, because it would allow things like resolution independence (based on vector scaling), easy extensibility, etc. We aren't there yet.. but .NET wasn't meant just as a developer platform, but as a new API.

  • User profile image
    Cream​Filling512

    IE was written long before .NET existed, it's probably heavy in COM though, which is basically .NET's predecessor.

  • User profile image
    Cannot​Resolve​Symbol

    brian.shapiro said:
    vesuvius said:
    *snip*

    Firefox's interface isn't in XUL ?

    Firefox's interface is written in XUL...  but you have to render XUL with something (XUL isn't magic).  That "something" (Gecko) is written in C++.

  • User profile image
    brian.​shapiro

    CannotResolveSymbol said:
    brian.shapiro said:
    *snip*

    Firefox's interface is written in XUL...  but you have to render XUL with something (XUL isn't magic).  That "something" (Gecko) is written in C++.

    .NET isn't magic either. I doubt many people are asking that the rendering engine or javascript engine in IE be based on the CLR... the idea would be that IE's interface be XAML based, and the browser object would be exposed to the XAML interface through its .NET wrapper.

     

    People basically want IE to work like Firefox in that regard.

  • User profile image
    ManipUni

    What is the benefit of moving IE9 to the CLR? You asked why it isn't, but you never really said why it SHOULD?

     

    If your reasoning is security then frankly IE9 could do more good by dropping back-compatibility with every existing addon and OS tie-in, and only allow back in those that supported low privileged execution. If they developed a CLR version and supported existing addons etc then it would do absolutely no good at all.

     

    Frankly I'd like to see all browsers move to a "whitelist" model for automatic file type execution... Drop PDF, Office Formats, and unknown formats entirely from auto-starting and require the user download, save, and run them.

  • User profile image
    DevJunkie111

    ManipUni said:

    What is the benefit of moving IE9 to the CLR? You asked why it isn't, but you never really said why it SHOULD?

     

    If your reasoning is security then frankly IE9 could do more good by dropping back-compatibility with every existing addon and OS tie-in, and only allow back in those that supported low privileged execution. If they developed a CLR version and supported existing addons etc then it would do absolutely no good at all.

     

    Frankly I'd like to see all browsers move to a "whitelist" model for automatic file type execution... Drop PDF, Office Formats, and unknown formats entirely from auto-starting and require the user download, save, and run them.

    I did...touch on the benefits of writing IE on the CLR earlier in the thread...

    if IE were written on the CLR we would get a lot of benefits. The innovation in the browser would drive the evolution of the CLR and vice versa. 

    When Javascript needs a runtime we could use the CLR to build it? So it would become a first class CLR language. So if I need to create a library and use it outside the browser I could just do that.  We could also imagine generating Javascript libraries from .Net languages!

    here is an example of the kind of things we would get; when the browser folks need to create the concept of isolation so that tabs would not crash each other for example. We could use the same technology in our .Net apps. 

    The browser folks would benefit from any good work that was done on the CLR; new techniques to code for concurrency is a good example. 

    there are many more benefits... 

     

  • User profile image
    Bass

    DevJunkie111 said:
    ManipUni said:
    *snip*

    I did...touch on the benefits of writing IE on the CLR earlier in the thread...

    if IE were written on the CLR we would get a lot of benefits. The innovation in the browser would drive the evolution of the CLR and vice versa. 

    When Javascript needs a runtime we could use the CLR to build it? So it would become a first class CLR language. So if I need to create a library and use it outside the browser I could just do that.  We could also imagine generating Javascript libraries from .Net languages!

    here is an example of the kind of things we would get; when the browser folks need to create the concept of isolation so that tabs would not crash each other for example. We could use the same technology in our .Net apps. 

    The browser folks would benefit from any good work that was done on the CLR; new techniques to code for concurrency is a good example. 

    there are many more benefits... 

     

    Microsoft had some plans to make JavaScript (or "JScript") a first class .NET language via the DLR, but they were seemly dropped. Currently most of the work is underway to make Python and Ruby first class languages.

  • User profile image
    AndyC

    ManipUni said:

    What is the benefit of moving IE9 to the CLR? You asked why it isn't, but you never really said why it SHOULD?

     

    If your reasoning is security then frankly IE9 could do more good by dropping back-compatibility with every existing addon and OS tie-in, and only allow back in those that supported low privileged execution. If they developed a CLR version and supported existing addons etc then it would do absolutely no good at all.

     

    Frankly I'd like to see all browsers move to a "whitelist" model for automatic file type execution... Drop PDF, Office Formats, and unknown formats entirely from auto-starting and require the user download, save, and run them.

    ManipUni said:
    Frankly I'd like to see all browsers move to a "whitelist" model for automatic file type execution... Drop PDF, Office Formats, and unknown formats entirely from auto-starting and require the user download, save, and run them.

    How does that help in real terms? It's just another hoop for the user to jump through for no real reason, it won't stop somebody opening a malicious file if they've already decided that's what they are going to do (the Dancing Bunnies problem) but it will frustrate and confuse users who want things to "just work".

  • User profile image
    ManipUni

    AndyC said:
    ManipUni said:
    *snip*

    How does that help in real terms? It's just another hoop for the user to jump through for no real reason, it won't stop somebody opening a malicious file if they've already decided that's what they are going to do (the Dancing Bunnies problem) but it will frustrate and confuse users who want things to "just work".

    It will help stop all the "drive by" infections from adverts. You also reduce the scope of infection to just the browser and addons installed into said browser unless the user directly downloads a file and runs it.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.