JNI linkage issue

[Thomas Dorris]

I'm attempting to disassemble the COMMAPI's win32com.dll file, make a
simple change, then re-assemble it into a replacement win32com.dll.
To start, I really just want to disassemble then reassemble the
original win32com.dll to verify that the process works. But, so far,
it's not. I'm using pedasm to generate the disassembly. I have to
clean up a few of the names it spits out to make it reassemble OK and
generate a .dll file. Using dumppe on both the original win32com.dll
and the newly generated one shows that exported names as well as
import names from other DLLs match. The "hints" for the imported
names don't match up, but I don't know exactly what that means.
Additionally, the newly generated DLL shows "local symbols stripped"
as one of the characteristics where as the original DLL does not.
Otherwise, they appear identical.

Now, the problem. When this new .dll file is used by the JVM in a
sample COM port application, the DLL load fails with the following:

Error loading win32com: java.lang.UnsatisfiedLinkError:
C:\jre\bin\win32com.dll: Invalid access to memory location

This "feels" like something stupid. Like I'm using some wrong
libraries to link against or something like that. But I just can't
figure it out. Anybody have any ideas? Clearly the JVM is locating
the DLL file, bit just fails to load it.

Thomas Dorris

 

[Gordon Beaton]

I'm attempting to disassemble the COMMAPI's win32com.dll file, make a
simple change, then re-assemble it into a replacement win32com.dll.
To start, I really just want to disassemble then reassemble the
original win32com.dll to verify that the process works. But, so far,
it's not. I'm using pedasm to generate the disassembly. I have to
clean up a few of the names it spits out to make it reassemble OK and
generate a .dll file. Using dumppe on both the original win32com.dll
and the newly generated one shows that exported names as well as
import names from other DLLs match. The "hints" for the imported
names don't match up, but I don't know exactly what that means.
Additionally, the newly generated DLL shows "local symbols stripped"
as one of the characteristics where as the original DLL does not.
Otherwise, they appear identical.

Now, the problem. When this new .dll file is used by the JVM in a
sample COM port application, the DLL load fails with the following:

Error loading win32com: java.lang.UnsatisfiedLinkError:
C:\jre\bin\win32com.dll: Invalid access to memory location

This "feels" like something stupid. Like I'm using some wrong
libraries to link against or something like that. But I just can't
figure it out. Anybody have any ideas? Clearly the JVM is locating
the DLL file, bit just fails to load it.

It just sounds like you've broken the DLL by trying to hand patch it.
It apparently contains an invalid function pointer.

I fail to see how this is a JNI issue, despite the fact that you're
using the broken DLL from JNI.

I suggest you find an MS-specific newsgroup where someone can help you
with the tools and techniques of building a DLL from assembler.

/gordon

 

[Thomas Dorris]

It just sounds like you've broken the DLL by trying to hand patch it.
It apparently contains an invalid function pointer.

Thanks for the tip on an invalid function pointer. I'll disassemble
the new DLL to make sure it assembled as I expected it. However, in
this case I haven't patched any of the code yet. I've only attempted
to re-assemble the original DLL. The changes made to the output of
pedasm were to remove underscores so that the exports of the resulting
DLL were correct. Presumably, if those were the issue, the JVM
probably would have just complained about not finding the required
method.

I fail to see how this is a JNI issue, despite the fact that you're
using the broken DLL from JNI.

I assume you're referring to the subject which suggests a linkage
issue, not an issue with JNI itself. JNI I understand. The specifics
of how the windows implementation of the JNI loader work, I do not.
At the time I posted, I was thinking along the lines that some sort of
prototyping information might be missing from an assembled copy of a
DLL that would normally get dumped into the file if compiled from
original C code that the windows version of JNI might require. Thus
the post in this forum. But if we approach this as an internal DLL
problem (which could very well be the case), then I agree an MS
specific forum would be more appropriate. I'll try to locate such a
thing. I still believe this is an appropriate forum, though, as
others trying to do JNI work under windows may have run into the exact
same problem before.

All this crap aside, it may be a moot point anyway as I've had second
thoughts about this approach. It's kinda "neat" in one sense, but not
exactly very portable. If I instead write a whole new class that
provides a single method to act on the COM port like I want, then I've
provided a hook for other platforms to plug into. If I were to simply
hack the win32com.dll file to act like I want, then other platforms
would have to go through the same pain to get the same behavior since
there would be no source level entry points to code to.

Still, this problem has annoyed me to the point that I want to get it
solved whether I use it or not.

Thomas Dorris