Aw, actually I overlooked this, this SuiteType is already present in the ntdef.h shipped with the WindowsKit 8.0 inside VS11 Beta, Code: typedef enum _SUITE_TYPE { SmallBusiness, Enterprise, BackOffice, CommunicationServer, TerminalServer, SmallBusinessRestricted, EmbeddedNT, DataCenter, SingleUserTS, Personal, Blade, EmbeddedRestricted, SecurityAppliance, StorageServer, ComputeServer, WHServer, PhoneNT, MaxSuiteType } SUITE_TYPE;
I think we've already pretty much accepted that Windows Phone 8 will use a Windows kernel. But good confirmation
OK, there is also PhoneCLR, looks like an editon of CoreCLR. some guids inside mscoreei.dll/sos.dll Code: _CLR_ID_V4_DESKTOP = {267F3989-D786-4B9A-9AF6-D19E42D557EC} _CLR_ID_CORECLR = {8CB8E075-0A91-408E-9228-D66E00A3BFF6} _CLR_ID_PHONE_CLR = {E7237E9C-31C0-488C-AD48-324D3E7ED92A}
Fascinating stuff as always, but I'm pretty shocked at WP8 not being under the .NETCore section (Well, it being under the Silverlight group, as you said). Hopefully we'll hear some good news on the 20th.
as you can see there is no return after this.TargetsAtLeast_Phone_V8_0 = true; this could also mean the developer is trying to set both the flags if version is >=80000 possibly meaning apps targeted above version 80000 will also work on version 7.1 and app say that targets version 70000 might fail to set the this.TargetsAtLeast_Phone_V8_0 to true.
Well, I think .NETCore is pretty much a 'core', and it will be stupid to split a 'core' into different 'profile's, especially considering .NETCore is designed in the same timeframe as Windows 8 and Windows Phone 8. I mean, there is no 'profile' for Windows 8 specific .NETCore right ? so if Windows Phone 8 uses .NETCore, it wont be a seperate 'profile' either, they should be exactly the same '.NET Core 4.5', and be binary compatible at this layer. So, there is possiblity that the 'WindowsPhone8' profile of Silverlight is just another placeholder, and WP8 actually uses .NETCore with WinRT, we never know. Speculating is just speculating, this code doesnt mean too much. lets wait for the 20th. Huh ??
I can't believe it...I was right (about being "worried")! I've sat thru this two hour video and they didn't mention Windows Runtime once. Also the Xaml apps should be written in C# and VB (not C++) so it does seem as though it is still Silverlight in WP8!!!
Well, the actual situation might be much more complicated. WinRT must be there, for exposing the API to native code, at least. Or, how could they port Marble Maze with 'minimal code change' ?? there must be Windows:evices::Sensors::Accelerometer at least. And, they were talking about 'shared native api', is that Win32 API ? unlikely. And, they were talking about mix Xaml/C# and Dx/C++ in a same app, then what is the interface ? P/Invoke ? COM ? WinRT ? They didn't mention a word about WinRT, OK, but not a word about Silverlight / XNA either. MS is weird on infomation disclosing stuff recently. OTOH, there must be a Silverlight environment too, to run legacy apps, and those apps that targets both WP8 and WP7. Maybe its Phone XAML now. OT P.S. Actually WP8 XAML is more similiar to the original Silverlight than SL4WP7, which was SL avalon engine ported to CE and BCL ported to .NET CF. Now WP8 XAML is the avalon graphics core for NT + PhoneCLR which is a variation of CoreCLR. cool.
Yeah that's true they did mention mixing dx/xaml in one app but it really did sound like they'd just reinvented the wheel again. Perhaps they'll put the Accelerometer etc. in the same namespaces but I'm fairly sure it won't be the Win8 code (at least initiailly...maybe WP8.5 huh) If you can't do xaml/c++ or HTML5 apps then it's really just what we had before. Theories... 1: to avoid WP7 app development ceasing (might as well target WP7 & 8, where possible) 2: ease porting of existing apps to WP8-only features 3: Win8 not even finished yet so taking the least amount of OS code for this WP project until after RTM