On 20 July 2011 23:45, Robert Jordan wrote:
> Hi Tom!
Hi Robert!
> Yes - this is a good idea. I'm also wondering if the support library
> should
> > actually be linked in as a shared library, in which case it can simply
> hold
> > a flag about whether or not the JIT has been loaded.
>
> That
Hi Ivo,
On 21 July 2011 23:56, Ivo Smits wrote:
>
> That doesn't give the full power of Mixed Mode assemblies, but I think
> it's definitely an interesting approach with many potential uses.
> Especially, I think, when replacing existing libraries or building
> plugins or extensions for existing
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
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
On 20 July 2011 17:41, Robert Jordan 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 some
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 t
On 20 July 2011 17: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 ;)
>
> -- Tom
>
And, I've just stuck it into GitHub, if you
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
___
Mon
On 20 July 2011 16:05, Robert Jordan 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 about that
Hi Tom!
On 20.07.2011 15:14, Tom Spink wrote:
>
> 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 to
On 10 July 2011 06:28, arkain 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 native forma
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 t
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 ex
On 09.07.2011 20:12, Tom Spink wrote:
>
> I agree with you here, Jon, and it sounds like quite an interesting
> exercise. Of course, one of the other interesting things here would be what
> compiler do you use to generate a mixed-mode ELF? Or, how do you embed IL
> (and associated metadata) into
On 9 July 2011 19:31, Alex Corrado wrote:
> On Sat, Jul 9, 2011 at 2:12 PM, Tom Spink wrote:
> > I agree with you here, Jon, and it sounds like quite an interesting
> > exercise. Of course, one of the other interesting things here would be
> what
> > compiler do you use to generate a mixed-mode
On Sat, Jul 9, 2011 at 2:12 PM, Tom Spink wrote:
> I agree with you here, Jon, and it sounds like quite an interesting
> exercise. Of course, one of the other interesting things here would be what
> compiler do you use to generate a mixed-mode ELF? Or, how do you embed IL
> (and associated metada
On 9 July 2011 18:57, Jonathan Pryor wrote:
> On Jul 9, 2011, at 1:06 PM, arkain wrote:
> > Here's another possibility. I don't see what the problem would be in
> > embedding ELF objects into a PE following the usual COFF objects. Doesn't
> PE
> > have a text section that could be used to tag for
On Jul 9, 2011, at 1:06 PM, arkain wrote:
> Here's another possibility. I don't see what the problem would be in
> embedding ELF objects into a PE following the usual COFF objects. Doesn't PE
> have a text section that could be used to tag for extraction the native
> portion of the assembly? If tha
Here's another possibility. I don't see what the problem would be in
embedding ELF objects into a PE following the usual COFF objects. Doesn't PE
have a text section that could be used to tag for extraction the native
portion of the assembly? If that were used, then it would be possible to
create a
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 i
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 wrote:
> Well, I managed to do exctly this (extracting embedded .dll
Well, I managed to do exctly this (extracting embedded .dll/.so & it's
dependencies on Win32/Win64/Linux32/Linux64) on WkHtmlToXSharp (
https://github.com/pruiz/WkHtmlToXSharp).
And I got fine results. It has some limitations (like being able to write on
working dir, etc.) but it makes deployment
On 09.07.2011 12:20, Quandary wrote:
> 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 x86&x64&ARM&PPC Linux&Windows&Mac
> version of the native d
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 x86&x64&ARM&PPC Linux&Windows&Mac
version of the native dll into the .NET dll's ressources, then stream
t
On Fri, Jul 8, 2011 at 2:04 PM, Alex 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.
>
> Regards,
On 8 July 2011 18:57, Alex Corrado wrote:
> Tom,
>
> On Fri, Jul 8, 2011 at 1:40 PM, Tom Spink 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 t
Tom,
On Fri, Jul 8, 2011 at 1:40 PM, Tom Spink 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 doubt, every c
On 8 July 2011 18:04, Alex 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.
>
> Regards,
> Alex
>
>
: Rodrigo Kumpera
> 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 wrote:
>> On Thu, Jul 7, 2011 at 5:34 PM, Jonathan Pryor wrote:
>>> But try u
ly 7, 2011 5:44 PM
Subject: Re: [Mono-dev] Mixed Mode Assemblies
On Thu, Jul 7, 2011 at 5:32 PM, Rodrigo Kumpera wrote:
> On Thu, Jul 7, 2011 at 5:34 PM, Jonathan Pryor wrote:
>> But try using dlopen(3) on Linux to load an assembly, and dlopen(3) will
>> (rightfully) fail -
On Thu, Jul 7, 2011 at 5:32 PM, Rodrigo Kumpera wrote:
> On Thu, Jul 7, 2011 at 5:34 PM, Jonathan Pryor 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
>> file format difference here.
On Thu, Jul 7, 2011 at 5:34 PM, Jonathan Pryor 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 assemblies. How
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
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 m
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
assemblies.
2011/3/1 Kornél Pál :
>> 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
>> chosen and loa
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
> 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
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 ar
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 c
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 cod
42 matches
Mail list logo
