Loading DLL from file not PATH
-
Valentinor wrote:
The code execution cannot proceed because jvm.dll was not found.
I think I have answered that more than once.
Valentinor wrote:
They should add an image preview
This has been rejected a number of times as it would be open to abuse by spammers.
Richard MacCutchan wrote:
If the customer correctly installs the Java runtime then it will set the PATH variable with the correct details. Your code should then run correctly. I have done a test on my system and that is all that is needed as far as I can tell.
You did said this, and I've done it, even on 2 new separate VM's, installed Java and needed redistributable and on both I get the same error.
-
Richard MacCutchan wrote:
If the customer correctly installs the Java runtime then it will set the PATH variable with the correct details. Your code should then run correctly. I have done a test on my system and that is all that is needed as far as I can tell.
You did said this, and I've done it, even on 2 new separate VM's, installed Java and needed redistributable and on both I get the same error.
-
So you keep saying. But I cannot see what is happening on your system. I have tried multiple tests of this issue with Java versions 1.8, 14 and 17 and cannot recreate the problem you are having.
unknown 2022 06 16 11 59 - YouTube[^] Here is a video, first run is on host where I have jdk, Visual Studio..., and second is on VM.
-
unknown 2022 06 16 11 59 - YouTube[^] Here is a video, first run is on host where I have jdk, Visual Studio..., and second is on VM.
I owe you an apology. I do not have a VM to run this on so my reinstalls of Java were missing something that I had set up in the past. The jvm.dll is not in the bin directory of the JRE installation, but in a subdirectory named server. This was in my PATH variable and was not removed when I uninstalled one of the Java versions. So you need to add that location to the PATH variable manually. Sorry again for the confusion.
-
I owe you an apology. I do not have a VM to run this on so my reinstalls of Java were missing something that I had set up in the past. The jvm.dll is not in the bin directory of the JRE installation, but in a subdirectory named server. This was in my PATH variable and was not removed when I uninstalled one of the Java versions. So you need to add that location to the PATH variable manually. Sorry again for the confusion.
The thing is that when Java is installed it doesn't add some kind of dynamic link in PATH to where
jvm.dllis located, well it doesn't add one at all. Yes, if I'm compiling the class with 1.8 and then on VM I can manually add in PATH the server folder, but here is a problem, the user should not go though this process of opening variables and find PATH to add it there. A solution would be that when the app is opened, it would check if Java in installed, if it is not, then the user would be prompted to download it, or I have to search and see if you can legally distributeJavaSetup8uxxx.exefile and if you can the app would automatically run the file and the user would go though the process of installing Java. After Java is installed by either way then the app will search what version is installed to know what location to add in PATH, which it would do after knowing that. At this point the app will run fine. BUT then you run into another problem, if the user updates Java then the location will change forjvm.dll, so you would have to add another variable to PATH with the new location for it, and remove the old one. Adding a variable to PATH shouldn't be a problem, as Java and other programs do it too, I'll just have to see how that is done from C++ code. If this is actually the only way to do it, then I guess I can do it this way, but having another solution that wouldn't involve adding variables to PATH would have been better. -
The thing is that when Java is installed it doesn't add some kind of dynamic link in PATH to where
jvm.dllis located, well it doesn't add one at all. Yes, if I'm compiling the class with 1.8 and then on VM I can manually add in PATH the server folder, but here is a problem, the user should not go though this process of opening variables and find PATH to add it there. A solution would be that when the app is opened, it would check if Java in installed, if it is not, then the user would be prompted to download it, or I have to search and see if you can legally distributeJavaSetup8uxxx.exefile and if you can the app would automatically run the file and the user would go though the process of installing Java. After Java is installed by either way then the app will search what version is installed to know what location to add in PATH, which it would do after knowing that. At this point the app will run fine. BUT then you run into another problem, if the user updates Java then the location will change forjvm.dll, so you would have to add another variable to PATH with the new location for it, and remove the old one. Adding a variable to PATH shouldn't be a problem, as Java and other programs do it too, I'll just have to see how that is done from C++ code. If this is actually the only way to do it, then I guess I can do it this way, but having another solution that wouldn't involve adding variables to PATH would have been better. -
The thing is that when Java is installed it doesn't add some kind of dynamic link in PATH to where
jvm.dllis located, well it doesn't add one at all. Yes, if I'm compiling the class with 1.8 and then on VM I can manually add in PATH the server folder, but here is a problem, the user should not go though this process of opening variables and find PATH to add it there. A solution would be that when the app is opened, it would check if Java in installed, if it is not, then the user would be prompted to download it, or I have to search and see if you can legally distributeJavaSetup8uxxx.exefile and if you can the app would automatically run the file and the user would go though the process of installing Java. After Java is installed by either way then the app will search what version is installed to know what location to add in PATH, which it would do after knowing that. At this point the app will run fine. BUT then you run into another problem, if the user updates Java then the location will change forjvm.dll, so you would have to add another variable to PATH with the new location for it, and remove the old one. Adding a variable to PATH shouldn't be a problem, as Java and other programs do it too, I'll just have to see how that is done from C++ code. If this is actually the only way to do it, then I guess I can do it this way, but having another solution that wouldn't involve adding variables to PATH would have been better.I have been working on a possible answer to this. If you send me a personal email (see the link below this message) I can let you have the details, and the code. One of the things I have discovered is the the jvm.dll must be the same version as that of the javac compiler that buiolds the class file(s).
-
I have been working on a possible answer to this. If you send me a personal email (see the link below this message) I can let you have the details, and the code. One of the things I have discovered is the the jvm.dll must be the same version as that of the javac compiler that buiolds the class file(s).
I don't see any link it might have been cut, or it is hidden, but this is an old email I have that I don't care about spam so it is fine to make it public: Email removed