[Mono-list] mono_verify_corlib - Checking on non-standard fields - Why?
2 Jan 2003 14:00:13 -0000
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?
On Tue, 31 Dec 2003 Piers Haken wrote :
>Yes, you're right: the corlib interfaces are standardized.
>_internal_ interface between corlib and the runtime is not, and
>where the incompatibility lies.
>Corlib needs to do stuff that cannot be written in c#, eg.
>creating/reflecting types, IO, threading, GC, etc... The
>doing these are native (C for mono, C++ for MS) functions
>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
>However many of the Microsoft DLLs also use their own internal
>exported from the MS runtime. This means that although, in theory
>for example, you can use Mono's System.XML.DLL on the MS runtime,
>cannot use MS's version on Mono.
> > -----Original Message-----
> > From: bvv [mailto:firstname.lastname@example.org]
> > Sent: Monday, December 30, 2002 7:50 AM
> > To: Piers Haken; email@example.com
> > Subject: Re: RE: [Mono-list] Microsoft's compiler with
> > corlib! - Issues!
> > Hi Piers,
> > Could you explain what this tight coupling is?
> > I was thinking that since all mscorlib class interfaces are
> > of the ECMA standard it doesn't matter how you implement them
> > long as you provide all the necessary classes as per the spec.
> > which case i should ideally be able to mix & match the
> > 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:firstname.lastname@example.org]
> > > > Sent: Saturday, December 28, 2002 6:41 AM
> > > > To: email@example.com
> > > > Subject: [Mono-list] Microsoft's compiler with mono's
> > >corlib!
> > > > - Issues!
> > > >
> > > >
> > > > Tried to compile and run a helloworld written in C# using
> > >MS
> > > > compiler but mono's corlib.
> > >
> > >
> > >You cannot do this. The corlibs and runtimes are very
> > >bound. You
> > >cannot mix & match.
> > >
> > >Piers.