Create Windows version

[nschlia]

It could be desireable to have a Windows version.

Possible Windows Fuse versions here:

• https://github.com/billziss-gh/winfsp (active 10 days ago)
• https://github.com/dokan-dev/dokany (active 2 days ago)
• https://github.com/BenjaminKim/dokanx (dead, last activity 2015)

Notes:

• https://superuser.com/questions/179436/is-it-possible-to-use-fuse-with-windows

Winfsp could be the best idea, it brings its own driver, relieving me from the hastle to build it (requires MS Visual Studio + the Windows Driver Development kit). Would be a huge project anyways as it requires to provide Windows DLLs of FFmpeg as well.

[dangowrt]

Having a Windows build using winfsp would be great! It would allow to have proprietary hard- and software (like Pioneer CDJ/XDJ players which rely on rekordbox exports) transparently support working with free formats (FLAC, OGG, MKV, ...) being automatically transcoded to uncompressed (e.g. WAV) on-access.

I'm trying to do this right now running rekordbox in a Windows VM accessing ffmpegfs mount on the Linux host via Samba. For normal every-day users of e.g. rekordbox this is too complicated, so having a native Windows build would make this amazing feature accessible to them.

[nschlia]

I'm trying to do this right now running rekordbox in a Windows VM accessing ffmpegfs mount on the Linux host via Samba. For normal every-day users of e.g. rekordbox this is too complicated, so having a native Windows build would make this amazing feature accessible to them.

Until now this was just an idea, I did not put too much time into it. At least I found out that now some promising Windows ports of the Fuse API exist. This means I do not have to port everything to Windows...

As the feature list of FFmpegfs is somewhat complete, I could spend some time on the port. Unfortunately I did not waste a thought on Windows when writing it, so it contains a lot of Linux system calls that have to be replaced or emulated for Windows...

To make it short: It's a bigger task to get it running under Windows, so please be patient.

[nschlia]

The Windows version is currently being worked on.

Unbelievably, this would-be operating system does not support expanding the length of a memory mapped file; hence, it is once again the last screw that gets jammed.

The cache class makes considerable use of dynamically growing memory-mapped files.

I'll have to come up with a fix for that issue.