Tech Off Thread

35 posts

Forum Read Only

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

Why can't MS create a new browser based on .Net?

Back to Forum: Tech Off
  • User profile image
    BitFlipper

    Just curious:

    Why can't MS create a new browser from scratch based purely on .Net? The current browser is enough of an embarrassment that it would serve them well to release something new that is:

    • As standards compliant as possible (yes, even pass the stupid Acid tests 100%)
    • Secure. Using .Net will give them a lot of security out of the box. There is your sandbox right there. You need to try really hard to create an insecure app with .Net
    • Fast*
    • Have a good plug-in API. Using .Net will allow much easier plugin development, including being able to force plugins to be secure. No untrusted code. No memory leaks from badly written plugins. No invalid memory access, corrupted memory, etc.

    *Note, I say "fast", because even though .Net apps will always be slightly slower than native apps, the overhead is not that much, and currently IE is roughly 20 times slower than the competition in some places, so creating something newer that is faster than what we have now should be possible with a well designed, well implemented .Net version.

    And don't tell me they can't afford it. Yes, this would be a monumental task, but IE is one of MS' apps that are quite visible to the public , the press and end users. It is hurting their image. Putting resources into developing a better IE should be a high priority I believe.

    Thoughts?

  • User profile image
    W3bbo

    No, because:

    • They've already made a huge investment in the Trident engine which is now standards compliant and works fine.
    • It would break backwards compatibility with existing websites since you'd have to recreate the issues in IE7 for its compatibility mode
    • MSHTML is used by a lot of programs, introducing the CLR will introduce problems like if the program already uses the CLR, but uses a different and incompatible version to whatever "IE.NET" uses
    • The NSAPI and ActiveX plugin systems are here to stay. Adobe and Apple aren't going to bend over backwards to make a managed interface for Flash and QuickTime respectively.
  • User profile image
    AndyC

    BitFlipper said:
    You need to try really hard to create an insecure app with .Net

    You really, really don't.

    .NET might make a small class of bug less likely but it's still very easy to introduce security flaws if you don't take the time to architect things correctly. Especially if you're getting untrusted data from the Internet.

  • User profile image
    BitFlipper

    W3bbo said:

    No, because:

    • They've already made a huge investment in the Trident engine which is now standards compliant and works fine.
    • It would break backwards compatibility with existing websites since you'd have to recreate the issues in IE7 for its compatibility mode
    • MSHTML is used by a lot of programs, introducing the CLR will introduce problems like if the program already uses the CLR, but uses a different and incompatible version to whatever "IE.NET" uses
    • The NSAPI and ActiveX plugin systems are here to stay. Adobe and Apple aren't going to bend over backwards to make a managed interface for Flash and QuickTime respectively.
    • Works fine? Are you seeing how it is losing in almost any comparison with FF or Chrome, speed and compliance wise? Maybe that is the problem with IE - its developers think it "works fine".
    • Just as FF or Chrome doesn't break backwards compatibility, why would a new MS browser be any worse of than those? If people want to view websites that can only work in IE8, let them keep IE8 installed (side-by side).
    • There is nothing preventing MS from creating a stand-alone browser that does not replace, or even use, the current MSHTML renderer. keep MSHTML as is for all the reasons you list.
    • ActiveX - keep using IE8 if you need that. Introduce a better plugin API with the new browser.

    At some point the current IE line needs to die, and MS needs to create something better to replace it. Other people are creating better alternates.  I am a long-time IE user and supporter, but it is getting harder and harder to justify staying with it. Its performance compared to other browsers is just plain pathetic. MS should fix it before everyone abandons it, unless they are fine with that outcome.  Maybe they don't care about the browser any more.  That is also fine.  But just let me know in that case and I'll switch now instead of hoping things will get better somewhere down the line.

  • User profile image
    BitFlipper

    AndyC said:

    BitFlipper said:
    *snip*

    You really, really don't.

    .NET might make a small class of bug less likely but it's still very easy to introduce security flaws if you don't take the time to architect things correctly. Especially if you're getting untrusted data from the Internet.

    I hardly call a lack of memory leaks and corrupted memory "a small class of bugs". While I develop .Net apps these days, some of my co-workers spend huge amounts of time tracking down obscure memory corruption bugs in their C++ code. And from my days of developing C++ apps in the past, this is also what I remember wasting endless time on.

    And lets not foget how FF struggles with plugins causing all sorts of memory leaks and instability.

    A "small class of bugs"? Hardly.

  • User profile image
    AndyC

    BitFlipper said:
    AndyC said:
    *snip*

    I hardly call a lack of memory leaks and corrupted memory "a small class of bugs". While I develop .Net apps these days, some of my co-workers spend huge amounts of time tracking down obscure memory corruption bugs in their C++ code. And from my days of developing C++ apps in the past, this is also what I remember wasting endless time on.

    And lets not foget how FF struggles with plugins causing all sorts of memory leaks and instability.

    A "small class of bugs"? Hardly.

    It protects against buffer overrun type attacks (mostly), but it's certainly possible to leak memory in a .NET app (even though a memory leak isn't necessarily a security issue) even if it more difficult than with unmanaged code. And there are plenty of other attack vectors which .NET by itself can't protect you from.

  • User profile image
    joechung

    They could create a new one using managed code, but it wouldn't be able to replace Internet Explorer.

  • User profile image
    staceyw

    IMO, they should.  It could be an OS Codeplex project and go from there.  Not to replace IE as such, but more like a OS research project.  They will need one for Singularity anyway.  They probably have one already in research mode.  You could make one today using the browser control in .Net.  Not sure if the control itself is managed or native.

  • User profile image
    AndyC

    staceyw said:

    IMO, they should.  It could be an OS Codeplex project and go from there.  Not to replace IE as such, but more like a OS research project.  They will need one for Singularity anyway.  They probably have one already in research mode.  You could make one today using the browser control in .Net.  Not sure if the control itself is managed or native.

    The web browser control in .NET is just the native code rendering component. If there is a compelling reason to write one in .NET then why not start a project on CodePlex today?

    FWIW I think there are advantages to having a webbrowser written entirely in WPF. Not necessecarily because of "security", "plugins" or "speed" but because it would open up the possiblity of applying transforms and other WPF-y effects that you can't do on an interop'd control. That would be a far more compelling argument to me. I'm also not naive enough to believe that such a thing would be trivial (though I'd certainly be interested in helping if there was a project underway!)

  • User profile image
    Dr Herbie

    AndyC said:
    staceyw said:
    *snip*

    The web browser control in .NET is just the native code rendering component. If there is a compelling reason to write one in .NET then why not start a project on CodePlex today?

    FWIW I think there are advantages to having a webbrowser written entirely in WPF. Not necessecarily because of "security", "plugins" or "speed" but because it would open up the possiblity of applying transforms and other WPF-y effects that you can't do on an interop'd control. That would be a far more compelling argument to me. I'm also not naive enough to believe that such a thing would be trivial (though I'd certainly be interested in helping if there was a project underway!)

    WPF Browser project?  http://khaos.codeplex.com/ is available ...

    Herbie

  • User profile image
    AndyC

    Dr Herbie said:
    AndyC said:
    *snip*

    WPF Browser project?  http://khaos.codeplex.com/ is available ...

    Herbie

    See, now that is interesting.

  • User profile image
    Ion Todirel

    AndyC said:
    Dr Herbie said:
    *snip*

    See, now that is interesting.

    very

     

  • User profile image
    stevo_

    I wouldn't get to excited, I don't think its going anywhere.. theres just a lot of work that needs to go into a browser.. writing one in .net would be interesting from an extensibility point (perhaps, but still less so interesting than extensions in say firefox- which are much more approachable).

    But I don't really see otherwise why..

  • User profile image
    magicalclick

    stevo_ said:

    I wouldn't get to excited, I don't think its going anywhere.. theres just a lot of work that needs to go into a browser.. writing one in .net would be interesting from an extensibility point (perhaps, but still less so interesting than extensions in say firefox- which are much more approachable).

    But I don't really see otherwise why..

    The reason is simple. Anyone could use the same core to build browser ontop of .Net. Any machine supports .net platform would be able to run the program easily. For example, run you own version of browser on Win Mo, on Win CE based GPS system, on many other Win CE bases systems.

     

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    AndyC

    stevo_ said:

    I wouldn't get to excited, I don't think its going anywhere.. theres just a lot of work that needs to go into a browser.. writing one in .net would be interesting from an extensibility point (perhaps, but still less so interesting than extensions in say firefox- which are much more approachable).

    But I don't really see otherwise why..

    Paste the following into XAMLpad:

    <Window
            xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Window1" Height="300" Width="300">
        <Grid>
            <Rectangle Width="40" Height="40" Fill="Beige" HorizontalAlignment="left"/>
            <WebBrowser  Margin="15" Source="http://channel9.msdn.com" />
            <Rectangle Width="40" Height="40" Fill="AliceBlue" VerticalAlignment="top"/>
            <Menu VerticalAlignment="Top">
                <MenuItem Header="_File">
                    <MenuItem Header="_New"/>
                    <MenuItem Header="_Open"/>
                    <MenuItem Header="Close"/>
            </MenuItem>
            </Menu>
            <Label VerticalAlignment="Center" HorizontalAlignment="Center">This Text should should appear over the top of everything</Label>
        </Grid>
    </Window>

     

    Notice how the webbrowser appears over the top of everything. It's a limitation of hosting a native control in a WPF application, which really limits the things you can acheive. A 100% WPF based managed webbrowser control would allow you to integrate HTML content in a much more natural and flexible way.

  • User profile image
    stevo_

    magicalclick said:
    stevo_ said:
    *snip*

    The reason is simple. Anyone could use the same core to build browser ontop of .Net. Any machine supports .net platform would be able to run the program easily. For example, run you own version of browser on Win Mo, on Win CE based GPS system, on many other Win CE bases systems.

     

    Uh you could do that in c++, both will need platform abstraction layers... but you wouldn't want to do that because the UI / experience of a phone is different to a desktop.. the core of the rendering engine should be re-used, and that would have significantly less dependencies than a UI would..

    Also AndyC, that example doesn't mean you should do it in .NET, it just means there needs to be a better way to interop the drawing layers in WPF and native.. maybe they already do have a good way but the web browser control just isn't compat..

    But I'm pretty sure they could make that work faster than it would for them to write an entirely new browser..

    .NET is great, I solely program .NET, in-fact I've had such a brief time in native world that I hardly remember it, but I at least know that native isn't obsolete to .NET - and that I can't see any reason why they wouldn't instead- write an entirely new browser in native..

  • User profile image
    AndyC

    stevo_ said:
    magicalclick said:
    *snip*

    Uh you could do that in c++, both will need platform abstraction layers... but you wouldn't want to do that because the UI / experience of a phone is different to a desktop.. the core of the rendering engine should be re-used, and that would have significantly less dependencies than a UI would..

    Also AndyC, that example doesn't mean you should do it in .NET, it just means there needs to be a better way to interop the drawing layers in WPF and native.. maybe they already do have a good way but the web browser control just isn't compat..

    But I'm pretty sure they could make that work faster than it would for them to write an entirely new browser..

    .NET is great, I solely program .NET, in-fact I've had such a brief time in native world that I hardly remember it, but I at least know that native isn't obsolete to .NET - and that I can't see any reason why they wouldn't instead- write an entirely new browser in native..

    steveo_ said:
    Also AndyC, that example doesn't mean you should do it in .NET, it just means there needs to be a better way to interop the drawing layers in WPF and native.. maybe they already do have a good way but the web browser control just isn't compat..

    Unlikely, doing that would mean pretty much redeveloping large parts of Win32, since it is fundamental Win32 decisions that lead to the limitations involved. And that in itself would be not only an enormous job, but a compatibility nightmare. And even after all that it might not even be fixable without breaking basic Win32 assumptions - remember it's not necessarily just layering, but the ability to truly treat it as a WPF control, including applying transformations, animations or embedding the control onto a 3D surface whilst remaining functional.

    Given that Trident no longer has any actual dependencies on real Win32 controls, it would probably be easier to port that into WPF via C++/CLI if they wanted to fix that. It's questionable whether that would have any benefit for Microsoft though, given it's not something they necessarily need themselves. I still think it would be a useful third party control though. 

  • User profile image
    DCMonkey

    AndyC said:
    stevo_ said:
    *snip*

    Unlikely, doing that would mean pretty much redeveloping large parts of Win32, since it is fundamental Win32 decisions that lead to the limitations involved. And that in itself would be not only an enormous job, but a compatibility nightmare. And even after all that it might not even be fixable without breaking basic Win32 assumptions - remember it's not necessarily just layering, but the ability to truly treat it as a WPF control, including applying transformations, animations or embedding the control onto a 3D surface whilst remaining functional.

    Given that Trident no longer has any actual dependencies on real Win32 controls, it would probably be easier to port that into WPF via C++/CLI if they wanted to fix that. It's questionable whether that would have any benefit for Microsoft though, given it's not something they necessarily need themselves. I still think it would be a useful third party control though. 

    I hear WebKit has a reasonably portable back end. I wonder if it could be ported to render to a Direct3D surface which could then better interop with WPF via D3DImage.

Conversation locked

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