On 22.07.2011 00:56, Ivo Smits wrote:
Also, I think that eventually the 'reverse interop code' could be
generated from an assembly file by using the Reflection framework. You
could make the code generator a managed application.
This is kinda obvious :) The same in C++ would be taking
like 10
Op 20-7-2011 15:14, Tom Spink schreef:
Hi Guys - if you're still watching this thread,
So I may have done something brilliant - or something terrible. I
don't quite know yet - I need your feedback to see if I'm heading
along the right lines.
What I've done is to create a tool that
On 10 July 2011 06:28, arkain king...@gmail.com wrote:
So it looks like you guys are saying that allowing mono to create
mixed-mode
assemblies is possible given the following constraints:
1. The .NET metadata must always be found in a PE container.
2. A mixed mode assembly must always be a
On 20 July 2011 16:05, Robert Jordan robe...@gmx.net wrote:
Hi Tom!
Hi Robert!
Nice :) Not exactly Mixed Mode Assemblies though, because the
really interesting part (calling unmanaged code w/out having to
go through p/invoke) remains the same pain.
Absolutely - I've been thinking a lot
Hi guys,
Since it's only 3.5k tarred up, I've attached it to this email - I hope
that's not too rude!
Let me know what you think! And don't give me a hard time for some of the
hacks ;)
-- Tom
sogen.tar.gz
Description: GNU Zip compressed data
___
On 20 July 2011 17:02, Tom Spink tsp...@gmail.com wrote:
Hi guys,
Since it's only 3.5k tarred up, I've attached it to this email - I hope
that's not too rude!
Let me know what you think! And don't give me a hard time for some of the
hacks ;)
-- Tom
And, I've just stuck it into GitHub,
Hi Tom!
On 20.07.2011 18:02, Tom Spink wrote:
Hi guys,
Since it's only 3.5k tarred up, I've attached it to this email - I hope
that's not too rude!
Let me know what you think! And don't give me a hard time for some of the
hacks ;)
I'm quoting from the TODO:
* Automate DLL_NAME to pull
On 20 July 2011 17:41, Robert Jordan robe...@gmx.net wrote:
Hi Tom!
Hey!
On 20.07.2011 18:02, Tom Spink wrote:
Hi guys,
Since it's only 3.5k tarred up, I've attached it to this email - I hope
that's not too rude!
Let me know what you think! And don't give me a hard time for
Hi Tom!
On 20.07.2011 23:41, Tom Spink wrote:
* Rewrite each stub after first call to call the function pointer
proper, and hence bypass the NULL test.
Well, I went ahead and did it before I got your reply... Let me know what
you think. It's most certainly non-portable, which is a /bad
It's true that p/Invoke + InterOp services do not form a complete solution.
However, creating a interface in managed code across platforms isn't
very difficult.
All you need to do is to pack a x86x64ARMPPC LinuxWindowsMac
version of the native dll into the .NET dll's ressources, then stream
the
Another 'problem' with this approach is size. Due to the fact that the
native component I'm using it's quite big (chrome + qt are quite huge), the
final assembly weights a few MBs.. :(
On Sat, Jul 9, 2011 at 2:10 PM, Pablo Ruiz pablo.r...@gmail.com wrote:
Well, I managed to do exctly this
When I raised this topic, I walked in knowing that any such solution to
providing mixed-mode assemblies will produce assemblies that are not
cross-platform compatible. That much is a given. My point was simply that
this is an irrelevant fact. The whole point of providing for mixed mode
assemblies
Approach 4 worked well for me so far.
Declare delegates, then use an abstract class for dlopen/LoadLibrary,
based on OS.
Write once - use infinite times.
The real question is:
Do you have write access to a temporary directory, and can the
webserver-process read from there ?...
As to the large
So it looks like you guys are saying that allowing mono to create mixed-mode
assemblies is possible given the following constraints:
1. The .NET metadata must always be found in a PE container.
2. A mixed mode assembly must always be a native format library so as to
allow native programs to load
@lists.ximian.com
Sent: Thursday, July 7, 2011 5:44 PM
Subject: Re: [Mono-dev] Mixed Mode Assemblies
On Thu, Jul 7, 2011 at 5:32 PM, Rodrigo Kumpera kump...@gmail.com wrote:
On Thu, Jul 7, 2011 at 5:34 PM, Jonathan Pryor jonpr...@vt.edu wrote:
But try using dlopen(3) on Linux to load an assembly
Cc: mono-devel-list@lists.ximian.com
Sent: Thursday, July 7, 2011 5:44 PM
Subject: Re: [Mono-dev] Mixed Mode Assemblies
On Thu, Jul 7, 2011 at 5:32 PM, Rodrigo Kumpera kump...@gmail.com wrote:
On Thu, Jul 7, 2011 at 5:34 PM, Jonathan Pryor jonpr...@vt.edu wrote:
But try using dlopen(3) on Linux
Tom,
On Fri, Jul 8, 2011 at 1:40 PM, Tom Spink tsp...@gmail.com wrote:
Why do you think that? I've actually pondered this approach for a while, as
it could potentially bring a couple of benefits.
I am curious to know what benefits you are referring to. The original
poster said:
Without a
On 8 July 2011 18:57, Alex Corrado alexander.corr...@gmail.com wrote:
Tom,
On Fri, Jul 8, 2011 at 1:40 PM, Tom Spink tsp...@gmail.com wrote:
Why do you think that? I've actually pondered this approach for a while,
as
it could potentially bring a couple of benefits.
I am curious to know
On Fri, Jul 8, 2011 at 2:04 PM, Alex xtzgzo...@gmail.com wrote:
Hi,
While this is theoretically possible, it would be completely
nonstandard. How do you actually want to store CIL /and/ native code
in ELFs? I'm not very familiar with the format, but I can't imagine
it'd be a clean endeavor.
I understand the reasons why the developers chose to leave out support for
developing mixed-mode assemblies using mono: the lack of cross-platform
compatibility in such assemblies. However, I would argue that such things
are not a consideration for those who would choose to develop such
As I understand it, Mono on Windows does support running mixed-mode
assemblies.
My guess is the primary reason for not supporting it on other platforms
has more to do with the hassle of developing a C++/CLI compiler than
concerns about cross-platform compatibility.
A long time ago, there was a
On Jul 7, 2011, at 11:55 AM, arkain wrote:
I understand the reasons why the developers chose to leave out support for
developing mixed-mode assemblies using mono: the lack of cross-platform
compatibility in such assemblies. However, I would argue that such things
are not a consideration for
On Thu, Jul 7, 2011 at 5:34 PM, Jonathan Pryor jonpr...@vt.edu wrote:
On Jul 7, 2011, at 11:55 AM, arkain wrote:
I understand the reasons why the developers chose to leave out support
for
developing mixed-mode assemblies using mono: the lack of cross-platform
compatibility in such
On Thu, Jul 7, 2011 at 5:32 PM, Rodrigo Kumpera kump...@gmail.com wrote:
On Thu, Jul 7, 2011 at 5:34 PM, Jonathan Pryor jonpr...@vt.edu wrote:
But try using dlopen(3) on Linux to load an assembly, and dlopen(3) will
(rightfully) fail -- Linux wants ELF, not PE. There's a rather fundamental
Hi,
Vincent Povirk wrote:
My preferred way would be to call exports that Windows calls:
- _CorValidateImage on image load
- _CorImageUnloading on image unload
- _CorExeMain instead of exe entry point
- _CorDllMain instaad of dll entry
Is there a reason for us to add this to the Wine loader
2011/3/1 Kornél Pál kornel...@gmail.com:
Another possible approach, if we don't share mscoree.dll code, would
be for Wine and Mono to both implement ICLRMetaHost
(http://msdn.microsoft.com/en-us/library/dd233134.aspx) and
ICLRRuntimeInfo, both of which can be accessed before a runtime is
Two very interesting things happened in Mono recently:
1. The implement type compare for 1b assert failure that would
usually occur when loading a mixed-mode assembly in Mono was fixed. So
whoever did that, thank you.
2. Rodrigo Kumpera added an ENABLE_COREE define, default off, because
that code
Hi,
I have some unsubmitted modifications to mixed-mode support I made about
a year ago. I should revise them and those may improve mixed-mode support.
I haven't had time to sort out the verifier conflict but that should be
possible and hopefully easy to resolve.
My preferred way would be to
I forgot about the mixed mode Visaul C++ application issue:
Mixed-mode code is supported, however the C++ runtime (by MS) assumes
some runtime internals (COM interop (may work by now), fixed RVA fields
are shared between app domain, and maybe others) that are not supported
by the runtime and
My preferred way would be to call exports that Windows calls:
- _CorValidateImage on image load
- _CorImageUnloading on image unload
- _CorExeMain instead of exe entry point
- _CorDllMain instaad of dll entry
Is there a reason for us to add this to the Wine loader soon? I've
been putting it
30 matches
Mail list logo
