Sequel to bug 330276. Gecko 1.9 does not support Win 9x/ME any more so that we don't need to keep what's added only to support those platforms in xpcom/io and uriloader/base/windows.

not yet tested, but it should work. uploading it to put it in a safe place ;-)

*** Bug 333705 has been marked as a duplicate of this bug. ***

Comment on attachment 244893 [details] [diff] [review] patch (not yet tested) |#if defined (XP_WIN) && !defined (WINCE)| and the closing #endif should be kept. > NS_COM void StartupSpecialSystemDirectory() > { >-#if defined (XP_WIN) && !defined (WINCE) >- /* On windows, the old method to get file locations is incredibly slow. >- As of this writing, 3 calls to GetWindowsFolder accounts for 3% of mozilla ..... >+ // SHGetKnownFolderPath is only available on Windows Vista >+ // so that we need to use GetProcAddress to get the pointer. > gShell32DLLInst = LoadLibrary("Shell32.dll"); > if(gShell32DLLInst) ..... >-#endif

Comment on attachment 244893 [details] [diff] [review] patch (not yet tested) Asking for r/sr. I've tested the patch and it works well.

Comment on attachment 244893 [details] [diff] [review] patch (not yet tested) nsWindowsRegKey could also receive similar treatment. r+sr=darin

Thanks for r/sr. Landed on the trunk. I also cvs-removed nsWinAPIs.*. Searching for 'OSVERSION' yields a few more places (inclduing nsWindowsRegKey*) that need a similar treatment.

> // Per http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/versioninformation/versioninformationreference/versioninformationfunctions/getfileversioninfosize.asp > // if the "short" version of this file name is > 125 characters, > // GetFileVersionInfoSize will not work (for Win9x compatibility) > WCHAR shortPath[126]; > ::GetShortPathNameW(path, shortPath, sizeof(shortPath)); This looks a Win9x only limitation. Is it still required?

(In reply to comment #7) > > // if the "short" version of this file name is > 125 characters, > > // GetFileVersionInfoSize will not work (for Win9x compatibility) > > WCHAR shortPath[126]; > > ::GetShortPathNameW(path, shortPath, sizeof(shortPath)); > This looks a Win9x only limitation. Is it still required? Thanks for bringing it up. I'll get rid of it when I make a next patch. I also realized that |OpenFile|, |OpenDir| and other static functions I had added in bug 162361 can go away once we begin to build with NSPR for WINNT (rather Win95).

Some Win CE shunt went away with this patch. dougt should like them go :-) xpfe part is not tested, yet because it's only built with seamonkey, I believe. netwerk/base/src/nsAutodialWin.cpp netwerk/protocol/http/src/nsHttpHandler.cpp xpcom/ds/nsWindowsRegKey.cpp xpfe/components/winhooks/nsWindowsHooksUtil.cpp intl/locale/src/windows/nsCollationWin.cpp intl/locale/src/windows/nsCollationWin.h intl/locale/src/windows/nsDateTimeFormatWin.cpp intl/locale/src/windows/nsDateTimeFormatWin.h embedding/browser/activex/tests/RegMozCtl/RegTask.cpp modules/libutil/src/stopwatch.cpp

Comment on attachment 246104 [details] [diff] [review] patch : 2nd round sorry for bug spam. somehow, bugzilla doesn't prompt me to pick one when there are multiple matches for a partially typed email address.

the same as attachment 246104 [details] [diff] [review], but this one is easier to read.

(In reply to comment #9) > netwerk/base/src/nsAutodialWin.cpp netwerk/protocol/http/src/nsHttpHandler.cpp > xpcom/ds/nsWindowsRegKey.cpp xpfe/components/winhooks/nsWindowsHooksUtil.cpp > intl/locale/src/windows/nsCollationWin.cpp > intl/locale/src/windows/nsCollationWin.h > intl/locale/src/windows/nsDateTimeFormatWin.cpp > intl/locale/src/windows/nsDateTimeFormatWin.h > embedding/browser/activex/tests/RegMozCtl/RegTask.cpp > modules/libutil/src/stopwatch.cpp Did you forget to include nsLocalFileWin.cpp in your patch? :-)

Thanks, Masatoshi. I forgot to include nsLocalFileWin.cpp in the patch.

Comment on attachment 246104 [details] [diff] [review] patch : 2nd round Maybe we should define UNICODE and then use the normalize API call (not the A or W function call, but rather let the header files do the right thing)? Do we know if this is the first change to the source which will prevent the trunk running on 98? I am asking because we might want to ensure that his is communicated _again_ to everyone. Plus, we might want to also check that the installer does the right thing. Looks good, and sorry I didn't review this later year. happy new year.

(In reply to comment #14) > Maybe we should define UNICODE and then use the normalize API call (not the A > or W function call, but rather let the header files do the right thing)? That's bug 239279. Of course, we don't have to care about MSLU or its equivalent anymore. > Do we know if this is the first change to the source which will prevent the > trunk running on 98? I am asking because we might want to ensure that his is > communicated _again_ to everyone. The trunk is already broken on Win9x by bug 330276. It's also relnoted. http://www.mozilla.org/projects/firefox/3.0a1/releasenotes/ BTW, this relnote is slightly wrong since WinNT4 is no longer supported, either. > Plus, we might want to also check that the > installer does the right thing. That's bug 330208.

Comment on attachment 246104 [details] [diff] [review] patch : 2nd round +++ intl/locale/src/windows/nsDateTimeFormatWin.cpp 20 Nov 2006 16:29:31 -0000 + LPCWSTR wstr = NULL; + if (format) + wstr = NS_CONST_CAST(LPCWSTR, NS_ConvertASCIItoUTF16(format).get()); You can't do this... wstr will point to deleted memory after this line.

Jungshik: Should another bug maybe filed for removing the use of native methods through the tree when referring to Windows? By that I mean examples such as: http://lxr.mozilla.org/mozilla/source/xpcom/threads/nsProcessCommon.cpp#99 ...or should ones like this just be picked off as people come across them? :)

(In reply to comment #15) > BTW, this relnote is slightly wrong since WinNT4 is no longer supported, > either. I brought up the issue of the release notes being misleading in regards to WinNT4 support in the talk page for the Alpha2 release notes as well. Hopefully it gets corrected at some point. http://wiki.mozilla.org/Gecko_Talk:1.9a2/ReleaseNotes

Comment on attachment 246104 [details] [diff] [review] patch : 2nd round This was checked in already, right?

We have already removed code for Win9x and Win2000 past years. mark as WFM