251341 - Fails to find SHGetSpecialFolderPathA in shell32.dll on Windows NT 4

Status: RESOLVED DUPLICATE of bug 246616

(Firefox :: General, defect)

Description

[Matthew Hambley]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8a2) Gecko/20040707 Firefox/0.8.0+
Build Identifier: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-07-13-10-0.9/Firefox-win32.zip

The browser fails to start with the error "The procedure entry point
SHGetSpecialFolderPathA could not be located in the dynamic link library
shell32.dll"  This problem has existed since I started looking at the branch
builds on the 8th.

I have upgraded my Windows installation as far as I can and shell32.dll reports
its version as 4.00 from the file explorer.  According to MS documentation this
error can accur if an insufficiently recent version of IE is installed and
recomends at last version 4.  I have version 6 installed.

Reproducible: Always
Steps to Reproduce:
1. Launch Firefox


Actual Results:  
An error box appears containing "The procedure entry point
SHGetSpecialFolderPathA could not be located in the dynamic link library
shell32.dll".  The firefox process then dies.

Expected Results:  
Started running.

Comment 1

[Seb Perez-D]

I can confirm this bug on Win NT4 with IE6 (except the message is in french).
This bug seems to be related to bug 54198 (which has a patch attached but no
review). This bug only happens on branch builds, not 0.9.2.

Comment 2

[Seb Perez-D]

SHGetSpecialFolderPathA only appears twice in the source (Aviary branch), both
times in the same file /xpcom/io/SpecialSystemDirectory.cpp, line 113 and 119,
and once of those times in a comment.

However the modifications to that part of that file come from 2003, so I can't
see how it could be the culprit.

Comment 3

[Seb Perez-D]

I've narrowed it down to:
* Firefox build 2004-06-22-10-0.9 starts correctly
* Firefox build 2004-06-23-10-0.9 fails with SHGetSpecialFolderPathA 

Comment 4

[Seb Perez-D]

(sorry for the bug spam)

The trunk builds from 2004-07-18 work perfectly, however the branch builds (0.9)
do not.

Comment 5

[Bernd]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetspecialfolderpath.asp

Comment 6

[Bernd]

it looks like that we need a working IE installation to run 
http://www.google.com/search?hl=en&lr=&safe=on&q=procedure%20entry%20point%20SHGetSpecialFolderPathA%20dynamic%20link%20library%20SHELL32.dll.

Comment 7

[Bernd]

from one of the Google links

Apparently SHGetSpecialFolderPath doesn't work without the shell update
installed on NT4. Therefore, substituting this function will help:

BOOL UtilGetSpecialFolderPath (
char *path, // Path buffer
int folder) // Special folder ID
{
ITEMIDLIST *pidl; // Shell Item ID List ptr
IMalloc *imalloc; // Shell IMalloc interface ptr
BOOL result; // Return value

if (SHGetSpecialFolderLocation (NULL, folder, &pidl) != NOERROR)
return FALSE;

result = SHGetPathFromIDList (pidl, path);

if (SHGetMalloc (&imalloc) == NOERROR) {
imalloc->lpVtbl->Free (imalloc, pidl);
imalloc->lpVtbl->Release (imalloc);
}

return result;
}

Thanks to Roger Hunen who posted this on comp.os.ms-windows.programmer.win32.

Comment 8

[Jean-Marc Desperrier]

This has been caused by the patch to bug 246616.

http://lxr.mozilla.org/aviarybranch/source/modules/libpr0n/decoders/icon/win/nsIconChannel.cpp#236
calls directly SHGetSpecialFolderLocation (which is mapped by the compiler to
SHGetSpecialFolderLocationA).

The code should be modified in a way similar to SpecialSystemDirectory.cpp#113,
maybe encapsulate both calls to SHGetSpecialFolderLocation (and other functions
that may sometimes be missing) inside a function that will do the right thing.

Comment 9

[Jean-Marc Desperrier]

In fact, the problem is already taken care of within bug 246616 with a patch (I
should have read all the comments), so I'll mark duplicate.

*** This bug has been marked as a duplicate of 246616 ***

Comment 10

[Seb Perez-D]

This bug is marked as a duplicate of 246616, and 246616 has been marked as
fixed. The patch still has to make it into the branch, so should this really be
marked as duplicate, or should a new bug be filed ?

The patch is http://bugzilla.mozilla.org/attachment.cgi?id=151754&action=view