On 7/28/16, 10:29 AM, Mark Geisert wrote:
>>I am going to really try to get that Win 7 supporting build out by the
>>end
>> of Thursday (Pacific time).
>
>That's the timezone I'm in. I'll see what's going on later tonight :) .
Ok, great. Then we should be able to do this today.
>My mistake. I thought your FUSE implementation had to be compiled for
>Cygwin,
>in order to make use of the cygfuse glue logic. But instead you have a
>native
>Windows FUSE implementation? Won't you have ABI (not API) problems
>connecting
>those two pieces, depending on how the FUSE guts are implemented?
>Apologies if
>you've sorted that all out; don't want to hold you up talking about
>solved aspects.
Yes. I have a FUSE implementation that works for native and Cygwin
programs. The ABI was indeed a bit of an issue, hence my use of fsp_fuse_*
symbols vs fuse_* symbols.
Quick example: instead of offering a fuse_loop symbol, WinFsp offers an
fsp_fuse_loop symbol. Then fuse_new is coded as (for native):
static inline int fuse_loop(struct fuse *f)
{
return fsp_fuse_loop(fsp_fuse_env(), f);
}
Similar code is used in the cygfuse DLL (in fact the same fuse_loop
definition is used on native and Cygwin through macro (ab)use).
The fsp_fuse_env() captures the “environment” which includes things like
the local MSVCRT/Cygwin malloc, etc. I also make sure not to use long
anywhere (since its size is different on Win64 vs Cygwin64).
I have some more information on this scheme here:
http://www.secfs.net/winfsp/blog/files/sshfs-port-case-study-step-2.html
>I agree with how you want to adjust license and transfer ownership. I
>don't
>have a presence on GitHub but I should be able to grab cygfuse anyway.
Excellent. I will change the project to BSD and will explicitly say that I
am assigning ownership to you in the README/LICENSE files.
Bill
