Answered by:

How are c++ winrt apps compiled and run

Question

Hello, I have a question about how windows 8 c++ apps are compiled and run.

1) Does a windows 8 app written in C++ compile into machine code? I know it heavily uses COM etc (?) but is it so that it compiles into machine code and doesn't use a JIT?

2) I'm not sure exactly what is this "sandbox" that is referred. The app runs in a "sandbox". What is this sandbox? does it mean that there is some layer above the OS that the apps is running on? or does it mean that when compiled it
has certain constraints? or?

Thanks,

Peter

Wednesday, October 29, 2014 9:17 AM

Answers

1.) C++/Cx on the WinRT is compiled to regular native code. Along with the binaries a .winmd file is created that provides the necessary metadata for other languages to integrate with it (this is similar to the MetaData directly embedded into .Net
assemblies). Therefore C++/Cx in contrast to C++ .Net is not run on top of the .Net CLR (Common Language Runtime) and does not use JIT. This also means that different binaries will have to be compiled for ARM and x86 CPUs.

WinRT is an evolution of COM that allows components written using C++ native code, .Net CLR code and HTML5/JS code are easily interoperable with a lot of the heavy lifting being done by the Runtime behind the scenes (everyone who did COM development
knows how tedious that could be).

2.) Compared to Desktop Applications Windows Store Apps are sandboxed. That simply means that security measures are in place to prevent Apps from doing a lot of things. E.g. an App can't directly read or write to other App's local storage. Writing to other
parts of the file system is limited and intentions to access certain folders has to be declared in the App manifest. So technically the C++ machine code is still executing directly on the CPU but there are measures in place to prevent an App from interfering
with system functionality or other App's functionality. You can likely compare that to how code running with "regular user permissions" on the Windows Desktop can't apply changes to system settings that would require "administrative permissions".

Something to keep in mind as well is that the application lifecycle of Windows Store Apps is different. Once they are removed from the foreground and therefore not being in active usage the OS scheduler will no longer give CPU time to the App. It is effectively
frozen. All background processing will have to happen in special background tasks that also have runtime constraints placed upon them regarding (CPU time and memory consumption and aren't able to invoke certain APIs available to regular Apps - e.g. you can't
force an App to open from a background task).

All replies

1.) C++/Cx on the WinRT is compiled to regular native code. Along with the binaries a .winmd file is created that provides the necessary metadata for other languages to integrate with it (this is similar to the MetaData directly embedded into .Net
assemblies). Therefore C++/Cx in contrast to C++ .Net is not run on top of the .Net CLR (Common Language Runtime) and does not use JIT. This also means that different binaries will have to be compiled for ARM and x86 CPUs.

WinRT is an evolution of COM that allows components written using C++ native code, .Net CLR code and HTML5/JS code are easily interoperable with a lot of the heavy lifting being done by the Runtime behind the scenes (everyone who did COM development
knows how tedious that could be).

2.) Compared to Desktop Applications Windows Store Apps are sandboxed. That simply means that security measures are in place to prevent Apps from doing a lot of things. E.g. an App can't directly read or write to other App's local storage. Writing to other
parts of the file system is limited and intentions to access certain folders has to be declared in the App manifest. So technically the C++ machine code is still executing directly on the CPU but there are measures in place to prevent an App from interfering
with system functionality or other App's functionality. You can likely compare that to how code running with "regular user permissions" on the Windows Desktop can't apply changes to system settings that would require "administrative permissions".

Something to keep in mind as well is that the application lifecycle of Windows Store Apps is different. Once they are removed from the foreground and therefore not being in active usage the OS scheduler will no longer give CPU time to the App. It is effectively
frozen. All background processing will have to happen in special background tasks that also have runtime constraints placed upon them regarding (CPU time and memory consumption and aren't able to invoke certain APIs available to regular Apps - e.g. you can't
force an App to open from a background task).