mixing SHELL32.DLL and SHFOLDER.DLL

[Saulius Krasuckas]

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
> behavior.
> 
> 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 [1]:

* >    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
shell32.dll.

> 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.


[1] http://www.winehq.org/hypermail/wine-devel/2000/12/0049.html