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.
Order by: Score:
moondevil
Member since:
2005-07-08

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.

Reply Score: 4

kaiwai Member since:
2005-07-06

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.

Reply Score: 1

moondevil Member since:
2005-07-08

"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:
"

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.

Reply Score: 3

kaiwai Member since:
2005-07-06

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

Reply Score: 2

Thom_Holwerda Member since:
2005-06-29

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.


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.

Reply Score: 1

lucas_maximus Member since:
2009-08-18

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".

Reply Score: 2

zima Member since:
2005-07-06

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

Reply Score: 2

butters Member since:
2005-07-08

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.

Reply Score: 3

moondevil Member since:
2005-07-08

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.


No it is not. It is built on top of ntdll with some additional wrappers to existing Win32 APIs.

Reply Score: 3

1c3d0g Member since:
2005-07-06

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!

Reply Score: 6

Dave_K Member since:
2005-11-16

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...

Reply Score: 2

tomcat Member since:
2006-01-06

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!


This comment brought to you, courtesy of the year 2003.

Reply Score: 2

Comment by ephracis
by ephracis on Sun 11th Mar 2012 23:04 UTC
ephracis
Member since:
2007-09-23

Can I expect the same special treatment for my Stoffi Music Player? Or what if I want to create a video player?

Reply Score: 3

RE: Comment by ephracis
by Moredhas on Mon 12th Mar 2012 21:00 UTC in reply to "Comment by ephracis"
Moredhas Member since:
2008-04-10

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..

Reply Score: 2

RE[2]: Comment by ephracis
by ephracis on Mon 12th Mar 2012 21:04 UTC in reply to "RE: Comment by ephracis"
ephracis Member since:
2007-09-23

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"?

Reply Score: 2

RE[3]: Comment by ephracis
by Moredhas on Mon 12th Mar 2012 21:07 UTC in reply to "RE[2]: Comment by ephracis"
Moredhas Member since:
2008-04-10

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.

Reply Score: 4

Comment by Drumhellar
by Drumhellar on Sun 11th Mar 2012 23:09 UTC
Drumhellar
Member since:
2005-07-12

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


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.

Reply Score: 3

RE: Comment by Drumhellar
by Stephen! on Sun 11th Mar 2012 23:29 UTC in reply to "Comment by Drumhellar"
Stephen! Member since:
2007-11-24

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.

Reply Score: 1

RE[2]: Comment by Drumhellar
by zima on Sun 11th Mar 2012 23:56 UTC in reply to "RE: Comment by Drumhellar"
zima Member since:
2005-07-06

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).

Reply Score: 4

Bill Shooter of Bul Member since:
2006-07-14

In what area are monopolies sensible?

Reply Score: 3

RE[4]: Comment by Drumhellar
by zima on Mon 12th Mar 2012 16:28 UTC in reply to "RE[3]: Comment by Drumhellar"
zima Member since:
2005-07-06

... 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)

Reply Score: 2

RE: Comment by Drumhellar
by viton on Sun 11th Mar 2012 23:31 UTC in reply to "Comment by Drumhellar"
viton Member since:
2005-08-09

They could just ban other browsers from the web store, like Apple with iOS.

Opera?

Reply Score: 2

RE[2]: Comment by Drumhellar
by zima on Sun 11th Mar 2012 23:48 UTC in reply to "RE: Comment by Drumhellar"
zima Member since:
2005-07-06

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.

Reply Score: 4

RE[3]: Comment by Drumhellar
by viton on Mon 12th Mar 2012 15:17 UTC in reply to "RE[2]: Comment by Drumhellar"
viton Member since:
2005-08-09

I know. Still Opera Mini is a browser and it is not banned =)

Reply Score: 2

RE[4]: Comment by Drumhellar
by zima on Mon 12th Mar 2012 16:30 UTC in reply to "RE[3]: Comment by Drumhellar"
zima Member since:
2005-07-06

Still, Opera Mobile is more of a full proper browser, and is banned.

Reply Score: 2

RE[4]: Comment by Drumhellar
by phoenix on Mon 12th Mar 2012 17:13 UTC in reply to "RE[3]: Comment by Drumhellar"
phoenix Member since:
2005-07-11

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.

Reply Score: 3

RE[4]: Comment by Drumhellar
by BallmerKnowsBest on Mon 12th Mar 2012 19:02 UTC in reply to "RE[3]: Comment by Drumhellar"
BallmerKnowsBest Member since:
2008-06-02

I know. Still Opera Mini is a browser and it is not banned =)


Ever hear the saying "the exception that proves the rule"?

Reply Score: 2

RE[4]: Comment by Drumhellar
by Neolander on Mon 12th Mar 2012 19:17 UTC in reply to "RE[3]: Comment by Drumhellar"
Neolander Member since:
2010-03-08

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)

Reply Score: 2

RE[2]: Comment by Drumhellar
by Drumhellar on Mon 12th Mar 2012 05:11 UTC in reply to "RE: Comment by Drumhellar"
Drumhellar Member since:
2005-07-12

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.

Reply Score: 3

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 UTC 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 Score: 2

RE: I think
by Moochman on Sun 11th Mar 2012 23:46 UTC 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 Score: 4

RE[2]: I think
by Nelson on Mon 12th Mar 2012 00:03 UTC 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 Score: 2

RE[3]: I think
by ba1l on Mon 12th Mar 2012 04:01 UTC in reply to "RE[2]: I think"
ba1l Member since:
2007-09-08

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.


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.

Reply Score: 5

RE[4]: I think
by Nelson on Mon 12th Mar 2012 04:34 UTC in reply to "RE[3]: I think"
Nelson Member since:
2005-11-29


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.


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.


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.


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.



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.


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.

Reply Score: 1

RE[5]: I think
by Alfman on Mon 12th Mar 2012 06:14 UTC in reply to "RE[4]: I think"
Alfman Member since:
2011-01-28

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

Reply Score: 6

RE[6]: I think
by moondevil on Mon 12th Mar 2012 08:44 UTC in reply to "RE[5]: I think"
moondevil Member since:
2005-07-08

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?


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.

Reply Score: 3

RE[6]: I think
by Nelson on Mon 12th Mar 2012 12:53 UTC in reply to "RE[5]: I think"
Nelson Member since:
2005-11-29


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;


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.


they've gone down this path countless times already. So why exactly are the new incompatible APIs better?


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 not trying to make an assertion myself, but it seems some of the claims being made here warrant stronger evidence than has been given.


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.


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?


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.

Reply Score: 2

RE[7]: I think
by Alfman on Mon 12th Mar 2012 23:51 UTC in reply to "RE[6]: I think"
Alfman Member since:
2011-01-28

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.

Reply Score: 4

RE[5]: I think
by dsmogor on Mon 12th Mar 2012 12:50 UTC in reply to "RE[4]: I think"
dsmogor Member since:
2005-09-01

>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.

Reply Score: 4

RE[6]: I think
by Nelson on Mon 12th Mar 2012 12:57 UTC in reply to "RE[5]: I think"
Nelson Member since:
2005-11-29

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.

Reply Score: 2

RE[7]: I think
by zlynx on Mon 12th Mar 2012 15:22 UTC in reply to "RE[6]: I think"
zlynx Member since:
2005-07-20

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.

Reply Score: 2

RE[2]: I think
by modmans2ndcoming on Mon 12th Mar 2012 01:15 UTC 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 Score: 2

Jaktar
Member since:
2011-06-03

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.

Reply Score: 1

Lennie Member since:
2007-09-22

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.

Reply Score: 3

Win8 resembles GNOME Shell
by Jason Bourne on Mon 12th Mar 2012 02:47 UTC
Jason Bourne
Member since:
2007-06-02

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.

Reply Score: 4

RE: Win8 resembles GNOME Shell
by orestes on Mon 12th Mar 2012 11:42 UTC in reply to "Win8 resembles GNOME Shell"
orestes Member since:
2005-07-06

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.

Reply Score: 5

Jason Bourne Member since:
2007-06-02

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.

Reply Score: 2

Bing search
by Lennie on Mon 12th Mar 2012 11:53 UTC
Lennie
Member since:
2007-09-22

Maybe they should use Bing instead of Google search ? ;-)

Probably not.

Reply Score: 3

RE: Bing search
by zima on Mon 12th Mar 2012 16:38 UTC in reply to "Bing search"
zima Member since:
2005-07-06

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...

Reply Score: 2

Comment by andih
by andih on Mon 12th Mar 2012 17:11 UTC
andih
Member since:
2010-03-27

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.

Reply Score: 2

RE: Comment by andih
by lucas_maximus on Mon 12th Mar 2012 19:38 UTC in reply to "Comment by andih"
lucas_maximus Member since:
2009-08-18

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

Reply Score: 1

Not sure why browsers are so special
by ToddB on Mon 12th Mar 2012 18:36 UTC
ToddB
Member since:
2012-01-25

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.

Reply Score: 1

Moochman Member since:
2005-07-06

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.

Reply Score: 4

ba1l Member since:
2007-09-08

They have hardware acceleration for drawing, url request capability and dynamic language runtime for javascript as well as fast validating xml parser available.


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.

I can see the not being able to set as default browser being a minor issue.


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.

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.


No. No part of that description resembles a modern web browser.

The fact that html is generally not xml compliant and parsers have to be a bit sloppy just hurts performance all the more.


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.

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.


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.

Reply Score: 2

Already failed strategy
by siki_miki on Tue 13th Mar 2012 17:17 UTC
siki_miki
Member since:
2006-01-17

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.

Reply Score: 2

RE: Already failed strategy
by Alfman on Tue 13th Mar 2012 18:04 UTC in reply to "Already failed strategy"
Alfman Member since:
2011-01-28

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

Reply Score: 2