[Gtk-sharp-list] Cross Platform Assemblies?
Mon, 17 Mar 2003 11:53:35 +0100
On 03/15/03 Charles Iliya Krempeaux wrote:
> Looking at GLib's "gtypes.h", I see definitions like:
> typedef int gint;
> Now, what this means is that something like a "gint" is going to be a
> different size on different platforms. (On a x86 architecture it will
> be 32 bits wide. On something else it may be 64 bits wide.)
This is not a problem in practice.
> This is because, on a 64 bit architecture, a C "gint" will be
> 64 bits wide. But the .NET "int" will still be 32 bits wide
> (since it is an alias for "System.Int32".)
In almost all the 64 bits architectures a int is 32 bit wide.
The only exception I remember is unicos (a short is 64 bits wide, too)
and it is something that it's not worth supporting (both for it's very
small user base and the target).
The only issue comes from the use of long/glong/gulong in the C
interfaces and there are less than 10 such cases in Gtk+ and slightly
more in glib.
> This will likely require us to build 32 bit versions, 64 bit versions,
> and possible other size versions, of all our assemblies. (And maybe
> create stub .dll's that link to the correct one at runtime.)
No, there is no need for that.
On 03/16/03 Charles Iliya Krempeaux wrote:
> It would be nice though, if the .dll file could configure
> itself at runtime. And change the DllImport statements,
> at runtime, to the correct size for the system that it
> is running on.
Such a mechanism already exists and it's called marshaling descriptors,
the runtime takes care of the conversion for you if the right descriptor
is attached to the parameter or field. This is needed only for
methods that in the C interface use glong/gulong.
But before thinking about that, it's better to fix a real issue, like
the use of uint in glib/Type.cs to represent a GType: a GType is the
size of a pointer, so UIntPtr must be used there.
email@example.com Monkeys do it better