[Mono-devel-list] A few clarafications

Jonathan Pryor jonpryor at vt.edu
Mon Nov 3 07:45:48 EST 2003


Inline...

On Sun, 2003-11-02 at 17:51, Etienne Boucher wrote:
> Sorry to ask these silly questions, I'm new to .NET and I would like to
> clarify a few things about mono.
> 
> 1) Are 100% .NET applications going to be truly platform-independant the way
> java applications are as long as there is a framework available for the used
> platform?

Yes.  As long as the required assemblies are present (and implemented).

Actually, it isn't a hard and fast requirement that the app be 100%
managed.  It's just a requirement that:

  - Assemblies must be made of fully managed code (that is, don't expect
    MSVC C++ code to work properly, as the generated binaries tend to
    have *both* managed and unmanaged code *in the same binary*).  You 
    can mix managed & unmanaged code between libraries (using 
    P/Invoke), just not in the same assembly.

  - Any native libraries (used by P/Invoke) must be present on all 
    platforms.

Note that it is possible to get fully-managed C++ code, but it takes
work; see http://www.go-mono.com/faq.html.

It's because of the second bullet that Wine apps, Gtk# apps, etc., work
portably.  The assemblies are fully managed, but have unmanaged
dependencies (the Win32 and GTK+ libraries).  As long as the unmanaged
dependencies exist on all the platforms you want, you should work.

Being 100% managed code does simplify things, however.

> And assuming the anwser is yes:
> 2) What about endianess issues or charset issues of a tcp client made for
> Windows that uses bytes for text if it was to run on a PPC?

Bytes are fully portable between all architectures.  0x32 is 0x32
everywhere.  It's when you get to values larger than a byte that you
have problems, such as ints, longs, etc.

The typical solution is to use "network byte order" (NBO) for all
network operations.  This way the byte order on the network can be
assumed, and everyone will interoperate.

The problem is that NBO is big-endian, so the most prevalent platform
(x86) needs to do more work.  But it's faster, too, so who cares? ;-)

I don't know if .NET transparently handles the byte order issues,
though.  You'll have to read the docs (or hope someone else answers).

Alternatively, you can use Text for all network operations.  
(Text *is* The Unix Way (TM).)

This implies ASCII or UTF-8 encoded text, however, as those travel as
bytes, avoiding thus endian issues.

> 3) Will applications that use Windows.Forms without any P/Invoke or Wndproc
> overload will be able to run on mono without using wine as is?

It could be possible, but don't count on it.

That would require that someone implement Windows.Forms without using
Wine.  There has been an effort, but it's stalled (while Wine has
continued).

I don't see it being a reliable solution any time soon, if ever.

 - Jon





More information about the Mono-devel-list mailing list