Created attachment 720 [details] jogamp-2.3.2 19aug test.log test_dbg.log .7z The runtime version check using etc\test.bat fails on WinXP with the message Exception in thread "main" java.lang.RuntimeException: java.lang.ClassNotFoundException: Failed to find NEWT Display Class <.windows.DisplayDriver> at jogamp.newt.DisplayImpl.create(DisplayImpl.java:299) cause seen in test_dbg.log NativeLibrary.findLibrary(<newt>) (TempJarCache): C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\jogamp_0000\file_cache\jln3132821475144545958\jln6337580148321003734\natives\windows-i586\newt.dll JNILibLoaderBase: loadLibraryInternal(newt), TempJarCache: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\jogamp_0000\file_cache\jln3132821475144545958\jln6337580148321003734\natives\windows-i586\newt.dll JNILibLoaderBase: System.load(C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\jogamp_0000\file_cache\jln3132821475144545958\jln6337580148321003734\natives\windows-i586\newt.dll) - mode 2 java.lang.UnsatisfiedLinkError: C:\Documents and Settings\Administrator\Local Settings\Temp\jogamp_0000\file_cache\jln3132821475144545958\jln6337580148321003734\natives\windows-i586\newt.dll: The specified procedure could not be found at java.lang.ClassLoader$NativeLibrary.load(Native Method) this regression has been introduced between 2.2.4 == working 2.3.0 == not working
Created attachment 721 [details] dependencywalker-newt.dll-2.3.0.png Using dependencywalker http://dependencywalker.com/ reveal that the newt.dll fail to resolve strncpy_s from MSVCRT.DLL
Created attachment 722 [details] dependencywalker-newt.dll-2.2.4.png running dependencywalker on the newt.dll from 2.2.4 manages to resolve all functions used from MSVCRT.DLL
it appears this is a mingw issue: http://sourceforge.net/p/mingw-w64/mailman/message/31184492/ " We recently received some bug reports that executables compiled with mingw-w64 couldn't be executed on Windows XP environments. Users would get fatal error messages which indicate that the symbol strnlen couldn't be found in msvcrt.dll (which is correct for Windows XP). "
(In reply to comment #3) > it appears this is a mingw issue: > http://sourceforge.net/p/mingw-w64/mailman/message/31184492/ > > " > We recently received some bug reports that executables compiled with > mingw-w64 couldn't be executed on Windows XP environments. Users > would get fatal error messages which indicate that the symbol strnlen > couldn't be found in msvcrt.dll (which is correct for Windows XP). > " we need to check if there is a similar issue with mingw and strncpy_s
2.2.4 == working = 78f641de80d1c37cd61e5300eeba369c6aa9b1a1 2.3.0 == not working = 99f14475993d127f1b927056b309477753563a02 "git diff 78f641de80d1c37cd61e5300eeba369c6aa9b1a1..99f14475993d127f1b927056b309477753563a02 src/newt/natives" Discloses that WindowsEDID.c has been added, i.e. a method to report the monitor dimension on Windows. Even though this module loads all symbols dynamically .. there might be an issue. (No str*len* or str*cpy* call has been added)
(In reply to comment #5) > Discloses that WindowsEDID.c has been added, > i.e. a method to report the monitor dimension on Windows. > Even though this module loads all symbols dynamically .. > there might be an issue. Confirmed, without WindowsEDID.c module, the newt.dll could be loaded and launched. Now .. it doesn't seem that dependency walker show the actual missing symbols .. hmm, darn.
commit 07fb56cdd2ce6a74b2874cc6131bc2fd65f0887b Bug 1196: Fix Unresolved strncpy_s (MSVCRT) on WinXP Unresolved strncpy_s (MSVCRT) on WinXP, as shown w/ dependency walker (red module, red unresolved line). Mapped: _tcsncpy_s -> strncpy_s (!UNICODE). On WinXP MSVCRT has no strncpy_s. _tcsncpy_s(sOut, sOutLen, s, len) -> bound-check + _tcsncpy(sOut, s, len)