How do I find out the current directory of my EXE on Windows? `File(".").absolutePath` returns the ...

# compose-desktop

[Stefan Oltmann]

How do I find out the current directory of my EXE on Windows?

File(".").absolutePath returns the working directory which I could change in a symlink.

Server.class.getProtectionDomain().getCodeSource().getLocation().getPath()

results in NullPointer if started from the EXE.

Is there something compose specific to find that out?

[Tomasz Krakowiak]

Not sure why you're looking for something "compose specific". Maybe natvie specific. And if you want to support it for JVM, than do you mean to find java.exe path?

[Stefan Oltmann]

I was thinking that maybe Jetbrains has made a nice API for that I'm not aware of. The pure Java ways are somewhat hacky and some of them don't work from that EXE.

I meant "Compose for Desktop specific"

[Stefan Oltmann]

Think of the very nice way they implemented to detect if the dark mode is active... You can do this on yourself, but sometimes Compose for Desktop already has a nice util for stuff like that ready to use. 😉

[Stefan Oltmann]

val path = Thread.currentThread().contextClassLoader.getResource("icon.ico")

val jarPath = path.path.substring(6, path.path.length - 10)

val pathToDir = File(jarPath)
  .parentFile
  .parentFile
  .canonicalPath
  .replace("%20", " ")

Not nice, but seems to work.

[ephemient]

a more reliable way to get the JAR file from a resource URL would be

File((path.openConnection() as JarURLConnection).jarFileURL.toURI())

[ephemient]

and a more reliable way to get the JAR file containing a class in general would be

java.io.File(this::class.java.protectionDomain.codeSource.location.toURI())

[Stefan Oltmann]

No, that does not work. "codesource" is NULL executed in the EXE

[ephemient]

which class are you using for that? it will be null if it's a system class, but if it's one of your own I would expect it to work… unless something unusual is going on with the packaging

[Stefan Oltmann]

I improved my solution a bit.

val url = Thread.currentThread().contextClassLoader.getResource("icon.ico")

val jarPath = url.path.substring(0, url.path.length - 10)

val pathToExe = Paths.get(URI(jarPath))
  .resolve("../../MyApp.exe")
  .toFile()
  .canonicalPath

[Stefan Oltmann]

Oh, well... Yes, I used a system class. I wasn't aware that this will make a difference 😅

[ephemient]

it makes a huge difference; it comes from the parent classloader, after all. in any case I would consider File(.toURI()) to be far more reliable than .replace("%20", " ")

[Stefan Oltmann]

Yes, you are right. Even URLDecoder.decode() is better than that.

[Stefan Oltmann]

I ended up with this and tested it even for UNC paths:

val url = Thread.currentThread().contextClassLoader.getResource("icon.ico")

val jarPath = url.path.substring(0, url.path.length - 10)

val pathToExe = Paths.get(URI(jarPath))
    .resolve("../../MyApp.exe")
    .toFile()
    .canonicalPath

<http://Log.info|Log.info>("App location: $pathToExe")

[Stefan Oltmann]

Other solutions may work well, too, but I think this is good enough.
I can change the working dir in a link and it still finds the correct place of the EXE file.
Is there any case where this code could break? 🤔

[Stefan Oltmann]

I would really love JetBrains to provide a variable with the path to the EXE and I think based on the Gradle native distribution configuration they could provide it. All they need is the name of the EXE which is configured and unless the user actively changes it I see no reason why this can fail.

[Stefan Oltmann]

But if the user starts to rename files in my distribution a lot of other things should fail as well 😄