OK, a bit of progress.

The actual application I'm writing is a demo that will be used once at a conference, then thrown away. So I will feel less like I wasted my time if I can contribute working code/examples back to the community in the process. So I restricted my search to fully free, open source (both the native wrapper itself, and any reliances on access to the DLL source code, which we do not have) "Pure Processing" solutions. (Yeah, "just load up Eclipse/javac and..." could simplify the solution maybe, but Processing users aren't Processing users because they wanted to become Java developers...)

So here are the native interface options I found:

JNIWrapper 30-day trialware.

JNI we have no public DLL source code, and so can't recompile it with JNIEXPORT*s. JNI is also reputed to be very complicated and error-prone (possibly by people selling their own native wrapper products...). * It may be possible (if messy) to create another DLL from scratch that wraps the closed-source DLL functions and re-exports them JNI-aware, but my whole purpose of writing a heavily graphical demo app in Processing is the avoidance of work, and this really is starting to sound like work. This may be a last-resort try.

JNative (Java to Native Interface) It takes a lot of typing to actually call the DLL function, but this is the only one I found so far that a) does not require DLL source, writing C code, setting up a native compiler, etc., b) supports Callbacks, and c) works! I now have a working (ugly, but working!) proof of concept using JNative as a Processing library.

Java Native Access (JNA) ...maybe? Looks like nLink, but messier.

nLink Weirdness with non-Pascal calling conventions and on further inspection, won't support callbacks anytime soon. I'll post my progress so far with nLink, maybe it'll help someone else. If you know your native function uses the _stdcall convention (all the DLLs that come on your Windows CD use this) and you don't need callbacks, nLink is probably the easiest way to go.

NativeCall No callbacks; supports the _stdcall convention only

J/Invoke Trialware

JNIEasy 5-day trialware

Gluegen - auto-generate JNI wrapper?

SWIG - auto-generate wrapper DLL source?

Hey,

I'm a newbie when it comes to Processing but impressed so far. I've been using JNative hack as documented but have one problem:

Has anyone had any problems exporting to a windows app? My exported apps simply won't launch?

Thanx.

J.

Where is the DLL? Is it in the Windows path?

Looks like a good place, indeed...

Disclaimer: I never use JNative and even less you DLL! Just trying to help.

Some people had issues with export function recently, you should first try it with a plain sketch.

I just tried, plain sketch and one using an external jar, it worked fine with Processing 1.0.1 on Windows XP Pro SP3.
I noticed the .exe file must have the lib folder with it to work, otherwise I get an error message:
---------------------------
Java Virtual Machine Launcher
---------------------------
Could not find the main class. Program will exit.
---------------------------
OK  
---------------------------

You write: "the app crashed on execution". Do you get an error message? A stack trace?

Mmm, I tried to run a sketch doing only println stuff then exiting, I get no output on stdout.
I made it write to a file, it isn't created when running the exported Windows application, while I got it when running in PDE.
I will investigate a bit more.

If you look at Export page, you will see a number of libraries seems not to work when exported as applications (video at least).
Maybe this one suffers the same issue...

The fact my simple sketch using PrintWriter doesn't create a file after being exported, while it does when running in PDE, is another hint that this export is, sometime, problematic.
I should fill in a bug report for this last issue.

Hint: I used Sysinternals' Process Monitor to see the file activity when running the sketch. I can see the text file created when running in the PDE, and no attempt at all when running the exe file... In both cases, an input file is read OK.
Maybe you can use the same utility to check if the DLL is correctly found.

OK, I was half wrong for the "text file not created" part.
The problem is that I didn't create a sketch frame: just read info, write file and exit. Apparently, the exit is too fast and doesn't let Java the time to write the file. If I display some image, I have the file created. Same if I add delay(1000); before exit() in my former sketch.

There is still the problem of not getting stdout (println output). I think that's a side effect of using ShellExecuteEx (similar to doing "start something" on the command line: it uses the "open" verb, and javaw to boot). It would need to pipe stdout (and stderr) to standard channels, or something. Perhaps more trouble than worth, since we rarely use Processing to do something else than graphics output!

Side note: the xxx.exe file is always the same: it just goes to the lib folder, and finds which sketch to run, with which jar files, in the args.txt file.
You might want to try and add your DLL to this list, who know? In this case, you should copy the DLL to the lib folder.

Update: Just tried this out on a different DLL file (User32.dll) which comes with windows. Same result, works fine in PDE but not when exported. Think this one might have me beaten!