Patch from "J Doe": Use SHGetSpecialFolderLocation instead of

SHGetSpecialFolderPath in order to find application data folder.

Apparently, until IE 4 (!?) came out, nobody realized that programmers
might like to get paths as strings.  Clearly, a fancy pseudo-OO list
of "identifiers" is a far more convenient way to deal with these
things.  And while we're being OO, why return object that you can free
with free()?  Instead, let's make the user get a handle to an abstract
allocation object, and ask it to free the fancy list, and then ask it
to release itself.  Won't that be fun and convenient?

Navigating ancient Win32 APIs is like bikini-waxing creatures from HP
Lovecraft: to do a good job you must understand what's going on... but
the understanding itself can blast your sanity.


svn:r2480

src/or/config.c

@@ -486,8 +486,27 @@ static void init_options(or_options_t *options) {
 static char *get_default_conf_file(void)
 {
 #ifdef MS_WINDOWS
+  LPITEMIDLIST idl;
+  IMalloc *m;
+  HRESULT result;
   char *path = tor_malloc(MAX_PATH);
-  if (!SUCCEEDED(SHGetSpecialFolderPath(NULL, path, CSIDL_APPDATA, 1))) {
+  /* Find X:\documents and settings\username\applicatation data\ .
+   * We would use SHGetSpecialFolder path, but that wasn't added until IE4.
+   */
+  if (!SUCCEEDED(SHGetSpecialFolderLocation(NULL, CSIDL_APPDATA,
+                                            &idl))) {
+    tor_free(path);
+    return NULL;
+  }
+  /* Convert the path from an "ID List" (whatever that is!) to a path. */
+  result = SHGetPathFromIDList(idl, path);
+  /* Now we need to free the */
+  SHGetMalloc(&m);
+  if (m) {
+    m->lpVtbl->Free(m, idl);
+    m->lpVtbl->Release(m);
+  }
+  if (!SUCCEEDED(result)) {
     tor_free(path);
     return NULL;
   }