Recommended Posts

I'm pretty happy with IE10 on the Win8 DP, but it's good to see others are already planning a metro version of their browser

Also, desktop Firefox 10 (every beta so far, and the final) works just fine in the WDP.

The blog post earlier today on WOA (Windows On ARM) clears up a few misperceptions (including mine) on WinRT. A true WinRT version of FF will run without changes on any platform that supports WinRT(x86/x64/ARM) - true CPU neutrality. (Naturally, that hasn't been the case for any browser before - regardless of platform.) It also means that MetroIE is the *same browser* regardless of the OS underneath - and why plug-ins got banished. (Would you really want an ARM CPU sandbagged by some of the heavier plug-ins - or ActiveX controls, for that matter - that desktop IE and desktop FF have to deal with?)

Also to note. Chrome on ICS doesnt support Flash. If i remember correctly.

So flash is going out anyway. Till windows 8 hits the shelves everybody should move on to html5

And i dont think so other browsers can run on WOA (in desktop mode i mean).

And browsers will require native code to offer comparable performance to IE10 (immersive).

And browsers will require native code to offer comparable performance to IE10

Well, the C++ code in WinRT runs at generally native speed (albiet sandboxed within the runtime) - and they can directly access DirectX in WinRT. They already have a DirectX hardware acceleration layer working in Firefox desktop, and most of their code is C++, so there's not too much reason why they couldn't get the performance they want.

If they tried to be ridiculous and write it in C# & XAML, then they wouldn't have a chance of getting decent performance :p

Well, the C++ code in WinRT runs at generally native speed (albiet sandboxed within the runtime) - and they can directly access DirectX in WinRT. They already have a DirectX hardware acceleration layer working in Firefox desktop, and most of their code is C++, so there's not too much reason why they couldn't get the performance they want.

If they tried to be ridiculous and write it in C# & XAML, then they wouldn't have a chance of getting decent performance :p

Looking through Mozilla's notes on Windows 8 support, it seems that still isn't an ideal situation for them and possibly other browser vendors. The main issue it seems is that metro doesn't support native code, which most of Firefox is written in. They've noticed however that IE10 works differently to other metro apps, in that it is the same exe as the desktop app, running with native code outside the sandbox, just using the metro interface instead of its normal desktop UI. Therefore it's possible that Microsoft might permit this later on, removing the issues they have.

They've noticed however that IE10 works differently to other metro apps, in that it is the same exe as the desktop app, running with native code outside the sandbox, just using the metro interface instead of its normal desktop UI. Therefore it's possible that Microsoft might permit this later on, removing the issues they have.

It'd be unlikely Microsoft ever would. Allowing a WinRT Firefox app to access native code outside the sandbox paints Firefox as a big security risk, and a potentional attack vector for virus / malware to get into the system - considering here that Windows On ARM tablets will not allow any other native apps apart from Office, and the Metro apps are sandboxed. With IE, this isn't *as much* of a concern, as they can push a patch down Windows Update as soon as they can for any issue - it's their program in their hands, and they can make sure they take action right away. But I don't think they're in any mood to let a third party have that kind of responsibility.

Also to note. Chrome on ICS doesnt support Flash. If i remember correctly.

So flash is going out anyway. Till windows 8 hits the shelves everybody should move on to html5

And i dont think so other browsers can run on WOA (in desktop mode i mean).

And browsers will require native code to offer comparable performance to IE10 (immersive).

Actually, no.

MetroIE (the Immersive version) is straight WinRT code (going forward - there may be some native code remaining in the version in the WDP, as it does support ActiveX controls). The *desktop* version (which supports ActiveX controls) is native code (and likely, on x86/x64) Win32/Win64. Yes - that means *three* versions of IE on the x64 versions.

Looking through Mozilla's notes on Windows 8 support, it seems that still isn't an ideal situation for them and possibly other browser vendors. The main issue it seems is that metro doesn't support native code, which most of Firefox is written in. They've noticed however that IE10 works differently to other metro apps, in that it is the same exe as the desktop app, running with native code outside the sandbox, just using the metro interface instead of its normal desktop UI. Therefore it's possible that Microsoft might permit this later on, removing the issues they have.

Metro style apps can be written in 100% native code.

Metro style apps can be written in 100% native code.

As far as I can see that's not the case, you can only use managed code. The closest you can get as far as I can see is using managed C++ allowing you to reuse code from native C++, but of course with the lack of Win32 and many other APIs often used in native code.

Just a quick question

Are there any known plans for other companies to make internet browsers for metro? and can it even be done because from what i understand metro apps are made in HTML 5?

not worth it maybe!! who knows metro might be gone in Windows 9.

As far as I can see that's not the case, you can only use managed code. The closest you can get as far as I can see is using managed C++ allowing you to reuse code from native C++, but of course with the lack of Win32 and many other APIs often used in native code.

Brandon is a member of the Windows Shell team. He knows. :)

As far as I can see that's not the case, you can only use managed code. The closest you can get as far as I can see is using managed C++ allowing you to reuse code from native C++, but of course with the lack of Win32 and many other APIs often used in native code.

We actually do not really support (or at least emphasize) managed C++ (aka C++/CLI) for WinRT development.

The primary targets are via the API "projections." They are:

Native C++ with "Component Extensions" - also called "high level" C++

C# and VB.Net (managed)

JavaScript

C++ apps can use DirectX (D3D/D2D) to render directly (or via a custom UI framework built on top of it), or use the new (fully native) XAML system.

.NET apps can use the same XAML system (the implementation of which is all native).

JS apps use HTML / canvas / SVG

You can also forego the C++/CX extensions and the niceties of the high-level projection, and instead write purely standard C++. Here you'd interact with the WinRT in its raw form, what we call the ABI (Application Binary Interface). That level would be most familiar to experienced COM developers (HRESULTs instead of exceptions, etc). For those developers we also include the new WRL (Windows Runtime Library) helpers, which is analogous to a modernized subset of ATL. But it's all new and designed for the WinRT ABI (and new base platform constructs like HSTRING and such). That said, I don't know why you would :-) The ABI layer is... verbose, compared to the elegant and concise CX goodness (and the result the compiler spits out is the same).

Just a quick question

Are there any known plans for other companies to make internet browsers for metro? and can it even be done because from what i understand metro apps are made in HTML 5?

The UI is declared in HTML5 but then compiled into code just as a UI can be declared in XAML then compiled into binary.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • I've been on Deezer for over a decade, but glad that Tidal joined them in fighting AI slop. Can't stand such takes as Spotify's: "Spotify's CEO recently pushed back against listeners who call AI music "slop," urging people to stop using the term and instead embrace the creative potential of AI music."
    • “Could” … in the IS the healthcare is run by insurance companies that make indecent profits denying basic treatments to people that are paying money for nothing. Besides, where are all the Trump epigones who were stating that the tariffs were going to paid by foreign companies and not the US citizens? …
    • Microsoft Teams gets smarter at spotting sneaky meeting bots by Usama Jawad Microsoft Teams is set to receive a couple of new features soon, including a dedicated Recap app and a rather controversial location tracking functionality. The Redmond tech giant has also explained how it has made online communication and collaboration a lot more performant this year. Now, the company has detailed more secure bot admission mechanisms, as first reported by us in March 2026, and now available in Teams. As the use of AI has expanded across enterprise environments, Microsoft has begun allowing users to integrate bots into their meetings for various tasks, such as note-taking. While this has a tangible productivity benefit for users, Microsoft has highlighted how misconfiguration has allowed bots to join meetings that they shouldn't. This has created security and privacy risks, which Microsoft is now combating using a new Teams admin policy that allows organizers to control how external bots access meetings. Admins can leverage a policy called Manage external bots and their access to meetings. The default configuration is "When detected, require approval before joining", which places detected bots in a lobby before they are explicitly admitted into the meeting. The other option disables the experience. Microsoft has also requested admins to only allow organizers and co-organizers to manage access to a meeting, so that other people don't randomly allow bots into meetings. Teams will now be able to leverage infrastructure signals to intelligently detect and distinguish between bots and humans. Microsoft will soon also trial a registration experience for independent software vendors (ISVs) to build a system that registers a bot with Microsoft, so it is marked as a "known" bot. Teams will also categorize bots as trusted and suspected threats so that organizers can quickly identify which bots they want to allow into a meeting. Additional safeguards to block accidental admission of a bot into a meeting include: No one-click Admit option for identified bots Confirmation prompts when admitting participants that include bots Warnings when organizers choose Admit all, and bots are included Microsoft has begun rolling out this experience, and it will be retiring the current CAPTCHA verification implementation. In the future, the company plans to roll out new capabilities like allow-lists, organization-wide policies, admin reports, audit logs, and more granular controls.
    • With the current hardware prices Microsoft should lift the restriction. Then if you have the correct TPM then allow you to use X feature, if you don't have the correct TPM then don't but still actually let you run windows. 11. With a disclaimer during install that X features would be unavailable.
    • It's good for recycling of course. But commence inflation of a second hand RAM bubble and price gouging on DDR 4 inventory in 3... 2... 1...
  • Recent Achievements

    • Reacting Well
      NovaEdgeX earned a badge
      Reacting Well
    • Week One Done
      NovaEdgeX earned a badge
      Week One Done
    • One Year In
      BA the Curmudgeon earned a badge
      One Year In
    • Conversation Starter
      rosiecharles earned a badge
      Conversation Starter
    • First Post
      KMilenkoski1202 earned a badge
      First Post
  • Popular Contributors

    1. 1
      +primortal
      538
    2. 2
      +Edouard
      266
    3. 3
      PsYcHoKiLLa
      151
    4. 4
      Steven P.
      98
    5. 5
      macoman
      66
  • Tell a friend

    Love Neowin? Tell a friend!