I'd like to know whether applications designed for WinRT are run within a Virtual Machine or compiled in bytecode in order to be compiled once and run everywhere as the slogan says.
The slogan isn't that. WinRT apps rely on COM for runtime cross-environment calls and a metadata format (winmd) to describe the types.
A WinRT app can be fully native (as is most/all of the framework and even the XAML engine).
Individual DLLs or the app itself could be written in a .NET language, and it will interop almost seamlessly with the rest of WinRT thanks to the extended interop code added to the CLR. Under the hood, it's mostly COM interop as usual, but with added "projections" of chosen WinRT types. This is what makes a WinRT IVector look like an IList in .NET. They're just automatically wrapped.
The strength of WinRT is the binary method calling abstraction of COM and the metadata system (without which the language "projections" wouldn't exist). But it is definitely native, just like COM is, and you can stay in C++ without revving up the .NET CLR if you like.
Related
I'm working on a UWP app (C++/WinRT) that must communicate extensively with a background process. Unfortunately, the background process must remain a full trust "Win32" process. Both are packaged in an MSIX.
For performance and programmability reasons, my first choice would be to turn the background process into an out-of-process WinRT component. App Services is a possibility but not ideal.
I've found numerous code samples for creating an OOP WinRT component via WRL. However, activation is performed via CoreApplication::RunWithActivationFactories(), which (as far as I know) requires an AppContainer.
I know I can consume a WinRT component in a Win32 process. Can I create one? If so, what would activation look like in C++/WinRT?
Yes, from the Windows 10 Version 1903, May 2019 Update, the windows have added support for non-packaged desktop apps to make use of user-defined (3rd party) Windows Runtime (WinRT) Components, which means that we can consume a Winrt component from the Win32 process directly. To successfully reference a C++ Windows Runtime component from a Win32 app, you need to use C++/WinRT to generate projection header files of your component. You can then include these header files in your app code to call your component.
For the detailed information, please refer to this article:
https://blogs.windows.com/windowsdeveloper/2019/04/30/enhancing-non-packaged-desktop-apps-using-windows-runtime-components/.
For the detailed sample, please refer to here:
https://github.com/microsoft/RegFree_WinRT/tree/master/Cpp.
Thanks.
I can't find any deep information about how UWP apps are actually running.
I read on Wikipedia that UWP is based on WinRT. WinRT incorporates some kind of .NET runtime. Is it CLR? Is it some form of CLR or what?
UWP has nothing to do with .NET or the CLR. It is implemented in C++ and uses COM under the hood. It is language agnostic, meaning its API can be consumed by different languages (C#, VB.NET, F#, C++/CX, C++ and JavaScript right now).
If you're using C# to consume the UWP APIs, then the UWP types are projected into equivalent CLR types. For example, if you instantiate a Windows.Web.Http.HttpClient instance, not only do you get a CLR System.Object back, but under the hood the underlying COM object is "activated" a-la RoActivateInstance (or something like that).
Recently I began working in WinRT for Windows Store Apps (and the upcoming Windows 10 Universal Apps) using C#. After working in .NET for awhile previously, I was excited to work with .NET on mobile devices, only to find that WinRT did not feel like home at all.
Constantly I find myself having to search for alternatives to certain classes that I'm familiar with in .NET since often they're not the same or even implemented in WinRT. I figure that the lack of implementation derives from the fact that WinRT at its core is unmanaged, even though the CLR binds to it from managed code.
My question is: What is stopping Microsoft from allowing developers to import and use all of the familiar .NET classes from managed code, even with WinRT running from behind? I know it's not a limitation of the device because my Surface Pro can run desktop .NET apps just fine and the Mono project has succeeded in porting almost the entire .NET API to devices of every kind.
Thanks for your input!
This is a big topic but there are three basic reasons why you don't get the full .NET API from a Windows Store app.
The APIs don't fit on smaller devices like phones. Since the purpose of the Universal Windows Platform is to have apps that can run everywhere, it can't include APIs that are too resource-intensive (disk, memory, CPU, etc.) to run on smaller devices. (Note that even if the managed API appears to be small, it might have a dependency on a large underlying Win32 API).
The APIs aren't compatible with the Store app model. Many APIs that require permissions not granted to Store apps fall into this category, as do APIs that would enable apps to do "unwanted" things to your machine (the degree of "unwantedness" is subjective).
The APIs are deprecated or there are newer alternatives. This was the case with a lot of APIs in Windows 8, where things like file-system access and network sockets were blocked from Store apps because there were newer WinRT equivalents.
Note that Microsoft is always open to re-evaluating whether a specific API should be included or not. For example, Windows 10 brings back many APIs that were banned from Windows 8.1 (such as System.IO and System.Net.Sockets) and has expanded the capabilities granted to apps. You can file feedback via the Windows Feedback app or on UserVoice if you want additional APIs brought back (adding detailed justification never hurts).
I need to make a Windows Store application that exchanges xml serialized data over a TCP connection with a server. Since I need to use Direct3D rendering in the application I went for the c++/cx store application template however I ran into issues with xml serialization/deserialization.
My usual approach in C# would be to use the XmlSerializer and classes with DataContractAttribute annotations. However as soon as I try to import System.Xml.Serialization assembly I get the C1114 error - WinRT does not support #using of a managed assembly. However there are lots of examples that mention using this approach in a Windows Phone app from C#.
So the question is - is only c++/cx limited in support for .NET in Windows Store applications and C# can use all the standard components on phone as well or is switching to C# in this case also not a solution and I need to use the WinRT classes for xml serialization/deserialization?
Your confusion is understandable, what with the variety of frameworks Microsoft has put out there.
C++/Cx is a native binding to the Windows Runtime (WinRT). It does not use any managed code or the .NET framework in any way, which is why you're getting the C1114 error.
C# provides a managed binding to WinRT. It does leverage the .NET framework, so in a C# Windows Store application, you can make use of some of the base-class library. This subset is referred to as the .NET Profile. This article talks about this more: http://blogs.msdn.com/b/dotnet/archive/2012/04/17/net-for-metro-style-apps.aspx
In your specific case, you are using a C++/Cx application because you want access to Direct3D. This makes sense, although it means that you will not have access to System.Xml.Serialization. Instead, as you surmised, you will need to use APIs that are available to C++/Cx to read XML, specifically Windows.Data.Xml.Dom: https://msdn.microsoft.com/en-us/library/windows/apps/windows.data.xml.dom.aspx
Is there any way to use the library of other language in Action Script 3 ?
For C/C++
I learned that we can use Alchemy: http://labs.adobe.com/technologies/alchemy/
But for other languages (here I mean Ruby or Java), can I use their libs via AS3 ?
Alchemy is a cross-compiler from LLVM to ABC, if the language you are interested in can compile to LLVM, then, in theory, you can compile to ABC. So, Alchemy supports (with some tweaks) also C# or Java (but you will have to spend some time getting them to work together, there's no out of the box solution).
AIR (which is a desktop variant of Flash) can use something called "NativeProcess" which means that granted the operating system can execute the code in the library, then you can do so by creating a new process that calls the function from the library you need.
In AIR, again, there's a new feature called ANE (AIR Native Extensions) - this allows you to bind AIR more tightly to the native code. But, it doesn't need to be native as in object files only, it should be something the underlying system can execute. But I have to confess, I never tried creating any such extension, so my knowledge of it is theoretical.
No you can not use Ruby or Java code/libraries in Flash. Alchemy only allows you to use C and C++ libraries. The only way is to port those libraries to ActionScript, or maybe the library you want to use has already been ported to AS3.
It is also possible that there is something similar in AS3. You could ask another question here or on an Flash forum if anyone knows if the library you need has an equivalent in flash.