Cross-platform DLL selection

Friends,

I'm sorry if this is already covered somewhere but I've looked and can't find it.

Is it possible to configure a Swing Application Framework app that uses JOGL to dynamically choose the right set of Windows DLLs (64- or 32-bit) at startup based on VM word size?

Currently I'm running a tiny Java program in the Installer that queries the JVM and then copies the corresponding DLLs.

But this app is installed in (many) schools. Some have complex setups with both JVMs installed under 64-bit Windows. Sysadmins install my app with one JVM and user paths are set for the other. So my app dies a horrible death at startup.

Even though this is a dumb problem, it happens often enough that it would be worthwhile to modify my app to choose the right DLLs at runtime.

Is there a way to set up JOGL and code for this?

Thanks.

Hi

Actually, it already works, it is already implemented. As I have no access to any machine under Windows, someone else tested my game with a 32 bits JVM on a 64 bits operating system and it works (after JOAL bug 550 has been fixed by Sven). All JogAmp APIs (JOCL, JOGL, JOAL) use the same mechanism by default: just put the JARs containing the native libraries into the same directory than those containing the classes, put only the JARs containing the classes into the classpath and GlueGen will automatically extract the proper native libraries (.so, .jnilib, .dll) and loads them.

If you're not convinced, try it by yourself:
http://tuer.sourceforge.net/very_experimental/tuer.jnlp

Sven just implemented a great feature, it drives the deployment easier, you don't need to set the Java library path anymore. Best regards. I'm falling asleep...

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.

Set jogamp.gluegen.UseTempJarCache to false as early as possible to disable this feature.

On Thursday, January 19, 2012 12:16:12 AM Gene [via jogamp] wrote:
Even if you don't disable the native JAR file feature,
as you would with '-Djogamp.gluegen.UseTempJarCache=false',
it should fall back to plain old DLL files (if found in the usual lib path).

The snapshot you show just tells me that you haven't installed
the gluegen native JAR file for Windows 32bit, thats all.
Maybe the machine is 64bit, but the running JVM is 32bit!

Either way (native JAR file or plain DLL's) you need to provide those
resources.

As Julien mentions, when disabling the native JAR feature completly
via a Java property setting (at launch for example, see above),
it should behave as you are used to.

I still prefer native JARs .. since deployment is much simpler.
The next RC will also contain one 7z archive file including all
native JAR files for all supported platforms.

Dunno if this helps ..

Oh .. you could ask on of your students/clients to run our JOGL
information applet:
  <http://jogamp.org/deployment/jogamp-current/jogl-applet-version.html>

or Webstart:
  <http://jogamp.org/deployment/jogamp-current/jogl-application-version.jnlp>

which shows you details about the running platform and JVM.


~Sven

>
> http://forum.jogamp.org/file/n3670982/Untitled.png 

Thanks Sven. Extremely helpful as usual.   Great to know about the ability to turn off this feature.  

I was really worried this would turn into a big problem because we needed to release and there was no way to delay.

But we've released and had about 1,000 downloads now and only 2 complaints.  The other looks like a broken Java installation.  This is without disabling the DLL caching behavior, so you're right it's defaulting correctly.

However this one installation affects about 32,000 kids, so I'd really like to figure it out.  It's a big school complex.

My reasoning was it's looking for a 586 gluegen native and not finding it, so must have already looked for the DLL and couldn't see it.

So I verified by asking the user to check exact file size that the correct 32-bit glugen-rt.dll is installed with the main() jar just where it should be.  I also took Launch4j out of the picture by having them run java -jar directly.

I have asked them to install the jogl and gluegen native jars to see what happens.

My bet is that this is some very aggressive non-default DLL search policy or else an aggressive virus checker. Schools put these things in place so student's can't mess up their laboratory machines.

Perhaps there's something about the DLL manifests or it could be that my installer doesn't have a code certificate so the virus checker thinks the DLLs are tainted.  (I'm in process of getting a code certificate.)  Since you guys deal with lots of installation issues, I thought maybe someone has heard of this kind of thing before.

>>> Added after initial post:
As early as Windows XP SP1 there was a policy option to load only signed DLLs, so this is moving up the ladder as a good possiblity for what is wrong.  The reference is http://technet.microsoft.com/en-us/library/bb457006.aspx.
>>> End addition.

I'll post more if I learn something that may be of use to others.  Again thanks for your help.

On Friday, January 20, 2012 01:57:39 AM Gene [via jogamp] wrote:
Sounds awesome and we appreciate your direct and 1st hand experience very much,
since we only see the complaints about something not working :)

> However this one installation affects about 32,000 kids, so I'd really like
> to figure it out.  It's a big school complex.

Of course.

>
> My reasoning was it's looking for a 586 gluegen native and not finding it,
> so must have already looked for the DLL and couldn't see it.

Oh .. it's the other way around, ie. it tires to use the native JAR file.
This wasn't found on that machine (the stack traces and exception messages
- note: _Catched_). Then it will try to load the plain DLL files from the
usual location (java library path, or PATH, ..).

>
> So I verified by asking the user to check exact file size that the correct
> 32-bit glugen-rt.dll is installed with the main() jar just where it should
> be.  I also took Launch4j out of the picture by having them run java -jar
> directly.
>
> I have asked them to install the jogl and gluegen native jars to see what
> happens.
very good. Again: testing the Applet or Webstart may also give some hints.

I remember one post here (but not exactly ..) saying that some virus scanner
had a false positive w/ one of our files .. never experienced this personally though.

Of course, you can try to use on of our _signed_ JAR files (native + pure-java)
of our official RC5 release:
  http://jogamp.org/deployment/v2.0-rc5/jar/ (all properly signed)

If they could run the Applet/WebStart (which uses these signed JARs) ..
that may also strengthen this direction / suspicion.

>
> I'll post more if I learn something that may be of use to others.  

Yes, please do so! These experiences are very valuable.

> Again
> thanks for your help.

Thank you!

Cheers, Sven

>

AVG antivirus believes JOGL is a virus, Sven is right. If you want, I can try to contact the people liable for this software.

On Friday, January 20, 2012 10:35:30 AM gouessej [via jogamp] wrote:
>
> AVG antivirus believes JOGL is a virus, Sven is right. If you want, I can try
> to contact the people liable for this software.
>

That would be awesome, I know this will takes some time - thank you!

~Sven

I've just done it. I will phone them Monday if necessary.

Just a note here to close out this discussion.  This turned out not to be that the DLLs weren't loading but that the call to GLCapabilities was generating a memory access error inside the graphics driver.  The user wasn't furnishing enough of the stack trace to see the final lines indicating this as the problem.

As my app now has both OpenGL and vanilla Swing rendering paths, I was able to work around this by providing a limited graphics mode where the JOGL API is never touched at all.

Given the bug report frequency we are seeing, JOGL 2 seems more likely to manifest driver bugs during initialization than JOGL 1.  I suppose this is because it's making a more thorough probe of supported features.

Thanks again for all the help.

JOGL 2.0 uses a slightly different path than JOGL 1 during initialization but I don't think it's making a more thorough probe of supported features. This problem mainly occurs under Windows. Could your user provide the full stack trace please? It would be very helpful. Some applications cannot use a Swing rendering path; therefore, fixing this bug is very important in my humble opinion.

On Thursday, January 26, 2012 11:23:27 AM gouessej [via jogamp] wrote:
>
> JOGL 2.0 uses a slightly different path than JOGL 1 during initialization but
> I don't think it's making a more thorough probe of supported features.

We do a more thorough probing w/ JOGL2.

For example, JOGL1 was 'only' creating a context on-demand when a user issues the call.
JOGL2 does query all available profiles and hence it's capabilities.
This query is thorough, ie. it creates the context, makes it current and releases it.

If there is a bug within this query, initialization fails somehow.
We have experienced such failure w/ OS X 10.6 and NVidia, where we had to add
a glFlush() or glFinish() before releasing the context.


> This
> problem mainly occurs under Windows. Could your user provide the full stack
> trace please? It would be very helpful.

Yes, running the 'etc\test_dbg.bat' as our FAQ (Bugreport ..) mentiones
could disclose the root cause of the bug.
    <http://forum.jogamp.org/Problem-with-GLProfile-and-jogl2-rc2-td3447491.html#a3447546>

We actually have a few bug reports in regards Windows XP w/ old driver open,
but since I could not get my hands on those machines and I could not
reproduce the problem with my old machines .. it's hard to find those issues.

> Some applications cannot use a Swing
> rendering path; therefore, fixing this bug is very important in my humble
> opinion.

Of course it is, I agree.
Hope we can get to the root cause.

~Sven

I tried to setup Internet on an old machine with Windows XP but it is so old that even my ADSL set top box does not work fine with it and my Wifi USB key does not work neither :(

I finally got a full description of the machine where this problem was occurring and uploaded it as an attachment [CAD-CAM_Lab.pdf] .  As you can see the display is ATI Radeon Xpress 1150 Series.  Windows XP.  This does not list the driver version, but the sysadmin says he got the most recent ones from ATI.

I also notice they have SMART Notebook and other SMART software installed. Their stuff is pretty aggressive about grabbing video hardware.  I'll ask him to disable these programs and see if JOGL starts working.

Anyway this is not urgent because I got them running by implementing a dumbed-down animation with native Swing graphics.  It only cost me two long nights and a weekend to convince Swing it really wanted to do hidden surface removal... ;-)

Take care all.