Thanks for the patch I tried it here on Windows Vista and it works fine.

Unfortunately it doesn't work on Windows XP, so we have to find a way to make this available in newer versions of Windows only without having to create separate executables and installations.

Have a look at this article on MSDN Obtaining a File Name From a File Handle http://msdn.microsoft.com/en-us/library/aa366789%28v=VS.85%29.aspx.

If you cannot use that to make it work on XP, use

OSVERSIONINFOW OSVersion;
ZeroMemory(&OSVersion, sizeof(OSVERSIONINFO));
OSVersion.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx(&OSVersion);

If(OSVersion.dwMajorVersion >= 6)//its vista or higher

See MSDN article http://msdn.microsoft.com/en-us/library/ms724832%28v=VS.85%29.aspx

Thanks for the code, Richard. Unfortunately i can't compile Blender now due to the pthreads.h error so i can't try it until i fix that. Can you add it to the patch and test?

New patch (patch_vista.txt). Added function to check if the Windows version is one given or later so now the new code should not run for Xp and earlier (can't try so please check).

Hi Ignacio,
Turns out that still doesn't work on XP because blender is trying to load GetFinalPathNameByHandle() from the dll when it starts(Which doesn't exist in the XP dll so it causes a error and crash). Other than that its fine. However I did find this Tutorial http://www.dreamincode.net/forums/topic/118076-dlls-explicit-linking , I'll try it out and see if I can get it to load this way.

Hi Richard,

Didn't think of that. Let me know if you find something but if there is no way to skip that load two separate builds will be needed or a way to get the reparse point addres without using that function.

Maybe there is a way to fake that function when is not present in xp and earlier as it won't be used anyway, but i don't know how to do that.

Hi Ignacio,

Managed to get this working on Vista and not crashing on XP see updated patch here http://docs.google.com/View?id=dd299srs_31g3g7km4j. I've added in

#ifdef __MINGW32__
#define _WIN32_WINNT 0x0500
#endif

so it will build on minGW(as well as visual studio), but I doubt this is how this should be done. Other than that there aren't any other problems that I've found.

Hi Ignacio, Hi Richard,

I've got a bit of time on my hand in the next days or so and would like to attempt to fix this issue. Unfortunately I can't get to the updated patch on docs.google.com anymore - could you attach the latest patch here on the tracker? (I know it's been a long time...)

Cheers,
Andrea