JIntellitype64.dll can not be loaded correctly since 8u261 about jintellitype HOT 54 CLOSED

A deeper debug: when it runs to JIntellitypeHandler.cpp @ line 40, I find it unable to get the correct pointer, that is, l_handler , while it can be returned properly using 8u251. I don't know whether it's caused by jvm or not, but again, for detailed information, I need jvm.pdb. Now I'm trying to compile openjdk 11 to see if I can get the pdb file.

from jintellitype.

AdoptOpenJDK has a few request for a distribution of openjdk that would include the necessary jvm.pdb debugging files. Perhaps creating a request there or contacting one of the devs to do a single build would be useful? Really hoping we can get this figured out @melloware @RocketBD . For now I can continue to force an install of 8u251, but obviously this is less than ideal.

from jintellitype.

@melloware I'm excited to inform you of the solution of this problem. After countless random attempts, I finally found out the key breakthrough point the size of JIntellitypeHandler pointer which was the same as jint's years ago.
According to the result, I suppose that jvm compiled with VS2017 has doubled the size of JIntellitype pointer, so when getting it after store, the pointer is incorrect. So I changed the type of handler from int to long in Java code(And synchronized modifications in cpp code).
It has passed tests running with openjdk 11. I recommend you to create a new branch as later I will create a pull request. By the way, I will also release binary files in my fork soon. Solving such a historical problem, could you add me to the contributor list?

from jintellitype.

@melloware now you can remove

Currently does not work on Java 11, probably starting with Java 9. Latest recommended version is Java 8.

in your README.md.

from jintellitype.

I would think so. Something they have done has broken my JNI code and I wonder if they backported JDK9+ fixes see here:
#21

from jintellitype.

The release note may be useful: https://www.oracle.com/java/technologies/javase/8u261-relnotes.html
"
As part of ongoing maintenance, the Microsoft Visual Studio 2017 tool chain will be used to build JDK 7 and JDK 8 for Windows. JDK 8u261, in the July 2020 CPU, was built with Visual Studio 2017. With the release of the January 2021 CPU, JDK 7u291 will move to Visual Studio 2017.

Moving to Visual Studio 2017 for JDK 7 and JDK 8 requires changing the runtime library that the JDK/JRE depends on. Before this change, JDK/JRE implementations used and shipped the Microsoft Visual C++ 2010 SP1 Redistributable Package (x86/x64) that included MSVCR100.dll [a][b]. Microsoft Visual Studio 2017 uses a different set of libraries/DLLs.

Native applications (including JNI) that have depended on and assumed the presence of MSCVR100.dll in the JDK/JRE directory will fail to run. When this happens, users will see an error such as:

"The code execution cannot proceed because MSVCR100.dll was not found. Reinstalling the program may fix this problem."

These applications should be rebuilt and shipped with modern C++ runtime dependencies that use a later instance of Visual Studio. Applications should not depend on DLLs included with the JDK/JRE that are not documented in the product as offering support for the specification or other functionality in Java SE.
"
I don't know if it's the reason of crashes.

from jintellitype.

that is very possible its the cause.

from jintellitype.

I think it may be a good decision to rebuild your dll files using newer IDEs like VS, VS Code or JetBrains CLion 'cause these will not only build files in new mode (probably), but also give you some targeted suggestions which I learnt from using IntelliJ Idea.

from jintellitype.

@RocketBD I am absolutelly looking for help with that. I am not a C++ expert and i used the open source BloodShed IDE back when I first wrote this. then a user helped compile and build it for 64 bit DLL.

Unfortunately I don't have the time or the C++ experience to do this but I would love it if if someone did I would gladly release a new version if someone did.

from jintellitype.

@melloware I've found that when I build your project, I'm told the error C2733 occurs in your main file(Jintellitype.cpp), that is, you can't make 2 functions extern "C" at the same time. I think that's the main problem.

from jintellitype.

OK any clue on how to fix it?

from jintellitype.

Eh I'm not an expert at C++ too, so I don't know how to revise it.

from jintellitype.

@melloware I've compiled your cpp project with VS, and when I'm trying to debug it, I find that if I'm using 8u251, m_window object is normal(that is at JIntellitypeHandler.cpp@181:20), so your program runs successfully. But when I use 8u261, the m_window seems broken when it's going to register hot key.

from jintellitype.

That is great debugging. I thought I had read some post somewhere about the new JRE's preventing creation of Windows in JNI. But for the code to work I think I have to have a MS Window to listen for the Intellitype calls. Unless there is some other way to do it.

from jintellitype.

@melloware https://github.com/RocketBD/jintellitype Here's my fork and I mainly modified JIntellitype.cpp(GWL_USERDATA->GWLP_USERDATA(or the IDE can't find it's declare)) and com_melloware_jintellitype_JIntellitype.h(at line 48: jobject -> jclass(that causes C2733 error)).

from jintellitype.

The main problem I'm facing to is that I don't know which statement caused the damage of m_window. I think if I know it, I may solve the problem.

from jintellitype.

So bascically here is where i create an invisible window can you debug this?

// Create window
	m_window = CreateWindow
	(
		TEXT( "JIntellitypeHandlerClass" ),
		TEXT( "JIntellitypeHandler" ),
		WS_OVERLAPPEDWINDOW,
		0, 0, 0, 0,
		NULL,
		NULL,
		m_instance,
		NULL
	);

is that not creating the Window?

from jintellitype.

No, I create a breakpoint on the statement you mentioned, but in two cases above, when I try to step over, though VS can't resolve m_window in the memory, I can clearly see its address. The point is, if I use 8u261, when it runs to line 181, I put my mouse over m_window, I can't see its address, while the address will be shown correctly with 8u251.

from jintellitype.

I think getting jvm.pdb may provide me with more help in debugging.

from jintellitype.

I've done some debugs just now and gotten some new things. Using 8u261, I find that your program can be initialized correctly, but when it's registering hot keys, the whole object(this) of JIntellitypeHandler looks deleted, I can't get any objects belong to this. That causes the fatal exception and the DLL stops running.

from jintellitype.

Hmmm so somehow something is being lost in the JNI hand off between the DLL and Java. I was googling and there are tons of examples of doing something similar to what I am doing.

from jintellitype.

So here is a sample JNI app listening for windows events that is almost exactly what JIntellitype is doing: https://www.codeproject.com/Tips/1257858/How-to-get-shutdown-event-in-windows-from-java-app

from jintellitype.

So can it run properly?

from jintellitype.

I don't know if as just pointing out that article is doing exactly what we are doing. So I would think a lot of JNI code like this would be failing and not just ours.

from jintellitype.

Why not try Visual Studio out? The community version is free but powerful for individuals.

from jintellitype.

Yeah I know its a bloated beast was hoping to avoid having to install. :) I will see if I can get it installed and take a look.

from jintellitype.

Yeah it takes up more than ten gigs of my hard drive space, but it DOES help me a lot with generating DLL file, examining unexpected errors and debugging. For it, Dev-C++ is just like a useless dot.

from jintellitype.

Maybe it's a good idea to build it with OpenJDK.

from jintellitype.

I think I could get this error to occur with Oracle or OpenJDK after 9+.

from jintellitype.

@melloware not sure if this would help? This seems to use JNI also and is capturing keyboard/mouse events natively?

https://github.com/kwhat/jnativehook

from jintellitype.

I can't quite follow his code but it looks like he is using something called a Hook Thread to listen to Windows events and we use a hidden Window to listen to all the events. Like I said though I am not a C expert by any means. But he definitely looks like he is doing it differently than we are.

from jintellitype.

Would it be possible to switch to his method in the underlying JNI code and adapt it for use in JIntelliType?

from jintellitype.

It could be possible however to register for IntelliType events like PLAY PAUSE etc I believe it HAS to be a Windows Hook to an invisible window like I am doing. I don't know if those are available to just a hook thread. Years ago I know it had to a use a Window else you could not intercept those events.

from jintellitype.

Oh I forgot about the IntelliType events....I don't use those myself, so completely forgot!

from jintellitype.

HA yeah that was the whole reason I wrote this library what I had a Java Mp3 Jukebox app and need to listen to those for pausing and playing music in the Jukebox for keyboards that have them or the MSFT MCE Remote could send those signals.

from jintellitype.

I did some testing with the JAR and all of the media keys actually seem to be captured (voume up/down/mute, play/pause, skip track, etc).

edit: I take that back, I had my function keys messed up on my keyboard.
volume controls work, but media controls do not work.

There is actually an open issue on the github regarding this exact topic:
kwhat/jnativehook#324

from jintellitype.

@melloware would you consider branching the code based off of jnativehook with the note that it currently doesn't work with intellitype keys? I'm trying to see how easy it would be for me to do it myself, but I know little to nothing about this kind of stuff regarding JNI.

from jintellitype.

@scottismyname let me ask the jnativehook team. I think the problem is the two biggest features of JIntellitype are Global Hotkeys and Intellitype messages and I think both you need a Window for. But let me check.

from jintellitype.

Excellent! When you submit the PR make sure to add yourself to the developers section of the Pom.xml and I will do a release to Maven Central!!

from jintellitype.

@melloware I just tested basic functions, so bugs are possible. By the way, using win10, my dll and your dll can not detect bindings: Win + A and Ctrl + Shift + C. Maybe these are detected by the OS.

from jintellitype.

@RocketMaDev do I need a new Jintelli64DLL as well? I am trying to run the JintellitypeDemo.java and its getting this error:

Exception in thread "main" java.lang.NoSuchFieldError: handler
	at com.melloware.jintellitype.JIntellitype.initializeLibrary(Native Method)
	at com.melloware.jintellitype.JIntellitype.<init>(JIntellitype.java:114)
	at com.melloware.jintellitype.JIntellitype.getInstance(JIntellitype.java:207)
	at com.melloware.jintellitype.JIntellitype.checkInstanceAlreadyRunning(JIntellitype.java:359)
	at com.melloware.jintellitype.JIntellitypeDemo.main(JIntellitypeDemo.java:86)

And also seeing a JVM crash.

from jintellitype.

That's right. I haven't update the binary files inside. But I have upload them in my fork repo (in release bin)

from jintellitype.

OK I grabbed your binaries and now I get past that issue but now get this error...

Caused by: java.lang.UnsatisfiedLinkError: C:\Users\melloware\AppData\Local\jintellitype\1.4.0-SNAPSHOT\JIntellitype64.dll: Can't find dependent libraries
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
	at java.lang.Runtime.load0(Runtime.java:809)
	at java.lang.System.load(System.java:1086)
	at com.melloware.jintellitype.JIntellitype.loadLibrary(JIntellitype.java:136)
	... 2 more

Can't find dependent libraries? I am on the latest Windows 10.

from jintellitype.

I wonder if this requires some Visual C++ runtime I don't have installed on my machine?

from jintellitype.

I wonder if this requires some Visual C++ runtime I don't have installed on my machine?

I think that's the main reason. Try to warn users to download necessary runtime file in your README.md. You may use some tools to detect what files are missing as I've installed full environment.

from jintellitype.

OK it says I am missing "VCRUNTIME140_1D.dll" and I installed VC++ Runtime on my machine

https://developercommunity.visualstudio.com/t/vcruntime140-1ddll-is-missing/888909

"you are not allowed to take a program built in debug from a machine to another machine that does NOT have visual studio installed. Instead I would recommend you build with debug /Zi but use /MD not /MDd so that your debug code has non debug c runtime dll's."

So can you build non DEBUG versions of those DLLs for me?

from jintellitype.

I've modified parameter and regenerated them, please grab them again in my release.

from jintellitype.

OK the 32 bit version went from 60KB to 55 KB but the 64.dll is the exact same size and Dependency Checker is still saying its using the Debug DLL.

Your 32BIT DLL is passing the check.

from jintellitype.

I've update config and upload them again. Check them out in my release.

from jintellitype.

OK it works now! I will work on putting together a release to Maven Central. Thanks!!

And yes I see that WINDOWS+A and CTRL+SHIFT+C used to work but do not work now. Looks like anytime I press WIN+ its bringing up some kind of help screen on my laptop.

from jintellitype.

1.4.0 is now in Maven Central: https://repo1.maven.org/maven2/com/melloware/jintellitype/

from jintellitype.

@scottismyname You can use 8u261 now as the new version 1.4.0 has fixed the bug.

from jintellitype.

README.MD is updated.

from jintellitype.

Thank you both! I have already deployed this to my program and confirmed it is working with 1.8u281 as well as AdoptOpenJDK 11

from jintellitype.