I understand that CLR in its current state is bound to windows OS and provides various services by using Win32 APIs internally.
Since .NET Core is platform independent, this basically implies the same IL code can run on different OS. Is CoreCLR OS specific? Or is CoreCLR code written to take different execution paths depending upon current execution environment/OS ?
CoreCLR is the . NET execution engine in . NET Core, performing functions such as garbage collection and compilation to machine code. . NET Core is a modular implementation of . NET that can be used as the base stack for a wide variety of scenarios, today scaling from console utilities to web apps in the cloud.
. NET Core and . NET 5+ releases have a single product version, that is, there's no separate CLR version.
CLR provides the services and runtime environment to the MSIL code. Internally CLR includes the JIT(Just-In-Time) compiler which converts the MSIL code to machine code which further executed by CPU. CLR also uses the . NET Framework class libraries.
CoreRT is a native toolchain that compiles CIL byte code to machine code (e.g. X64 instructions). By default, CoreRT uses RyuJIT as an ahead-of-time (AOT) compiler, the same one that CoreCLR uses as a just-in-time (JIT) compiler.
From the discussion in coreclr repository:
As far as I am aware the CLR in this repo [coreclr] is identical to the CLR in full .NET and the only differences are in the available API set in corefx.
... but seems like there is at least C++/CLI that is missing...
To answer some of the other questions:
Since .NET Core is platform independent, this basically implies the same IL code can run on different OS
Yes. IL is a custom "language". You can write an interpreter/runtime for it that can run on any platform. This is true for other intermediate representations in other languages too, including java bytecode, llvm ir, python bytecode and so on.
Is CoreCLR OS specific? Or is CoreCLR code written to take different execution paths depending upon current execution environment/OS ?
It's a mix. A particular build of coreclr will only work on one OS, because it has been compiled to use features from that OS (including the OS-specific compiler, linking against the right OS-specific libraries, and running code specific to handle that OS). There is also a Platform Abstraction Layer in CoreCLR so that developers can code against one API - based on the Win32 API - and the PAL layer converts it to the right syscalls on Linux and Mac. As pointed out in a comment by @HansPassant, there's a large number of #ifdefs - both on native side and the managed side of CoreCLR.
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