Overriding QDir::homePath()

goetz

On Windows, the user directory is searched in the following order, the first method that returns a valid[1] path is used:

The value returned by GetUserProfileDirectoryW Windows API call
The value of USERPROFILE environment variable
The value of HOMEDRIVE + HOMEPATH environment variables
The value of HOME environment variable
The value of SystemDrive environment variable (no check for existence)
"C:/" (hard coded as last resort, no check for existence)

fn1. valid means the method returns a value and the directory denoted by that value does exist

lwcorp

[quote author="Volker" date="1332108047"]

The value returned by GetUserProfileDirectoryW Windows API call[/quote]
So my question is how does GetUserProfileDirectoryW work. Had I understood it, maybe I could have bypassed it.

goetz

I don't know the internals. Thats Windows API and I avoid digging into that wherever I can :-) Some Google search may get you more details. Usually that method returns "C:/Documents and Settings/USER" on Win2k/XP and "C:/Users/USER" on Vista/Win7.

lgeyer

Just to let me get this right: you want to modify the behaviour of an existing binary, you are not a developer who wants to modify its own sourcecode or application.

Well, I guess you are left with four options then, in the order of work and stress involved

recompile the binary not using QDir::homePath() or
file a bug report or a merge request which modifies the behaviour of QDir::homePath() in a way that <code>%USERPROFILE%</code> takes precedence over GetUserProfileDirectoryW or
distribute the binary with a patched set of the Qt libraries which modify the behaviour of QDir::homePath() or
hook GetUserProfileDirectoryW directly to modify its behaviour.

I'm not quite sure as of right now but I tend to say that <code>%USERPROFILE%</code> and <code>%HOME%</code> should take precedence over GetUserProfileDirectoryW just to cover cases like yours (where you want to temporarily redirect the home directory) and to get a more consistent cross-platform behaviour.

lwcorp

Would you be kind enough to submit that bug report? I don't seem to find such an option anywhere.

Had I understood GetUserProfileDirectoryW, I could have somehow bypassed it without actually modifying the code.

andre

The bugsystem is currently at https://bugreports.qt-project.org/secure/Dashboard.jspa

lwcorp

"Thanks!":https://bugreports.qt-project.org/browse/QTBUG-24907

goetz

Regarding the text in your bugreport:

bq. Various standalone portable softwares could have been forced to become portable, if only they hadn't stored their data in a path that involves QDir::homePath().

A sane Qt application doesn't use homePath() for that, but calls QDesktopServices::storageLocation() with, for example, QDesktopServices::DataLocation as argument. These methods do not use homePath() under the hood (or only as a last resort), but call SHGetFolderPath() on Windows, which is native Windows API again.

lwcorp

The OP links to at least 2 programs that do this. Well, if their authors knew what they were doing, they would have accepted an "/ini=" command line parameter in the first place.

But what advantage does SHGetFolderPath() offer? Can it easily be bypassed?

BTW:

bq. Deprecated

SHGetFolderPath function, Microsoft MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/bb762181(v=vs.85).aspx

andre

Deprecated for Vista and up, but Qt also runs on XP, where the replacement function does not exist yet.

lwcorp

Please answer:

bq. But what advantage does SHGetFolderPath() offer? Can it easily be bypassed?

goetz

[quote author="lwcorp" date="1337853314"]Please answer:

bq. But what advantage does SHGetFolderPath() offer? Can it easily be bypassed?[/quote]

Advantage: it is official API, although deprecated. But as Andre already mentioned, as long as Qt is running on XP, one will have to use it, as the replacement isn't there.

Bypassing: I don't know, as I never had a need to do this.