inteller
Banned
It was a quaint thing to say WP needs more time two years ago. Today it just sounds naive. If developers aren't writing apps for it now, chances are they never will.
The .NET runtime is just a middleware layer. It could sit on top of a mini kernel, not Windows, so that can't be a justification.
The only reason for a Windows kernel is to allow C++ programmers lower-level access to the Win32 APIs.
I think you and I are referring to a native app differently. <snipped> I think native applications in the manner you are referring to are a dieing breed maybe only used for core functions on specific applications.
It was a quaint thing to say WP needs more time two years ago. Today it just sounds naive. If developers aren't writing apps for it now, chances are they never will.
I don't think we can say never, but otherwise agree. People still expecting WP to catch up with iOS and Android in the apps department will be disappointed. It never was a realistic expectation. WP needs to carry and sell itself based on its own merits as an OS, and whatever Microsoft themselves decide to deliver exclusively for WP (which doesn't seem to happening right now).
Apps won't ever be WP's strong suite. For that iOS and Android have just had too much of a head start.
Everyone has their own opinion
Windows Blue. The big "magic bullet" seemingly is being looked at as the big catch all and man I hope it delivers.
Maybe I shouldn't have said "ever be WP's strong suite". Things can change. History is on my side of that argument however. It's happened hundreds of times before, and wishful thinking isn't likely to change the outcome. Microsoft is huge, but not even they can change how markets work.
WinRT doesn't call MinWin (which is an internal thing far below what we're discussing here), it calls the regular Win32 APIs. WinRT is just another user mode app framework. In fact, when I profiled my WinPRT app while it was doing intensive Direct3D work on my HTC 8X, I was surprised to see that the largest amount of time was spent in, get this, GDI32.DLL (42%). The second highest component was the Snapdragon 8960 DX9 graphics driver (at 12%). I asked MSFT about GDI32.DLL on Windows Phone 8 and why it was involved at all but received no response. It would be interesting to profile a pure XAML+C# app on a phone to see how much GDI32.DLL shows up (my guess is a lot since the XAML renderer uses D3D, which is probably the component that touches GDI32). One final note on this topic, in my profile I also saw that DWRITE.DLL was in use. WinPRT apps are not allowed to use DirectWrite. Why not? Basically, you have most of the important Win32 APIs sitting right there on the phone, ready to use yet MSFT artificially restricts accessing them. It's silly.The thing is, the .NET runtime was never designed to be as portable across systems as was the java platform. The runtime environment and Windows aren't really separate entities. One example of this is the extent to which the .NET runtime makes direct calls into MinWin. The two are "baked" together. So, the only viable solution Microsoft really had was to bring MinWin over to WP, and MinWin includes the kernel.
When I said "Windows kernel" I was referring to something more general. Maybe a better term is "Windows Core" or "Win32 API". It's difficult to come up with a description of what I mean by "core" given all the bits and pieces in the Win32 API ... but basically I'm referring to the commonly used components in C++ programs (e.g. File APIs, WinInet, WinSock, etc.). It was silly to artificially prevent access to these well known and battle-tested APIs.I was a C++ programmer and I would disagree. Most of the OS doesn't run in kernel mode. That includes all of the API surface exposed by Win32. If you look at Microsoft's architectural diagrams of Windows, you will find Win32 sitting at least one layer above the kernel.
WinRT doesn't call MinWin (which is an internal thing far below what we're discussing here), it calls the regular Win32 APIs. WinRT is just another user mode app framework. In fact, when I profiled my WinPRT app while it was doing intensive Direct3D work on my HTC 8X, I was surprised to see that the largest amount of time was spent in, get this, GDI32.DLL (42%). The second highest component was the Snapdragon 8960 DX9 graphics driver (at 12%). I asked MSFT about GDI32.DLL on Windows Phone 8 and why it was involved at all but received no response. It would be interesting to profile a pure XAML+C# app on a phone to see how much GDI32.DLL shows up (my guess is a lot since the XAML renderer uses D3D, which is probably the component that touches GDI32). One final note on this topic, in my profile I also saw that DWRITE.DLL was in use. WinPRT apps are not allowed to use DirectWrite. Why not? Basically, you have most of the important Win32 APIs sitting right there on the phone, ready to use yet MSFT artificially restricts accessing them. It's silly.
When I said "Windows kernel" I was referring to something more general. Maybe a better term is "Windows Core" or "Win32 API". It's difficult to come up with a description of what I mean by "core" given all the bits and pieces in the Win32 API ... but basically I'm referring to the commonly used components in C++ programs (e.g. File APIs, WinInet, WinSock, etc.). It was silly to artificially prevent access to these well known and battle-tested APIs.
There are two problems with C++ development on WinPRT (no XAML access and large differences between WinRT and WinPRT) and there are no "good" reasons for those limitations. In a MSDN blog post, one of the Dev Managers for WinPRT said that they weren't 'philosophically opposed' to C++ XAML access but that they 'ran out of time'. I assume this is also the reason for the API inconsistencies, too. This is unacceptable for a strategic product from a company with 90,000+ employees. The dev managers should have recognized the time shortfall early on and fought for more dev help (and upper management should have offered the WinPhone team anything they needed).Silly from your perspective but maybe MS had good reasons of their own.
I think they are simply in the process of building this environment. Just the fact that they are unifying these products is a million mile stones ahead of where MS was just a couple years ago. Its pretty impressive what that company has done over the past 2 years across their entire portfolio.
We shouldn't be sitting around waiting for MSFT to get it "right" with Windows Blue. I don't know what they're smoking up in Redmond these days but they appear to be unaware of the dire situation for them out here in the real world.
There are two problems with C++ development on WinPRT (no XAML access and large differences between WinRT and WinPRT) and there are no "good" reasons for those limitations. In a MSDN blog post, one of the Dev Managers for WinPRT said that they weren't 'philosophically opposed' to C++ XAML access but that they 'ran out of time'. I assume this is also the reason for the API inconsistencies, too. This is unacceptable for a strategic product from a company with 90,000+ employees. The dev managers should have recognized the time shortfall early on and fought for more dev help (and upper management should have offered the WinPhone team anything they needed).
We shouldn't be sitting around waiting for MSFT to get it "right" with Windows Blue. I don't know what they're smoking up in Redmond these days but they appear to be unaware of the dire situation for them out here in the real world.
It doesn't require borrowing devs from other products. The MSFT devs are not single function robots that can only work on one part of a project. You may have a GDI guy that does some work in KERNEL or USER or whatever is required at the time. This mostly happens when a dev is finished with his/her specific work on the main project (and especially when there are piles of beta bug reports to sort through/classify/fix/postpone/etc).Second, those teams are limited to the resources they have, they can't just borrow some developers from the other products. Especially because those developers are not familiar with the products environment.