Add support for Windows

[khanetor]

The command uname -sm only works for Unix-based OSes. Currently I have to manually set

nativePlatform := "win32-x86_64"

[jodersky]

Windows is currently not officially supported, however it shouldn't be too complicated to add. Here is the rough outline:

• find a way to distinguish the windows architectures (I'm not sure if there are mutliple), similar to what uname can provide on unix
• use that mechanism in JniNative and JniLoad to bundle and extract the corresponding native libraries

[eaplatanios]

What about System.getProperty("os.arch") and System.getProperty("os.name"). Could we change the code to use these instead of uname?

[jodersky]

That's a good idea and was also what was used in a very early version of this project. Unfortunately, the os.arch property is too vague. It is able to distinguish between certain architectures only, such as x86 and ARM for instance. The latter however has several, incompatible, architectures which are indistinguishable with that mechanism. For example armv6 (used in the original raspberry pi) and armv7l (used in subsequent models) are incompatible, yet they both show up as simply "arm" from os.arch.

[eaplatanios]

I see. How about we fall back to these two properties when uname is not available. Do you think that's acceptable behavior until we find a better solution?

[jodersky]

I think we could check the os.name property and in case it is windows handle it specifically. Otherwise we should use the standard uname method.

[andraxin]

My platform is neither Windows nor ARM, but I'm still inconvenienced by the need to spawn an extra process to run uname during JNI loading, since that's not allowed, causing my application to crash.
My fix was also to use sys.props("os.name") and sys.props("os.arch") to avoid forking a process.

That's a good idea and was also what was used in a very early version of this project. Unfortunately, the os.arch property is too vague. It is able to distinguish between certain architectures only, such as x86 and ARM for instance. The latter however has several, incompatible, architectures which are indistinguishable with that mechanism. For example armv6 (used in the original raspberry pi) and armv7l (used in subsequent models) are incompatible, yet they both show up as simply "arm" from os.arch.

I may be jumping to conclusions too fast, but would it be correct to assume that sys.props("os.arch") == "arm' is the only problem case? Shouldn't this be handled via a trouble report back to Oracle to fix this in Java? That coarse-grain reporting of the underlying architecture is obviously(?) not very helpful and likely to cause pain for others as well...

I think we could check the os.name property and in case it is windows handle it specifically. Otherwise we should use the standard uname method.

I don't know, but IF dragging in uname is only needed on ARM, THEN -perhaps- special-casing Windows is not the optimal approach. In my use case, I'd much rather opt for only falling back to uname when sys.props("os.arch") == "arm'.

What do you think?

[jodersky]

I doubt that anything can be done about changing the property of os.arch upstream, as that could break user code. However, I think your proposal of using system properties by default and calling uname only on an arm platform is worth a shot!

[andraxin]

Great! Will you fix that or would you prefer a pull request?

[andraxin]

PR created.