This content has been marked as final. Show 2 replies
The "current working directory" has a very specific meaning which is defined by the OS, not java.
If you want to change the working directory then you need to call something to do just that. However that changes it for the entire application. I am not going to look but there might be a Java API to do that perhaps hanging off of Runtime, or one of the IO classes or management classes.
Changing it impacts the entire application.
Changing it to the location of a jar at best seems odd.
And of course none of that alters the fact that you are using GetModuleFileName() which returns the VM location. Which means nothing more than that there is a bug in the dll since the logical placement if you are going to extract the path would be to use the location of the dll rather than the executable. At a minimum such functionality should check the location of the dll and the executable.
I use GetModuleFileName method to get the current working directory, it's supposed to get the directory where the java class is(a) No it isn't. GetModuleFileName() isn't supposed to do either of those things. It is a Windows API that does something quite different. Look it up. While you're looking up the Windows API, find the one that gives you the current directory.
(b) The 'current working directory' is not the same thing as 'the directory where the Java class is'.
(c) How to get the current working directory inside a DLL is not a Java question in the first place.
(d) Why a Windows API would give a good goddam about Java classes is a mystery.
@jschell he isn't asking about changing the cwd.