TC 9.10-11.50: Required SHGetKnownFolderPath pseudo-variables don't work on XP

[Fla$her]

1. All this should be working on XP (tested by other means) and possibly earlier versions, because the API is supported:

List

AdminTools
CDBurning
CommonAdminTools
CommonOEMLinks
CommonPrograms
CommonStartMenu
CommonStartup
CommonTemplates
Cookies
Documents
Favorites
History
InternetCache
LocalAppData
LocalizedResourcesDir
Music
NetHood
Pictures
PrintHood
Profile
ProgramData
ProgramFiles
ProgramFilesCommon
PublicDesktop
PublicDocuments
PublicMusic
PublicPictures
PublicVideos
Recent
ResourceDir
RoamingAppData
SendTo
System
SystemX86
Templates
Videos
Windows

Here it's necessary to remove the Vista+ restriction.

2. 'Desktop' should be removed from the list in the help, as it is available in the SHGetSpecialFolderLocation list.

[Dalai]

Here it's necessary to remove the Vista+ restriction.

According to Microsoft the SHGetKnownFolderPath function is supported on Vista and newer. And according to my inspection of XP's shell32.dll it indeed doesn't export this function. So I don't see why it would make sense to change anything here. Not even sure there is a restriction in place because I think TC will try to find and call the exported function dynamically.

2. 'Desktop' should be removed from the list in the help, as it is available in the SHGetSpecialFolderLocation list.

It's supported by both functions so it should be listed accordingly.

[Fla$her]

According to Microsoft the SHGetKnownFolderPath function is supported on Vista and newer. And according to my inspection of XP's shell32.dll it indeed doesn't export this function.

It's about CSIDL, which then migrated to KNOWNFOLDERID (at the top of the page you specified). See where "value introduced" is not specified.

It's supported by both functions so it should be listed accordingly.

Do you mean case-sensitive? In that case, why is there no Fonts, Programs, StartMenu and Startup?

[Dalai]

It's about CSIDL, which then migrated to KNOWNFOLDERID (at the top of the page you specified). See where "value introduced" is not specified.

If TC only retrieves the variables you listed via SHGetKnownFolderPath then it can't do it on XP because that function isn't available there. What TC could do is retrieve these variables via SHGetSpecialFolderPath or SHGetSpecialFolderLocation. But your OP made it sound like SHGetKnownFolderPath is available on XP which is definitely not the case.

However, there are some variables which don't make much sense to retrieve on XP:

Code: Select all

RoamingAppData - not retrievable via SHGetSpecialFolder (no CSIDL), also it's the same as AppData

ProgramData,
PublicDesktop,
PublicVideos,
PublicDocuments,
PublicPictures - these have an equivalent in CSIDL but TC would need to make a mapping which would make the whole thing more complex

Do you mean case-sensitive?

No, TC only requires the first character to be uppercase.

[Fla$her]

If TC only retrieves the variables you listed via SHGetKnownFolderPath then it can't do it on XP because that function isn't available there.

You're right. I didn't take into account that the new Autorun function "GetKnownFolderPath" uses SHGetFolderPath for XP, because of this there was a discrepancy.
In this case, the second question remains, and this one can be attributed to wishes.
I think this should have been done as soon as new pseudo-variables were added.

However, there are some variables which don't make much sense to retrieve on XP:

I don't think so.

RoamingAppData - not retrievable via SHGetSpecialFolder (no CSIDL), also it's the same as AppData

With SHGetFolderPath, it's possible. I know it's the same thing, but this variable is already listed.

these have an equivalent in CSIDL but TC would need to make a mapping which would make the whole thing more complex

In Autorun, for example, this was not a problem.

No, TC only requires the first character to be uppercase.

In this case, which of us is right, given the other variables named?

[Dalai]

With SHGetFolderPath, it's possible.

There is no CSIDL named CSIDL_RoamingAppData, so, no it's not possible to do on XP and older. It would work if you "convert" RoamingAppData and subsequently feed CSIDL_AppData into SHGetFolderPath. Doesn't make much sense to me. But FOLDERID_RoamingAppData doesn't make much sense to begin with anyway.

In this case, which of us is right, given the other variables named?

It's a matter of perspective.

When listing all variables that can be retrieved via the named functions, it creates completeness in a way. On the other hand it repeats Microsoft's documentation (which might not be a bad thing because MS is known to remove documentation they deem deprecated/old/unnecessary/irrelevant). And it will create duplicates because there's a lot of overlap between CSIDL and KnownFolderID.

Leaving out duplicates makes the lists shorter (obviously) but it doesn't tell the full story about these functions. Whether or not that is necessary is probably best left for Ghisler to decide.

[ghisler(Author)]

I'm moving this thread to suggestions because it isn't a bug, just a missing function on XP.

Moderator message

Moved to suggestions

[Fla$her]

There is no CSIDL named CSIDL_RoamingAppData, so, no it's not possible to do on XP and older. It would work if you "convert" RoamingAppData and subsequently feed CSIDL_AppData into SHGetFolderPath. Doesn't make much sense to me.

This makes sense primarily in order not to separate lists with analogs. The common list is more useful in fact. It's not necessary to be attached to the function names. The main thing is that the variables whose values can be returned on older systems should be universal for different versions. This is the approach chosen by the author of Autorun, and I think it is the most correct one.

It's a matter of perspective.
Leaving out duplicates makes the lists shorter (obviously) but it doesn't tell the full story about these functions. Whether or not that is necessary is probably best left for Ghisler to decide.

If you remove the binding to the name of the functions and make a compatible list of pseudo-variables, then there is no need to have any idea about the API connections.

[Fla$her]

2ghisler(Author)
In any case, you need to make a decision on the second question with help and the variables Desktop vs Fonts, Programs, StartMenu and Startup.

And hopefully you will make support for the constants of the same _name (CSIDL > KNOWNFOLDERID) supported in XP.

[Dalai]

It's not necessary to be attached to the function names.

It's not necessary, but it's nice to know so other people (e.g. programmers) can learn from it.

The main thing is that the variables whose values can be returned on older systems should be universal for different versions.

I agree. However, it's a matter of how much work it is and how much complexity it adds which might introduce new bugs. Only the author can truly assess that.

If you remove the binding to the name of the functions and make a compatible list of pseudo-variables, then there is no need to have any idea about the API connections.

Apparently Ghisler wanted to specify the function names in the help, otherwise they wouldn't be in there. It's not necessary to give this piece of information, but nice to have nonetheless.

[Fla$her]

It's not necessary

I managed to rephrase it, you didn't see.

However, it's a matter of how much work it is and how much complexity it adds which might introduce new bugs.

It doesn't seem to me that version checking and setting flags by constants is something difficult compared to many other implementations in TC. And it would be possible to get used to the appearance and fixing of bugs over so many years.

Apparently Ghisler wanted to specify the function names in the help, otherwise they wouldn't be in there. It's not necessary to give this piece of information, but nice to have nonetheless.

It's not easier to list these functions in one sentence for a common list. What do you think?