mixing SHELL32.DLL and SHFOLDER.DLL
saulius2 at ar.fi.lt
Mon Aug 30 13:25:51 CDT 2004
On Mon, 30 Aug 2004, Juan Lang wrote:
> From MSDN on SHGetFolderPath:
> This function is a superset of SHGetSpecialFolderPath,
> included with earlier versions of the Shell. On
> systems preceeding those including Shell32.dll version
> 5.0 (Windows Millennium Edition (Windows Me) and
> Windows 2000), SHGetFolderPath was obtained through
> SHFolder.dll, distributed with Microsoft Internet
> Explorer 4.0 and later versions. SHFolder.dll always
> calls the current platform's version of this function.
> If that fails, it will try to simulate the appropriate
> So, I think your patch is a good first step, to use
> GetProcAddress rather than letting the linker do it.
Maybe, but it became of no use.
> A next step would be, I think, to do what I suggested:
> if this fails, try to GetProcAddress for
> SHGetSpecialFolderPath, since this was available on
> older versions of shell32. You might have to search
> by ordinal if searching by name fails.
I don't know ordinal value of this function. The only way to get it for
me would be to debug shfolder.dll DllMain() from/on some old windows
boxes. OTOH, Juergen writes :
* > Which means Win98's shell32 does not have an SHGetFolderPath at
* > all.
* It has a SHGetFolderPathA exported by ordinal. (like the nt4 one has
* SHGetFolderPathW on the _same_ ordinal). Later versions did it in a
* clean way.
So if SHGetSpecialFolderPath* can be found this way, maybe
SHGetFolderPath* could be found also? It is a pity I have no Win95 box at
my hand and cannot test this situation with very old version of
> So, I don't think my suggestion is that different from
> Juergen's, just that I suggest an implementation of
> "try to simulate the appropriate behavior" if the
> function is not in fact in shell32.
Yes, I understand now. IMHO, the easiest way still would be to move the
code from shell32 to shfolder. But forget it.
More information about the wine-devel