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

    • Simple answer is yes, you will still get the Windows updates and as long as browser is up to date, you will be good. Only thing secure boot does is protect you against boot level threats and make it harder to install other OS's. I've been looking into this pretty thoroughly lately myself as wifes computer has secure boot disabled plus my other, older computers that run Linux, don't have secure boot enabled. Have seen all kinds of questions about this on the Linux Mint and MX Linux forums. Just don't suddenly enable secure boot now.
    • How many other companies will follow Ford's lead? Or, have they already gotten lazy and become enslaved to AI--and now can't figure out how to get out of that mess.
    • Why would any self-respecting intelligent person follow any recommendation by Donald's GOP administration? With almost two years of fabrications, deceit, and blatantly illegal behavior, why believe them now? They had best be gone after the November 2026 election, so we'll wait and see.
    • AltSendme 0.4.1 by Razvan Serea AltSendme is a minimal, cross-platform application designed for fast, secure, and private peer-to-peer file transfers. It allows users to send files or entire directories directly between devices without relying on cloud servers, accounts, or any personal information. Everything is encrypted end-to-end using modern protocols like QUIC and TLS 1.3, ensuring both strong security and low-latency performance. Transfers are verified with BLAKE3 for data integrity, and interrupted downloads automatically resume, making the experience reliable even on unstable connections. You can transfer anything—images, videos, documents, and more. Integrity checks are performed on both ends, so your files are automatically verified for correctness during both sending and receiving. AltSendme works seamlessly across local networks or long-distance links, capable of saturating multi-gigabit connections for extremely fast delivery. With built-in NAT traversal and encrypted relay fallback, it connects devices almost anywhere. The app integrates with the Sendme CLI and will soon support mobile and web platforms. Fully free and open-source, AltSendme offers a lightweight, privacy-first alternative to traditional cloud-based services, removing size limits, upload costs, and unnecessary data exposure. AltSendme 0.4.1 changelog: Release Highlights Self-hosted relays: Run your own iroh relay so transfers don't rely on public infrastructure. Includes a full deployment template in deploy/relay/ with Docker Compose for a VPS and configuration examples for production use. Fly.io support: One-click deploy template for Fly.io, including a quick-start config (fly.dev.toml) for testing without a custom domain, plus production setup with Let's Encrypt and your own hostname. Relay settings UI: New Settings → Network panel to choose how AltSendme connects: automatic public relays, custom self-hosted URLs (with optional auth token), or disabled. Test connections, verify latency, and see live relay status in the footer. Disable relays: Turn off relay servers entirely when you only need same-network transfers (e.g. LAN). Direct connections only. No relay hop required when devices can reach each other. Android graduates from beta: Android is now part of the regular release cycle alongside desktop. APKs ship with each version (universal, arm64, and armv7). Other improvements Private relay access control via shared auth token Relay fallback notifications when a custom relay is unreachable Broadcast mode toggle in sharing settings Android release build fixes (split-per-ABI APKs, universal APK preservation) UI polish: mobile safe-area insets, dropzone layout, transfer progress animation Bug fixes for minification-related serialization issues and system tray icon loading What's Changed feat(relay): add relay status functionality and settings UI (a120cdf) feat(relay): implement custom relay server configuration and verification (51276c7) feat(relay): add configuration for private relay access and enhance observability features (48fbabf) feat(relay): enhance relay URL validation, display connection status (d4fffa0) feat(relay): add RelayChangeGuard component and enhance relay-related translations (16ba514) feat(broadcast): add toggle setting for broadcast mode in sharing UI (ca6d977) fix(relay): correct QUIC discovery port, pin image, templatize fly.dev (52a2ba5) fix: More broken serialization due to minification (67491a9) fix(android): preserve true universal APK across per-ABI builds (e9f256f) fix(ui): conditional safe-area insets padding on mobile (1182f0e) refactor(transfer): CircularRing component animation fix (944572b) chore(android): drop x86 and x86_64 release APKs, keep universal+arm64+armv7 (34ada0b) Download: AltSendme 0.4.1 | ARM64 | ~9.0 MB (Open Source) Download: AltSendme for MacOS | Android Links: AltSendme Home Page | GitHub | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • You are mostly right about the ephemeral nature of it. As I mention in the article, if you dont add a second device or take a backup of your account before uninstalling it, then yes you will lose access to your account. That said, in terms of actual user experience when you sync multiple devices your message history carries across and there's also a Saved Messages chat like there is on Telegram to send messages and attachments between your installs. But yh, what you point out are correct and its not trying to emulate Messenger or Telegram.
  • Recent Achievements

    • Week One Done
      flexorcist earned a badge
      Week One Done
    • One Month Later
      Woland13 earned a badge
      One Month Later
    • Week One Done
      Woland13 earned a badge
      Week One Done
    • One Year In
      bernmeister earned a badge
      One Year In
    • Week One Done
      Scoobystu earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      495
    2. 2
      +Edouard
      225
    3. 3
      PsYcHoKiLLa
      150
    4. 4
      Steven P.
      75
    5. 5
      FloatingFatMan
      71
  • Tell a friend

    Love Neowin? Tell a friend!