>
> 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.