We Keep Coding

.net framework system calls and cross platform capabilities

I know this question sounds silly, so please let me explain. I've been learning how to program in c# on windows, and have been doing pretty well. One thing i've realized recently though is that i'm not really sure how it works. I know the basics, for example, i know that c# gets compiled to CIL, or MSIL. that is then run though a JIT compiler that produces that native code that is actually run.
My confusion happens when we look at the cross platform capabilities of .net framework though.
From my study of other languages on other platforms such as C on linux, i've learned about system calls and how system calls are necessary anytime a program uses a hardware system such as the hard drive. Now, in C on linux, when you call a function like fopen(), the C standard library on linux ends up eventually making a system call to linux to perform the actual work of fopen(). Once the OS is done, it returns to the calling program.
Now, i imagine that c#/.net framework is similar correct? So when I type file.open(something); it somehow ends up calling into the win32 API, and that handles the operation and then returns to the program. is this assumption correct?
If that is correct though, then how is c# cross platform at all? if when i write file.open(); it calls into the win32 api, how is it that it can run just fine in mono on linux? If it calls the win32 API on linux, it should fail because that doesn't exist there. So is it the .net framework library that calls into the OS API, similar to C? or is it the JIT compiler that does the actual call when the final compilation takes place, depending on what platform it's running on?
So is the final pipeline something like this? ->
-c#, file.open(something) gets compiled to -><
-MSIL, equivalent command in MSIL language, gets compiled to ->
-native code, calls into OS API, either win32 API or linux API via system call
(I'm just asking for a rough overview of the process, no in depth details needed)
Secondly, when the developers of mono where creating Mono, did they just have to go one class at a time, method by method, through the entire .net framework library and have to recreate it to work on linux? Because that would be A LOT of work.
Thank you

The file system is an operating system resource, I/O methods in both .NET Core and .NET Framework wrap calls to the underlying operating system.
Below is the picture that explains how .NET works with non-.NET code (using CCW & RCW).
Ref: managed-code-and-unmanaged-code-in-net
Here is another image that might help understand what is available on which platform
Ref: cross-platform-capabilities-of-dot-net
Now what we need to understand is if you are using any features from .NET's Base Class Libraries, They are implemented to make appropriate calls based on which platform it's running.
However, if you are building an application that should support any platform then there are certain things that we must take care
There are two main requirements for making your software platform-agnostic:
Don’t use any APIs that are not implemented across other platforms
(including Base Class Library methods that are not implemented
outside of Windows and PInvoke calls to Windows-only libraries).
Properly treat file and folder paths so that platform-specific path
separators (i.e., “\” and “/”) are not used explicitly.
If you really want to understand how CLR works, I would Highly recommend the book http://sd.blackball.lv/library/CLR_via_CSharp_(Jeffrey_Richter_4th_Edition).pdf
Reference:
https://www.c-sharpcorner.com/uploadfile/puranindia/managed-code-and-unmanaged-code-in-net/
https://learn.microsoft.com/en-us/dotnet/standard/io/handling-io-errors
https://headspring.com/2018/07/10/cross-platform-capabilities-of-dot-net/

Alternative ways to restricting certain functions being called?

I recently learned that AppDomain is not fully supported in .NET Core, and they have no plans so far of implementing full support.
What I am trying to do is to make a program that can run a plugin, but I don't want that plugin to be able to access certain assemblies or namespaces (for instance System.IO).
The way I used to solve this problem prior to .NET Core will no longer work due to the lack of support.
Is there any other way I can achieve the same in .NET Core?
More concrete example
Let's say I load an assembly using Assembly.LoadFrom from the file system, which contains a plugin method that I then invoke. But I don't want plugins to be able to erase files, etc. In fact, I only want the plugin to be able to call functions from a specific assembly.

Basically they want you to use the platform boundaries for the environment you are developing for.
Sandboxing
Why was it discontinued?
Sandboxing, i.e. relying on the runtime or the framework to constrain which resources a managed application can access, is considered a non-goal for .NET Core. Sandboxing applications and components is also really hard to get right, which is why generally recommend customers not to rely on it. It also makes the implementation more complicated and often negatively affects performance of applications that don’t use sandboxing. Hence, we do not offer sandboxing features in .NET Core.
What should I use instead?
Use operating system provided security boundaries, such as user accounts for running processes with the least set of privileges.
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

Static linking in C#?

The Windows Azure client libraries are very big (several MBs), and I have a fairly small project (on the order of a few hundred KBs) that uses only a few functions from them. Is there a way for me to link in those functions at build time, so that the resultant DLL doesn't get hugely bloated, and I don't have to link the functions in at runtime?
Something like this http://blogs.msdn.com/b/microsoft_press/archive/2010/02/03/jeffrey-richter-excerpt-2-from-clr-via-c-third-edition.aspx, but I get the impression that bundles in the whole DLL.
Thanks!
Edit: Because there are external constraints on the size of the final deliverable DLL, inflating it this much is an absolute last resort - the only other option I'm aware of is just to duplicate the code I use verbatim.

In a word: No.
Remember that even though you only use a few functions, there are likely many other function in the library that those functions use, that you don't even know about!
You can't do this, because you don't have access to all the dependencies. Remember also that those dependencies may even reside in another DLL, and you need to include that entire DLL for the same reason.

What you are looking for sounds very like .NET Native.
Unfortunately for you, its only preview and right now works only with Store Apps for devices. Statements like this
We will continue to evolve and improve native compilation for the range of .NET applications
can be found on the internet but nothing specific about web apps\Azure.
Until then, answer is No

A full operating system in c#

I saw this thread here. I was wondering if this was legit (sounds like it) and what are the drawbacks of doing this. What does it entail to run it stand alone in some architecture?
Thanks

Trying to create an operating system in a managed language is currently an "interesting research problem". This means that it seems possible, but there are still quite a few important issues that need to be resolved (for example, I wouldn't expect "managed windows" anytime soon).
For example, take a look at the Singularity project (also available at CodePlex). It still has some native parts, but very few of them. As far as I know, even the garbage collector is written in managed code (with some language extension that allows safe manipulation with pointers).
The trick is that even managed code will eventually be compiled to native code. In .NET, the compilation is done usually by JITter when you start the application. In Singularity, this is done in advance, so you run native code (but generated from managed). Singularity has some other interesting aspects - for example, processes communicate via messages (and cannot dynamically load code), which makes it possible to do some aggressive optimizations when generating native code.

There's an open source project that's trying to achieve exactly that.
It's called the "Managed Operating System Alliance". Mainly targeted as a framework (supplying users with a compiler, libraries, interfaces, tools and an example kernel), it will also feature a complete operating system kernel and small apps.
For further information:
Website: http://mosa-project.org/projects/mosa
IRC: #mosa on freenode

It is legit. Drawbacks are clear, this is a micro kernel. It is going to be a while before your video adapter driver will be fully managed as well. That takes acquiring critical mass with many devs and manufacturers jumping on the bandwagon. Difficult, but it has happened with Linux as the obvious example.
This is being pursued by Microsoft as well. Singularity has been well published about. It has evolved into a secret research project named Midori. There have been enough leaks about it to know its goal, Wikipedia has an article about it. I think lots of the devs that worked on the original CLR joined this project. Whether it will come to a good end is an open question. If it does, clearly the project backer is probably enough to get that critical mass rolling.

Microsoft's Singularity project is a operating system architecture framework which will allow people to write customizable operating system and probably Microsoft's new operating system will be based on singularity.
.NET is very powerful framework, it evolved and it probably contains everything from metadata attributes to linq and which certainly makes us free from bad pointer errors.
Just like Windows Phone and iPhone, people will be able to write customizable operating system for devices.
Today most of firewall, routers (the hardware ones) contain customized linux, that can be replaced with Singularity kernal and your own business process.
Singularity kernel is small it looks like perfect alternative of embedded windows/linux.
I dont think there is any drawback, except that it is totally new system and it will take time for hardware vendors to supply devices comptabile with this, but it will happen in future.

What can be done in VC++ (native) that can't be done with VC#?

What can be done in VC++ (native) that can't be done with VC#?
From what I can tell the only thing worth using VC++ native for is when you need to manage memory yourself instead of the CLR garbage collector, which I haven't seen a purpose in doing either (but thats for another question to be asked later).

Cross-platform development. Yes Mono exists, and Java's somewhat more predictable to have it function EXACTLY the same on more platforms, you can find a C/C++ compiler for just about any platform out there, where you can't with C#.
Also linking into 3rd-party libraries, while I'm sure there's a way to leverage them in C#, you'll be able to take advantage of them without interop (Marshaling, etc) in C++.
Edit: one last thing: RELIABLE memory management. Yes you can use dispose(), and try-finally, but there's nothing quite like KNOWING the memory is gone when it's popped off of the stack. Through techniques like RAII, when you use well-constructed classes, you will KNOW when your classes release resources, and not waiting around for the GC to happen.

With P/Invoke there is very little that is impossible in .NET (most obviously device drivers).
There are also things where the advice is to not use .NET (e.g. shell extensions, which get loaded into any process that opens a file dialogue1).
Finally there are things which will be much harder in .NET, if possible at all (e.g. creating a COM component that aggregates the FTM).
1 This can create a problem if that process is already using a different version of .NET. This should be alleviated in the future with .NET 4 having the ability to support side by side instances of the runtime.

I'm not sure if you're talking about language features or applications. My answer though is for applications / components.
Really there are only 2 things you cannot do in C# that you can do in C++.
You cannot use C#, or any other .Net language, to write a component for a system that only accepts native components
You cannot use C#, or any other .Net language, to alter certain properties of a CCW for which the CLR does not allow customization
The most notable item here is Device Drivers. This is a framework that only accepts native components and there is no way to plug in a managed component.
For everything else it's possible to do the same thing in C# as it is in C++. There are just a lot of cases where you simply don't want to and a native solution is better. It's possible for instance to manage and manipulate memory in C# via unsafe code or IntPtr. It's just not nearly as easy and generally there's no reason.

You can't write device drivers for one.

I think there are several important points:
You can do anything in C#/C++/Java/Python/Lisp or almost any other language, finally all of them Turing complete ;)... The question is it suits your needs?
There is one big and extreamly important limitation of C#... It runs only one single platform Windows... (Mono is still not mature enough).
There are many applications where GC is just a waste of resources, applications that can't afford you throw up 1/2 of memory untill next gc cycle: Games, Data Bases, Video auido Processing and many other mission critical applications.
Real Time applications (again games, video processing and so on). Non-deterministic GC makes life much harder for them.
In fact, most of desktop applications: Web Browsers, Word Processors, Desktop Environment itself (like Windows Explorer, KDE or Gnome) are written in compiled languages with careful thinking about resources... Otherwise, they would just be terrible bloated applications.

Whereas writing shell extensions in Windows XP was possible in C# it is next to impossible to write shell extensions for Vista and Windows 7. Shell extensions and Namespace extensions (and anything else that uses the new Properties system) (kindof) must be done in C++ unless you're into pain.

There are two obvious answers:
VC# can never run without the .NET
framework. Native C++ can. That may
be necessary in some areas (others
have mentioned device drivers, but
more common examples might simply be
clients where the .NET framework is
not installed. Perhaps you're
distributing an application and you
know not all of your customers are
willing to install .NET, so your
sales would go up if you made an app
that just worked without the
dependency on .NET. Or perhaps you're
working on some mobile device where
the couple of megabytes taken up by
the .NET CF can not be justified. Or shell extensions where using .NET can cause nasty problem for the user.
And VC# can never use C++ language
features. Native C++ can. (Managed
C++ can too, of course, but that's a
different issue). There are, believe it or not, things that can be done more conveniently or elegantly in C++. And they're only accessible if you're programming in C++.
System calls are no problem, however. p/invoke lets you do those from C#, almost as easily as you could from C++.

inline assembler
You cannot use C++-Libraries with classes (P/Invoke can only be used for functions AFAIK)
You cannot use callbacks with P/Invoke.

Is C# in particular and .NET in general self compiling yet (this is not a troll, I genuinely don't know)? If not, you can use VC++ to write C# and .NET, but you can't use C# to do the same job.

This is tongue in cheek, but it also is an answer to your question... you can screw things up much more severely in VC++ than you can in VC#. Not that you can't manage to screw things up severely in VC#, but in general, you can screw them up easier and more thoroughly in VC++.
Again, kind of tongue in cheek, but also an answer to your question. Perhaps not what you were hoping for, but... :-)

There's also hard real-time applications. Any language with a GC cannot be used, just in case it decides to collect during a time-constrained part of the code. Java was notorious for not even allowing you to try (hence the EULA about not using it for software "intended for use in the design, construction, operation or maintenance of any nuclear facility"
(yes, I know they've since made a modified version of Java for real time systems).

For example, it makes sense to use C++ if it's harder to translate the header files for existing libraries than it is to give up the existing managed libraries.

The Main difference is:
C++ is a core language with which you can build stand-alone programs. These Programs communicate directly with the the operating system and nothing else. C++ compilers exist for more or less all platforms (operating systems).
C# is a language that conforms to the CLS. A program written in C# can not start without a CLI engine (.NET Framework, Mono, etc.). A Program written in C# communicates with the .NET framework AND with the operating system. You have a man in the middle. Like all servicing personal, this man can help but it will cause additional trouble. If you want to port, you have a different man in the middle etc. CLI Implementations do not exist for all platforms.
By my opinion every additional framework is a additional source of problems.

Using SSE instructions seems to be one of these cases. Some .NET runtimes will use some SSE instructions, depending on your code. But in VC++, you can use the SSE intrinsics directly. So, if you're writing a multimedia code, you'd probably want C++. (C++/CLI might work as well, presumably)