Created attachment 154581 [details]
Fix - (I've used mingw64 for building and testing)

Currently an installer based on NBI cannot locate what is known as 'known folders' in Windows. A 'known folder' in Windows is a standard location in the Windows OS such as where program files reside or where Downloaded files reside.

The concept of 'known folders' was introduced with Windows Vista and Win32 function SHGetKnownFolderPath() is now the preferred way of finding the actual path of a standard folder on Windows.

For some - and only some - of these folders it is possible to use other means to locate the actual folder path. Indeed before Windows Vista it was necessary to use environment variables or registry keys but the method was not bullet proof. This is exactly what NBI does today (as it was developed in the before Windows Vista existed).

Over time existing Windows path locating methods in NBI should be migrated to use this method, IMHO. Additionally the new method provides the NBI user the ability to locate some folders which could not previously be located:  where to place pictures, where to place program files for a single user, where to place music, etc.

Use of the SHGetKnownFolderPath() function - as opposed to alternatives like
environment variables or registry keys - solves all these problems:

- A folder name may include nasty Unicode chars
- Windows allows the user to freely relocate his own "known folders" to a non-default location. You cannot hardcode or guess a location.
- Some folders change with the bit arch: 32 bit vs 64 bit   (OS can be either and app can be either, giving a total of 4 combinations of which one is illegal)
- Known folders default location are OS language specific  
- Access to known folders that are not detectable via environment vars or registry keys.


I've included a ready-made fix. The attachment includes JNI C code and Java code which is ready to be dropped into the "NBI Native Library: Windows" project as an addition. The downside is that the produced DLL will no longer work with Windows XP. I believe this is okay as Windows XP is long dead for new development anyway. (I'm pretty sure that Oracle doesn't support Java on Windows XP anymore at least not for a version of Java which isn't EOL'ed). If this is unacceptable I'll have to change the C code a bit. See included README for more details.