Closed Bug 251341 Opened 20 years ago Closed 20 years ago

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

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 246616

People

(Reporter: matthew, Assigned: bugzilla)

Details

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

(sorry for the bug spam)

The trunk builds from 2004-07-18 work perfectly, however the branch builds (0.9)
do not.
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.
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.
Status: UNCONFIRMED → NEW
Depends on: 246616
Ever confirmed: true
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 ***
Status: NEW → RESOLVED
Closed: 20 years ago
No longer depends on: 246616
Resolution: --- → DUPLICATE
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
You need to log in before you can comment on or make changes to this bug.