379738 - Error "entry point GetLongPathNameA could not be located" under NT 4.0 starting Firefox 2.0.0.4 RC1

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Nathan Lineback]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070501 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; WinNT 4.0; en-US; rv:1.8.1.4) Gecko/20070501 Firefox/2.0.0.4

Firefox 2.0.0.3 and previous versions of 2.x installed and run fine under Windows NT 4.0 without any complaints. 

After updating to the 2.0.0.4 RC1 build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0.0.4-candidates/rc1/ Firefox no longer starts. 

The error message is "The procedure entry point GetLongPathNameA could not be located in the dynamic link library KERNEL32.dll"

Tested on two computers with NT 4 Workstation Service Pack 6a.

Reproducible: Always

Steps to Reproduce:
1. Install or update to Firefox 2.0.0.4 RC1 from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2.0.0.4-candidates/rc1/
2. Try to run
Actual Results:  
Won't start any more!

Expected Results:  
Should start and run like the previous 2.0.0.x versions.

Comment 1

[Samuel Sidler (old account; do not CC)]

Does this happen with a new profile?

http://kb.mozillazine.org/Profile_Manager

If so, can you please determine when this regressed? I don't have any available Windows NT machines to test on.

Also did you post this forum topic on the same issue with Thunderbird or is that another account of the problem from another user? http://forums.mozillazine.org/viewtopic.php?p=2867268

Comment 2

[Samuel Sidler (old account; do not CC)]

This very well may be a regression from bug 375710. CCing some people.

Comment 3

[(not reading, please use [e-mail] instead)]

for winnt, do we need to #include NewApis.h?

Windows NT and Windows 95:  Include an additional header file called NewAPIs.h to make GetLongPathName available on these operating systems. The function is not implemented natively, but by a wrapper that uses other native functions on these systems. For details about using preprocessor directives that make the function available, see the header file. If you do not have this header file, you can download the most recent SDK from the SDK Update Site.

http://msdn2.microsoft.com/en-us/library/aa364980.aspx

Comment 4

[Benjamin Smedberg]

This function is not available in Windows 95 or NT 4.0. However, we do not support either of these operating systems. The minimum supported OS is Windows 98, which was released well after NT 4.0.

http://www.mozilla.com/en-US/firefox/system-requirements.html

I suggest WONTFIX

Comment 5

[Samuel Sidler (old account; do not CC)]

(In reply to comment #4)
> This function is not available in Windows 95 or NT 4.0. However, we do not
> support either of these operating systems. The minimum supported OS is Windows
> 98, which was released well after NT 4.0.

That's not clear to me since we specifically mention Windows NT in the release notes.

http://www.mozilla.com/en-US/firefox/2.0.0.3/releasenotes/

Comment 6

[(not reading, please use [e-mail] instead)]

I knew about win95, but not about winnt.

in case we do still support it:

743   DWORD len = GetLongPathName(appPath.get(), buf, MAXPATHLEN);
744   // Failing GetLongPathName() is not fatal.
745   if (len <= 0 || len >= MAXPATHLEN)
746     longPath.Assign(appPath);
747   else
748     longPath.SetLength(len);

if failing GetLogPathName() is acceptable, could we have also used the trick of using GetProcAddress() to determine if we have it, and if we don't proceed onwards?

Comment 7

[Samuel Sidler (old account; do not CC)]

Additionally, this bug affects Thunderbird 2 which *does* support Windows NT 4.

http://www.mozilla.com/en-US/thunderbird/system-requirements.html

Comment 8

[juan becerra [:juanb]]

mscott, do we really not support Windows NT 4 on Thunderbird 2?

Comment 9

[Scott MacGregor]

the system requirements for thunderbird should be the same as Firefox. We probably just didn't properly update the page to track changes to the Firefox page.

Comment 10

[Carsten Book [:Tomcat]]

Error Message confirmed on my NT 4 VM Test installation. Let me know i can help with this test environment.  

Comment 11

[Scott MacGregor]

(In reply to comment #9)
> the system requirements for thunderbird should be the same as Firefox. We
> probably just didn't properly update the page to track changes to the Firefox
> page.

all that being said, I still thought WINNT 4.0 was supported on the 1.8.1 branch for both products :)

Comment 12

[Jay Patel [:jay]]

After some discussion on this and a confirmation from mconnor that we DO support Windows NT 4.0 for Firefox 2 and Thunderbird 2, we need to get a patch for this ASAP and respin for 2.0.0.4 rc2.

Who wants to take this bug?  Seth?  Bsmedberg?

Comment 13

[(not reading, please use [e-mail] instead)]

Attachment: draft patch (need to test and discuss with bsmedberg / mk-san)

Comment 14

[Masatoshi Kimura [:emk]]

Comment on attachment 263789 [details] [diff] [review]
draft patch (need to test and discuss with bsmedberg / mk-san)

Sorry for forgetting about NT 4.0.
+   GetProcAddress(GetModuleHandle("kernel32.dll"), "GetLongPathName");
This will never succeed. It should be:
+   GetProcAddress(GetModuleHandle("kernel32.dll"), "GetLongPathNameA");
Trunk dropped a support for pre-Win2k platforms, so we could back out the patch after baking and landing on the branch.

Comment 15

[Benjamin Smedberg]

There's no point in landing this on the trunk, since we couldn't test it anyway.

seth, did you try just adding newapis.h to the top of this file?

Comment 16

[(not reading, please use [e-mail] instead)]

Attachment: patch to use NewApis.h

Comment 17

[(not reading, please use [e-mail] instead)]

sorry for the delay.

Benjamin and MK-san, on my windows XP box, after including NewApis.h (and setting some #defines), stepping through Probe_GetLongPathName() in newapis.h looks good.

if GetLongPathNameA (or GetLongPathNameW when UNICODE is defined) is in kernel32.dll, we'll use it.  otherwise, we'll use Emulate_GetLongPathName() as defined in newapis.h

Comment 18

[(not reading, please use [e-mail] instead)]

Comment on attachment 263951 [details] [diff] [review]
patch to use NewApis.h

mk-san was right about GetLongPathName never succeeding in my first draft.

seeking review from both mk-san and bsmedberg.

Comment 19

[(not reading, please use [e-mail] instead)]

benjamin, thanks for the review.  

as mk-san points out in comment #14, we could land this on the trunk (to make sure it doesn't hork windows xp, vista, etc) before landing on the branch, and then back it out.

what do you think about doing that?  Or would you prefer this to be a MOZILLA_1_8_BRANCH only fix, since we can't test the trunk on winnt, and test it out on the 2004 nightly?

Comment 20

[Benjamin Smedberg]

I don't think that landing this on the trunk would be valuable, since we couldn't test it anyway. Really we should file a bug to make the trunk use the wide-char APIs.

Comment 21

[(not reading, please use [e-mail] instead)]

Comment on attachment 263951 [details] [diff] [review]
patch to use NewApis.h

seeking approval to land on the MOZILLA_1_8_BRANCH (only)

Comment 22

[juan becerra [:juanb]]

Comment on attachment 263951 [details] [diff] [review]
patch to use NewApis.h

approved for 1.8.1.4, a=juanb for release-drivers

Comment 23

[(not reading, please use [e-mail] instead)]

Attachment: patch to use NewApis.h (same patch but it applies cleanly to the MOZILLA_1_8_BRANCH)

carrying over r/a

Comment 24

[(not reading, please use [e-mail] instead)]

Comment on attachment 264022 [details] [diff] [review]
patch to use NewApis.h (same patch but it applies cleanly to the MOZILLA_1_8_BRANCH)

as always, I would appreciate mk-san's additional review.

Comment 25

[(not reading, please use [e-mail] instead)]

fixed on the MOZILLA_1_8_BRANCH

Checking in nsXREDirProvider.cpp;
/cvsroot/mozilla/toolkit/xre/nsXREDirProvider.cpp,v  <--  nsXREDirProvider.cpp
new revision: 1.37.2.9; previous revision: 1.37.2.8
done

note, this fix was not checked into the trunk as the trunk does not support Windows NT.

Comment 26

[(not reading, please use [e-mail] instead)]

my change is not building cleaning. 

Two different flavors of build bustage:

1)

C:\Program Files\Microsoft SDK\include\NewAPIs.h(325) : error C2440: '=' : cannot convert from 'int (__stdcall *)(const char *,char *,unsigned long)' to 'unsigned long (__stdcall *)(const char *,char *,unsigned long)'

2) 

e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/toolkit/xre/nsXREDirProvider.cpp(733) : fatal error C1083: Cannot open include file: 'NewAPIs.h': No such file or directory

For #1, google tells me:

http://groups.google.com/group/microsoft.public.dotnet.languages.vc/browse_thread/thread/c175e0dee5de48ad/255eedefdc0464fa?lnk=st&q=GetLongPathName+dword+build&rnum=1#255eedefdc0464fa

Not sure yet what to do about that yet.

For #2

From http://msdn2.microsoft.com/en-us/library/aa364980.aspx:

"Windows NT and Windows 95:  Include an additional header file called NewAPIs.h to make GetLongPathName available on these operating systems. The function is not implemented natively, but by a wrapper that uses other native functions on these systems. For details about using preprocessor directives that make the function available, see the header file. If you do not have this header file, you can download the most recent SDK from the SDK Update Site."

The recent sdk is http://www.microsoft.com/downloads/details.aspx?familyid=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en, but I don't know if upgraded to the new SDK is a good idea.

FWIW, On my machine, I am building the MOZILLA_1_8_BRANCH with 

Microsoft Visual Studio 2005
Version 8.0.50727.42  (RTM.050727-4200)

From 
/cygdrive/c/Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/Include/NewAPIs.h

extern DWORD (CALLBACK *GetLongPathName)(LPCTSTR, LPTSTR, DWORD);

Comment 27

[(not reading, please use [e-mail] instead)]

I've backed myself out due to the build bustage

Comment 28

[(not reading, please use [e-mail] instead)]

an explanation of the pacific-vm bustage:

$ diff NewAPIs.h NewAPIs-pacifica-vm.h
2c2
<  *  Copyright (c) 1997-2004, Microsoft Corporation
---
>  *  Copyright (c) 1997-1999, Microsoft Corporation
312c312
<     DWORD (CALLBACK *RealGetLongPathName)(LPCTSTR, LPTSTR, DWORD);
---
>     BOOL (CALLBACK *RealGetLongPathName)(LPCTSTR, LPTSTR, DWORD);

an explanation of the patrocles bustage, see bug #374682 (Patrocoles Needs the Platform SDK Installed on it)

After chatting with bsmedberg, he suggestion something along the lines of the first patch, except with GetLongPathNameA (per mk-san).

Comment 29

[(not reading, please use [e-mail] instead)]

Attachment: revised version of the first patch, this time with GetLongPathNameA (per mk-san)

Comment 30

[Benjamin Smedberg]

Comment on attachment 264053 [details] [diff] [review]
revised version of the first patch, this time with GetLongPathNameA (per mk-san)

>Index: nsXREDirProvider.cpp

>+  DWORD (WINAPI *pGetLongPathName)(LPCTSTR, LPTSTR, DWORD);
>+  // GetLongPathName() is not present on WinNT 4.0
>+  *(FARPROC *)&pGetLongPathName =
>+   GetProcAddress(GetModuleHandle("kernel32.dll"), "GetLongPathNameA");

This line looks a little weird. IMO the following would be more readable:

typedef DWORD (WINAPI *GetLongPathNamePtr)(LPCTSTR, LPTSTR, DWORD);
GetLongPathNamePtr pGetLongPathName =
  (GetLongPathNamePtr) GetProcAddress(GetModuleHandle("kernel32.dll"), "GetLongPathNameA");

But, if this is wrong for some reason, the version you have is fine.

Comment 31

[(not reading, please use [e-mail] instead)]

> But, if this is wrong for some reason, the version you have is fine.

I agree it looks a little weird, but I'm unable to get your suggestion to compile:

c:/builds/bonecho/mozilla/toolkit/xre/nsXREDirProvider.cpp(750) : error C2564: '
GetLongPathNamePtr' : a function-style conversion to a built-in type can only take one argument.

fwiw, the patch I've attached follows a similar pattern to what's in NewAPIs.h's Probe_GetLongPathName().

Comment 32

[(not reading, please use [e-mail] instead)]

Comment on attachment 264053 [details] [diff] [review]
revised version of the first patch, this time with GetLongPathNameA (per mk-san)

seeking a= for the branch

Comment 33

[(not reading, please use [e-mail] instead)]

rob strong asks, if GetLongPathName() is not available, what about switching our code in nsXREDirProvider.cpp to use GetShortPathName() instead?

[see also http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileWin.cpp#2924, on the trunk, where we use GetShortPathName() for, among other things, nsLocalFile::Equals()]

bsmedberg / mk-san:  Given that GetShortPathName() is available on WindowsNT, what about this approach?

Comment 34

[(not reading, please use [e-mail] instead)]

Attachment: an alternative approach (for branch) using GetShortPatName(). still need to test.

Comment 35

[(not reading, please use [e-mail] instead)]

Attachment: an alternative approach (for trunk) using GetShortPatName(). still need to test.

Comment 36

[(not reading, please use [e-mail] instead)]

Comment on attachment 264053 [details] [diff] [review]
revised version of the first patch, this time with GetLongPathNameA (per mk-san)

clearing r=, awaiting benjamin's thoughts on the solution suggested by rstrong

Comment 37

[Benjamin Smedberg]

GetShortPathName can fail if NtfsDisable8dot3NameCreation is on, see bug 303599. We should at least not bail in that case.

Comment 38

[Masatoshi Kimura [:emk]]

Quoting from what I have sent to seth directly while I can't login bugzilla:
> GetShortPathName() will fail if Ntfs8dot3NameCreation=1.
> Don't bail out if GetShortPathName() fails because caller will fallback to <ap
> pDir>\update if we fail.
> Please note also nsLocalFileWin::EnsureShortPath() ignore the failure of GetSh
> ortPathName().
> 1. Check if GetLongPathName() is present.
> 2. If it is not available or failed, fallback to GetShortPathName().
> 3. If GetShortPathName failed, just copy a path as a last resort.
This patch will be required only for the branch. Windows 2000 or later will always support GetLongPathName().

Comment 39

[Benjamin Smedberg]

I don't think we need to use *both* GetLongPathName and GetShortPathName. Just use GetShortPathName, but copy on failure.

Comment 40

[Masatoshi Kimura [:emk]]

Using short path may cause a problem when update from 2.0.0.3 (or earlier) to 2.0.0.4 (or later), or major update update from branch to trunk.
For example:
1. Install Thunderbird 2 (short name C:\PROGRA~1\MOZILL~1 will be created)
2. Install Firefox 2.0.0.3 (short name C:\PROGRA~1\MOZILL~2 will be created)
3. Launch Fx via long path.
4. Check for update (short name %localappdata%\Mozilla\Firefox\MOZILL~1 will be created)
5. Select Restart Now (Fx will search %localappdata%\Mozilla\Firefox\MOZILL~2, but it will not found)

Comment 41

[Masatoshi Kimura [:emk]]

Comment on attachment 264053 [details] [diff] [review]
revised version of the first patch, this time with GetLongPathNameA (per mk-san)

Sorry for the delay. I tested this on my NT 4.0 box and it worked.
Although I'm not sure whether you still consider landing this on the branch, r+'ing anyway.

Comment 42

[Daniel Veditz [:dveditz]]

Comment on attachment 264053 [details] [diff] [review]
revised version of the first patch, this time with GetLongPathNameA (per mk-san)

approved for 1.8.1.4, a=dveditz

Comment 43

[(not reading, please use [e-mail] instead)]

just chatted with bsmedberg and dveditz, and here's the plan we've come up with:

1) for the trunk, do nothing, as GetLongPathName() is available on all windows platforms the trunk supports.

2) for the MOZILLA_1_8_BRANCH, take the low risk patch that has r=mk-san, r=bsmedberg, a=dveditz that checks for GetLongPathNameA.  That patch makes it so for non-WinNT, we do what we've already done for bug #375710.  For WinNT, since we won't have GetLongPathName(), we will fail gracefully.  But on WinNT, we can run into bug #375710 (downgrade from 2004 -> 2002).

For winnt, this is less than ideal, but once they go down to 2002, and then back up to 2004, they won't get downgraded again.

As mk-san points out, a solution with GetShortPathName() has issues and is risky.

Comment 44

[(not reading, please use [e-mail] instead)]

fixed on the branch only.

Checking in nsXREDirProvider.cpp;
/cvsroot/mozilla/toolkit/xre/nsXREDirProvider.cpp,v  <--  nsXREDirProvider.cpp
new revision: 1.37.2.11; previous revision: 1.37.2.10
done

Comment 45

[Carsten Book [:Tomcat]]

Seth, the patch works fine. Build Mozilla/5.0 (Windows; U; WinNT4.0;
en-US; rv:1.8.1.4pre) Gecko/2007050812 BonEcho/2.0.0.4pre is running fine on NT, will verify fixed this bug when we have the 2.0.0.4 RC2

Comment 46

[(not reading, please use [e-mail] instead)]

carsten:  thanks for the quick turn around on the verification!

Comment 47

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.4 using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.1.4) Gecko/2007050903 Firefox/2.0.0.4 RC 2 - Build starts and is running normal.

Adding verified keyword

Comment 48

[Randy J. Anderson]

This isn't a bug. It's a Windows issue! Windows NT 4.0 apparently don't have the function "GetLongPathNameA" or Windows NT 4.0 don't like how it was called.

Comment 49

[Nathan Lineback]

Just loaded up the RC2 that is out there now - It works great! Yay! Using it to post this right now! Thanks!! 

Posted using: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.1.4) Gecko/20070509 Firefox/2.0.0.4