In doing a mix & match of corlibs between CLRs I found that the issue involves more than the icalls!
Running mint I found that there's a check done on the corlib. interp.c has a call to funciton "mono_verify_corlib" which is found in verify.c.
I was surprised to find that the verification involves checking if certain "private" fields are present in various classes of corlib. I say "private" because these fields are *NOT* part of the ECMA standard class definitions.
I stepped through Rotor code to see if they do they same thing, and yes they do!
If u try to replace Rotor's corlib with mono's corlib the checking that Rotor does on the corlib fails because the *private* fields that Rotor expects to find are either not available in mono's corlib or the name of the field differs!
Now, what i don't understand is
What's the purpose of corlib verification?
Why is corlib verification done based on such *private* fields?
Thanks
On Tue, 31 Dec 2003 Piers Haken wrote :
Yes, you're right: the corlib interfaces are standardized. However the
_internal_ interface between corlib and the runtime is not, and this is
where the incompatibility lies.
Corlib needs to do stuff that cannot be written in c#, eg.
creating/reflecting types, IO, threading, GC, etc... The functions for
doing these are native (C for mono, C++ for MS) functions exported by
the runtime. In mono they are referred to as 'icall's (see
mono/mono/metadata/icall.c) and they are runtime-specific.
I believe that the only Mono DLL that uses internal calls is corlib.dll.
However many of the Microsoft DLLs also use their own internal calls
exported from the MS runtime. This means that although, in theory and
for example, you can use Mono's System.XML.DLL on the MS runtime, you
cannot use MS's version on Mono.
Piers.
> -----Original Message-----
> From: bvv [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 30, 2002 7:50 AM
> To: Piers Haken; [EMAIL PROTECTED]
> Subject: Re: RE: [Mono-list] Microsoft's compiler with mono's
> corlib! - Issues!
>
>
> Hi Piers,
>
> Could you explain what this tight coupling is?
> I was thinking that since all mscorlib class interfaces are part
> of the ECMA standard it doesn't matter how you implement them as
> long as you provide all the necessary classes as per the spec. In
> which case i should ideally be able to mix & match the corlibs
> between different .Net runtimes.
>
> Correct me if i'm wrong please
>
> Thanks
>
> On Sun, 29 Dec 2002 Piers Haken wrote :
> > > -----Original Message-----
> > > From: bvv [mailto:[EMAIL PROTECTED]]
> > > Sent: Saturday, December 28, 2002 6:41 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: [Mono-list] Microsoft's compiler with mono's
> >corlib!
> > > - Issues!
> > >
> > >
> > > Tried to compile and run a helloworld written in C# using the
> >MS
> > > compiler but mono's corlib.
> >
> >
> >You cannot do this. The corlibs and runtimes are very tightly
> >bound. You
> >cannot mix & match.
> >
> >Piers.
>
>
>
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
