X-Git-Url: https://tinc-vpn.org/git/browse?a=blobdiff_plain;f=src%2Ftincctl.c;h=f4379b7f8ebbe6dce5de0cdb42f5321e47d4599b;hb=19e42b76f546dc3baee4a5d6a4f161155d279c74;hp=6227750ce73ed2c9b9139bfd69115a953a283170;hpb=e024b7a2c50e23311834e6d180e5acc72783b339;p=tinc

diff --git a/src/tincctl.c b/src/tincctl.c
index 6227750c..f4379b7f 100644
--- a/src/tincctl.c
+++ b/src/tincctl.c
@@ -810,16 +810,31 @@ static int cmd_start(int argc, char *argv[]) {
 	int nargc = 0;
 	char **nargv = xzalloc((optind + argc) * sizeof *nargv);
 
-	nargv[nargc++] = c;
+	char *arg0 = c;
+#ifdef HAVE_MINGW
+	/*
+	   Windows has no real concept of an "argv array". A command line is just one string.
+	   The CRT of the new process will decode the command line string to generate argv before calling main(), and (by convention)
+	   it uses quotes to handle spaces in arguments.
+	   Therefore we need to quote all arguments that might contain spaces. No, execvp() won't do that for us (see MSDN).
+	   If we don't do that, then execvp() will run fine but any spaces in the filename contained in arg0 will bleed
+	   into the next arguments when the spawned process' CRT parses its command line, resulting in chaos.
+	*/
+	xasprintf(&arg0, "\"%s\"", arg0);
+#endif
+	nargv[nargc++] = arg0;
 	for(int i = 1; i < optind; i++)
 		nargv[nargc++] = orig_argv[i];
 	for(int i = 1; i < argc; i++)
 		nargv[nargc++] = argv[i];
 
 #ifdef HAVE_MINGW
-	execvp(c, nargv);
-	fprintf(stderr, "Error starting %s: %s\n", c, strerror(errno));
-	return 1;
+	int status = spawnvp(_P_WAIT, c, nargv);
+	if (status == -1) {
+		fprintf(stderr, "Error starting %s: %s\n", c, strerror(errno));
+		return 1;
+	}
+	return status;
 #else
 	pid_t pid = fork();
 	if(pid == -1) {