Paul Thurrot: "Tipped off by a reader, I checked my System log in Event Viewer today and what did I find but a stack of pending updates for all of the core apps in Windows 8. I'm not 100 percent sure this is what I think it is. But if we're right, it looks like 18 of the core apps in Windows 8 are about to get updated. Or, almost all of them." Foley confirms it. By far Windows 8's weakest link, so I'm hoping this is true. Especially the Mail application is dreadful.

I sure know I gave Microsoft's vision of how Windows 8 should be used a fair chance for almost a month - until finally one day I couldn't take it anymore.

Now it's business as usual - I've installed a Start Menu replacement that's not as disruptive as the Start Screen and has a decent aggregated search, I boot directly to Desktop and I've disabled the hot corners. I haven't seen the "Modern" crap in weeks.

Modern apps on the desktop don't need to be updated, they need to be killed ... with fire.

I sure know I gave Microsoft's vision of how Windows 8 should be used a fair chance for almost a month - until finally one day I couldn't take it anymore.

I went and sold my iMac and MacBook Pro, bought a two Lenovo computers which I both upgraded to Windows 8 and ran it since it came out publicly. It has been 50 shades a horrible after moving to the PC world but now I've moved back to Mac and happier for it. I gave Microsoft a chance, I really did but the reality is that once the dust settles and one confronts actually having to do something productive with ones computer then it is difficult to overlook all the flaws in Windows over all - Windows 8 being a symptom of a much larger problem of the Windows ecosystem.

Apple has realised that there is a desktop and there is a tablet - cross pollination will occur but in each case of cross pollination the imported idea has to be re-crafted for the new environment. Microsoft on the other hand, even with all evidence regarding 'gorilla arm' and the lack of scalability in Metro to scale up to complex applications we still have them holding onto a false set of ideas. What makes the issue even more funny is WinRT API was billed as a 'new API' when Arstechnica divided deeper to expose that it is merely a wrapper around win32 and nothing has actually changed - we're not really seeing any movement forward but a re-arranging of rotten deck chairs then being labelled as 'brand new'.

Microsoft on the other hand, even with all evidence regarding 'gorilla arm' and the lack of scalability in Metro to scale up to complex applications we still have them holding onto a false set of ideas.

Do you have any specific examples of where WinRT can't scale up to complex application? There's not really much in the way of developers who want to write feature rich applications.

Sure, some things are limited, but not all things. There is also a distinction to be made between something being completely missing from WinRT, and something being done a different way with WinRT.

What makes the issue even more funny is WinRT API was billed as a 'new API' when Arstechnica divided deeper to expose that it is merely a wrapper around win32 and nothing has actually changed - we're not really seeing any movement forward but a re-arranging of rotten deck chairs then being labelled as 'brand new'.

The first is handled by a souped up version of COM, and the second varies.

Some WinRT APIs are completely new implementations of functionality (Sensors, the entire XAML stack, every aspect of the new Application Model for example) and some are even allowed to be called from Desktop applications, and other APIs are wrappers around existing Win32 APIs like StreamSockets wrapping WinSock.

It doesn't really matter though because its an implementation detail that's completely transparent to the developer. Whereas with Windows 7 you directly coded against Win32, with the Windows Runtime you are an additional step removed from Win32, which makes it easy to replace it from under developers noses in the future.

The Windows Runtime could just as easily do the things that Win32 does itself, but it'd be a massive duplication of effort, given that Win32 itself still ships with Windows.

Whereas with Windows 7 you directly coded against Win32, with the Windows Runtime you are an additional step removed from Win32, which makes it easy to replace it from under developers noses in the future.

Hmmmmm building a cleaner API on Win32 sounds like a good idea. They should design this new layer to support multiple languages and platforms, even a mobile subset. They could call it .NET.

The Windows Runtime could just as easily do the things that Win32 does itself, but it'd be a massive duplication of effort, given that Win32 itself still ships with Windows.

Microsoft's API history could be summed as as massive duplication of effort.

So I'm not entirely sure what you find so funny.

What I find funny is that both you and Microsoft execs don't seem to know much about developing software for Microsoft platforms. I develop Windows software for a living so you might want to consult me before providing shoddy defenses.

Hmmmmm building a cleaner API on Win32 sounds like a good idea. They should design this new layer to support multiple languages and platforms, even a mobile subset. They could call it .NET.

And WinRT borrows a lot from .NET, including its metadata language and a lot of the design from the BCL.

If it wasn't for .NET, WinRT wouldn't exist. Furthermore, you bringing up .NET actually proves a great point.

.NET abstracted things like I/O away from Win32. When WinRT implemented those same APIs in native code instead of managed, .NET developers didn't even notice.

The APIs are the same, the concrete implementations differ. This is why its irrelevant what underpins *some* APIs that the Windows Runtime provides. Other APIs as I've said before are completely new to Windows.

I know oversimplifications are your thing, but to this extent, its misleading.

Microsoft's API history could be summed as as massive duplication of effort.

I agree, which is why its nice that the Windows Runtime reduces it by blurring the lines between native and managed code.

All APIs in Windows are not first party to .NET and even HTML5 apps on the platform. If that doesn't make you happy, then your criticism was in bad faith in the first place.

What I find funny is that both you and Microsoft execs don't seem to know much about developing software for Microsoft platforms. I develop Windows software for a living so you might want to consult me before providing shoddy defenses.

Look, it's great that you spend your day playing with DataGrids and WinForms, and its amusing that you're stuck in 2005, but overall, I don't really care and its not really relevant.

This is like the third or fourth time I've had to beat back your misinformation and frankly, extraordinary ignorance about .NET and Windows Development in general. How you keep your job with such a fundamental misunderstanding of what it is you do is beyond me.

This myopic obsession you have with legacy Windows is almost clinical, you need help.

When .NET came out, the idea was to migrate everything to .NET, and C++ got a second class status.

There were two attempts to bring C++ developers to .NET world, first with Managed C++ and with .NET 2.0 C++/CLI.

Additionally, not all wannabe .NET developers, even today, are aware that you can compile to native code on installation time via NGEN.

Vista suffered a bit from the typical over engineering that is part of so many enterprise projects, which lead partly to its failure.

This allowed the Windows division, which isn't a big .NET fan, to make the Tools division go full circle back to native code.

This is why we have the C++ Renaissance, most of the new Windows APIs since Vista are COM based and not Win32, and finally WinRT offers a .NET like experience for native languages.

Even C++/CX is a set of C++ extensions, which although similar to C++/CLI, are used in native code.

While I don't like them, they are no different than C++ Builder's language extensions, or the ones almost every C or C++ compiler offers.

For those that are not aware, .NET applications are actually compiled to native code in Windows Phone 8, and according to some job offers on Microsoft, they might eventually integrate Visual C++ backend with native code backend for .NET.

Personally, I think the best way would be just to have a direct to native code compiler for .NET, or improve NGEN optimizations. But the political wars between Microsoft divisions have most likely lead to WinRT, which was in part the initial design for .NET, before they adopted the bytecode model.

This is nothing new, I have a few scars from political wars between software teams in Fortune 500 companies.

Yeah, it's crazy. WP8 cloud compiling seems to be a step above even what NGEN does, by introducing an additional type of IL that is closer to the metal and avoids the issues that install time NGEN has on Windows 8: Its not immediate.

Windows Store apps typically perform better (from a launch POV) after you've used them for a little while, this is because the NGEN service needs to get around to compiling your app and avoiding JIT.

That said, we live in dark days. Mirosoft's JIT suffers from an almost criminal lack of investment. There's been no real advancement in years prior to this.

Things could be so much closer to native code, but here we are, paying the price for a JIT that doesn't even output SIMD instructions yet (Except for hacked on Windows Phone XNA code)

There is no C++ renaissance. Sinofsky was another irrational managed code hater that couldn't answer most of our technical questions. Yes he got WinRT through but it will be almost entirely ignored just like WPF.

A team of .NET or Java developers can outproduce a team of C++ developers and that won't change with WinRT. C++ is used heavily for games but the enterprise world has zero interest in bringing it back for internal applications.

If anything there is a Java renaissance thanks to Android. The future of internal applications is the web and that has only been strengthened with Microsoft's incredibly stupid move of creating yet another API. The corporate world is getting sick of Microsoft trying to sell a new API every few years, especially when they have a hard time explaining productivity benefits and hope we all just fall for new 'n shiny.

When WinRT implemented those same APIs in native code instead of managed, .NET developers didn't even notice.

.NET developers won't notice any changes in WinRT because they don't care about it. The economic case isn't there. Most .NET developers are not fanboys and will use what they are ordered to or what makes them the most money.

The APIs are the same, the concrete implementations differ.

That's bs, C# is supported but .NET is not directly accessible.

I agree, which is why its nice that the Windows Runtime reduces it by blurring the lines between native and managed code.

No one has asked for such lines to be blurred. Game developers have wanted a C++ layer but has more to do with compatibility than anything else. Microsoft could have provided that without killing Silverlight and creating yet another needless API for application development.

Look, it's great that you spend your day playing with DataGrids and WinForms, and its amusing that you're stuck in 2005, but overall, I don't really care and its not really relevant.

Again you reveal how distant you are from actual Windows development. Fortune 500 hundred companies 'play' with Winforms more than anything else. Microsoft has already FAILED to push WPF and partly due to ignoring criticisms. WinRT will fail even harder because it is another stupid plan from Sinofsky that isn't based in sound thinking. New corporate applications will be built on servers and not with another pointless API that Microsoft wants everyone to use. The corporate world was sick of this bullshit with WPF and we saw what happened to Silverlight, or perhaps you don't remember Microsoft pushing it as the next big thing?

This is like the third or fourth time I've had to beat back your misinformation and frankly, extraordinary ignorance about .NET and Windows Development in general.

I've been right about Windows 8 while you haven't and I'll be right about WinRT as well. I was also right about Sinofsky from day one while you defended his inane plans. I was also right about the stock dropping after the Windows 8 release. I was also right about holiday sales failing to boost Windows 8 sales. I was also right about Surface being a dud.

So go ahead and question my competence when I'm the one with the superior track record of predicting what happens to Microsoft's technologies. I beat all the top Wall St analysts who last year were bullish on MSFT since like you they bought into this stupid, stupid plan. Anyone who took my advice to short the stock at the peak is now sitting pretty.

What makes the issue even more funny is WinRT API was billed as a 'new API' when Arstechnica divided deeper to expose that it is merely a wrapper around win32 and nothing has actually changed - we're not really seeing any movement forward but a re-arranging of rotten deck chairs then being labelled as 'brand new'.

Wow, are you serious? LMFAO... now that's bad. Everyone, including Microsoft, claimed that Metro was all 100% new stuff... now, it turns out it's just a wrapper on top of win32, and at the same time Microsoft wants us to ditch that crusty old win32-based desktop for being so rusty and outdated? I smell some serious irony and hypocrisy wafting in from the west coast right now...

Wow, are you serious? LMFAO... now that's bad. Everyone, including Microsoft, claimed that Metro was all 100% new stuff... now, it turns out it's just a wrapper on top of win32, and at the same time Microsoft wants us to ditch that crusty old win32-based desktop for being so rusty and outdated? I smell some serious irony and hypocrisy wafting in from the west coast right now...

No he's not serious. In fact, he's wrong. And uncharacteristically, so are you.

Now it's business as usual - I've installed a Start Menu replacement that's not as disruptive as the Start Screen and has a decent aggregated search, I boot directly to Desktop and I've disabled the hot corners. I haven't seen the "Modern" crap in weeks.

So basically you've turned your Windows 8 into Windows 7!

Don't get me wrong, after first seeing Windows 8 I refuse to install it on anything I will be using alot, I find it counter productive and much prefer the way Windows 7 handles things.

This is the advantages of the new Windows Store application model -- apps can be updated independently of the OS out of band.

Not just small apps, but essentially every app except the Store app itself can be updated independent of Windows Update, completely via the Store.

In addition, Windows 8 apps like Mail support protocol activation and URI schemes which means another third party app can just be dropped in to replace it.

On the topic of quality, I agree. Some of the stock apps are not very flattering. Some need more work than others. I hope that these updates are significant and fix a lot of the issues. It'll send a clear message that Microsoft is listening to users.

This is the advantages of the new Windows Store application model -- apps can be updated independently of the OS out of band.

This is in no way dependent on having a central repository. See Windows Live Essentials, which in theory at least could be updated at any time, out of band with the OS, or IE9, or .NET (not an app, but still part of the OS). The only advantage of the Store is that you don't litter your system with dozens of updaters, but even that could be avoided without the need of a Store by using an updater to which apps can register. They could name it Windows Update.

In addition, Windows 8 apps like Mail support protocol activation and URI schemes which means another third party app can just be dropped in to replace it.

This is in no way dependent on the Store or unique to Windows 8 either. Windows supported custom URI schemes for like forever.

This is in no way dependent on having a central repository. See Windows Live Essentials, which in theory at least could be updated at any time, out of band with the OS, or IE9, or .NET (not an app, but still part of the OS). The only advantage of the Store is that you don't litter your system with dozens of updaters, but even that could be avoided without the need of a Store by using an updater to which apps can register. They could name it Windows Update.

They could be, and WLE definitely was progress but it wasn't on the scale of what's been ushered in by the Windows Store being the place for applications on Windows.

You now have a central, trusted place to get app updates you know have been vetted to work within the capabilities and constraints they declare to require.

This requires not just out of band distribution, but deep architectural OS sandboxing and brokering which wasn't present pre-Windows 8.

The Windows Store is an updater that you can subscribe to, it just so happens to be a Store front too.

But what we're seeing now is a trend for more agile releases from the various teams within Microsoft as a result of all of this. The Bing applications have been updated various times, same with Microsoft's other stock apps including Mail a few times. This wouldn't be Mail's first update.

I was also wrong before, IE and any other browser which opts into the Metro environment by running a mixed mode app also isn't updated via the Windows Store.

This is in no way dependent on the Store or unique to Windows 8 either. Windows supported custom URI schemes for like forever.

Yes, but we also had named pipes, shared memory, and other IPC which made the use of these URI schemes rather limited.

With WinRT, the only method for app to app communication is custom URIs and protocol associations which pushes these features into the mainstream.

It's not only used for Mail, or for IE, but used for Xbox Music, and Skype, and the People app and a lot others.

You use it intrinsically because it's part of how apps navigate on the Windows Store, if you support secondary tiles, developers could in theory leverage your work and have their app deep dive to any point you expose within yours.

On top of this, if a URI scheme isn't registered on the OS (or a protocol association), then the Windows Store is automatically invoked and all apps containing the relevant support are shown in the results.

This is a much richer and deeper level of integration that has existed before in versions of Windows.

P.S. I've read the comments by others about how other distros have had centralized repositories before, and that's fine, I agree that this has been a long time coming.

And have to use them extensively for work.
Both are really poor user experiences compared to Android or even Ubuntu (let alone OSX).

Windows 8 works, but it just feels like unnecessary hassle compared to previous versions, and I never ever use the "modern" stuff, since everything I need is on the desktop anyway.

Windows Phone 8 is full of bugs and annoyances, my calendars vanish and reappear the next day, Nokia Maps work terrible, apps take a long time to start or even resume, the notification system sucks because each service has it's own tile, and the dicoverability of everything is also vastly inferior to iOS and Android.

Oh, and plug them together: Nothing happens.

So I don't know, Microsoft is competing with inferior products as always, but their current approach just doesn't seem to work.

Which phone do you use? Nearly *all* my apps open extremely fast. Where on Windows Phone 7 apps took a second or two, on Windows Phone 8 I often don't even see the splash screen.

As for your other bugs, I don't know. I do find Windows Phone 8 to be buggier than Windows Phone 7, but that's just relatively speaking -- it hasn't been terrible for me. A reboot last week out of nowhere or something.

It probably will improve enormously when they release 8.1 or something like that.
However, the poor integration with Google services and the vastly inferior mapping application means i'll soon switch back to Android..
About apps loading slow, don't you see a "Loading.." sign when you open apps? most of the apps show that. Depending on the app it might take 5 to 15 seconds.

right, It's resuming..
Maybe it suspends applications or something like that.
The battery life on my winphone lasts much longer than other Android phones i owned (though it doesn't come close to the Z10).

Apps tombstone on Windows Phone 8 only during low memory situations or crashes. If you consistently see "Resuming.." it means the app is loading state from disk instead of from memory. That overlay shows when the app takes more than X amount of time to resume.

So its likely that there's either an issue in how the developer handles tombstoning or the developer is leaking some memory somewhere causing the process manager to kill it.

Today morning i woke up and it won't sync with Google anymore, claiming certificate issues.
This phone OS is so buggy that by the time they get it right, I'm afraid no one will even remember it existed.

nope, windows phone 8 always reloads the apps from scratch for me, it doesn't allow them to stay on the background like android or modern ios.
Pretty annoying with apps such as gchat on 3G, has to load the contact list all the time. Happens with all applications, so at this point I think it's just the OS that doesn't support proper multitasking

nope, windows phone 8 always reloads the apps from scratch for me, it doesn't allow them to stay on the background like android or modern ios.

This isn't true. At all. It is provably false if you read any of the developer documentation that Microsoft provides.

App state is completely persisted in memory while the OS isn't under pressure, or while the app has not crashed. This is called Fast App Switching, or FAS.

In addition to this, there's tombstoning that goes on under low memory conditions or during crashes, as I've explained before.

In an additional addition to this, Windows Phone 7 apps and Windows Phone 8 apps behave differently when launched from their tile.

Windows Phone 8 apps have the ability to opt in to an experience called Fast App Resume (FAR) which means that the app resumes from the same place it previously was, even when launched from a tile.

FAS which I mentioned above only resumes state when you navigate backwards in the OS navigation stack, either by pressing the back button or long pressing back and using the app switcher UI.

The summarize:
FAS+FAR on Windows Phone 8 is what gives apps parity with iOS when it comes to being able to pick up where you left off of, even from a tile launch.

FAS by itself only does this when you navigate backwards into it, by returning to an already running instance. Otherwise, WP7 apps and WP8 apps without the opt-in behave identically and only support FAS.

My hunch is that you're just trying to re-launch the app from the tile and expecting it to pick up from where it left off of, which makes sense if the app supports FAS and opts into FAR, but it isn't always the case.

On top of this there is background agents which can run at regular intervals, or constantly in the case of Audio, Location, and VOIP.

P.S This is different from the situation on Windows 8, where apps support FAS+FAR out of the box and there is no way to opt-out. All Windows 8 apps relaunch from their previous position, even if they're relaunched from their tile.

Windows Phone 8 just brings WP to feature parity with Windows 8 in this respect.

Microsoft is facing some trouble with their new products, but IMO is not a design problem (bad product), but bad marketing and preparation, in the same way Vista was affected.

1. They went too fast in unifying an interface for all devices (tablets, phones, computers), maybe by fear of Android who's dominating the phone market, and will dominate the tablet soon, and which also has one "unsupported" beta version working on AMD laptops around. The problem (and probably the one Google saw) is that desktops and laptops lacked the touch device which may make the user experience less pleasant. MS went first by fear and got burned.

2. Apps and developent kits... Microsoft should learn from Blizzard on this one. Blizz introduce class changes in WoW prior to an expansion became online, allowing users to adapt first. In MS case, they should give the development tools for new technologies way ahead (close to a year) before OS is released, so devs have time to adjust and release good software. They made the same mistake with Net Framework when was released and took like 1 year or more for Microsoft to get its own Messenger ported to it.