Starkit + Ffidl (Windows specific)

[s.effe...@googlemail.com]

Setup: Windows and a starkit with ffidl and a utility DLL in it. Ffidl is the good old one that can be downloaded from elf.org.

If I run the starkit with ActiveTcl, ffidl can load its payload DLL directly from the kit, no need to copy it out of it. The version of ffidl that I use is the one that uses LoadLibraryA. Has ActiveTcl installed a hook on LoadLibraryA? If so, would it be a good idea to adopt this method in non-ActiveState versions of Tcl?

Open end: Until now I haven't managed to successfully compile ffidl myself. It's a bit tricky, because I have managed to compile libffi and ffidl, but running a simple test gives a bad result, therefore this is a question that I cannot answer myself at the moment:
Tcl_LoadFile is publicly accessible and ffidl offers an option to use it (officially not under Windows, at least the Makefile says so). If ffidl would be compiled with Tcl_LoadFile, it would reduce the extra burden of the temporary DLL copy for users of ffidl. Is that possible?

And a general question: How would anybody who is unable or just unlucky to compile a binary extension like ffidl locate a ready-made extension? Add some kind of recipe to kbs or BAWT? In the past I had some luck by using vanillawish from the AndroWish project as a one-stop repository (need tkpath? unwrap it from a vanillawish!), but ffidl is not in there, at least not for Windows.

[undro...@gmail.com]

> And a general question: How would anybody who is unable or just unlucky to compile a binary extension like ffidl locate a ready-made extension? Add some kind of recipe to kbs or BAWT? In the past I had some luck by using vanillawish from the AndroWish project as a one-stop repository (need tkpath? unwrap it from a vanillawish!), but ffidl is not in there, at least not for Windows.

In a future release of vanillawish/undroidwish Ffidl for Win32 and Win64 will be included built to a single DLL. It is a question of time, few days hopefully.

[s.effe...@googlemail.com]

> In a future release of vanillawish/undroidwish Ffidl for Win32 and Win64 will be included built to a single DLL. It is a question of time, few days hopefully.

That's great news, thank you Christian!

Also, some good news from my side:
Somewhere inside Ffidl the decision is made to use the raw ffi API. If I force this decision to be false and use the standard ffi_call then I can get Ffidl to work properly for me. I'm using MinGW5.1.0 on Windows Pro 7/32, just in case somebody already knows what might be going on before I can dig deeper into the problem.

Aaaand ... I can indeed use Tcl_LoadFile and let Tcl itself figure out if the payload DLL has to be copied out of a starkit.

I'll continue to look at this.

Other that that ... see you in Munich!
-- Stephan

[s.effe...@googlemail.com]

Further down the rabbit hole...

As far as I understand how ffi_raw_call wants to be used, I've written a test that uses this function, i.e. no Ffidl involved, just plain libffi (version 3.2.1), and I got bad results.
There's still a chance that I did something wrong in the configure ; make ; make install ritual, but since ffi_raw_call is not well documented (is it at all?) and the test suite of libffi doesn't even cover ffi_raw_call, I'd suggest to stay away from the raw API. Since using the raw API is a runtime decision in Ffidl, I suggest to add an option to explicitly enable this feature.

[s.effe...@googlemail.com]

Solved (if you're good with using a release candidate).

The implementation of ffi_raw_call in V3.2.1 of libffi, which is supposed to be the stable version since 2014, looks very different from what it should look like. The helper function ffi_prep_args_raw is total humbug.
V3.3, only available as a release candidte, works properly (for me).

Summary:
- Don't use libffi3.2.1 for Win32 and perhaps Win64 as well. Use libffi3.3.
- Enable Tcl_LoadFile for Windows if nobody else complains.
- I still suggest to make raw calls a runtime option in Ffidl.