Please send un-answered questions to the cinvoke-dev mailing list.
How does C/Invoke compare to libFFI?
At the C API level they're pretty similar, aside from some minor quibbles. libFFI has been around longer and is much more portable, but the last "release" was in 1998. An explanation why and the current status of libFFI is detailed here:
http://sourceware.org/ml/libffi-discuss/2006/msg00039.html
The main difference from my POV is concentrating on interfacing with existing languages so people don't have to write extension modules just to call a few C functions. The current crop of interpreters (PHP, Perl, Python, Ruby, Lua, Tcl, etc. etc.) aren't going anywhere anytime soon, but if you're writing code in these languages and you happen to need something quickly from C, you're faced with a disproportionate amount of effort in terms of coding/building/distributing/etc. Writing things in [insert language here] is supposed to be fast and easy.
So, the way we're attacking this is: 1) Design the C library to it's easy to integrate with existing languages. 2) Actually implement extension modules which provide P/Invoke-like interfaces on various languages ourselves.
What is the relationship of C/Invoke to Parrot?
Parrot is a virtual machine with some similarities to Microsoft's .NET Framework. In a sense, .NET, Parrot and C/Invoke are all trying to solve the same problem, which is that the proliferation of new programming languages, while providing developers with an indispensible variety of tools, has led to a situation where the various environments are isolated from one another and unable to easily share code. The result is duplication of effort, because a useful library written for one language cannot be easily leveraged in another. Parrot and .NET look to solve this by creating "universal" runtimes, thus uniting all high-level languages on a single platform and creating opportunities to interoperate. C/Invoke takes a different approach: integrating with existing language interpreters and providing a simple bridge to C, a.k.a. the "universal" low-level language. This approach is important because these interpreters are already widely deployed and have such a large mass of code written for them, whereas Parrot is not even a complete and usable system as of this writing. However, it is this author's opinion that neither approach is "wrong", they both can complement each other as we continue to build better interoperation tools in the future.
Beyond this casual connection, it doesn't look like there is much opportunity to unify C/Invoke and Parrot. Parrot has its own C interface called NCI which is functionally similar to .NET's P/Invoke. While the interface itself is not currently as mature as C/Invoke, it does have the advantage of being implemented with Parrot's JIT compiler, which means it is faster, easier to maintain, and (for the moment) more portable. Since NCI is strongly coupled to the Parrot runtime, it seems as though the two projects should remain distinct. Perhaps in the future if the Parrot developers can achieve their goal of having at least most of the currently popular languages deployed on top of it, with a sizable user base, then C/Invoke's usefulness will be diminished substantially.
Can I contact the creator of C/Invoke directly?
Certainly, my e-mail is will "at" cambia.com.