CLR vs Core CLR

Question

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 ?

Driblet

"Different paths" is the wrong mental model. It starts with the Unixes having a completely different format for the executable file. So you need a C++ compiler and linker that can do this right, currently the GCC toolchain afaik. And #define a bunch of macros that match the desired target OS and processor. The source code is peppered with a boatload of #if, invariably the way C++ code needs to be made cross-platform. They currently have 10 build servers slaving away, constantly looking for errors. – Spearhead

@HansPassant Thanks !! "The source code is peppered with a boatload of #if" you meant same copy of CoreCLR goes to all OS ? – Driblet

Roughly, there is one codebase, but some files will never get used in a specific build since they are too OS-specific. But get used in another build. – Spearhead

@HansPassant I have to be skeptical about your entire answer, only because CoreCLR sources indicate it needs clang, not gcc.github.com/dotnet/coreclr/blob/master/Documentation/building/…. – Moultrie

That's why I said "afaik", I saw a lot of "gcc" in the cmake files. But sure, dismiss it all. – Spearhead

Answer 1

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.

Moultrie