Is w/inline hardcoded to look for .dll files on Windows? Because when I tried to use MSYS and MinGW the file produced was a .so file rather than a .dll, which caused an error when w/inline looked for a .dll file. Thanks.
Well, the library extension is added automatically to the generated file by mzscheme. A .so is added on Unix systems, a .dll on Windows. The solution would be to change the compilation command in ffi.arc : it's something like "gcc -O3 --shared -o foo.so foo.c". Just change it to foo.dll and it might be working. I don't know how to automate this however. If someone has an idea...
The funny thing is that I wrote FFI for one reason besides optimization : I wanted a POSIX interface, so as not to rely on the system function, which is as broken as any shell script.
Imagine you make a script to remove all files ending with a ~ as they are backup files : foo.tex~, bar.c~ and so on. Now imagine your stupid user named a file ~. Guess what happens if you call "rm -r $file" in your script. It also works with files starting with - and many other funny things.
