Added path String variable for Windows 7/8

[paulmatthews]

In Windows, os.arch returns the architecture of the JVM. If os.arch
contains 64, then the JVM is 64-bit and path is set to the default
64-bit VLC installation directory. Otherwise, assume the JVM to be
32-bit and set path to the default 32-bit VLC installation directory.

[paulmatthews]

This fix just makes sure that the Java Virtual Machine and the VLC DLL's
match in 'bitness', ie, 32-bit with 32-bit and 64-bit with 64-bit. I was
having an issue because I have a 64-bit version of Windows, running 32-bit
JRE and VLC. But the way the program was coded, it was looking for the VLC
DLL's in the 64-bit directory, ie, C:\Program Files\VideoLAN\VLC instead of
the correct C:\Program Files (x86)\VideoLAN\VLC.

You still need to make sure that your installed and running libraries
match. So if you're running 32-bit Java, make sure you have the 32-bit
version of VLC installed and likewise with 64-bit versions.

Is your VLC installation in the default directory?

On Fri, Aug 23, 2013 at 9:58 PM, rmc3 notifications@github.com wrote:

I'm not sure if this commit is intended to fix the issue I'm encountering,
which is the following:

java.lang.RuntimeException: Failed to load the native library.

The error was "Unable to load library 'libvlc': JNA native support (win32-amd64/
libvlc.dll) not found in resource path (Fling-0.0.1-SNAPSHOT-jar-with-dependenci
es.jar)".

The required native libraries are named "libvlc.dll" and "libvlccore.dll".

But, if it is, it did not fix it for me after building paulmatthew's fork
with maven. I'm running Windows 7 64-bit with VLC Media Player 2.0.3

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/8#issuecomment-23201040
.