[PATCH] windows.c: Change the current process path to the module path

Lubomir I. Ivanov neolit123 at gmail.com
Tue Mar 5 11:56:27 PST 2013


From: "Lubomir I. Ivanov" <neolit123 at gmail.com>

When an executable is started on Windows, it has a "Working
directory". This directory for a program shortcut stored on the
Desktop can be different than the actual executable directory.
This also applies if a shell extension is registered to that
executable (in the case of Subsurface that could be a .DLD file).

When another process simply "executes" a file with a certain extension
(e.g. when you double click on a .DLD file), a method ShellExecute
is called, which without explicit parameters sets the "Working
directory" to the .DLD file directory. This can be a bit of a trouble
if the executed module depends on relative paths (e.g. ./xslt, ./share).

To solve that we obtain our module full path and filename using
GetModuleFileName(), strip the filename from it (e.g. subsurface.exe)
and then pass the resulted string to SetCurrentDirectory(), which
updates the "Working directory".

Signed-off-by: Lubomir I. Ivanov <neolit123 at gmail.com>
---
 windows.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/windows.c b/windows.c
index b711480..6f40a26 100644
--- a/windows.c
+++ b/windows.c
@@ -243,13 +243,20 @@ extern int __wgetmainargs(int *, wchar_t ***, wchar_t ***, int, int *);
 /* expand-convert the UTF-16 argument list to a list of UTF-8 strings */
 void subsurface_command_line_init(gint *argc, gchar ***argv)
 {
-	wchar_t **wargv, **wenviron;
+	wchar_t **wargv, **wenviron, *p, path[MAX_PATH];
 	gchar **argv_new;
 	gchar *s;
 	/* for si we assume that a struct address will equal the address
 	 * of its first and only int member */
 	gint i, n, ret, si;
 
+	/* change the current process path to the module path, so that we can
+	 * access relative folders such as ./share and ./xslt */
+	GetModuleFileNameW(NULL, path, MAX_PATH - 1);
+	p = wcsrchr(path, '\\');
+	*(p + 1) = '\0';
+	SetCurrentDirectoryW(path);
+
 	/* memory leak tools may reports a potential issue here at a call
 	 * to strcpy_s in msvcrt, wich should be a false positive. but even if there
 	 * is some kind of a leak, it should be unique and have the same
-- 
1.7.11.msysgit.0



More information about the subsurface mailing list