GetModuleHandleExA

677 views
Skip to first unread message

cessationoftime

unread,
Jan 15, 2012, 5:52:01 PM1/15/12
to NativeLibs4Java
I am trying to use the function GetModuleHandleExA:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683200(v=VS.85).aspx

And I am having a terrible time trying to get it to work.

BOOL WINAPI GetModuleHandleEx(
__in DWORD dwFlags,
__in_opt LPCTSTR lpModuleName,
__out HMODULE *phModule
);

I believe I am probably passing in the 2nd parameter incorrectly but I
have tried every possibility I can think of.

I have a callback function:

val hooked = new hookBack{
override def apply(wParam: Int, lParam: Int): Int = {
1
}
}

I get the address of the Callback function and then I need to pass it
into GetModuleHandleEx as a CString or WideCString.

val hookedAddress : Long = hooked.toPointer().getPeer()
val hSelf = allocatePointer[HINSTANCE__]

GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS |
GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT, hookedAddress, hSelf);

No matter what I seem to do GetModuleHandleEx fails and returns 0. I
have tried wrapping hookedAddress in numerous kinds of Pointers as
well as converting it to a string and a null terminated array of bytes
and passing it as a Pointer. What is the proper way to pass in this
argument and\or how can I get this function to return properly?


Thanks,
Chris

Olivier Chafik

unread,
Jan 15, 2012, 7:46:06 PM1/15/12
to nativel...@googlegroups.com
Hi Chris,

From what I understand, you're trying to get the module handle that corresponds to the address of a BridJ-generated callback, which does not actually correspond to any module : the function pointer is not the result of memory-mapping a part of any DLL, it's the result of BridJ (or actually, dyncall) allocating some executable memory and dumping some assembler code so that it can behave as a function.

Have you tried using a symbol that's actually exported ? FYI you can enumerate all the symbols of a DLL using NativeLibrary.getSymbols(), and you can get BridJ's native lib instance with BridJ.getNativeLibrary("bridj").

Otherwise, assuming the signature of your binding is something like GetModuleHandleEx(int, Pointer<Byte>, Pointer<HMODULE>) you can indeed pass the callback pointer directly : GetModuleHandleEx(..., callback.toPointer().asUntyped(), hSelf).

Cheers
-- 

cessationoftime

unread,
Jan 15, 2012, 9:21:14 PM1/15/12
to NativeLibs4Java
Thanks, that explains why it isn't working. It shouldn't! I have not
tried NativeLibrary.getSymbols, thanks for letting me know it is
there.

I need to be able to capture keypresses from anywhere to trigger the
microphone. So, I am trying to get a ModuleHandle that I can use to
set a global windows hook on the Callback function using
SetWindowsHookEx(). But based on what you just said and the MSDN page
for SetWindowsHookEx. It sounds like my callback function must be
contained within a c++ dll or it cannot be loaded, unless dyncall
provides a way around this. Perhaps I can use a Handle into the
section of memory that Dyncall is allocating, instead of HModule.

Chris

On Jan 15, 7:46 pm, Olivier Chafik <olivier.cha...@gmail.com> wrote:
> Hi Chris,
>
> From what I understand, you're trying to get the module handle that
> corresponds to the address of a BridJ-generated callback, which does not
> actually correspond to any module : the function pointer is not the result
> of memory-mapping a part of any DLL, it's the result of BridJ (or actually,
> dyncall) allocating some executable memory and dumping some assembler code
> so that it can behave as a function.
>
> Have you tried using a symbol that's actually exported ? FYI you can
> enumerate all the symbols of a DLL using NativeLibrary.getSymbols(), and
> you can get BridJ's native lib instance with
> BridJ.getNativeLibrary("bridj").
>
> Otherwise, assuming the signature of your binding is something like
> GetModuleHandleEx(int,
> Pointer<Byte>, Pointer<HMODULE>) you can indeed pass the callback pointer
> directly : GetModuleHandleEx(..., callback.toPointer().asUntyped(), hSelf).
>
> Cheers
> --
> Olivierhttp://ochafik.comhttp://twitter.com/ochafik
>
> 2012/1/15 cessationoftime <cessationoft...@gmail.com>
>
>
>
>
>
>
>
> > I am trying to use the function GetModuleHandleExA:
>
> >http://msdn.microsoft.com/en-us/library/windows/desktop/ms683200(v=VS...

Olivier Chafik

unread,
Jan 16, 2012, 2:10:27 PM1/16/12
to NativeLibs4Java
Hi Chris,

On Jan 16, 2:21 am, cessationoftime <cessationoft...@gmail.com> wrote:
> Thanks, that explains why it isn't working.  It shouldn't!  I have not
> tried NativeLibrary.getSymbols, thanks for letting me know it is
> there.
>
> I need to be able to capture keypresses from anywhere to trigger the
> microphone. So, I am trying to get a ModuleHandle that I can use to
> set a global windows hook on the Callback function using
> SetWindowsHookEx().

Have you tried GetModuleHandle(NULL) ?
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683199(v=vs.85).aspx

Cheers
--
Olivier

cessationoftime

unread,
Jan 16, 2012, 5:36:33 PM1/16/12
to NativeLibs4Java
Yes, GetModuleHandle(NULL) successfully returns a handle. I have not
tried using that handle to call SetWindowsHookEx as yet though. The
example I had made me think that GetModuleHandleEx was required, but
of course they were loading their function to SetWindowsHookEx from a C
++ DLL. I will try that tonight and see if it will work for me.

If it fails though I was considering trying to build my function in
the D language and link the JVM to the win32 API through D instead.
Are you aware of anyone trying to use Bridj with D ?

Chris
> Have you tried GetModuleHandle(NULL) ?http://msdn.microsoft.com/en-us/library/windows/desktop/ms683199(v=vs...
>
> Cheers
> --
> Olivier

Olivier Chafik

unread,
Jan 16, 2012, 6:23:31 PM1/16/12
to nativel...@googlegroups.com
Hi Chris,

2012/1/16 cessationoftime <cessati...@gmail.com>

Yes, GetModuleHandle(NULL) successfully returns a handle.  I have not
tried using that handle to call SetWindowsHookEx as yet though.  The
example I had made me think that GetModuleHandleEx was required, but
of course they were loading their function to SetWindowsHookEx from a C
++ DLL. I will try that tonight and see if it will work for me.

I can't think of a reason why it wouldn't work, but please keep us posted !


If it fails though I was considering trying to build my function in
the D language and link the JVM to the win32 API through D instead.
Are you aware of anyone trying to use Bridj with D ?

That would probably be a first, and would probably yield *interesting* bug reports :-)

cessationoftime

unread,
Jan 16, 2012, 10:15:41 PM1/16/12
to NativeLibs4Java
Well my SetWindowsHookEx call appears to succeed. However it appears
to succeed if I pass it the address of anything (I gave it a pointer
to an Int), not just the Callback function. I don't get any effect
from the hook, but it could be that I don't have this threaded
properly for it to work. However I think I probably cannot install it
globally as is. MSDN seems very adamant about the function coming
from a DLL, see what I pasted below. So instead, what if I created a
DLL that Bridj could stash away specifically to interact with Hooks,
and then that Bridj DLL talked to the Bridj Callback function as an
intermediary. In the Java code my hook handler could then inherit
from Hook<SomeMethod> instead of Callback<SomeMethod>

From MSDN : http://msdn.microsoft.com/en-us/library/windows/desktop/ms644960(v=vs.85).aspx#installing_releasing

"A global hook monitors messages for all threads in the same desktop
as the calling thread. A thread-specific hook monitors messages for
only an individual thread. A global hook procedure can be called in
the context of any application in the same desktop as the calling
thread, so the procedure must be in a separate DLL module. A thread-
specific hook procedure is called only in the context of the
associated thread. If an application installs a hook procedure for one
of its own threads, the hook procedure can be in either the same
module as the rest of the application's code or in a DLL. If the
application installs a hook procedure for a thread of a different
application, the procedure must be in a DLL. "

"You must place a global hook procedure in a DLL separate from the
application installing the hook procedure. The installing application
must have the handle to the DLL module before it can install the hook
procedure. To retrieve a handle to the DLL module, call the
LoadLibrary function with the name of the DLL. After you have obtained
the handle, you can call the GetProcAddress function to retrieve a
pointer to the hook procedure. Finally, use SetWindowsHookEx to
install the hook procedure address in the appropriate hook chain.
SetWindowsHookEx passes the module handle, a pointer to the hook-
procedure entry point, and 0 for the thread identifier, indicating
that the hook procedure should be associated with all threads in the
same desktop as the calling thread. This sequence is shown in the
following example."

Chris

On Jan 16, 6:23 pm, Olivier Chafik <olivier.cha...@gmail.com> wrote:
> Hi Chris,
>
> 2012/1/16 cessationoftime <cessationoft...@gmail.com>
>
> > Yes, GetModuleHandle(NULL) successfully returns a handle.  I have not
> > tried using that handle to call SetWindowsHookEx as yet though.  The
> > example I had made me think that GetModuleHandleEx was required, but
> > of course they were loading their function to SetWindowsHookEx from a C
> > ++ DLL. I will try that tonight and see if it will work for me.
>
> I can't think of a reason why it wouldn't work, but please keep us posted !
>
> > If it fails though I was considering trying to build my function in
> > the D language and link the JVM to the win32 API through D instead.
> > Are you aware of anyone trying to use Bridj with D ?
>
> That would probably be a first, and would probably yield *interesting* bug
> reports :-)
>
> Cheers
> --
> Olivierhttp://ochafik.comhttp://twitter.com/ochafik

Olivier Chafik

unread,
Jan 17, 2012, 3:30:41 AM1/17/12
to nativel...@googlegroups.com
Hi Chris,

It looks like it's possible to do this with JNA, so you might want to inspire yourself from this :
http://stackoverflow.com/questions/3078646/jna-keyboard-hook-in-windows

Cheers
--
zOlive
--
Olivier

cessationoftime

unread,
Jan 17, 2012, 1:48:59 PM1/17/12
to NativeLibs4Java
It Works! Thanks for the link. The key was following
SetWindowsProcEx with the PeekMessage function they mentioned


val modHandle = GetModuleHandleA(null: Pointer[java.lang.Byte])
val hhKeyboard = SetWindowsHookExA(WH_KEYBOARD_LL,
hookedKeys.toPointer(), modHandle, 0);
if (hhKeyboard == null) sys.exit(0);

val msg = new MSG();
val ptrmsg = Pointer.pointerTo(msg)
while (quit < 10) {
PeekMessageA(ptrmsg, null, 0, 0, 0);
Thread.sleep(100);
}


On Jan 17, 3:30 am, Olivier Chafik <olivier.cha...@gmail.com> wrote:
> Hi Chris,
>
> It looks like it's possible to do this with JNA, so you might want to
> inspire yourself from this :http://stackoverflow.com/questions/3078646/jna-keyboard-hook-in-windows
>
> Cheers
> --
> zOlive
>
> Le mardi 17 janvier 2012, cessationoftime <cessationoft...@gmail.com> a
> écrit :> Well my SetWindowsHookEx call appears to succeed.  However it appears
> > to succeed if I pass it the address of anything (I gave it a pointer
> > to an Int), not just the Callback function.  I don't get any effect
> > from the hook, but it could be that I don't have this threaded
> > properly for it to work.  However I think I probably cannot install it
> > globally as is.  MSDN seems very adamant about the function coming
> > from a DLL, see what I pasted below. So instead, what if I created a
> > DLL that Bridj could stash away specifically to interact with Hooks,
> > and then that Bridj DLL talked to the Bridj Callback function as an
> > intermediary.  In the Java code my hook handler could then inherit
> > from Hook<SomeMethod> instead of Callback<SomeMethod>
>
> > From MSDN :
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms644960(v=vs...

Richard Gomes

unread,
Jun 7, 2012, 7:45:39 PM6/7/12
to nativel...@googlegroups.com
Hello,

Could someone please publish environment settings which knowingly build the entire nativelibs4java properly?
Actually, I'm interested only on ScalaCL and its direct and transitive dependencies. I don't need the entire nativelibs4java thing.


My environment is:

$ mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 08:44:56+0000)
Maven home: /opt/java-dev/apache-maven-3.0.4
Java version: 1.6.0_31, vendor: Sun Microsystems Inc.
Java home: /opt/java-dev/jdk1.6.0_31-linux-x86_64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "2.6.32-5-amd64", arch: "amd64", family: "unix"


I have also tried these environments:
* Maven 2.2.1 with JDK1.6.0_31
* Maven 3.0.4 with JDK1.7.0_04



I've also removed my entire ~/.m2/repository and tried a build from scratch as shown below:

$ rm -r -f ~/.m2/repository
$ cd nativelibs4java/libraries
$ cd ScalaCL
$ mvn install -DskipTests


[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] ScalaCL Parent Project ............................ SUCCESS [3:21.616s]
[INFO] ScalaCL Collections ............................... SUCCESS [2:33.824s]
[INFO] ScalaCL Compiler Plugin ........................... FAILURE [3.634s]
[INFO] ScalaCLv2 Test .................................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6:00.716s
[INFO] Finished at: Fri Jun 08 00:38:43 BST 2012
[INFO] Final Memory: 14M/74M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project scalacl-compiler-plugin: Could not resolve dependencies for project com.nativelibs4java:scalacl-compiler-plugin:jar:0.3-SNAPSHOT: Failed to collect dependencies for [com.nativelibs4java:scalacl:jar:shaded:0.3-SNAPSHOT (compile), com.nativelibs4java:scalaxy:jar:0.3-SNAPSHOT (compile), com.nativelibs4java:scalaxy:jar:tests:0.3-SNAPSHOT (test), org.scala-lang:scala-compiler:jar:2.9.1 (compile), com.nativelibs4java:javacl:jar:1.0-SNAPSHOT (compile), org.scala-lang:scala-library:jar:2.9.1 (compile), junit:junit:jar:4.10 (test)]: Failed to read artifact descriptor for com.nativelibs4java:scalaxy:jar:0.3-SNAPSHOT: Could not find artifact com.nativelibs4java:nativelibs4java-parent:pom:1.7-SNAPSHOT in sonatype (http://oss.sonatype.org/content/groups/public) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :scalacl-compiler-plugin


I've circumvented the trouble by commenting out the plugin module:

<modules>
<module>Collections</module>
<!-- module>Plugin</module -->
<module>Test</module>
</modules>


Any direction is well appreciated.

Thanks a lot

Richard Gomes

Reply all
Reply to author
Forward
0 new messages