Skip to main content

phoneme pp b127, DLL issue

4 replies [Last post]
jldominguez
Offline
Joined: 2008-01-02

Hello,

I have tested phoneme personal profile b127 in my PDA with Windows Mobile 6.1 and it fails to load my DLLs which worked fine with b107 for example. I have tested also phoneme for WM5 and WM2003 on this PDA with WM6.1 without success.

The DLLs and the EXE file that starts the app were created with the same MS Visual Studio framework, but the EXE works and the DLLs dont work.

I have read your comment about those three required DLLs (AYGSHELL.DLL, WS2.DLL and WINSOCK.DLL). All of them are available in my Windows folder.

Any ideas?

If you want to make a test, this code should be enough to use our smalles DLL. The DLL can be downloaded here:

http://subversion.gvsig.org/gvSIG-mobile/pilots/branches/pilot2/resource...

==================================================
package es.prodevelop.gvsig.mobile.common;

public class ProcessUtils {

static {
try {
System.loadLibrary("processes");
} catch (Throwable th) {
System.err.println("Unable to load 'Processes' library!");
}
}

public static native boolean startOrForeground(
String title_part,
String exec_file_full_path,
String exec_parameters) throws UnsatisfiedLinkError;
public static native String getSDCardPath();
public static void touch() { }
}
==================================================

Regards
Juan Lucas

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jldominguez
Offline
Joined: 2008-01-02

Thanks

davyp
Offline
Joined: 2007-01-03

Confirmed.

I had another SWT application that did not run anymore either. I will look into it.

Davy

davyp
Offline
Joined: 2007-01-03

Could you check what happens if you copy the processes.dll file into the same bin folder as the cvm.exe binary?

It appears that the option -Djava.libary.path does not work, but if the dll library is in the
folder mentioned above, my test applications work.

Davy

davyp
Offline
Joined: 2007-01-03

I have traced the problem back to svn rev 18009 that modified the loadLibrary
function of the class loader. Undoing that change seems to fix the problem. I have
tested with development build b129 (svn rev 19446), and it solved the problem,.

In the mean time there have been changes in svn rev 19471 that modify that same
file, so the problem may have already been fixed in trunk. I will try to put new builds
online that incorporate my temporary fix, and look if the problem is fixed when the
current code in trunk is promoted into a development build.

Davy