Even if there is a way to have a different working directory for your application listed in the registry, you really have to fix it in the application. The reason is that there are several ways to open the data file with your application, and you simply cannot fix it for all of them. Consider
D: \> c: \ Programs \ MyApp \ MyApp.exe \\ public \ foo \ data.ext
where a program with a file name (as a UNC path) is launched to open as a parameter, executed in a completely different directory. I do such things regularly, and I expect applications to work under these conditions.
Note that setting the working directory to the root path of the application first after the start is not a good idea, since then the relative paths will be wrong. The right decision means changing the application so that it works correctly, regardless of what happens in the current working directory, using internal paths.
Edit:
You are commenting
But then this means that my application is completely registry-dependent. This is a pain for development testing, if every time I run my dev build it goes and downloads all the files for the installed version
but this is not necessarily the case. You can read the path to the executable executable using the GetModuleFileName() function or its equivalent shell in the GUI library (for example, Application.ExeName in Delphi). Installing a working directory from this path is simple, I just don't think it is a good idea, since changing the working directory violates the relative paths that the user can expect from work. It’s not true that
Windows starts the EXE from the location of the file that you double-click. This is apparently an exceptional case; in other cases, the EXE always works from where I expect.
because there can be many ways how an application can be executed with a different working directory than the path to the executable itself. A well-designed program does not assume that they are equal. This makes using the application in scripts or from the command line much more difficult.