Updates to callconvutil.cs for .NET 2.0
Anyone else out there started to mess with Python.NET on the 2.0 platform? One of the first hurtles was the output from ildasm does not always place the method name on the next line, causing callconvutil to place the modopt in the wrong place. I've added a regex in to check for and split the method line if the function name is found.
Michael Eddington wrote:
Anyone else out there started to mess with Python.NET on the 2.0 platform? One of the first hurtles was the output from ildasm does not always place the method name on the next line, causing callconvutil to place the modopt in the wrong place. I've added a regex in to check for and split the method line if the function name is found.
Here's something I just discovered. You can now (in .NET 2.0) apply the UnmanagedFunctionPointer attribute to delegate types to get them to work as cdecl. For example:
[UnmanagedFunctionPointer(CallingConvention.Cdecl)] public delegate IntPtr UnaryFunc(IntPtr ob);
From what I can tell, that delegate type is compatible with any managed
method with the right signature. When called from unmanaged code, such delegates will use the cdecl convention (this must be done in some kind of thunk, since the method itself still uses the normal .NET calling convention).
Anyway, the upshot is it looks like you can apply that attribute to all the CallConvCDecl delegates in Interop.cs (removing the CallConvCDecl attribute, since it's not needed), and then not need callconvutil at all.
Hee hee - this is good news. I'm looking forward to getting rid of that horrible IL hack... ;)
Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
-----Original Message----- From: pythondotnet-bounces@python.org [mailto:pythondotnet-bounces@python.org]On Behalf Of Greg Chapman Sent: Monday, September 19, 2005 3:50 PM To: pythondotnet@python.org Subject: Re: [Python.NET] Updates to callconvutil.cs for .NET 2.0
Michael Eddington wrote:
Anyone else out there started to mess with Python.NET on the 2.0 platform? One of the first hurtles was the output from ildasm does not always place the method name on the next line, causing callconvutil to place the modopt in the wrong place. I've added a regex in to check for and split the method line if the function name is found.
Here's something I just discovered. You can now (in .NET 2.0) apply the UnmanagedFunctionPointer attribute to delegate types to get them to work as cdecl. For example:
[UnmanagedFunctionPointer(CallingConvention.Cdecl)] public delegate IntPtr UnaryFunc(IntPtr ob);
From what I can tell, that delegate type is compatible with any managed
method with the right signature. When called from unmanaged code, such delegates will use the cdecl convention (this must be done in some kind of thunk, since the method itself still uses the normal .NET calling convention).
Anyway, the upshot is it looks like you can apply that attribute to all the CallConvCDecl delegates in Interop.cs (removing the CallConvCDecl attribute, since it's not needed), and then not need callconvutil at all.
-- Greg Chapman
Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
Rock on, I have Python.NET running under 2.0 using 2005 Beta 2 and the change below.
I've tried both the console and embedding in another .NET application.
To compile I made my own solution with three projects (console, crl, and runtime). For CRL I used the Visual IL addin to studio. Did a search/replace and whala.
mike
On 9/19/05, Greg Chapman glc@well.com wrote:
Michael Eddington wrote:
Anyone else out there started to mess with Python.NET on the 2.0 platform? One of the first hurtles was the output from ildasm does not always place the method name on the next line, causing callconvutil to place the modopt in the wrong place. I've added a regex in to check for and split the method line if the function name is found.
Here's something I just discovered. You can now (in .NET 2.0) apply the UnmanagedFunctionPointer attribute to delegate types to get them to work as cdecl. For example:
[UnmanagedFunctionPointer(CallingConvention.Cdecl)] public delegate IntPtr UnaryFunc(IntPtr ob);
From what I can tell, that delegate type is compatible with any managed
method with the right signature. When called from unmanaged code, such delegates will use the cdecl convention (this must be done in some kind of thunk, since the method itself still uses the normal .NET calling convention).
Anyway, the upshot is it looks like you can apply that attribute to all the CallConvCDecl delegates in Interop.cs (removing the CallConvCDecl attribute, since it's not needed), and then not need callconvutil at all.
-- Greg Chapman
Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
participants (3)
-
Brian Lloyd -
Greg Chapman -
Michael Eddington