Posted by Gene on Jan 18, 2012; 11:16pm
URL: https://forum.jogamp.org/Cross-platform-DLL-selection-tp3667506p3670982.html

Thanks for the quick reply!  Gee it would have been nice to know that.  I did not realize the "Natives" jars contain DLLs.  Is this documented somewhere?

Anyway I've learned in the school of hard knocks that when executing a program entails writing executable files, many enterprise security schemes will interfere. So maybe this would not be the best for my app that must run on many different machines whose configuration I cannot control.

I am using Launch4J to wrap the main JAR of my app (solely so the Java icon can be replaced). For JOGL 1 I built an NSIS installer that checks the JVM and copies the right set of DLLs.  It puts them in the same folder with the Launch4j-generated EXE.  

This scheme worked well with over 10,000 different machines and JOGL 1.  So I'm using this same system for the JOGL 2 upgrade, and it seemed to work perfectly until now.

I have one school district where the DLLs are not being found.  It's a 32-bit JVM and the 32-bit DLLs are installed, but when they run they are getting a stack trace, attached below.  Sorry their machines are hobbled so I can't get text from them, only an image.

This is the same as a "DLL not found" trace I've received for other reasons in the past.  I under stand now why the tail end of the trace contains an Unzip attempt!

But normally putting DLLs in the same directory as the executable ensures those DLLs will be loaded AFAIK.  

These machines clearly have some management and security measures applied.  I am wondering if a non-standard DLL search policy is in effect.  

I'm debugging over the phone, so it's not simple to get information.

Many thanks to anyone who can help.