Hey Bruce,
Can you put those stubs up somewhere? I will be happy to start coding them
(the ones that we don't need to discuss ATM at least).
Regards,
Jonathan Chayce Dickinson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruce
Markham
Sent: 19 November 2007 11:46 AM
To: SharpOS Developers
Subject: [SharpOS Developers] RuntimeCop and Mono Interop
Hey folks:
I've spent some time this evening using our (xfury's?) RuntimeCop utility -
which basically is designed to scan an assembly and check for internal calls
to the runtime - specifically, to check Mono's corlib to see what kind of
stubs we have to deal with. And while I did not count the stubs, there are a
bunch of them. Probably 30 or 40, spread out across almost every namespace
in the corlib.
So I wrote a modified version of RuntimeCop - RuntimeCopStubGen (I'll commit
it, at least to my sandbox, when it works properly) - that generates method
stubs for each of those nasty 'extern' methods. Basically, it generates the
methods in modules named after the classes they are used in, in the same
namespace hierarchy as the Mono corlib.
Now, originally, I was just tinkering. But I think we can use this to help
us address what we need to do, to have full compatibility with the Mono
corlib, without having to re-tool it. (Remember - our plans are to load and
JIT the Mono corlib, whereas our korlib is a watered down version used to
support the JIT, scheduler, virtual file system, and HAL.)
What I'm thinking is - the stubs that we need in order to support our AOTed
EDC layer (JIT + scheduler + VFS + HAL), can go in the core of the kernel.
The rest - in a MonoInterop.dll assembly, that the JIT will use to support
the Mono corlib.
MonoInterop can call into the kernel, and it can our AOTed EDC facilities.
Examples of things that will be in MonoInterop: threading-related stubs, and
the shitload of stubs in System.IO.MonoIO.
Examples of things that will be in kernel:
System.ValueType.InternalGetHashCode(), reflection stubs (can't have AOTed
EDC without it), System.String.*alot*()...
With such, in some cases we will be able to use Mono's class-library code,
C+Psted, in the korlib. (Such as for strings.) Some of these stubs, on the
other hand, will require complicated emulations, depending on our own schema
(threading, for example) - but by knowing what we have to face, I'm sure we
can pull it off.
Lend me your thoughts. Implementing these stubs is definitely a better
option that re-writing the entire Mono corlib, but we still have alot of
work to do, so we need to talk about how it will be done - so that, well, we
can get it done. And it doesn't have to all be done at once, and definitely
not soon.
-Bruce
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
