Linked by Thom Holwerda on Sun 11th Mar 2012 22:21 UTC
Windows And thus, Microsoft bites itself in its behind with Metro. As you all surely know by now, the Metro environment in Windows 8, and its accompanying applications, need to follow a relatively strict set of rules and regulations, much like, say, applications on iOS. For one type of application, Metro has already proven to be too restrictive and limited: web browsers. Microsoft has had to define a separate application class [.docx] - aside from Metro and desktop applications - just to make third party web browsers possible for Windows 8.
Thread beginning with comment 510266
To read all comments associated with this story, please click here.
I think
by Nelson on Sun 11th Mar 2012 23:14 UTC
Nelson
Member since:
2005-11-29

This is at best a stop gap to ease the transition from Win32 to Metro, and as such, I'm not entirely opposed to it not working on ARM.

For example, what incentive do Firefox devs have now to use the WinRT's new asynchronous networking APIs to deliver optimal performance and reliability? Now they are not usage aware (Can't tell when the PC is on metered or data capped mobile broadband, as one example).

Another example is background tasks and conserving battery. Now you have the full weight of a Win32 process running at all times behind the scenes, instead of intelligently multitasking. Architectually, there's not much that was standing in the way of them implementing background transfer tasks and being able to go into a suspended state to conserve battery.

The overall theme is now there is no incentive for proper OS integration, and it will lack even a predictable update mechanism (All Metro Apps update one way, their user-visible Metro App will be updated by the voodoo Win32 process behind the scenes).

Whereas they had the opportunity to albeit more slowly, write a proper port, now they can just slap what they had, render XUL to a DirectX Surface, and call it a day.

Sure, some things like JIT were harder (but not impossible), it would've made sense to address those specific pain points instead of creating another Application class.

Which is why I view this as a stop gap, and I am hopeful that Firefox devs will eventually transition to a more streamlined approach. You want to talk jarring? Downloading setup.exe from Firefox's website, being thrown to Desktop Mode, to install a Browser, make it the default, only to get it's Metro Style counter part. That's fucking jarring.

It's sad, because they could've done so much more. But hey, that's the cross platform mantra, cut corners.

Reply Score: 4

RE: I think
by orestes on Sun 11th Mar 2012 23:39 in reply to "I think"
orestes Member since:
2005-07-06

Indeed. ARM, being a completely different architecture, has no legacy software to speak of and never will. There's exactly zero sense in allowing the old style of coding to get a foothold on the platform, it'd only create unnecessary complications later when it's deprecated entirely.

Reply Parent Score: 2

RE: I think
by Moochman on Sun 11th Mar 2012 23:46 in reply to "I think"
Moochman Member since:
2005-07-06

For example, what incentive do Firefox devs have now to use the WinRT's new asynchronous networking APIs to deliver optimal performance and reliability? Now they are not usage aware (Can't tell when the PC is on metered or data capped mobile broadband, as one example).

Does IE10 make any actual use of this usage-awareness?

You want to talk jarring? Downloading setup.exe from Firefox's website, being thrown to Desktop Mode, to install a Browser, make it the default, only to get it's Metro Style counter part. That's f--king jarring.

Well, if it turns out it's not allowed in the Windows Store and requires desktop switching you should blame Microsoft for that, not Mozilla....

Which is why I view this as a stop gap, and I am hopeful that Firefox devs will eventually transition to a more streamlined approach.

I fully expect them to, since as a browser they surely won't want to be barred from Windows on ARM. Whether Windows on ARM will be worth it to the likes of Adobe, Avid or Autodesk... I kind of doubt it.

Edited 2012-03-11 23:58 UTC

Reply Parent Score: 4

RE[2]: I think
by Nelson on Mon 12th Mar 2012 00:03 in reply to "RE: I think"
Nelson Member since:
2005-11-29


Does IE10 make any actual use of this usage-awareness?


I'm unsure, but I honestly hope that they don't view the bar as simply matching IE10. In fact, I'm pretty confident they don't.


Well, you can blame Microsoft for their asinine Windows Store requirements


I don't really consider the majority of them asinine. I am sympathetic for the JIT related APIs missing (regarding memory mapping Win32 APIs for which there is no equivalent), but for 99% of the other things, it's not something which can be engineered around.


and for any desktop-mode-switching that may or may not be required.


Actually it's not even a question. It is indeed what will happen, according to Microsoft's document. It's obvious this is a suboptimal solution, and one which I think is detrimental to the experience. The ideal situation would be an alternative Firefox Browser in the Windows Store. Not some Frankenstein browser.

IE10 gets away with it, only because they're bundled, so the User doesn't have to jump through these aforementioned hoops.


You seem to forget that the majority of third-party Windows software still relies on Win32 and will for years to come, and it's not a trivial effort to port away from that. I expect that Firefox will hardly be alone in this point, even among Metro UI-ified apps.


They will actually, by definition, be mostly alone. Considering that this is the only supported configuration for deep, deep interop of Win32 and WinRT.

By comparison the subset of Win32 exposed to regular Metro Style apps isn't anywhere near this, so the amount of legacy code is considerably less.

I don't understand why take shortcuts at this point in the development though, they'll only create engineering pain points by not planning for Metro Style applications from the outset.

I just don't think this is a sustainable solution in the long term.


I fully expect them to, since as a browser they surely won't want to be barred from Windows on ARM. Whether Windows on ARM will be worth it to the likes of Adobe, Avid or Autodesk... I kind of doubt it.


It remains to be seen, but I think whoever is first able to counter bringing that kind of information density (where UI chrome is actually valuable) to a Metro Style application in a useable manner, will be onto something special.

If I were Adobe or even the MSFT Office guys, I'd be thinking of creative ways to work with the Metro Design Language to enable efficient workflows. I think it can be done, it's just not trivial or obvious.

Reply Parent Score: 2

RE[2]: I think
by modmans2ndcoming on Mon 12th Mar 2012 01:15 in reply to "RE: I think"
modmans2ndcoming Member since:
2005-11-09

Have you seen Adobe and Avid's work on their iPad apps?

Yes, they are there and they work great.

Reply Parent Score: 2