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.
Web browsers and Windows have a troublesome history. Internet Explorer was supposedly tied so deep into Windows, it couldn’t be removed, according to Bill Gates. This put the competition – Firefox, especially – at a severe disadvantage. So much so, even, that the European Union forced Microsoft to implement that silly browser ballot box thing.
In trying to bring the restricted iOS-like environment from Windows Phone 7 to the desktop, Microsoft ran a risk of pissing off the European Union again. Since the Metro environment imposes numerous restrictions that would hinder the development of a decent browser, Microsoft has created a new application class, called “Metro style enabled desktop browser”.
This type of browser will work in both the traditional desktop, with a traditional interface, as well in Metro, with a fancy modern Metro interface. The user then gets to decide which variant of the browser he uses – similar to how Internet Explorer 10 currently works in Windows 8.
Aside from the new WinRT APIs, such a Metro style enabled desktop browser also has access to the full Win32 API, which it needs for things like optimal HTML5 support, as well as support for multiple background processes, JIT compiling, and other browser-specific stuff (like background downloading of files). A Metro style enabled desktop browser runs at the medium of low integrity level.
As great as this all sounds, there is one downside: such a browser will not work in Metro unless it is set as the default browser. This is an artificial limitation set by Microsoft. For what it’s worth, Internet Explorer 10 also suffers from this limitation – but there’s no word yet on if, say, an OEM could opt to ship a different browser as default.
This stuff all came out because the Firefox team has announced it’s working on implementing such a Metro style enabled desktop browser. However, Microsoft has provided very little information on this obscure third application class as of yet, making it very hard for browser developers to properly target it. Of course, Windows 8 is still in development, but considering the company’s past behaviour, it’s easy to assume they’re doing this on purpose.
“As a developer, your job gets pretty hard when you do a Google search for topics surrounding this barely supported third Metro application type and consistently get zero, one, or if you are lucky, two search results. All results being only slightly on topic,” Mozilla developer Brian R. Bondy writes.
Another uncertainty at this point is the ARM version of Windows 8. A Metro style enabled desktop browser must be distributed the old-fashioned way as opposed to through the new Windows Store, and since the traditional desktop is locked down on the ARM version (i.e., it is not possible to install applications outside of the Windows Store on ARM), this currently means Mozilla and Google will not be able to distribute Firefox or Chrome for the ARM version of Windows 8.
All this illustrates just how troublesome it is to implement a locked down iOS-like My First Operating Systemâ„¢ on a versatile, general-purpose computer. What about the HTML rendering engine inside an email client? Or do we need another application class for Thunderbird, a “Metro style enabled desktop email client”?
Personally I think the best would be to allow WinRT to be fully used for desktop applications and give legacy status to Win32.
Metro will most likely suffer the same fate as Vista on the desktop.
From what I have read WinRT isn’t a complete replacement for win32 yet and it is possible to create desktop applications using WinRT. The post I read a while back:
http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode…
Parts of the WinRT will be tied directly to metro such as certain XAML functions only make sense in a Metro environment however I’d say the enterprise preview will probably include more details being released and Windows 9 being the release where WinRT becomes a top to bottom replacement for Win32. Microsoft has a lot on its plate right now so one can only guess that they focused on WinRT for Metro because it is the most urgent as it addresses the tablet and the demand for a native API that many Windows Phone developers have been asking for.
I am aware of it, but what I meant is that Microsoft would do better by fully supporting WinRT for the desktop and forgeting this Metro nonsense.
I do have Windows 8 + MSVC 2011 installed, and also
do Windows development, so I am quite aware how Windows 8 is shaping up.
Why should the ‘forget this metro nonsense’ given that it will be the native API that Windows Phone developers have been clambering for – where you have an API that spans from the tablet to the phone. The two are going to co-exist together with Windows – this idea of the desktop being akin to classic on the Mac (a prior article posted on osnews.com) is quite frankly a persons flight of fancy rather than what reality is actually like. Microsoft may do some stupid things at times but I doubt they’re going to throw their bread and butter (enterprise customers) under the bus with a idea such as Metro replacing the desktop long term given that it simply doesn’t scale when it comes to large and complex applications such as Visual Studio or even Microsoft Office for that matter.
Edited 2012-03-12 16:21 UTC
They have Windows 7 for that. It will be supported and sold to businesses for a long time to come.
But yes, the desktop is legacy. It will most likely be a removable and/or optional package once Windows 9 arrives. Metro isn’t ready now – but this is a 1.0. It’ll get better functionality over time, just like Mac OS X 10.0.
No.
There is just too much bespoke software that relies on a desktop interface and .NET and we aren’t talking about old version of .NET as recent as 3.5 and 4.0.
Also Try firing up VS (even 2011) and there is no way this fits in with Metro.
I think there will be still a classic desktop, but will just have a much “flatter appearance”.
For now? And probably at least for most of current decade. Kinda like there was quite a lot of ~DOS UIs around, they are still around here and there.
But what I suspect might be at work here: a long(ish) term strategic push, for when the tech derived from MS Surface will be really ready for mass adoption – and, to really work, it would also probably require for its UI something like already fairly refined Metro; something MS probably needs to force a bit, in the meantime.
And in a decade, or maybe only half a decade, I imagine it could give something really awesome… (also useful for many “serious” usages and/or particularly the more creative ones – say, a return of inclined drawing board, as a large touchscreen)
Edited 2012-03-19 00:07 UTC
WinRT is built on top of Win32, so the latter isn’t going anywhere. At best, it might become inaccessible to third-party developers at some point.
But this speaks to the issue with third-party browsers, which is that as web clients become increasing rich application platforms with open-standard APIs for accessing native device functionality, it makes more sense for the web client to be tightly integrated with the OS and the underlying device hardware and not open to third-party implementations.
In other words, the IE 10 web client is now effectively a large subset of the native runtime environment on Windows 8, and there are substantial benefits in having one common runtime stack.
Hence Boot2Gecko. If you want a Mozilla stack, use the Mozilla stack. Otherwise choose the Microsoft, Apple, Google (ChromeOS or Android), or Amazon stacks. Or fork one of the open stacks and scratch your itch.
No it is not. It is built on top of ntdll with some additional wrappers to existing Win32 APIs.
Believe me, Metro will be much, MUCH worse than Vista ever was. I love Windows 7, but as it currently stands, Windows 8 is the O.S. that WILL push me towards Linux. Enough is enough!
Windows 7 will be around for a long time to come. I certainly plan to ignore 8 and keep on using 7 indefinitely.
I’ll be keeping up to date with Linux though, prepared for the switch if/when Windows no longer meets my needs, and I’m saying that as someone who definitely isn’t a Linux fan…
This comment brought to you, courtesy of the year 2003.
Can I expect the same special treatment for my Stoffi Music Player? Or what if I want to create a video player?
You’ll probably have to make a version of Stoffi for the app store, if you want it to use Metro, and integrate nicely with Twitter OS..
Yeah, I know. That’s the plan. But it would be cool if they’d let me do this “one version, two styles”-thing. Besides, what if I need to do heavy-duty stuff like FFT processing and hardware accelerated OpenGL for my visualizer plugin system (hint: I do)? Hope they’ll let me, or the Metro version will be crippled.
Btw, what do you mean “integrate nicely with Twitter OS”?
Oh, I call Windows 8 “Twitter OS” because that’s all it seems good for. Making posts on Twitter, sharing photos and stuff. I’ve been playing around with the consumer preview a bit, but because my Windows Live ID is Australian, and the consumer preview is US only, I can’t access any of the online services. Pretty much all I can do is browse the web with it.
I was wondering where my IE 10 disappeared to.
It could be worse. They could just ban other browsers from the web store, like Apple with iOS.
The EU would probably love that. Another excuse to fine Microsoft over having a browser monopoly.
There is nothing strictly wrong with monopolies (they are indeed natural and sensible in some areas).
Abuses of monopolies (or ~cartels) are a separate thing – and what’s the basis of such EU fines (mostly hitting European companies BTW).
In what area are monopolies sensible?
… parts of public utilities, infrastructure; where it’s just natural, efficient, lowers costs; and in return for servicing virtually whole of the population, also unprofitable parts, with stable prices.
Or spectrum, in a way – otherwise it would probably end up in mafia-like web of extortions and/or who can build the more powerful transmitters (or, really, jammers – so going back to extortions). Maybe also financial exchanges.
Or in general, network effects can be and are beneficial, especially where the infrastructure involved is very costly.
Properly regulated of course – EU fines are part of the process, that’s this “separate thing” that I mentioned.
(yeah, sure, I sorta can do business with another power company and such …but, really, this is just procedural cloak, hiding the nature of the situation, as part of those regulatory activities)
Opera?
Opera Mini is… not strictly a browser in the full sense of the word, it doesn’t render HTML and such – it essentially remotely displays the output of a browser engine running on the servers of Opera.
Opera Mobile, a full browser, is not available on iOS. And other “browsers” in appstore just wrap the iOS-native Webkit engine.
I know. Still Opera Mini is a browser and it is not banned =)
Still, Opera Mobile is more of a full proper browser, and is banned.
Opera Mini is closer to a remote desktop app than a browser unto itself.
In fact, there isn’t even an HTML rendering engine in Opera Mini (the app). It’s really just a graphics viewing program with clickable links and forms fields.
It actually has more in common with a PDF viewer than a browser.
Ever hear the saying “the exception that proves the rule”?
Opera Mini is as much of a web browser as a web app is equivalent to native software.
(And I suggest all people who sincerely believe that web apps are a proper replacement to native code to use Chrome OS as their main operating system)
Well, Opera is a special case. Apple bans anything that can load external software and execute it, which includes a browser executing Javascript. However, with the Opera browser for iOS, Javascript isn’t executed; Opera’s server just presents a barely interactive page and updates it remotely. This way, no javascript is actually executed on the device. How well this works for more complex stuff, I have no idea.
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.
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.
Does IE10 make any actual use of this usage-awareness?
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….
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
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.
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.
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.
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.
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.
Not being able to have a JIT (it’s technically possible, but applications that do it would fail validation) is, by itself, enough to prevent any modern web browser from being a native Metro application.
That’s not even considering everything else. It would require a massive effort to move everything over to WinRT. It wouldn’t gain you anything. The new WinRT APIs are still accessible from a hybrid WinRT / Win32 application. The replacement APIs, like networking, don’t actually offer any extra features over the existing Win32 APIs.
Besides, the architecture of Windows 8 requires that the Metro web browser be a hybrid application. That’s just the way it works. The Metro web browser is determined by whatever the default desktop browser is. That’s why, if you install Firefox on Windows 8 and set it as the default browser, the Metro version of IE 10 disappears.
Then this would have been an acceptable area to push for specific work on. A solution to this has implications beyond a browser, so getting some kind of brokered dynamic code generation API (For example, C# supports compiled Expression Tree’s which offer limited dynamic code gen) would be more beneficial in the long run.
Being conscious of mobile broadband networks is reason enough to warrant a rewrite. Firefox accommodates different networking subsystems already, and WinRT’s async networking API would have been no different.
I think massive is a little overstated, but it’d require *some* effort. That’s the entire point of WinRT, to be a clean break. I don’t think it’s asking for much, considering that the way we interact with these key things has fundamentally changed. The old rules no longer apply. So it’s best to be resource conscious.
If you were a pure Metro App, it wouldn’t much matter which is the default browser because you’d be on the Start Menu regardless.
My point is, there’s very little that was in the way of Firefox being a pure Metro Application. The upsides are immense, visibility in the Windows Store could probably go a long way towards Firefox adoption.
Nelson,
Can you point to *specific* code examples so that we might talk meaningful comparisons? I’m not going to believe the new APIs are better just because microsoft claims so; they’ve gone down this path countless times already. So why exactly are the new incompatible APIs better?
I’m not trying to make an assertion myself, but it seems some of the claims being made here warrant stronger evidence than has been given. Event oriented app models all tend to be reimplementing more of the same ideas, I’m curious to know if there’s anything substantially different this time? What’s been gained by creating yet another API?
Edited 2012-03-12 06:15 UTC
Like any other company, even on FLOSS world, the new APIs are always better.
Just look for the sound APIs in Linux or QT APIs in MacOS X, just to cite two examples.
No of course not, the consumer preview is like a week old. I don’t have two sets of code reimplementing the same functionality to link to you.
However, the facts speak for themselves. It’s a fact that the legacy code is not mobile aware, and doesn’t give you the breadth of information that the new networking model gives you.
Chief examples, like I stated before, being mobile broadband cost and cap awareness, and detailed information on network status switches. For instance, being able to know when a user switches from a metered 3G/4G connection to an unmetered WiFi connection is invaluable if you’re trying to be resource conscious.
Another point, which I’ve made before, is that you’re able to intelligently run these networking requests in the background (Through running as a Lock Screen App or by using Background Transfers.) . This is something that’s not possible with vanilla sockets.
By countless you mean how many times exactly? .NET had two paradigms, the second of which mostly carries over into WinRT, except it’s made optionally simpler by the async keyword.
As for native constructs like io-cp, these are a level above them, so not really comparable. They’re just convenient, and coincidentally, the only way forward for Metro Style applications.
Even then, another advantage is the capability isolation. You get what you ask for. So users immediately know what type of network requests on which protocols the application will ever make.
I’m unsure how any of what I said above is not something immediately obvious. It’s a given the old technology doesn’t, or most likely can’t, implement the new technology features. I then go on to cite said features as reasons for implementing the new technology. It seems pretty cut and dry to me.
Developers make the conscious choice, and I think this frankenstein hack let’s Firefox developers have more leg room than I think they should be afforded.
I’m not sure what you mean by event oriented? Do you mean asynchronous? I have a feeling you’re hinting at something here, and I’d be interested in discussing it further.
Nelson,
“No of course not, the consumer preview is like a week old. I don’t have two sets of code reimplementing the same functionality to link to you.”
“However, the facts speak for themselves. It’s a fact that the legacy code is not mobile aware, and doesn’t give you the breadth of information that the new networking model gives you.”
“I’m unsure how any of what I said above is not something immediately obvious. It’s a given the old technology doesn’t, or most likely can’t, implement the new technology features. I then go on to cite said features as reasons for implementing the new technology. It seems pretty cut and dry to me.”
I’ll give you the benefit of the doubt that you know something your not saying which allows you to say these things. However I was hoping for more solid evidence than “immediately obvious” and “facts speak for themselves”, since those are rather empty statements.
You say the networking has mobile cap awareness, but what exactly will apps do that they could not have done in a compatible way with older APIs? Is there really any technical reason that we’d fundamentally have to rewrite our whole application around a new API in order to take advantage of mobile cap awareness? I doubt it very much. I imagine the APIs have more in common than differences, which is why I would have liked to see an explicit concrete counter-example.
>Then this would have been an acceptable area to push for specific work on. A solution to this has implications beyond a browser, so getting some kind of brokered dynamic code generation API (For example, C# supports compiled Expression Tree’s which offer limited dynamic code gen) would be more beneficial in the long run.
This makes you dependent on a specific MS implementation. The quality of dynamic jit engine is a major competitive advantage for particular companies (Moz, Opera, Google, Apple). MS cannot mandate that.
They already are, they use Microsoft’s memory mapping APIs for their JITs, so they’re tied to Win32.
The difference would be that this would be an runtime verified versions of these APIs, which, given the circumstances is an acceptable cost.
JIT engines have farther reaching implications than JavaScript compilation, for example, many Game Engines JIT compile their scripting languages. So obviously, a more general solution is needed. They can’t keep carving out exceptions for apps.
But if Microsoft allows JIT their app store cannot do any meaningful inspection of the software for malware or bad behavior.
Allowing the program to modify machine code or generate entirely new machine code means that it could do anything.
Have you seen Adobe and Avid’s work on their iPad apps?
Yes, they are there and they work great.
It’s a good thing this is a developer preview and not the full blown release so they can work through these issues. It seems silly to me that Mozilla would complain about there not being a bunch of Google search results though. There are Windows forums that are dedicated to these types of problems and since this is all “new” stuff, you would not expect to find anything in a general search.
Actually, I’ve seen reports of new pages showing up in minutes in Google Search results.
It is possible.
Obviously new posts on a properly setup forum would take a few days.
A few resemblances:
– If you open many tiles, they get grouped as workspaces by your left corner. (gnome’s on right).
– Start Menu is a hot corner down left corner. (gnome’s hot corner is same side but up).
– If you start the tiles, you get the to be with no task bar of any other info, but only the mono application envinroment filling all the screen (gnome leaves the top bar).
Well, seems like Microsoft also wants to SHOOT its own foot in favour of mobile mania.
Unfortunately where Gnome 3 holds together as a cohesive whole Win 8 looks and feels like the result of Scotty being drunk at the transporter controls. Metro itself is so 1.0 it hurts.
There’s also the fact that when MS picks a direction, you’re stuck with it sooner or later unless you can leave the platform entirely. OTOH, if Gnome 3 really pisses you off there’s only half a billion other WMs and DEs under the sun to choose from, adapt, fork, rewrite, or otherwise bend to your will.
I’m using GNOME 3 for lack of a decent DE, really. Currently, I’m coping with it. Nothing major, but there’s this bitter sweet taste all over this desktop dilemma across the internet and it makes people move away farther from Linux.
Let’s see how 3.4 goes. As far as I am concerned, neither KDE or XFCE are really productive.
Maybe they should use Bing instead of Google search ? 😉
Probably not.
I can even imagine Microsoft using this is an opportunity for a “cute and fun” PR shots directed at Google.
Imagine some MS guy, in a webcast or such:
“so, Mozilla people are saying the required info can’t be found…”
He then goes on to search (bing?) it, and finds the info rapidly.
“…but, there it is. What? Googling didn’t work for them? Well, then it seems to us that their real problem is depending on Google Search instead of on, say, Bing”
Of course they’re probably more likely to let Ballmer out of his office, for some more chants of his…
Slavery..
All standards, defacto or not, should be open source! That would improve being humana lot
Strange that so few people realize that this madness and slavery.
I hope MS’s actions make people flee to open source solutions. Sadly, MS know the limits of how much they can abuse before people start going elsewhere.
Yes because “owning” a person is totally the same as providing a specification.
Also saying a “specification” should be open source is totally stupid. A specification just documents how something works or how it should work … nothing else.
There are no words to put into words how retarded you sound.
Edited 2012-03-12 19:44 UTC
They have hardware acceleration for drawing, url request capability and dynamic language runtime for javascript as well as fast validating xml parser available. I can see the not being able to set as default browser being a minor issue. Though I have a hard time believing there isn’t a way to associate certain extensions with applications. The javascript jit is a much smaller issue than people let on. What makes web applications slow generally is the DOM is a huge tree structure have to walk through everytime page loads and pass to composition manager as well as update all the nodes with css attributes. Then javascript has walk through node and do whatever programmer desires. The fact that html is generally not xml compliant and parsers have to be a bit sloppy just hurts performance all the more. I have seen these awesome javascript implementations though to be honest I see very little impact on actual web pages, unless it is like a canvas app that is only updating a single dom element. Most web pages are absolute pigs when it comes to resources, even though jquery is tiny the amount of code that actually has to parse and run is quite large they just use very short function and variable names to keep file itself small. I always wondered why iOS isn’t held to same scrutiny as windows when restrictions on that platform are much more severe.
Well, now Microsoft is making Windows just as limited as iOS, at least on ARM. And who knows when the x86 version follows and Apple scraps Mac OS? So the whole world is going to hell, basically.
OK, I’ll bite.
Hardware acceleration – fine. Networking – fine. Maybe. “Dynamic language runtime”? No.
Sure, you can use Microsoft’s JavaScript implementation to write an app, but you can’t embed that as a scripting language inside a web browser. The API does not permit it.
There’s no way to get any other modern JavaScript interpreter running inside Metro. None. Not possible. Any application that attempted to do this would fail validation, and not be available from the store.
I don’t see the relevance of a validating XML parser, either. Modern browsers don’t really use XML for anything. Certainly not a validating parser.
In order to integrate properly into the OS (and Metro, like Android, is built around the idea of things integrating), the web browser has to be the default web browser.
In order for a browser to be the default web browser in the Metro environment, it must also be the default web browser in the desktop environment. It must also be a hybrid Win32 / Metro application.
That’s just the way Microsoft built the thing. There is simply no other way to build a web browser for this platform. A pure native browser would not integrate into the platform as well as a hybrid browser. It could also never perform nearly as well.
No. No part of that description resembles a modern web browser.
Once the page is parsed, it doesn’t matter. Once it’s converted into an internal representation, it doesn’t matter how it got there. It’ll be exactly as fast.
XML parsers are not necessarily faster than HTML parsers. I believe they may be slower, because despite the extra error handling, HTML is not nearly as complex as XML.
Besides, the time taken to parse an HTML document is very low, compared to the time taken to fetch it from the network. And you can parse the document while it’s downloading, so you don’t even need to wait for it to finish.
OK… I don’t understand what you’re trying to say. Are you saying that JavaScript runtime performance is irrelevant because modern web pages contain large amounts of JavaScript?
Basic fact – if you give developers more power, they will use it. You may not have noticed web pages getting faster because of faster JavaScript interpreters. Instead, they’ve been adding functionality. Modern web applications simply wouldn’t be feasible without a modern JavaScript runtime.
It’s important. It wasn’t five years ago, because there weren’t many websites that really pushed JavaScript that hard, but it’s important now.
MS should have built WinRT as a complete replacement for the aged and ugly 90’s Win32. Just how Apple did it with OS X API’s and supported legacy ones for a while (until the 64 bit transition, that is). That would ease development for everyone, regardless of language and whether it is managed or native code.
With WinRT being useful only on Metro, they want to push their troubled and flawed interface, but I can already imagine how this is going to work out with PC crowd – it won’t, it will fail spectacularly. All that is another manager (Ballmer) decision that doesn’t have much sense, except that MS is comfortable enough on the desktop to go ahead with it trying to make a foothold in the market.
The locked down Metro for Windows doesn’t have any sense on PC’s, at least without the non-default option to disable signing check. It will be jailbroken and most people will run that, or otherwise completely ignored by devs. Really no need to pretend to be Apple.
siki_miki,
I agree that WinRT programming should not be dependent on using the metro interface, and that such a limitation is entirely artificial. A “write once, run anywhere” philosophy has delivered tremendous benefit to users and devs alike over the years. There’s no technical reason WinRT apps couldn’t be run on a WIMP desktop with a keyboard and mouse and be just useful as running fullscreen in Metro. Users would benefit from being able to choose where they want to run their apps.
However MS doesn’t want to risk having users who prefer to run their WinRT apps on the desktop rather than in Metro. So MS decided the best thing to do was to ban that possibility from the get-go. The ultimate goal is to rope all Win8 users into using metro and make everything else a jarring experience.
Edited 2012-03-13 18:08 UTC