Point of MSIL, making native?

This is a discussion on Point of MSIL, making native? within the C# Programming forums, part of the General Programming Boards category; What is the point of C# producing MSIL code really? Does JIT come in any other flavor than X86? Also ...

  1. #1
    Registered User
    Join Date
    Jan 2005
    Posts
    70

    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?

  2. #2
    Banned nickname_changed's Avatar
    Join Date
    Feb 2003
    Location
    Australia
    Posts
    986
    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).

  3. #3
    Registered User
    Join Date
    Jan 2005
    Posts
    70
    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.

  4. #4
    Registered User
    Join Date
    Jun 2005
    Location
    Stockholm, Sweden
    Posts
    64
    .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.

  5. #5
    Registered User
    Join Date
    Jan 2005
    Posts
    70
    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??

  6. #6
    Registered User
    Join Date
    Jun 2005
    Location
    Stockholm, Sweden
    Posts
    64
    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.

  7. #7
    Registered User
    Join Date
    Jan 2005
    Posts
    70
    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.

  8. #8
    Registered User Frobozz's Avatar
    Join Date
    Dec 2002
    Posts
    546
    Quote 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.

    Quote 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.

  9. #9
    Registered User
    Join Date
    Jan 2005
    Posts
    70
    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?

  10. #10
    C(++)(#)
    Join Date
    Jul 2004
    Posts
    309
    Quote Originally Posted by willkoh
    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?
    Not really...

    I believe Mono allows for GTK instead of Windows.forms though.
    To code is divine

  11. #11
    Banned nickname_changed's Avatar
    Join Date
    Feb 2003
    Location
    Australia
    Posts
    986
    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.

  12. #12
    Registered User
    Join Date
    Jan 2005
    Posts
    70
    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?

  13. #13
    Banned nickname_changed's Avatar
    Join Date
    Feb 2003
    Location
    Australia
    Posts
    986
    Quote 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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. point to point
    By robarm4 in forum Game Programming
    Replies: 3
    Last Post: 05-02-2007, 12:08 PM
  2. Looking at a Specified Point
    By gpr1me in forum Game Programming
    Replies: 1
    Last Post: 03-31-2006, 05:09 PM
  3. observing whether a point is in a triangle???
    By hebele in forum C++ Programming
    Replies: 1
    Last Post: 05-19-2003, 04:38 PM
  4. About Unix Programming - Making a career desision
    By null in forum C Programming
    Replies: 0
    Last Post: 10-14-2001, 08:37 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21