Universal Apps -- How Do They Work?

[tompkin]

I am just realizing gaps in my current knowledge about a number of technologies that Microsoft is introducing and was wondering if someone might explain something to me about Universal Apps. (Hopefully I won't be too long-winded).

 

A couple of scenarios come to my mind

 

********

1) From what I understand, a Windows 10 developer will be able to write an app on, say, a Windows Phone and it will run on any other Windows 10 device (tablet, phone, etc.)

I pretty much understand how that might work conceptually but I don't understand what the underlying layer is. Is the full "API" on Windows Phone as is on the desktop? Does it produce a "native binary" as we have known it in the past?

 

*********

2)The second seceneio I'm even more ignorant about. Supposedly, we will be able to compile an app for Windows Phone and then with very little effort produce a native Android app? How is this possible?

 

My understanding is with Java where there is a virtual machine running your Java program inside it. The virtual machine itself IS platform specific and does all the underlying machine-specific housekeeping chores.

 

My question is, again, how is a native Window app somehow going to turn into a native Android app? Won't their have to be some kind of "virtual machine" underneath it?  

 

Thanks!

[simplezz]

1) From what I understand, a Windows 10 developer will be able to write an app on, say, a Windows Phone and it will run on any other Windows 10 device (tablet, phone, etc.)

I pretty much understand how that might work conceptually but I don't understand what the underlying layer is. Is the full "API" on Windows Phone as is on the desktop? Does it produce a "native binary" as we have known it in the past?

I neither write Windows specific software nor do I know C#/dotNET particularly well, but as far as I'm aware, you don't write an app on a Windows Phone (didn't you mean for?). In theory, you'd write a single code base for your app (universal app project), package and upload it to the store, and it should run across all those devices. Usability of a single design/experience on a 50 inch tv vs a 5 inch phone is an altogether different kettle of fish.

2)The second seceneio I'm even more ignorant about. Supposedly, we will be able to compile an app for Windows Phone and then with very little effort produce a native Android app? How is this possible?

As far as I know, the only way you can do that is with Xamarin. And the compatibility is sketchy at best. From the looks of Windows 10, it might be easier to write the app in Java/Android, then import it using the new interop tools.

 

My understanding is with Java where there is a virtual machine running your Java program inside it. The virtual machine itself IS platform specific and does all the underlying machine-specific housekeeping chores.

Not on Android 5.0 (lollypop) or above. That uses ART to compile Java applications directly to native code upon installation. The last time I looked, dotNET/RT was still interpreting byte code at runtime (VM), but that may have changed.

 

My question is, again, how is a native Window app somehow going to turn into a native Android app? Won't their have to be some kind of "virtual machine" underneath it?

Xamarin tries to converts your C#/Windows code into compatible Java/Android I think. Or something like that. There isn't an adapter or interop layer as far as I'm aware.

[SharpGreen]

I neither write Windows specific software nor do I know C#/dotNET particularly well, but as far as I'm aware, you don't write an app on a Windows Phone (didn't you mean for?). In theory, you'd write a single code base for your app (universal app project), package and upload it to the store, and it should run across all those devices. Usability of a single design/experience on a 50 inch tv vs a 5 inch phone is an altogether different kettle of fish.

As far as I know, the only way you can do that is with Xamarin. And the compatibility is sketchy at best. From the looks of Windows 10, it might be easier to write the app in Java/Android, then import it using the new interop tools.

 

Not on Android 5.0 (lollypop) or above. That uses ART to compile Java applications directly to native code upon installation. The last time I looked, dotNET/RT was still interpreting byte code at runtime (VM), but that may have changed.

 

Xamarin tries to converts your C#/Windows code into compatible Java/Android I think. Or something like that. There isn't an adapter or interop layer as far as I'm aware.

Xamarin on Android is just a port of Mono. So it works the same as .NET on Windows. There is an interop layer that bring the Android APIs in to C#.

 

Windows Store apps written in C# or VB.NET are compiled to native code with .NET Native, though I'm not sure whether this has made the default yet or not..

 

On the phone I don't fully understand the process but I think they're processed into what's called MDIL which is then compiled on the device when you download the app from the store.

[simplezz]

Xamarin on Android is just a port of Mono. So it works the same as .NET on Windows. There is an interop layer that bring the Android APIs in to C#.

That's even worse than I thought then. I was under the impression that Xamarin compiled to a native Android app. So you're saying that C# apps have to run through mono first on Android? That's going to be a performance killer. Not to mention that they can't be compiled to native code by ART like other Java apps.

On the phone I don't fully understand the process but I think they're processed into what's called MDIL which is then compiled on the device when you download the app from the store.

It may have changed since I last looked. It used to compile to intermediate, then run it through a VM. Android actually compiles Java to native code these days.

[1337ish]

Here is an overview of cross platform:

https://msdn.microsoft.com/en-us/library/bb386063(v=vs.140).aspx

 

Xamarin: https://msdn.microsoft.com/en-us/library/dn879698(v=vs.140).aspx

[SharpGreen]

That's even worse than I thought then. I was under the impression that Xamarin compiled to a native Android app. So you're saying that C# apps have to run through mono first on Android? That's going to be a performance killer. Not to mention that they can't be compiled to native code by ART like other Java apps.

 

Mono-android apps are really just classic NativeActivity apps with C# wrappers around the platform APIs. So they work similarly to any other NativeActivity based app.

 

That's a very heavy simplification of it though but its close enough.

 

Also Mono has had AOT for years, which works on Android as well. But non-AOT, its not really any slower than apps were pre-ART.

 

 

 

It may have changed since I last looked. It used to compile to intermediate, then run it through a VM. Android actually compiles Java to native code these days.

 

 

 

Still talking about Android here? I was talking about Windows Phone in my comment about MDIL...

[libertas83]

First, most of this is not new technology really. It's just taking what already exists and doing it smarter.

1) From what I understand, a Windows 10 developer will be able to write an app on, say, a Windows Phone and it will run on any other Windows 10 device (tablet, phone, etc.)

I pretty much understand how that might work conceptually but I don't understand what the underlying layer is. Is the full "API" on Windows Phone as is on the desktop? Does it produce a "native binary" as we have known it in the past?

This is just pure .NET Framework stuff and is just like Java. The underlying layer is the Common Intermediate Language CIL, or what used to be called MSIL. When you compile a .NET App, you don't compile to a specific CPU, system, or device. You compile to CIL code which has always been cross-platform.

So none of the Universal Apps, or .NET Framework apps (any app in C#) ever compile to a "native binary". When these apps run on the device, they are compiled a second time into "native binaries" which is also called machine code.

The second piece is yes, all Windows 10 devices will have the full API for Universal Apps.

The problem today is that Microsoft split the APIs into subsets to optimize for different types of devices. We have .NET Framework on PCs, .NET Compact Framework for mobile, .NET Micro Framework for robotics I believe, and Silverlight (WPF Everywhere) for browser then later mobile devices. Then, Windows 8 really fractured the whole thing by creating yet another one called Windows Runtime. That was because Steven Sinfosky wanted his own version of .NET that was unique to Windows. Windows 10 is about going back to the roots and trying to unify all of this together.

So code is not the issue, just the APIs.

 

2)The second seceneio I'm even more ignorant about. Supposedly, we will be able to compile an app for Windows Phone and then with very little effort produce a native Android app? How is this possible?

 

The concept of "native apps" is mixing two terms that have very different meanings. A true native app would be code written in pure C++ for full control of the hardware. That is not the Android Runtime nor is it .NET.

It is possible because .NET is cross platform! All that is needed is the .NET Framework to be installed on Android. Xamarin has been doing this for a long time already by shipping the open source version of .NET that has been maintained by the community, Mono. This is done on a per-app basis so that a user doesn't need to figure this out. It just works.

My understanding is with Java where there is a virtual machine running your Java program inside it. The virtual machine itself IS platform specific and does all the underlying machine-specific housekeeping chores.

Correct.

My question is, again, how is a native Window app somehow going to turn into a native Android app? Won't their have to be some kind of "virtual machine" underneath it?  

 

Thanks!

Correct, that is Mono. Only problem is that Mono is unofficial and a separate distinct implementation as well. That means it does not share the same code base as the official .NET Framework.

Microsoft though is finally changing .NET though into an official open source implementation via .NET Core. Mono will eventually merge the unique work they did for Linux/Android into the .NET Core implementation and drop a lot of code it had to replicate just to make it compatible with .NET.

That means when the work is done, any app written in .NET will be much more stable and cross-platform than it is today.

That's even worse than I thought then. I was under the impression that Xamarin compiled to a native Android app. So you're saying that C# apps have to run through mono first on Android? That's going to be a performance killer. Not to mention that they can't be compiled to native code by ART like other Java apps.

It may have changed since I last looked. It used to compile to intermediate, then run it through a VM. Android actually compiles Java to native code these days.

Your misunderstanding how Android works. ART is not native code. The app is written into cross device code called byte-code which then gets compiled on demand on the machine. Now ART uses some tricks which I think you are referring to which will compile to native code before it runs. That is called AOT in Android world. .NET has had the functionality for years, and it is called ngen. Paint.Net actually uses ngen to make it's apps very fast.

From a quick look, Mono has some basic AOT but is fairly limited so there could be a performance penalty in Mono apps. How big it is though, I can't say.

In the future though, with Mono merging into .NET Core, ngen and even better .NET Native will likely be extended into Android.

I don't know

[tompkin]

Hi all, I have much more to discuss but it's 3a.m. where I am so I'll make this short. I just wanted to mention that I heard in a couple of places that on Android, Microsoft is going to be taking care of some "under the hood" plumbing and and the version of Android they are using won't come with Google's Play store or any of it's services. I don't know whether this is good or bad. 

[tompkin]

i"m trying to put the pieces to the puzzle here and I went to the Windows Weekly site and watched the May 1, 2015 show called "Back from Build". I started this show twice and have yet to finish the whole thing but the part where they start talking about what I say below is at ~33:00 mark and lasts about 4 min.

 

They are saying that on Android, that Microsoft is going to use the Android Open Source Project (AOSP). This means that this version of Android will not come with Google services (such as Play Store, Maps, etc.) which is very low level stuff. Microsoft will have to provide this. 

 

Paul Thurrott said that he expected that they would go in the opposite direction, i.e. they would port Universal Apps to Android and iPhone. I'm assuming he meant that he thought they would port universal apps to the stock Android that has the Google Services included.  They mentioned that Xamarin will now not work. I'm not sure why but you can hear this at the above spot in the video. They talk rather quickly so you have to pick it up rather quickly. 

 

They also said that (earlier in the show) that when porting Objective-C, that the number of changes that will have to be made to the code will vary depending on how much the app actually uses the underlying operating system, such as if it does  alot of input-ouput ("i.o.") They seem to imply that if you were porting, for instance, a 2-D game that there wouldn't be that much changes to be made.

 

I'm still learning but I thought I'd throw that out there.  

[+Fahim S. MVC]

That was because Steven Sinfosky wanted his own version of .NET that was unique to Windows.

 

Didn't know this.  Do you have a source?

[gawicks]

So none of the Universal Apps, or .NET Framework apps (any app in C#) ever compile to a "native binary". When these apps run on the device, they are compiled a second time into "native binaries" which is also called machine code.

 

 

That's actually false.

 

With Windows10 ALL C# universal apps are compiled to native using the c++ compiler backend. So there's no jitting involved. They're completely self contained and essentially indistinguishable from a c++ app.

[simplezz]

Your misunderstanding how Android works. ART is not native code.

And where exactly did I say that?

 

The app is written into cross device code called byte-code which then gets compiled on demand on the machine. Now ART uses some tricks which I think you are referring to which will compile to native code before it runs. That is called AOT in Android world. .NET has had the functionality for years, and it is called ngen. Paint.Net actually uses ngen to make it's apps very fast.

ART compiles Java applications to a native executable (yes, real native code, not byte code) when an Application is installed. It only gets compiled once, and thereafter is a native (CPU native) executable. This results in reduced power, cpu, and memory usage. There are no tricks involved as you suggest.

 

From a quick look, Mono has some basic AOT but is fairly limited so there could be a performance penalty in Mono apps. How big it is though, I can't say.

If Xamarin is running C# apps through Mono on Android and not doing a one-shot AOT compilation (as I thought they were) a la ART, then there will doubtless be performance implications.

 

In the future though, with Mono merging into .NET Core, ngen and even better .NET Native will likely be extended into Android.

That would certainly be an improvement. I know from experience that Android Java apps run far better after being compiled into a native executable by ART. Having to JIT the code at runtime will impact not just speed, but battery life too. I wouldn't install anything like that on my Android devices.

[vcfan]

1) From what I understand, a Windows 10 developer will be able to write an app on, say, a Windows Phone and it will run on any other Windows 10 device (tablet, phone, etc.)

I pretty much understand how that might work conceptually but I don't understand what the underlying layer is. Is the full "API" on Windows Phone as is on the desktop? Does it produce a "native binary" as we have known it in the past?

 

yes, its called the Universal Windows Platform which uses an API that is common to iot,phone,tablet,PC(WinRT).

Universal Windows Apps can be written in many different languages(c/c++,c#,html/javascript), and the produced output depends on which language the code is written. c/c++ will of course produce native machine code binaries(asm). c# code will compile to CIL code(think of java bytecode), which is executed by the CLR(think java virtual machine).

 

2)The second seceneio I'm even more ignorant about. Supposedly, we will be able to compile an app for Windows Phone and then with very little effort produce a native Android app? How is this possible?

 

My understanding is with Java where there is a virtual machine running your Java program inside it. The virtual machine itself IS platform specific and does all the underlying machine-specific housekeeping chores.

 

 

Thanks!

2. For this, you don't use WinRT API. Instead, you'll use Xamarin,which is a set of cross platform dev tools that uses Mono, which is an open source .net implementation(c# compiler,CLR,etc). You basically share the same c# code logic between the apps on different platforms, and the the UI controls will map to each platform's native controls so it looks native on whichever platform it is run on.

 

My question is, again, how is a native Window app somehow going to turn into a native Android app?

Windows apps using the Universal Windows Platform won't turn into android apps, unless Microsoft ports the platform to android.

[libertas83]

Didn't know this.  Do you have a source?

http://www.liveside.net/2012/08/22/is-this-what-really-happened-to-silverlight/

It's all hearsay and rumors but Paul Thurrott talked a lot about it as well. The short version is that there was infighting between Satya's Dev division and Steve Sinfosky's Windows division. Each were right in their own way, but the fall out was a new brand new API instead of continuing the evolution of .NET Framework itself and Silverlight.

Bad communication made it much worse as it left the community open to speculation that .NET itself was dead which it is not.

 

 

That's actually false.

 

With Windows10 ALL C# universal apps are compiled to native using the c++ compiler backend. So there's no jitting involved. They're completely self contained and essentially indistinguishable from a c++ app.

What I said is still correct. All C# apps must compile to CIL. That is what makes it work across devices without a developer writing C++ native code for every machine type. It is not C# code if it doesn't do this.

I briefly mentioned later in the post about ngen and .NET Native. .NET has always had the capability to compile to native code without using Just-In-Time Compiling (compile when it runs). That is called ngen and is typically done when the developer calls it on install.

Awhile back, Windows Phone gained the ability to do something like ngen in the cloud when it goes to install on your device to make apps faster.

Now we are evolved to .NET Native which really takes things to the next level and is closer to what you are referring to. With .NET Native, it uses the C++ compiler to optimize the CIL code for multiple devices and removes things it doesn't need if your code never used it.

A full detail of how .NET Native works is at

http://blogs.microsoft.co.il/sasha/2014/04/28/net-native-performance-internals/

So the answer is we are both correct, we just didn't detail the full picture. Regardless of compiling to native code, to be universal it has to support CIL.

 

And where exactly did I say that?

 

ART compiles Java applications to a native executable (yes, real native code, not byte code) when an Application is installed. It only gets compiled once, and thereafter is a native (CPU native) executable. This results in reduced power, cpu, and memory usage. There are no tricks involved as you suggest.

That is still not 100% correct. What I described above for .NET can be mostly applied to ART. ART is by itself not native code just like .NET Native is not native. You are missing the most fundamental aspects of how this works.

Code is compiled to bytecode, always, 100% of the time with ART. That is the foundation. A second compile is done always, 100% of the time. When that second compile happens is what matters. AOT is a trick to do it at install time instead of runtime. That is the only big difference here, but one that improves performance because it doesn't have to compile every time it runs.

Now I can't say for certain if ART is more like ngen or .NET Native in functionality but it would be one of them.

 

If Xamarin is running C# apps through Mono on Android and not doing a one-shot AOT compilation (as I thought they were) a la ART, then there will doubtless be performance implications.

 

That would certainly be an improvement. I know from experience that Android Java apps run far better after being compiled into a native executable by ART. Having to JIT the code at runtime will impact not just speed, but battery life too. I wouldn't install anything like that on my Android devices.

Agreed, without AOT optimizations there will be a hit. I couldn't tell from quickly looking at Xamarin how well it does AOT. Mono supports it but there are issues which Mono is full of because it basically reverse engineers .NET instead of building on top of that. In the next couple years, that will change as .NET will be fully supported on Linux going forward.

[tompkin]

That's actually false.

 

With Windows10 ALL C# universal apps are compiled to native using the c++ compiler backend. So there's no jitting involved. They're completely self contained and essentially indistinguishable from a c++ app.

C++ compiler's normally produce native Win32 binaries. Are you saying then that C# universal apps compile to Win32 binaries?

[vcfan]

On the phone I don't fully understand the process but I think they're processed into what's called MDIL which is then compiled on the device when you download the app from the store.

they're actually processed into MDIL on the server when you submit your app for certification. what you download is the actual native binary. No JIT on windows phone apps. this didn't apply to windows store apps on windows 8 though, only phone. Windows 10 app downloads will all probably be native images.

[simplezz]

That is still not 100% correct. What I described above for .NET can be mostly applied to ART. ART is by itself not native code just like .NET Native is not native. You are missing the most fundamental aspects of how this works.

Code is compiled to bytecode, always, 100% of the time with ART. That is the foundation. A second compile is done always, 100% of the time. When that second compile happens is what matters.

The fact remains that the end result is a CPU native executable produced by ART from Java source code. What steps ART needs to perform to achieve that doesn't concern me, just as a C/C++'s compiler's obj file generation and linker steps don't concern me. You're haggling over the internals of a compiler when the subject of this conversation is, whether or not ART produces native executables using AOT compilation. It does.

 

AOT is a trick to do it at install time instead of runtime.

Precompiling a C/C++ program is also AOT compilation. It's compiled before it's run. There's little difference except that it's automated on Android.

 

Now I can't say for certain if ART is more like ngen or .NET Native in functionality but it would be one of them.

Well certainly the goals are similar. I couldn't speak to the internals though.

[Eric Veteran]

Universal apps are almost the same thing as WinRT apps. The difference being the universal environment is identical across all platforms the runtime is available for.

 

Think Unity, but not just for games.

[Guest]

Universal apps are almost the same thing as WinRT apps. The difference being the universal environment is identical across all platforms the runtime is available for.

 

Think Unity, but not just for games.

 

They are exactly the same thing as WinRT apps. It is just fancier calling them Universal apps instead of Windows Runtime apps.

[tompkin]

 

yes, its called the Universal Windows Platform which uses an API that is common to iot,phone,tablet,PC(WinRT).

Universal Windows Apps can be written in many different languages(c/c++,c#,html/javascript), and the produced output depends on which language the code is written. c/c++ will of course produce native machine code binaries(asm). c# code will compile to CIL code(think of java bytecode), which is executed by the CLR(think java virtual machine).

 

2. For this, you don't use WinRT API. Instead, you'll use Xamarin,which is a set of cross platform dev tools that uses Mono, which is an open source .net implementation(c# compiler,CLR,etc). You basically share the same c# code logic between the apps on different platforms, and the the UI controls will map to each platform's native controls so it looks native on whichever platform it is run on.

 

Windows apps using the Universal Windows Platform won't turn into android apps, unless Microsoft ports the platform to android.

This, to me, makes the most sense. The Windows Universal Platform platform uses the WinRT API. This API is the full API regardless of which Windows 10 device you are using. In the case, of the .NET languages they would still compile to a CIL usng WinRT API.

 

[in response to another poster]

It's highly unlikely (impossible?) that C# could ever use a C++ compiler because the language specifications are so different. C# has always been ahead of C++ in terms of language features (think Generics) so there would be features in C# that the C++ compiler could not handle. There might be some type of compiler but it wouldn't be a C++ compiler.   

[Andre S. Veteran]

#2 - It's the opposite way around. Microsoft has demonstrated that with a new SDK you'll be able to easily convert Android and iOS applications to universal Windows apps.

If you want to write an application that runs across all platforms, use a cross platform technology like Xamarin. Universal Windows apps are limited to Windows platforms.

[Andre S. Veteran]

[in response to another poster]

It's highly unlikely (impossible?) that C# could ever use a C++ compiler because the language specifications are so different. C# has always been ahead of C++ in terms of language features (think Generics) so there would be features in C# that the C++ compiler could not handle. There might be some type of compiler but it wouldn't be a C++ compiler.

Actually .Net Native works by compiling IL to the representation used by the C++ backend so they can then apply the same compile and link-time optimizations. Pretty amazing stuff.

[DevTech]

libertas83, on 03 May 2015 - 04:28, said:

That was because Steven Sinfosky wanted his own version of .NET that was unique to Windows.

Didn't know this.  Do you have a source?

 

 

There might be a lot of things to dislike about Sinofsky but most of his ideas were driven by his perception of market and technical issues of that time period for which sources and discussions are endless if you dig a bit into the now dead blogs of thousands of WPF fans which he lost from a poor communication style that failed to show an inclusive vision of the future.

 

There is also no official history so any source will be guesswork. The most explicit source of information would be the blog of Scott Barnes.

 

Attempting a quick summary:

 

This was the time where every tech article included some reference to "Post PC" and "indie" developers everywhere were rushing to the Android and Apple App bonanza. This was the world of thinner and lighter and longer battery life in the Post-PC tablet world that never happenned. Sinofsky made one of many possible choices to go with a hybrid solution to compete in this new Post-PC world. In a battery constrained environment, C++ produces the most efficient code to minimize CPU usage. Hence he attempted to create a big push around making Apps in C++ instead of .NET although the architecture they came up with really gave equal status to C++, C# and Javascript.

 

Before this, C++ did not have a modern UI since WPF was .NET only. With this approach, of a native code minimal CPU battery drain, the UI needed to be part of the Windows API and not a .NET runtime layer on top of the O/S. WinRT took the essentials of .NET and WPF/Silverlight and adsorbed them into Windows which also addressed many of the WPF performance bugs people were complaining about in Windows 7. The technical effort was a huge sea change that gave Javascript and C++ acccess to the Windows UI layer and improved the performance for C# folks. The effort was communicated horribly and I wish I could think of a better word since horrible puts it far too nicely.

 

During all of this, there were lots of indications that Sinofsky had a personal displike for .NET and that might have blocked his ability to market WinRT as an improved WPF which could have been achieved by making an evolving WinRT part of an evolving WPF on the desktop side since embedding the core of WPF into Windows was an important evolutionary step which he nicely made happen. Instead important WPF/Silverlight people left Microsoft or jumped ship to Azure or vanished into WinDiv.

 

The WPF team has been re-assembled but there has been no statement of direction so far to know if my above concept is on their radar.

[BajiRav]

1) From what I understand, a Windows 10 developer will be able to write an app on, say, a Windows Phone and it will run on any other Windows 10 device (tablet, phone, etc.)

I pretty much understand how that might work conceptually but I don't understand what the underlying layer is. Is the full "API" on Windows Phone as is on the desktop? Does it produce a "native binary" as we have known it in the past?

From what I understand (and I haven't yet seen all documentation),

Your app is split into UI and logic. You will have multiple UI parts (one for every kind of the device you want to support). The app then loads UI appropriate to the device it is running on (Xbox, Phone, desktop etc.)

[Andre S. Veteran]

This was the time where every tech article included some reference to "Post PC" and "indie" developers everywhere were rushing to the Android and Apple App bonanza. This was the world of thinner and lighter and longer battery life in the Post-PC tablet world that never happenned. Sinofsky made one of many possible choices to go with a hybrid solution to compete in this new Post-PC world. In a battery constrained environment, C++ produces the most efficient code to minimize CPU usage. Hence he attempted to create a big push around making Apps in C++ instead of .NET although the architecture they came up with really gave equal status to C++, C# and Javascript.

 

Before this, C++ did not have a modern UI since WPF was .NET only. With this approach, of a native code minimal CPU battery drain, the UI needed to be part of the Windows API and not a .NET runtime layer on top of the O/S. WinRT took the essentials of .NET and WPF/Silverlight and adsorbed them into Windows which also addressed many of the WPF performance bugs people were complaining about in Windows 7. The technical effort was a huge sea change that gave Javascript and C++ acccess to the Windows UI layer and improved the performance for C# folks. The effort was communicated horribly and I wish I could think of a better word since horrible puts it far too nicely.

Thanks for the great write-up.

 

As a .NET dev these were some dark years where I thought Microsoft was just miscommunicating but some part of me feared they actually lost their mind and were deprecating .NET. These were times where entering "Is .NET" in Google had "Is .NET dead" as first suggestion. Today it has become "Is .NET open source" (to which the answer is yes). How attitudes and communications have changed at Microsoft in the last few years is very impressive.

[DevTech]

Some notes on the topic of universal apps.

 

Windows Targets:

 

• Web [ Javascript or Asm.js]
• Windows Desktop [C#/XAML(WPF) or C++/DirectX]
• Windows Desktop "Metro" [C#/XAML(WinRT) or C++/XAML(WinRT) or Javascript/WinJS(WinRT)]
• Windows Tablet (Metro) <same as above>
• Windows Phone (Metro) <same as above>
• Future XBox One with Windows 10 <same as above>
• Windows Surface Hub (3 people, 100 point touch) <same as above>
• Windows Embedded (Kiosk, industrial) <same as above>
• Windows Internet of Things (IOT) <headless?>

 

Other Targets:

 

• Android Phone/Tablet [C#/Xamarin]
• Apple Phone/Tablet [C#/Xamarin]
• Apple OSX Desktop [C#/Mono]
• Linux Desktop [C#/Mono]

 

Also, Unity 3D uses C# and covers most of the above targets and with a 3rd party UI system rendered to the 3D surface would also be close to "Universal"

 

 

The naming saga:

 

Metro --> WinRT --> Modern --> Windows Store Apps --> Universal App Platform (UAP) --> Universal Windows Platform (UWP)