Re: Using FFI as a plugin
- From: Coda Highland <chighland@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Thu, 17 May 2012 12:59:46 -0500
On Thu, May 17, 2012 at 12:54 PM, Dimiter 'malkia' Stanev
<malkia@xxxxxxxxx> wrote:
> On 5/17/2012 10:50 AM, Coda Highland wrote:
>>
>> On Thu, May 17, 2012 at 12:37 PM, Dimiter 'malkia' Stanev
>> <malkia@xxxxxxxxx> wrote:
>>>>
>>>> Yes, I had considered this, but that requires knowing exactly where
>>>> the host decided to install my plugin, which can and will vary from
>>>> system to system. If the plugin could somehow resolve its own path,
>>>> that would do the trick, but at present I don't think there's a way to
>>>> do that.
>>>>
>>>> /s/ Adam
>>>>
>>> On Windows, there are three ways for your module to get it's own path:
>>>
>>> Here are the first two, unfortunately I don't think they can work in
>>> luajit,
>>> not unless you link or
>>> know specific symbol that is part of your DLL - for example it might work
>>> if
>>> you link statically to
>>> luajit, but you are still DLL, then instead of using __ImageBase (this is
>>> MSVC specific, or
>>> &get_module_filename, use it, for example lua_open, or something like it)
>>>
>>> extern "C" IMAGE_DOS_HEADER __ImageBase;
>>> static std::string get_module_filename()
>>> {
>>> MEMORY_BASIC_INFORMATION mbi;
>>> VirtualQuery(&get_module_filename,&mbi, sizeof(mbi) );
>>> HMODULE mod1 = (HMODULE)mbi.AllocationBase;
>>> HMODULE mod2 = (HMODULE)&__ImageBase;
>>> assert( mod1 == mod2 );
>>> char buf[ _MAX_PATH ];
>>> GetModuleFileNameA( mod1, buf, sizeof( buf ) );
>>> return buf;
>>> }
>>>
>>>
>>> But there is a better way, and I think LuaJIT is already using it, it
>>> should
>>> work on anything XP+:
>>>
>>>
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683200(v=vs.85).aspx
>>>
>>> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms683200%28v=vs.85%29.aspx>
>>>
>>> static std::string get_module_filename()
>>> {
>>> HMODULE hModule = 0;
>>> GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS,
>>> get_module_filename,&hModule);
>>> char buf[ _MAX_PATH ];
>>> GetModuleFileNameA(hModule, buf, sizeof( buf ) );
>>> return buf;
>>> }
>>>
>>>
>>> Sorry for giving out C, instead of luajit/ffi examples, but these should
>>> be
>>> easy to translate
>>> (I just copied them from a forum, where I posted the original suggestion,
>>> and was given the
>>> latter which is much better)
>>>
>>> I don't think how this is done on UNIX* like systems, but there is
>>> probably
>>> a way...
>>>
>> I don't mind looking up a symbol from my library. That's no problem at
>> all.
>>
>> It's perfectly fine to get C -- possibly even preferable for the sake
>> of sandboxing.
>>
>> I do appreciate this, although it's Mac I'm really worried about at
>> the moment. If I can find a solution there, then this is half of the
>> battle -- the other being the other thread I posted.
>>
>> /s/ Adam
>>
>
> I've looked at the Mac OSX man-pages (I use 10.7.2 at home), but from what I
> know, and looked so far,
> neither install_name_tool or rebase help. There might be some trick that
> could be done with rebase, but
> I don't know what is going to work:
> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/rebase.1.html
>
> I've also looked whether the dyld linker could be lied somehow, but nothing
> there too:
> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man1/dyld.1.html
>
> here is the install_name_tool, but nothing helpful:
> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man1/install_name_tool.1.html
> (I'm using it to rename references to .dylib files just fine, but that's
> about it)
>
> At least in our studio we are so far Windows based (except some of the audio
> folks), and Maya/MotionBuilder/Max plugin
> using luajit might be a possibility (but for the next project). Not sure
> what is your main app, would be interesting to know.
>
>
Main app can be a huge variety of things -- on the Mac side, Logic
Pro, Ableton Live, Cubase, Reaper, ProTools, and Vienna Ensemble Pro
are the hosts in my testing regimen, and there are many others. There
are three different plugin formats here, too -- Audio Unit, VST, and
RTAS, the last of which has pathetic documentation.
I'm familiar with all of the stuff used by the normal dynamic linker
and use it as part of my standard build process. The only solution
I've found so far involves deploying the plugin as a library in a
known path and then having trivial wrappers that go in the hosts'
install paths, but that's been vetoed by the rest of my team as
causing more problems than it solves.
Thanks for trying, though. I really do appreciate it.
/s/ Adam
Other related posts:
