JNI UnsatisfiedLinkError- how do I load libraries correctly? - dll

I'm trying to work with the Java sample Database program from the CardScan SDK.
I am working with files located in Java/JNI and Java/Database. The program must be run with a 32 bit JRE. I was able to do so on a 64 bit machine by uninstalling Java and installing the 32 bit version, then re-adding the system path for Java. I can run the program and interface with a CardScan database file (.cdb) successfully by double clicking the SDKData.bat file, but when I open the source files for editing and edit the Java.library.path to include the required library (CRTK_JNI.dll), I get UnsatisfiedLinkErrors everywhere:
Exception in thread "main" java.lang.UnsatisfiedLinkError: sdkdata.CRTK.CRTK_Init([I)I
at sdkdata.CRTK.CRTK_Init(Native Method)
at sdkdata.CRTK.(CRTK.java:239)
at sdkdata.SDKData.(SDKData.java:97)
at sdkdata.SDKData.main(SDKData.java:643)
Java Result: 1
Presumably this is happening because the library is not loading properly.
What do I need to do to run and edit the program at full capacity (with all the native functions from CRTK_JNI in working order)?

Presumably this is happening because the library is not loading properly.
On the contrary. The library load is complete. You aren't getting that from a System.load()/loadLibrary() call, you are getting the error when calling your native method, the one that should have the signature:
package sdkdata;
public class CRTK
{
public native int CRTK_Init(int[]);
}
So it isn't there, or you have changed the signature without regenerating the .h and .c files, or you have manually mangled the declaration some other way.
Post your code.

To clarify, this Java sample program is officially unsupported by the CardScan API - it was a bad idea to try to use the API with an unsupported language relying solely on an experimental implementation. I ended up using one of the supported languages (Visual Basic) to work with the SDK; if anyone looking at this question happens to be struggling with using the CardScan API, here is my VB implementation on Github.

Related

image-height not resolve output

Trying to achieve this proposal to make a div size based on its background image I'm using Less 2.5.1 compiled by Web Essentials 2013 for Update 4 version 2.5.4 and some functions do not resolve:
My Less File:
.myClass{
height:image-height("myUrl.png"); //<-- Do not resolve
width:percentage(1/2); //<--Resolves
}
Resolved Css File:
.myClass{
height:image-height("myUrl.png"); //Not good
width:50%; //Good
}
I'm having this problem with image-height, image-width and image-size. Not with the rest of Misc Functions
There's no problem resolving the image by the compiler, because it's working fine when I used it like:
background-image:url("myUrl.png");
In the documentation there's a note for these methods saying:
Note: this function needs to be implemented by each environment. It is
currently only available in the node environment.
In the WebEssentials documentation it says:
Web Essentials uses the node-less compiler and it always uses the
latest version
And
NodeJS compilation - Web Essentials uses NodeJS to run the compiler.
It's the fastest and most accurate compiler for LESS available.
I'm missing something that I don't know. What does that note mean? What
should I do?
I've create a jsfiddle to share with you my goal.

How to load a dll in Tcl?

What I have tried (running Tcl and Tk 8.6.0 on Windows):
load D:/toot/bar/em.dll
load "D:/toot/bar/em.dll"
load D://toot//bar//em.dll
load "D://toot//bar//em.dll"
load D:\toot\bar\em.dll
load "D:\toot\bar\em.dll"
load D:\\toot\\bar\\em.dll
load "D:\\toot\\bar\\em.dll"
All of which return one of these two errors:
couldn't load library [what I put after 'load']: invalid argument
couldn't load library [what I put after 'load', rendered]: this library or a dependent library could not be found in library path
Assuming that file exists D:/toot/bar/em.dll returns truea, load D:/toot/bar/em.dll should work. However, it sounds like you've got problems with things (i.e., other DLLs) that the library depends on.
This is a general problem on Windows that has been asked elsewhere on Stack Overflow; the answers there are relevant to this question. You should also be aware that if the DLL has been linked against a specific version of the Tcl DLL (not recommended on Windows for Tcl extensions) then you need to have the same version of Tcl installed as it was linked against. Stub-enabled extensions do not have this problem at all (though they can still run into problems with other required libraries being absent).
It's a shame that the load command doesn't tell you what DLL is missing in its error message, but IIRC the underlying OS API doesn't report it either. You're stuck with using an external tool to diagnose these things…
a Don't worry about backslash/forward-slash issues; Tcl handles those for you.
I have this problem, too,couldn't load library "ChariotExt": invalid argument.
And sovled it by change tcl version x64 to x86.

Reflexil deobfustication error

I'm trying to modify a .net application and I'm new to this. First step is attempting to deobfuscate the code using reflexil and I get the following error:
Reflexil is unable to clean this assembly: Member 'System.RuntimeTypeHandle "bunch of obfustatcated jibberish"(System.Int32)' is declared in another module and needs to be imported
The application comes with a bunch of dll's that it certainly uses, so I assume the declaration is in one of those files. How do I import this module?
In case it's helpful, reflexil says it was obfuscated with .NET Reactor 4.1
I decided to try de4not to deobfuscate and it worked without this issue.

Another JNI UnsatisfiedLinkError DLL problem

I've read lots of posts about this, but none address my problem.
I have a very small DLL that allows a Java process to send windows messages. It simply calls
FindWindowEx(...)
SendMessage(...)
I have compiled that with VS2005 and linked with /MT and all's fine, but if I try to make my DLL depend on MSVCRT and link with /MD then I get the unsatisfied link error.
java.lang.UnsatisfiedLinkError: MyDll.dll: Can't find dependent libraries
According to depends.exe it has two missing DLLs, GPSVC.DLL and IESHIMS.DLL. The first exists in c:\windows\system32 and the second is in a winsxs path. There are LOADS of other DLLs loaded from c:\windows\system32 and GPSVC.DLL is an odd one in that even as admin on my win7x64 machine, I cannot run depends on that - it says it's not found...
Anyway, I tried forcing a load of both of those DLLs in my Java by (simplified - I'm not in control of java.library.path)
Field field = ClassLoader.class.getDeclaredField("usr_paths");
field.setAccessible(true);
String[] paths = (String[]) field.get(null);
String[] tmp = new String[paths.length + 2];
System.arraycopy(paths, 0, tmp, 0, paths.length);
tmp[paths.length] = "c:/windows/system32";
tmp[paths.length + 1] = "c:/Windows/winsxs/amd64_microsoft-windows-ie-ieshims_31bf3856ad364e35_8.0.7601.17514_none_c06d7c9c27da8591";
field.set(null, tmp);
but that made no difference. I can fallback to make it statically linked, but I'd rather not.
Any ideas on what I can try next?
Antony
Well, I´m using Visual Studio 2010 but it could work on 2005 too.
You could try configuring the VC compiler using vcvarsall.bat that you can find in ProgramFiles in /MicrosoftVisualStudio20xx/VC .
You have only to launch vsvarsall.bat in Command Line with one of these options: x86 or ia64 or x86_amd64 or x86_ia64. I don´t know if it will help but it could be one of the problems that VC compiler is not configured to work with 64 bit machine.
When I´m working with JNI I use command line to compile the code and I had to configure the compiler on 64 bit machine.
Or you could pobably try to compile it via Command Line. Here is my favourite tutorial http://www.ibm.com/developerworks/java/tutorials/j-jni/index.html

Unresolved external SHCreateItemFromParsingName referenced VCL.LIB / Dialogs

I have a C++ Builder application I'm porting from C++ Builder 6 to XE on Windows XP.
A number of 3rd party controls are in use as well.
I'm compiling with Dynamic RTL = False
If I compile without run time packages I get the subject error message:
[ILINK32 Error] Error: Unresolved external 'SHCreateItemFromParsingName' referenced from C:\PROGRAM FILES\EMBARCADERO\RAD STUDIO\8.0\LIB\WIN32\RELEASE\VCL.LIB|Dialogs
If I compile with run time packages the error goes away.
Googling around reveals the SHCreateItemFromParsingName has to do with common control dialogs one can invoke with WinAPI calls.
All 3rd party controls I use work in a new/separate project; thus this problem does appear to be a simple #define or something.... (not sure)
I can not find anything in my project source that would cause this. I do have an TOpenDialog and a TSaveDialog in my project that replaced an older TMC components of the same names (TntOpenDialog, TntSaveDialog) that were used in CBuilder6 to give Unicode support for the same. Converted to the ones that ship with the VCL has not resolved this problem.
There is an Embarcadero thread on this but that person appear to solve by creating #define's to build their app for WinXP and new compatibility. Under XE, I set the C++ Compiler option to target Windows XP and newer and that did not work either.
Tried adding:
"#define WINVER 0x0502"
"#define _WIN32_WINNT 0x0502"
per MSDN link here:
http://msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx
to no avail.
Other than the Open/SaveDialog components, anyone have any advise or seen this before?
OK, spent two days on this and as soon as I post it here, I found the solution.
Under the Build Configuration (right click | edit )
Under Application there is a check box "Enable runtime themes" that was unchecked.
Checked it and problem now gone.