Closed Bug 379738 Opened 14 years ago Closed 14 years ago
Error "entry point Get
Long Path Name A could not be located" under NT 4 .0 starting Firefox 2 .0 .0 .4 RC1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20070501 Firefox/220.127.116.11 Build Identifier: Mozilla/5.0 (Windows; U; WinNT 4.0; en-US; rv:18.104.22.168) Gecko/20070501 Firefox/22.214.171.124 Firefox 126.96.36.199 and previous versions of 2.x installed and run fine under Windows NT 4.0 without any complaints. After updating to the 188.8.131.52 RC1 build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/184.108.40.206-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 220.127.116.11 RC1 from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/18.104.22.168-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.
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
Severity: normal → critical
This very well may be a regression from bug 375710. CCing some people.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
(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/22.214.171.124/releasenotes/
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?
Additionally, this bug affects Thunderbird 2 which *does* support Windows NT 4. http://www.mozilla.com/en-US/thunderbird/system-requirements.html
mscott, do we really not support Windows NT 4 on Thunderbird 2?
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.
Error Message confirmed on my NT 4 VM Test installation. Let me know i can help with this test environment.
(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 :)
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 126.96.36.199 rc2. Who wants to take this bug? Seth? Bsmedberg?
Flags: blocking188.8.131.52? → blocking184.108.40.206+
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.
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?
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
Assignee: nobody → sspitzer
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.
Attachment #263951 - Flags: review?(benjamin)
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?
Status: NEW → ASSIGNED
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 on attachment 263951 [details] [diff] [review] patch to use NewApis.h seeking approval to land on the MOZILLA_1_8_BRANCH (only)
Attachment #263951 - Flags: approval220.127.116.11?
Comment on attachment 263951 [details] [diff] [review] patch to use NewApis.h approved for 18.104.22.168, a=juanb for release-drivers
Attachment #263951 - Flags: approval22.214.171.124? → approval126.96.36.199+
carrying over r/a
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.
fixed on the MOZILLA_1_8_BRANCH Checking in nsXREDirProvider.cpp; /cvsroot/mozilla/toolkit/xre/nsXREDirProvider.cpp,v <-- nsXREDirProvider.cpp new revision: 188.8.131.52; previous revision: 184.108.40.206 done note, this fix was not checked into the trunk as the trunk does not support Windows NT.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
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);
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I've backed myself out due to the build bustage
Status: REOPENED → ASSIGNED
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 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.
> 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 on attachment 264053 [details] [diff] [review] revised version of the first patch, this time with GetLongPathNameA (per mk-san) seeking a= for the branch
Version: unspecified → 2.0 Branch
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?
Attachment #264068 - Attachment description: an alternative approach (for trunk and branch) using GetShortPatName(). still need to test. → an alternative approach (for branch) using GetShortPatName(). still need to test.
Attachment #264071 - Flags: review?(benjamin)
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
GetShortPathName can fail if NtfsDisable8dot3NameCreation is on, see bug 303599. We should at least not bail in that case.
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().
I don't think we need to use *both* GetLongPathName and GetShortPathName. Just use GetShortPathName, but copy on failure.
Using short path may cause a problem when update from 220.127.116.11 (or earlier) to 18.104.22.168 (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 22.214.171.124 (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 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.
Attachment #264053 - Flags: review?(VYV03354) → review+
Comment on attachment 264053 [details] [diff] [review] revised version of the first patch, this time with GetLongPathNameA (per mk-san) approved for 126.96.36.199, a=dveditz
Attachment #264053 - Flags: approval188.8.131.52+
Attachment #264068 - Attachment is obsolete: true
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.
Version: 2.0 Branch → unspecified
fixed on the branch only. Checking in nsXREDirProvider.cpp; /cvsroot/mozilla/toolkit/xre/nsXREDirProvider.cpp,v <-- nsXREDirProvider.cpp new revision: 184.108.40.206; previous revision: 220.127.116.11 done
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Seth, the patch works fine. Build Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:18.104.22.168pre) Gecko/2007050812 BonEcho/22.214.171.124pre is running fine on NT, will verify fixed this bug when we have the 126.96.36.199 RC2
carsten: thanks for the quick turn around on the verification!
verified fixed 188.8.131.52 using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:184.108.40.206) Gecko/2007050903 Firefox/220.127.116.11 RC 2 - Build starts and is running normal. Adding verified keyword
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.
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:18.104.22.168) Gecko/20070509 Firefox/22.214.171.124
You need to log in before you can comment on or make changes to this bug.