Re: Eu->dll on Windows, can't get it to work
- Posted by jimcbrown (admin) Jun 02, 2016
- 1337 views
They don’t seem to work as advertised on OpenEuphoria either:
I think they do work as advertised.
This might be a bug related to E_SEQUENCE. Maybe, if we don't pass in any euphorian objects but stick to passing C_INT and so on back and forth, the issue of heap corruption won't happen? I haven't tried this. It might be worse though - we might have a generic issue with using multiple translated shared objects, period.
In any case, I don't think we advertise anywhere to use multiple translated shared objects.... though it would be nice if that worked.
I'm not sure if this was fixed or not. But it's unrelated to E_OBJECT et al - the issue here has to do with mangling of function names, and a tangent of having the same function name as a C backend function.
This is a generic memory leak issue with translated shared objects, that applies regardless of whether or not E_OBJECT et al are used. It's a long standing bug that should be fixed, but it's not related.
This references the same memory leak issue above.
Neither does http://openeuphoria.org/forum/113522.wc inspire me with confidence,
I don't see why. We don't advertise backwards compatibility with v3.1 or older E_OBJECT et al. In that thread, a library was provided for those who do need such compatibility - so as far as I'm concerned, the issue was fixed.
and nor does http://openeuphoria.org/forum/118514.wc though it is the closest (/only) thing my searches yielded that might actually be useful.
You don't see the 4.0<->3.1 shim library as useful?
In any case, we don't advertise that ram_space (from std/eumem.e) will work across translated shared objects or between a tso and the main OE program.
One thing that definitely affects Phix, but I can't say about OE, is that if a dll were compiled with it's own copy of the heap manager, then if any function in the dll allocated something and returned it to the calling exe, the latter would most probably try and release it in the wrong heap, which would end pretty badly.
Well, maybe http://openeuphoria.org/forum/127457.wc is an example of this problem for OE. OTOH, something allocated with allocate() should work fine in OE if using DEP protection - we use VirtualAlloc/mmap in that case.
