Created attachment 720 [details]
jogamp-2.3.2 19aug test.log test_dbg.log .7z
The runtime version check using
fails on WinXP with the message
Exception in thread "main" java.lang.RuntimeException: java.lang.ClassNotFoundException: Failed to find NEWT Display Class <.windows.DisplayDriver>
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]
reveal that the newt.dll fail to resolve strncpy_s from MSVCRT.DLL
Created attachment 722 [details]
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:
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:
> 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
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.
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)