Currently the windows port implementation of homedir() is attempting to determine %HOMEPATH% from the basename of argv[0]. This is particularly limited in that it only works relative to the path of argv[0], which at best corresponds to the binary's location as opposed to the user's %HOMEPATH% (or perhaps even "%HOMEPATH%/Application Data" or "%HOMEPATH%/Local Settings/Application Data/" on Windows XP and later). Moreover, argv[0] is not guaranteed to contain a '/' character, such as having added the binary's folder to the %PATH%. Consequently, homedir() returns the empty string and as such, all derivative paths are invalid.
At the very least, the gqview binary should identify its own location and attempt to load the global gqviewrc first.
Unless argv[0] contains the path to the gqview binary (with a requisite '/' character), any changes to the preferences, either through the preferences dialog or manually editing the gqviewrc, are not saved or parsed.
This was particularly frustrating to figure out as no error messages were seen...
+1 on this one.
GQView on my machine leaves .gqview directories everywhere: I have associated .JPG files with GQView. Double-clicking on the .JPG file opens GQView, which then creates a .gqview directory in the same directory as the JPEG is in.