Library failing to load when remoting over VNC?

Ryan Walters: Hello, wonderful people of the Sikuli project!

I'm representing a visual automation team that uses a tool called T-Plan Robot to do pixel by pixel image comparison searches. We utilize the tool to run Java scripts that test our applications by clicking on pictures in a similar fashion to what Sikuli does. However, the tool is not good at modifying and scaling images while conducting its searches, and thereby does not do very well with minute changes, such as how Flash renders its images. We would like to stop running into this problem, as it requires recapturing images every time the application changes, which for us is quite frequently. We are therefore trying to implement the Sikuli jars for image recognition and report back the findings to our existing tool.

When we run our scripts, we open up a VNC connection to a slave machine that the scripts use for testing. When we try to execute our search function using Sikuli's exists() function, we get an exception caused by a Sikuli error, like so:
Caused by: java.lang.UnsatisfiedLinkError: Can't load library: C:\Documents and Settings\ctlee\tmplib\ScreenMatchProxy.dll
 at java.lang.ClassLoader.loadLibrary(Unknown Source)
 at java.lang.Runtime.load0(Unknown Source)
 at java.lang.System.load(Unknown Source)
 at com.wapmx.nativeutils.jniloader.NativeLoader.loadLibrary(NativeLoader.java:44)
 at edu.mit.csail.uid.Finder.<clinit>(Finder.java:16)
 at edu.mit.csail.uid.Region.findNow(Region.java:520)
 at edu.mit.csail.uid.Region.wait(Region.java:228)
 at edu.mit.csail.uid.Region.exists(Region.java:255)
 at com.automation.library.Library.waitAndClick(Library.java:625)

 We checked the file paths on both our test driving machine and our target slave machine. Both have the .dll's in the specified file path. Both our host and target machine are running the latest version of Java. Both machines are running 32-bit Windows XP, both with full service pack updates. Our code is considered to be remote, and therefore our classpaths on the slave machines do not include the JDK, but do have JREs pointing to their correct paths.

Here is our current path configurations:

Computer A(The master):
Environment Variables:
Classpath: C:\Program Files\Java\jdk1.6.0_21\bin;C:\Documents and Settings\ctlee\Documents\automation\RobotFramework\Java\bin
Path: C:\Program Files\Java\jdk1.6.0_21\bin;C:\Program Files\Sikuli\tmplib

System Variables:
Classpath: C:\Program Files\Java\jdk1.6.0_21\bin;C:\Documents and Settings\ctlee\Documents\automation\RobotFramework\Java\bin
Path: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Java\jdk1.6.0_21\bin;C:\Program Files\TortoiseSVN\bin

Computer B(Slave)
Environment Variables:
Classpath: C:\Program Files\Java\jre6\bin
Path: C:\Program Files\Java\jre6\bin;C:\Program Files\Sikuli\tmplib

System Variables:
Classpath: C:\Program Files\Java\jre6\bin;
Path: %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;C:\Program Files\Java\jre6\bin

 Any clue as to what could be going on here?

Is there something else that we need to do on our end? Or is this a bug?