Thread: Point of MSIL, making native?

What is the point of C# producing MSIL code really?
Does JIT come in any other flavor than X86?

Also if the app should run on some mobile device, you'd have to make sure it fits the compact framework, but that's another issue I guess.

I've read that C# can be compiled to native code. What compiler does that and does it work when using .net fw features?

You can use NGen.exe I believe to make native code. I'm sure you still need the .NET framework to run it, but I've never tried.

C#, VB.NET, Delphi.NET, Eiffel.NET, Perl.NET, Managed C++, J#, and all the other .NET languages compile to MSIL. When you run the application, it is this MSIL that is compiled natively. MSIL is the same no matter the platform.

If you wanted to make your own .NET language, what would be easier - writing a compiler for every single platform that .NET runs on, or just writing one compiler that outputs MSIL? And if you wanted to use .NET components used in other languages, what would be easier - knowing how to read native images from every platform or knowing how to compile code in every language, or simply letting .NET and MSIL take care of it for you?

MSIL is there to make language and platform interoperability easy. That's why the IL stands for "Intermediate Language" (I think).

I realize that's the idea, but if JIT (that turns MSIL into native) doesn't support anything but X86 there's not much point in it.

.NET Framework currently only supports x86 and Win32 (.NET Framework runs in Win32 only). There are however ports of the .NET Framework (DotGNU, Mono) that run on *nix platforms - and they run on all platforms that *nix runs on as far as I am aware.

Which means PowerPC, Alpha, SPARC etc.

Well, that seems promising, but so far it it isn't fully compatible with *all* .net apps made for Win32 x86, right?

What all about the things that relate to the Windows API? Or perhaps that's not much a problem because x-windows is much similar to microsoft's??

Mono is adding support for more and more of the .NET Framework components every day. The Windows.Forms support is not fully expanded - which means some Win32 applications will not build with Mono yet.

The whole point of the .NET Framework is that you do not fiddle with Win32 API - you fiddle with the framework. If your application includes Win32 API code then it will not run on GNU/Linux without hacking it.

If your application uses only a .NET-language then it will run under Mono and thus GNU/Linux. Assuming of course that it uses those parts of the .NET Framework that's supported in Mono (or DotGNU).

Oh, and CPU architecture has nothing to do with the .NET Framework or .NET implementations - MSIL looks the same on all platforms and it is run inside the Virtual Machine (Common Language Runtime, according to Microsoft) making it possible to use the same code across multiple architectures.

The whole point of the .NET Framework is that you do not fiddle with Win32 API

Yes, but many .net framework features are object oriented wrappings of the way windows works so that's where I thought there might be a problem...

CPU architecture has nothing to do with the .NET Framework or .NET implementations - MSIL looks the same on all platforms and it is run inside the Virtual Machine

Ofcourse. Just seems the VM is just for X86 but I guess that's changing.

Originally Posted by willkoh

Yes, but many .net framework features are object oriented wrappings of the way windows works so that's where I thought there might be a problem...

From what I understand, only Windows.Forms is reliant on Windows. I can't really think of anything else that is complex and would be reliant on Windows.

Originally Posted by willkoh

Ofcourse. Just seems the VM is just for X86 but I guess that's changing.

Mono is also available for MacOS X so I guess it supports PowerPC also.

From what I understand, only Windows.Forms is reliant on Windows

If the whole windows.forms is reliant on windows that's quite a lot i'd say. How are they going about that in mono?

You'll find a large chunk of the Framework calls Windows-only code (ie the Win32 API), not just System.Windows.Forms.dll. However, it really doesn't matter.

The CLR simply abstracts a lot of platform specific code. It's a big wrapper for the most part.

Let's take the example of popping up a message box. In C#, you might write:

Code:

System.Windows.Forms.MessageBox.Show(this, "Hello world!");

Behind the scenes, the .NET Framework might call the Win32 API method:

Code:

MessageBox(NULL, "Hello, World!", "Default Caption", MB_OK);

And behind the scenes, Mono might make a call to something like:

Code:

// Note - I really don't care how Linux does it
xWindows.msgBox("Hello world!");

Now this would all be well and good. The Mono developers could have written the whole Windows.Forms library as a wrapper around the C code that does the same for XWindows.

The problem is, Linux and other window managers don't work the same as the ones on Windows. It doesn't matter that the code beneath them is different - the point is they are designed differently. You can do different things with GTK+ than with Windows Forms. So rewriting System.Windows.Forms would not have worked. That's why they use GTK+ (or is it GTK#? I don't remember, nor do I really care).

Reading files from the hard disk is the same no matter what OS you're using. That's why Mono and .NET probably both use System.IO. The Windows version of System.IO probably wasn't written with standard POSIX code, it no doubt calls Win32 API FILE * methods. The Mono version of System.IO might use POSIX compliant code so it runs on any OS. However, they both expose the same classes and objects.

So what I'm saying is it doesn't matter that the .NET Framework uses Windows only code - it's that System.Windows.Forms uses a Windows only design. A huge chunk of the framework probably uses Windows only code, but Mono is able to simulate the same functionality without it.

The Mono developers could have written the whole Windows.Forms library as a wrapper around the C code that does the same for XWindows.

That would be the best, for compatibility reasons. Then they could add some stuff within the namespace for additional GTK features.

If an app run in Linux-mono tries to use Windows.Forms, will it simply fail or will it be redirected to equivalent GTK features?

Originally Posted by willkoh

That would be the best, for compatibility reasons. Then they could add some stuff within the namespace for additional GTK features.

If an app run in Linux-mono tries to use Windows.Forms, will it simply fail or will it be redirected to equivalent GTK features?

I would have liked that too. I believe if you write it on Windows using the GTK framework it would run the same on Windows and Linux.

I've never actually tried Mono though, so I can't answer your question.

If it failed, you could always create your own wrapper for System.Windows.Forms to wrap GTK features.