[Mono-devel-list] The first (attempt to checkin) managed collation patch

Miguel de Icaza miguel at ximian.com
Sun Jul 24 13:10:18 EDT 2005


> > I personally like the idea of having this data on the dll files
> > themselves more, you can embed the resources with -resource and then get
> > the same IntPtr without adding a new icall like this:
> > 
> > int size;
> > Module module;
> > IntPtr data = GetManifestResourceInternal (name, out size, out module);
> Then, the latest managed-collation.patch in Mono.Globalization.Unicode
> already works like that. It casts Stream (returned from
> Assembly.GetManifestStream()) to IntPtrStream (renamed as
> UnmanagedMemoryStream in the patch though).

Notice that I suggested "GetManifestResourceInternal", not the similarly
named "GetManifestStream".  The managed collaction code uses a Stream

What am suggesting is that instead of adding a new icall whose purpose
is to return an IntPtr + the size of a special-cased resource, you can
use GetManifestResourceInternal which does exactly the same thing.  The
difference is that the GetManifestResourceInternal works with resources,
while the new icall uses a new framework for fetching values.

So you can move pretty much all of the logic you have in C into C# and
still get the (IntPtr, size) values with the existing framework.

> Actually if we avoid putting those resource files other than
> mcs/class/corlib directory, the build hack is anyways required,
> since csc won't work when those resource files are put under
> certain directory (like we had to replace '/' to '\\' for *.cs
> sources).

System.Web already has a framework for including resources, see
mcs/class/System.Web/Makefile for more details and this should be
working on both Windows and Linux (it seems very simple).


More information about the Mono-devel-list mailing list