Menu
Unmanaged applications are those that you install on your device manually, independent of the CyberArk Identity. Managed applications are those that your sysadmin has deployed and assigned to you using the CyberArk Identity. On iOS devices, only one instance of an application can exist on a device.
C#/WinRT is a NuGet-packaged toolkit that provides Windows Runtime (WinRT) projection support for the C# language. A projection assembly is an interop assembly, which enables programming WinRT APIs in a natural and familiar way for the target language.
WinRT applications are applications that use Windows Runtime framework. More specifically, these are Windows Store and Universal Windows Platform (UWP) applications.
Now contrast that to this definition of unmanaged code: An executable program that runs by itself. Launched from the operating system, the program calls upon and uses the software routines in the operating system, but does not require another software system to be used.
WinRT is a replacement for the age-old C-based Winapi. It is an api that must be usable in many runtime environments. Back 20 years ago, a C api was relatively easy to interop with. That has moved on since then, COM became the universal glue in the last half of the 1990s. Practically any language runtime in common use in Windows supports COM.
A garbage collector is a language runtime implementation detail. The collector for .NET is very different from the collector for Javascript for example. The native objects created in either must observe the very strict rules of the collector. Which in turn means that they would have had to create WinRT versions that are specific to each language runtime. That won't do, even a company as big as Microsoft cannot afford to create and support a specific WinRT version for every language binding. Nor is it necessary, given that these languages already support COM.
Right now, the best binding for WinRT is C++ since COM works more efficiently with explicit memory management. With ample help from the new C++ compiler extensions that make it automatic, very similar to _com_ptr_t of old with C++/CLI-like syntax to avoid it. Binding to managed languages is relatively simple since the CLR already has excellent COM interop support. WinRT also adopted the metadata format of .NET. Afaik, no work has been done at all on managed compilers as of today.
EDIT: Larry Osterman, a well known Microsoft programmer and blogger, left a rather good comment in a now deleted answer. I'll quote it here to preserve it:
WinRT is unmanaged because the OS is unmanaged. And by designing WinRT the way it was designed, it gains the ability to be expressed in many different languages, not just C++, C# and JS. For instance, I could easily see a set of Perl modules which implement the WinRT APIs which work on the desktop. If we had implemented it in .Net, that would have been extremely difficult
WinRT is unmanaged because it is intended to be a replacement for Win32 - the lowest level developer accessible API for Windows. An unmanaged API is still the most potentially performant one that can be exposed to the developer and the reasoning goes that it will always be possible to wrap a managed API on top of it, which is precisely what 'projections' do.
It also means that C++ developers can use WinRT without jumping through the hoops that C++/CLI introduces ( see https://www.stroustrup.com/bs_faq.html#CppCLI ) It does mean though that you will still have to study COM if you want to use WinRT.
The real question is 'why is COM necessary? why did Microsoft have to invent it?' Because plain C++ without all the added facilities of COM is inadequate for real OOP work and Stroustrup's claims of C++ giving you 'portability' are very very disingenuous in light of the working reality. See https://webmechs.com/webpress/2011/11/09/c-versus-objective-c-as-api-substrate/
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With