Re: config: add resources path

[Alexandre Julliard]

Kevin Koltzau  writes:
> Many registry keys under XP refer to a %ResourceDir% env that points
> to the path where windows themes are located.
>
> In case any apps refer to this, or if someone loads a registry
> export from XP this should be available in wine also
>
> Interestingly, windows doesn't actually have this env set..my guess
> is ExpandEnvironmentStrings has a special case to handle this
> particular name

I seriously doubt that; most likely it's something that is either
handled internally in uxtheme, or uxtheme defines the variable before
expanding the string. I think this needs more investigation, but it
doesn't seem to be something that should be handled in kernel.

config: add resources path

[Kevin Koltzau]

I haven't found where the actual translation happens yet, but the directory itself seems to be retrieved 
by SHGetSpecialFolderPath with CSIDL_RESOURCES (which is currently flagged FIXME).
However the current implementation of that function requires some registry info in CSIDL_Data,
but I haven't been able to find any registry settings that affect this value under XP.

Through some digging with strings, I found that shell32.dll has a string "ResourceDir", which I was
hopeing would be the registry value that may be used, but setting that value in all the normal locations in the
registry had no affect whatsoever. I havent found any other promising values to try.

Would it be acceptable to add a special case for SHGetSpecialFolderPath where szDefaultPath is returned
without attempt to retrieve this value from the registry first?

On Friday 12 December 2003 04:06 pm, Alexandre Julliard wrote:
> Kevin Koltzau  writes:
> > Many registry keys under XP refer to a %ResourceDir% env that points
> > to the path where windows themes are located.
> >
> > In case any apps refer to this, or if someone loads a registry
> > export from XP this should be available in wine also
> >
> > Interestingly, windows doesn't actually have this env set..my guess
> > is ExpandEnvironmentStrings has a special case to handle this
> > particular name
>
> I seriously doubt that; most likely it's something that is either
> handled internally in uxtheme, or uxtheme defines the variable before
> expanding the string. I think this needs more investigation, but it
> doesn't seem to be something that should be handled in kernel.

config: add resources path

[Alexandre Julliard]

Kevin Koltzau  writes:
> Would it be acceptable to add a special case for SHGetSpecialFolderPath where szDefaultPath is returned
> without attempt to retrieve this value from the registry first?

Only if there is clear evidence that Windows does that too. We must
not add a special case just to mask the fact that we don't know how
it's really supposed to work.

config: add resources path

[Kevin Koltzau]

I'm not really sure how to go about verifying this..this is what I've got so far:

Using regmon, windows does not seem to access the registry at all in relation to this function
(when called with CSIDL_RESOURCES. The registry is accessed a lot with other values)
I dug through some disassembly of this function in windows, and it seems there is some type
of cache that may be referenced (at least, the debug symbols are named in a way that sounds
like its a cache), but if I tweek some values to cause the function to not use the cache
the function simply fails

On Friday 12 December 2003 10:48 pm, Alexandre Julliard wrote:
> Kevin Koltzau  writes:
> > Would it be acceptable to add a special case for SHGetSpecialFolderPath
> > where szDefaultPath is returned without attempt to retrieve this value
> > from the registry first?
>
> Only if there is clear evidence that Windows does that too. We must
> not add a special case just to mask the fact that we don't know how
> it's really supposed to work.

config: add resources path

[Andreas Mohr]

Hi,

On Fri, Dec 12, 2003 at 09:06:24PM -0500, Kevin Koltzau wrote:
> I haven't found where the actual translation happens yet, but the directory itself seems to be retrieved 
> by SHGetSpecialFolderPath with CSIDL_RESOURCES (which is currently flagged FIXME).
> However the current implementation of that function requires some registry info in CSIDL_Data,
> but I haven't been able to find any registry settings that affect this value under XP.

I assume you know regmon, right?

Should be possible to find the "offending" registry values then...

Andreas Mohr