Last Comment Bug 330276 - Drop support for pre-Win2k platforms (Win9x/Me/NT4) for Gecko 1.9 (Firefox 3).
: Drop support for pre-Win2k platforms (Win9x/Me/NT4) for Gecko 1.9 (Firefox 3).
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Widget: Win32 (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal with 1 vote (vote)
: mozilla1.9alpha1
Assigned To: Masatoshi Kimura [:emk]
: Hixie (not reading bugmail)
Mentors:
: 333525 333810 (view as bug list)
Depends on: 331723 332830 333105 333118
Blocks: 330208 332737
  Show dependency treegraph
 
Reported: 2006-03-12 14:07 PST by Masatoshi Kimura [:emk]
Modified: 2007-04-17 10:27 PDT (History)
30 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch rv 1.0 (57.28 KB, patch)
2006-03-12 14:08 PST, Masatoshi Kimura [:emk]
no flags Details | Diff | Splinter Review
Patch rv 1.1 (83.55 KB, patch)
2006-03-13 07:00 PST, Masatoshi Kimura [:emk]
no flags Details | Diff | Splinter Review
Patch rv 2.0 (169.97 KB, patch)
2006-03-21 08:24 PST, Masatoshi Kimura [:emk]
no flags Details | Diff | Splinter Review
Patch rv 2.0, unbitrotted (170.51 KB, patch)
2006-03-24 21:06 PST, Masatoshi Kimura [:emk]
emaijala+moz: review+
doug.turner: review+
Details | Diff | Splinter Review
Patch rv 2.1 (171.27 KB, patch)
2006-03-28 02:58 PST, Masatoshi Kimura [:emk]
roc: superreview+
Details | Diff | Splinter Review
Fix sunbird bustage (1.07 KB, patch)
2006-04-05 04:37 PDT, Masatoshi Kimura [:emk]
dmose: review+
Details | Diff | Splinter Review
Fix ::BlockInput problem (1.50 KB, patch)
2006-04-06 07:28 PDT, Masatoshi Kimura [:emk]
roc: review+
roc: superreview+
Details | Diff | Splinter Review
subset of rv2.1 to fix mingw bustage on 1.8/1.8.0 branches (fixed1.8.1) (1.44 KB, patch)
2006-04-27 14:49 PDT, cls
emaijala+moz: review+
roc: superreview+
benjamin: approval‑branch‑1.8.1+
Details | Diff | Splinter Review

Description Masatoshi Kimura [:emk] 2006-03-12 14:07:17 PST
We will be able to save the code size.
On my build environment (VC8 --enable-debug --enable-shared):
I have reduced gkwidget.dll size to between 652KB and 632KB.
Comment 1 Masatoshi Kimura [:emk] 2006-03-12 14:08:40 PST
Created attachment 214849 [details] [diff] [review]
Patch rv 1.0
Comment 2 Masatoshi Kimura [:emk] 2006-03-12 14:10:07 PST
Comment on attachment 214849 [details] [diff] [review]
Patch rv 1.0

Asking masayuki for review about IME stuff.
Comment 3 Christian :Biesinger (don't email me, ping me on IRC) 2006-03-12 15:28:22 PST
Maybe we should use a DISABLE_PRE_WIN2K define for it or something like that, to make it clear what these ifdefs really want to check? and define that for cairo-win32.
Comment 4 Masatoshi Kimura [:emk] 2006-03-13 07:00:00 PST
Created attachment 214907 [details] [diff] [review]
Patch rv 1.1

biesi:
Could you take a look?
Comment 5 Christian :Biesinger (don't email me, ping me on IRC) 2006-03-13 13:08:44 PST
Comment on attachment 214907 [details] [diff] [review]
Patch rv 1.1

sorry, I don't want review blame for a patch that kills pre-win2k support
Comment 6 Hermann Schwab 2006-03-14 02:55:27 PST
couldn't start current nightly Firefox.exe, zip package unzipped into new empty directory, seems to be from here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006-03-13-07-trunk/

version as seen in Windows98 Windows Explorer properties: 
1.9a1: 2006031306  7.473.664 bytes, 13. März 2006 07:41:52

Error message something like Export missing: GDI32.DLL:getGlyphIndicesW.

Seems the messages is truncated, but I don't see a way to enlarge the alert, scroll the message or select and copy it.

working: Zip build from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/experimental/non-cairo/2006-03-13-06-trunk/

Comment 7 Masatoshi Kimura [:emk] 2006-03-14 03:37:55 PST
(In reply to comment #6)
This patch is not checked in yet. That is another problem (bug 330208).
However bug 330208 should be WONTFIXed if we proceed this bug.
Comment 8 Ere Maijala (slow) 2006-03-18 02:13:33 PST
Comment on attachment 214907 [details] [diff] [review]
Patch rv 1.1

You need to convince me this is a good thing. The patch clutters the source in a way I'd avoid unless the benefits are substantial enough. I'd like to see what we would save in a  release build. Any numbers?
Comment 9 Masatoshi Kimura [:emk] 2006-03-18 06:56:42 PST
Comment on attachment 214907 [details] [diff] [review]
Patch rv 1.1

--enable-optimize --enable-static
firefox.exe: 7,487,488 bytes to 7,479,296 bytes.
Probably I could use some macros to reduce cluttered #ifdef-s.
Comment 10 Masatoshi Kimura [:emk] 2006-03-20 19:37:55 PST
pavlov:
I was adding DISABLE_PRE_WIN2K for SeaMonkey. But you said SeaMonkey would stick at the 1.8 branch.
Can I simply remove the pre-Win2k support from trunk? If so, we can also *improve* the source readability rather than getting worse.
Comment 11 Stuart Parmenter 2006-03-20 23:58:57 PST
please. lets move forward, not backwards :)
Comment 12 Stuart Parmenter 2006-03-20 23:59:25 PST
er, whoops
Comment 13 Masatoshi Kimura [:emk] 2006-03-21 08:24:10 PST
Created attachment 215781 [details] [diff] [review]
Patch rv 2.0

There is no longer weird #ifdefs.
This patch not only saves the code size but also makes the source much more readable.
Comment 14 Masatoshi Kimura [:emk] 2006-03-24 21:06:58 PST
Created attachment 216187 [details] [diff] [review]
Patch rv 2.0, unbitrotted
Comment 15 Ere Maijala (slow) 2006-03-25 11:59:02 PST
Comment on attachment 216187 [details] [diff] [review]
Patch rv 2.0, unbitrotted

Ok, but need to check this doesn't break WinCE.
Comment 16 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-03-25 12:25:38 PST
In |nsWindow::ResizeTranslucentWindow| and |nsWindow::UpdateTranslucentWindowAl|, there is non-condition brackets.

And in |nsWindow::nsWindow|, the indent of '=' is not matching to around lines.

Please check it.
Comment 17 Hermann Schwab 2006-03-25 14:23:42 PST
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060325 SeaMonkey/1.5a

Check-in of this patch would mean I can't test trunk anymore?

Mozilla is catering to a lot of OS, is it really necessary to drop Win98 support, or is it just for the convenience or the incompetence of new programmers?
Could we also get rid of quirks mode in rendering, enforce standards compliance mode? That would make understanding the standards much easier.
Win98 is the last MS-consumer-OS not bound to hardware, you can replace your harddisk with a bigger one, or insert a new mainboard, without having to activate, and you don't have to fear something like Sasser will 0wn your computer. If you aren't in the video editing business win98 is sufficient enough for surfing, banking and sometimes writing something on an old computer.
In Mozilla 1.3 times Win98 was broken for weeks, and no developer cared about it, though the marketshare of WinXP was only 4% higher than that of Win98, according to google Zeitgeist. I don't know the marketshare of win9x nowadays, but mozilla.org also didn't care about then. Depending on the URL I can choose I can tell you which OS or which browser rulez the world, but I don't believe in statistics I faked myself, and hope not to believe in that one others faked.
Comment 18 Doug Turner (:dougt) 2006-03-26 16:05:55 PST
Comment on attachment 216187 [details] [diff] [review]
Patch rv 2.0, unbitrotted

so, is this the patch that will break windows 98 support?
Comment 19 Stuart Parmenter 2006-03-26 23:01:17 PST
no, we already broke win98 support when we changed to cairo on the trunk.
Comment 20 Darin Fisher 2006-03-27 07:11:13 PST
So, this bug is only about reducing codesize?  What happens if someone wants to add support for win9x?  What would we do then?
Comment 21 Stuart Parmenter 2006-03-27 09:38:52 PST
(In reply to comment #20)
> So, this bug is only about reducing codesize?  What happens if someone wants to
> add support for win9x?  What would we do then?
> 

to quote myself from the last bug you asked this exact same question in:
"If someone did want to keep it working on win9x
it might be better for them to do it as a compatibility library so that we can
keep most of the code clean."
Comment 22 Stuart Parmenter 2006-03-27 09:41:51 PST
(In reply to comment #20)
> So, this bug is only about reducing codesize?

Also, this bug is about making code readable.  All the little classes and such we use currently throughout the tree make anyone wanting to follow our code have to jump through hoops to do so.  We should also see some (probably tiny) speedup by reducing the extra function calls and classes and memory churn.
Comment 23 Darin Fisher 2006-03-27 10:15:37 PST
Pav, I know.  But, won't all those extra indirections need to be put back into place by someone wanting to support Win9x?  I guess I don't understand the proposal to "do it as a compatibility library."  Where are the API hooks that would allow someone to do that?  Trying to improve the readability of the code is a good thing, and removing extra layers of indirection is also a good thing.  I'm just asking for some clarification here.
Comment 24 Stuart Parmenter 2006-03-27 11:09:58 PST
I don't see why they would.  We might have to add a header include somewhere, but someone could implement a stub library for the missing functions and implement them as needed.  garrett or dougt did something similar for CE I believe.
Comment 25 Darin Fisher 2006-03-27 13:31:11 PST
OK, sure.  One could go the route of redirecting symbols to a shim library.  Or, suppose someone proposed a patch that extended XPCOM's nsWinAPIs.{h,cpp} to include GDI32 and USER32 functions (or implemented a similar solution for those functions).  Would you be opposed to changing calls from ::GetMessageW to nsWinAPIs::mGetMessage, for example?
Comment 26 Stuart Parmenter 2006-03-27 13:41:03 PST
(In reply to comment #25)
> OK, sure.  One could go the route of redirecting symbols to a shim library. 
> Or, suppose someone proposed a patch that extended XPCOM's nsWinAPIs.{h,cpp} to
> include GDI32 and USER32 functions (or implemented a similar solution for those
> functions).  Would you be opposed to changing calls from ::GetMessageW to
> nsWinAPIs::mGetMessage, for example?
> 

nsWinAPIs::mGetMessage is pretty gross.  For anyone doing windows programming, ::GetMessageW is _much_ cleaner and _much_ more clear.  

On the trunk, I would argue that we should get rid of nsWinAPIs.{cpp,h} entirely.

We've said for Gecko 1.9 that we are not going to support Win95,98,ME.  I don't really see what living in the world of What Ifs give us here.  We should tell people that they can build a shim library if they want, otherwise we aren't supporting it.
Comment 27 Doug Turner (:dougt) 2006-03-27 14:07:38 PST
Comment on attachment 216187 [details] [diff] [review]
Patch rv 2.0, unbitrotted

i will fix up WinCE after the landing.
Comment 28 Masatoshi Kimura [:emk] 2006-03-28 02:58:03 PST
Created attachment 216511 [details] [diff] [review]
Patch rv 2.1

resoleved nits in comment #16
Comment 29 Hans-Andreas Engel 2006-03-28 08:25:57 PST
Reducing codesize is great!  But completely killing Win9x support by not even allowing a customized build for Win9x?  Yuk!  (Cairo does not completely break Win98 support, as it can be disabled.)  I really prefer v1 of the patch--it is still easy to read.

On the other hand, this is certainly great for the IT industry, allowing it to sell more upgrades.
Comment 30 Stuart Parmenter 2006-03-28 09:18:32 PST
(In reply to comment #29)
> Cairo does not completely break Win98 support, as it can be disabled.) 
> 
That it can be disabled is temporary.  We'll remove that once we're on and good on all win,mac,linux.
Comment 31 Benoît 2006-03-29 04:34:57 PST
I'm against this dropping as well. A lot of users still use Win98, even more than Linux. This is supposed to be cross-platform. This is almost as bad as M$ making IE just for XP SP2.
Comment 32 Caleb 2006-03-29 05:24:34 PST
(In reply to comment #31)
> I'm against this dropping as well. A lot of users still use Win98, even more
> than Linux. This is supposed to be cross-platform. This is almost as bad as M$
> making IE just for XP SP2.
> 

You should re-read comment 30 and think some more. Whoever is stupid enough to use Win9x as his primary system must have an old computer and should get it replaced ASAP. Why should a group of users keep holding everyone else back?
Comment 33 Tristor 2006-03-29 05:35:16 PST
(In reply to comment #29)
> Reducing codesize is great!  But completely killing Win9x support by not even
> allowing a customized build for Win9x?  Yuk!  (Cairo does not completely break
> Win98 support, as it can be disabled.)  I really prefer v1 of the patch--it is
> still easy to read.
> 
> On the other hand, this is certainly great for the IT industry, allowing it to
> sell more upgrades.
> 

Win9x has been dead for a long time before this.  Microsoft EOLed 98SE the year before last, and ME is due to be EOLed either late this year or early 07.  Not to mention that 9x is an atrocity.  You are encouraging the same sorts of silly behavior that got Microsoft into its current position of having so many security problems due to leaving in things that were best removed in order to have backwards compatibility with legacy systems that a few old codgers use and no-one else.
Comment 34 Hermann Schwab 2006-03-29 15:59:21 PST
(In reply to comment #33)
> (In reply to comment #29)
> Win9x has been dead for a long time before this.  Microsoft EOLed 98SE the year
> before last, and ME is due to be EOLed either late this year or early 07.  Not
> to mention that 9x is an atrocity.  You are encouraging the same sorts of silly
> behavior that got Microsoft into its current position of having so many
> security problems due to leaving in things that were best removed in order to
> have backwards compatibility with legacy systems that a few old codgers use and
> no-one else.

If you're really serious about security, kill the extension system. Besides making the code beeing a security risk it generates lots of invalid bugs entries in bugzilla, independent of old or modern operating systems.
The source readability will get better, less hooks will improve speed and memory usage.

WinME never had any impact, Win98SE was the most stable Windows. When I thought about upgrading, Trojan after Trojan was hitting the net, downing Win2k and WinXP, but not Win9x, so WTF should I upgrade just for surfing the net to collect the most current free software made just for XP? 
Win9x had been neglected by the mozilla project at a time it was just 3% behind XP in market share. A beta was released, though it was crashing on Win9x, the reason was known for three days, and a patch was waiting for review.
 
Can you really give a reason why XP or Vista is better nowadays better than Win98SE? Of course it should have been better before it hit the streets, and when I think of the troubles to get drivers for Win2k, it took more than a year beeing relatively sure to get drivers. Drivers were promised for Floppy streamers, but never came.
What's so difficult to support Win9x? Is the problem nobody knows it and developers can't test?
What's the cost of supporting Win9x, and what's the cost of not supporting it?
I'm understanding there may be reasons to stop support, but I never heard them, besides some newspeak about progress.
Firefox was broken on Win9x before this bug was filed, and imho this bug was filed to get rid of fixing the bug. There are other bugs sitting for years, and nobody tells lets stop Firefox. Did Win9x really stop working when Cairo was checked in, or did it stop some days after? 
Comment 35 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-03-29 21:00:08 PST
Comment on attachment 216511 [details] [diff] [review]
Patch rv 2.1

The only thing I'm a bit concerned about is removing the region transparency code. The Win2K/XP translucent window code doesn't work well in some cases, and we might want to enable regions on those platforms in some situations. However, when we get around to fixing that, we can resurrect the code from CVS, and in the meantime I think it's better to not have the unused code rotting in the tree.
Comment 36 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-03-29 21:07:50 PST
Here's what needs to be done to restore Win9x support, by whoever volunteers to do so:

Define a new header file wincompat.h (or something like that). When building normally it does nothing. When building for Win9x (enabled by a configure flag), it #defines all the Win2K-only APIs to Win9x-based replacements. E.g. PeekMessageW gets #defined to Win9x_PeekMessageW, which gets implemented in a separate file as a wrapper around Win9x's PeekMessage. This patch is a great place to start.

You should then be able to get Win9x-builds working without interfering with trunk code. Regular Windows builds won't work on Win9x but that's no great loss. I'd be happy to review such a patch.
Comment 37 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-04-04 13:57:49 PDT
checked-in, thanks.
Comment 38 u88484 2006-04-04 14:25:22 PDT
Since more code was removed after the original pactch, what is the final codesize reduction?
Comment 39 Masatoshi Kimura [:emk] 2006-04-04 14:50:26 PDT
Debug gkwidget.dll: 664K to 636K.
I didn't measure about release build because static build requires much longer time.
Comment 40 Stefan Sitter 2006-04-05 03:56:12 PDT
Is this check in responsible for the burning solaria tinderbox at http://tinderbox.mozilla.org/showbuilds.cgi?tree=Sunbird ?

gkwidget.lib(nsWindow.obj) : error LNK2001: unresolved external symbol _ImmAssociateContext@8
gkwidget.lib(nsWindow.obj) : error LNK2001: unresolved external symbol _ImmSetCandidateWindow@8
gkwidget.lib(nsWindow.obj) : error LNK2001: unresolved external symbol _ImmGetCompositionStringW@16
gkwidget.lib(nsWindow.obj) : error LNK2001: unresolved external symbol _ImmReleaseContext@8
gkwidget.lib(nsWindow.obj) : error LNK2001: unresolved external symbol _ImmGetContext@4
gkwidget.lib(nsWindow.obj) : error LNK2001: unresolved external symbol _ImmNotifyIME@16
gkwidget.lib(nsWindow.obj) : error LNK2001: unresolved external symbol _ImmSetOpenStatus@8
gkwidget.lib(nsWindow.obj) : error LNK2001: unresolved external symbol _ImmGetOpenStatus@4
gkwidget.lib(nsWindow.obj) : error LNK2001: unresolved external symbol _ImmGetDefaultIMEWnd@4
gkwidget.lib(nsWindow.obj) : error LNK2001: unresolved external symbol _ImmGetCompositionWindow@8
sunbird.exe : fatal error LNK1120: 10 unresolved externals
Comment 41 Masatoshi Kimura [:emk] 2006-04-05 04:37:12 PDT
Created attachment 217279 [details] [diff] [review]
Fix sunbird bustage

Copied from mozilla/mail/app/Makefile.in that is checked in by pavlov to fix Thunderbird bustage.
Comment 42 tech 2006-04-05 08:17:04 PDT
(In reply to comment #34)
I think you've put the finger on it : the mozilla team is now using the same developping method as microsoft people :
- trying to add features without having solved the existing bugs
- changing all the time the version numbers so that the bug reports never match the last version and people doesn't even know what's the last...

I've been using mozilla 1.7 for a long time until 1.7.12, then when reporting bugs one told me "you're not using the last version, now it's the 1.8beta" then I installed the 1.8beta but when reporting bugs one told me "now you should use the nighly builds"
then another told me that mozilla won't be debugged anymore except for security issues, I had to change to seamonkey, I used seamonkey v 1.5 for a time and now there's a new release as seamonkey 1.0 ! strange isn't it ?
I feel like re-installing my nice Netscape 3.0...
Comment 43 Dan Mosedale (:dmose) 2006-04-05 09:48:38 PDT
Comment on attachment 217279 [details] [diff] [review]
Fix sunbird bustage

r=dmose; no sr required for Sunbird
Comment 44 Henrik Gemal 2006-04-05 10:19:48 PDT
this also broke building with gcc on mingw:

loads of errors like these:
d:/Mozilla/mozilla/widget/src/windows/nsWindow.h:234: error: `HIMC' has not been declared
d:/Mozilla/mozilla/widget/src/windows/nsWindow.h:234: error: `COMPOSITIONFORM' has not been declared
Comment 45 Worcester12345 2006-04-05 13:17:16 PDT
(In reply to comment #0)
> We will be able to save the code size.
> On my build environment (VC8 --enable-debug --enable-shared):
> I have reduced gkwidget.dll size to between 652KB and 632KB.
> 

Will OS/2 and BEOS also be dropped? I imagine that will save additional code size, and I don't think they are supported by their "vendor" either.
Comment 46 Masatoshi Kimura [:emk] 2006-04-05 13:23:38 PDT
(In reply to comment #45)
> Will OS/2 and BEOS also be dropped? I imagine that will save additional code
> size, and I don't think they are supported by their "vendor" either.
BeOS supported cairo now (see bug 331888). Also, widget/beos and widget/os2 is not complied at all when building win32 port.
And please stop spamming unless you can contribute bug 331723 by making a "compatibility layer".
Comment 47 Serge Gautherie (:sgautherie) 2006-04-05 13:36:38 PDT
Is it planned to add a dialog or whatever to explain the situation ("needs at least Win2K") to pre-w2k users who would try newer builds ?

Trying 2006-04-05 nighly builds, on W98SE:
*SeaMonkey v1.5a displays its splash screen then immediately exists.
*ThunderBird v3.0a1 refuses to start, complaining about missing export "USER32.DLL:UpdateLayeredWindow".
Comment 48 Masatoshi Kimura [:emk] 2006-04-05 13:41:46 PDT
(In reply to comment #47)
> Is it planned to add a dialog or whatever to explain the situation ("needs at
> least Win2K") to pre-w2k users who would try newer builds ?
That is bug 330208.
Comment 49 Stefan Sitter 2006-04-05 13:50:42 PDT
Comment on attachment 217279 [details] [diff] [review]
Fix sunbird bustage

Please check in the patch to fix sunbird bustage.
Comment 50 Masatoshi Kimura [:emk] 2006-04-05 14:39:05 PDT
Comment on attachment 217279 [details] [diff] [review]
Fix sunbird bustage

Sorry, I have no check in priv.
Please ask calendar owners.
Comment 51 Dan Mosedale (:dmose) 2006-04-05 15:01:48 PDT
Comment on attachment 217279 [details] [diff] [review]
Fix sunbird bustage

Sunbird bustage fix checked in on the trunk.
Comment 52 Dainis Jonitis 2006-04-05 23:01:35 PDT
The patch that was checked into trunk changed nsKeyboardLayout.cpp to call API function ::BlockInput even in DEBUG builds. That changed behaviour compared to old code. You should have #ifndef DEBUG around both ::BlockInput calls to make sure that you can use debugger in LoadLayout function. Otherwise your mouse and keyboard will be completely useless until you restart computer.
Comment 53 Kroc Camen 2006-04-06 02:27:06 PDT
I work fixing computers and I come across Windows98 several times daily. There are a lot of people who cannot afford a new computer (since that one cost over £1000 last time), and the machine itself is perfectly usable for the Internet, as long as the spyware and **** is removed and Firefox is put on. Now you're saying that my customers are morons for running Windows 98, when they don't even know what an OS is. Not everybody can just drop a load of money on a new computer, even £300. Thanks to your ignorance, alot of people are not going to be able to run the latest Firefox on their computer. 
Comment 54 Steve England [:stevee] 2006-04-06 04:21:07 PDT
Win98 users aren't going to be able to use Firefox 3. Firefox 2 isn't even out the door yet (and probably won't be for many months yet) so there's still plenty of life left in firefox for win98 users.
Comment 55 Masatoshi Kimura [:emk] 2006-04-06 07:28:31 PDT
Created attachment 217429 [details] [diff] [review]
Fix ::BlockInput problem

Thank you, Dainis Jonitis.
Comment 56 Benoît 2006-04-06 12:46:26 PDT
(In reply to comment #32)
> (In reply to comment #31)
> You should re-read comment 30 and think some more. Whoever is stupid enough to
> use Win9x as his primary system must have an old computer and should get it
> replaced ASAP. Why should a group of users keep holding everyone else back?

To slap some sense into people who think newer is better. I should downgrade (yes, downgrade) to a more recent version of Windows that has atrocious backwards-compatibility, is extremely vulnerable to malware, bloated, and treats me like an idiot?

Arguing that you should buy a new PC to surf the web is one of the worst arguments ever, considering that the Internet can be surfed decently with at least 166 Mhz and 32 MB of RAM.
Comment 57 Hermann Schwab 2006-04-06 16:36:30 PDT
(In reply to comment #38)
> Since more code was removed after the original pactch, what is the final
> codesize reduction?

I'm using zip builds, codesize increased about 8k ;-)

BuildID 2006040309 is last working version on Win98
BuildID 2006040411 is working on Win98, if you get it to run by switching profiles, profile manager doesn't close though.
BuildID 2006040509 exits after Zonealarm allows to go on.
Comment 58 Marek Stępień [:marcoos, inactive] 2006-04-07 10:59:42 PDT
Has support for Windows NT 4.x been dropped as well? The bug's title is about "pre-Win2k", but in the comments you only talk about 9x...
Comment 59 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-04-07 11:05:50 PDT
I don't know that NT4 is dropped. But NT4 cannot run thebes, because thebes uses after Win2k API.
Comment 60 Masatoshi Kimura [:emk] 2006-04-07 13:13:25 PDT
I dropped also NT4 because it cannot run thebes as masayuki said.
Changing summary to clarify.
Yes, "pre-Win2k" includes WinMe (Win2k = NT 5.0, WinMe = Win9x 4.90).
Comment 61 Laurens Holst 2006-04-08 09:11:02 PDT
Everyone who worries about dropping pre-win2k support, let’s put this in perspective.

This is work for Gecko 1.9, i.e. Firefox 3.0. It is still a year or so off before it is a final release. By that time, Windows Vista will be released and Windows 98 numbers will have dwindled even more. Before that, there will be Firefox 2.0 and even when 3.0 is released, 2.0 will still be supported and get security fixes.


~Grauw
Comment 62 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-04-11 09:21:54 PDT
attachment 217429 [details] [diff] [review] was checked-in.
Comment 63 Hermann Schwab 2006-04-11 23:45:16 PDT
*** Bug 333525 has been marked as a duplicate of this bug. ***
Comment 64 zug_treno 2006-04-13 05:32:54 PDT
*** Bug 333810 has been marked as a duplicate of this bug. ***
Comment 65 Masatoshi Kimura [:emk] 2006-04-13 06:01:48 PDT
Why 333525 and 333810 are dup of this? They are dup of 330208 (or 331723), I think.
Comment 66 tech 2006-04-20 02:06:49 PDT
If you drop support for pre-win2k platforms, why not also drop support for beos, solaris, linux, macosx... and integrate the Netscape team, or more easy, why not use Ms explorer to browse the web ?
Comment 67 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-20 02:53:09 PDT
We have maintainers who have volunteered to do the work to keep those platforms supported. We haven't yet had a single volunteer step up to keep Win98 supported.
Comment 68 Christian :Biesinger (don't email me, ping me on IRC) 2006-04-20 03:52:33 PDT
(In reply to comment #66)
> If you drop support for pre-win2k platforms, why not also drop support for
> beos, solaris, linux, macosx... and integrate the Netscape team, or more easy,
> why not use Ms explorer to browse the web ?

The product you mean is called Internet Explorer, and if you think that's a better choice for you, then by all means use it. I don't understand what you mean with "netscape team", and I'm not sure that you are addressing the same set of people in the "if you drop [...]" part of the sentence and the "why not use [...]" part.

Comment 69 Christian :Biesinger (don't email me, ping me on IRC) 2006-04-20 03:53:37 PDT
> mean with "netscape team"

(I meant with "integrate the netscape team")
Comment 70 Hans-Andreas Engel 2006-04-20 06:53:18 PDT
Note that mozilla/firefox depends on Internet Explorer components...  So there is already a partial "integration."

For example, MLang is required here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/thebes/public/gfxWindowsPlatform.h&rev=1.4&mark=47#30

According to MSDN,
  "MLang is implemented as an in-process server and is distributed as 
  Mlang.dll only with Microsoft Internet Explorer 4.0 or later."
  http://msdn.microsoft.com/workshop/misc/mlang/overview/overview.asp
Comment 71 Ivan Bútora 2006-04-23 18:09:08 PDT
(In reply to comment #67)
> We have maintainers who have volunteered to do the work to keep those platforms
> supported. We haven't yet had a single volunteer step up to keep Win98
> supported.
> 

I'll pitch this over to the folks at the msfn.org Win9x forums; there seem to be a couple of people there good with programming, and maybe one or more of them would eventually be interested in developing this compatibility library, along the lines that you suggested. (I myself know almost nothing about C++ programming.)
Comment 72 Ivan Bútora 2006-04-26 01:50:34 PDT
(In reply to comment #36)
> Here's what needs to be done to restore Win9x support, by whoever volunteers 
> to do so:
(...)

Robert, could you please explain (to someone who does not know much about C++ programming) what is or will be the difference between this patch and a compatibility library for Win9x? And how would all of this relate to MZLU/opencow. What is the status of that project?

Thanks.
Comment 73 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-26 02:24:36 PDT
I'm not sure how to explain it simpler than I did in comment #36.
Comment 74 cls 2006-04-27 14:49:38 PDT
Created attachment 220066 [details] [diff] [review]
subset of rv2.1 to fix mingw bustage on 1.8/1.8.0 branches (fixed1.8.1)
Comment 75 Ere Maijala (slow) 2006-04-29 10:11:13 PDT
Comment on attachment 220066 [details] [diff] [review]
subset of rv2.1 to fix mingw bustage on 1.8/1.8.0 branches (fixed1.8.1)

cls, is this the correct bug for this patch? The original patch wasn't applied to 1.8, or am I confused?
Comment 76 Masatoshi Kimura [:emk] 2006-04-29 13:25:37 PDT
Comment on attachment 220066 [details] [diff] [review]
subset of rv2.1 to fix mingw bustage on 1.8/1.8.0 branches (fixed1.8.1)

Please see bug 333777.
Comment 77 Ere Maijala (slow) 2006-04-29 13:31:11 PDT
Comment on attachment 220066 [details] [diff] [review]
subset of rv2.1 to fix mingw bustage on 1.8/1.8.0 branches (fixed1.8.1)

Ok. I think it would have been better to do this in bug 333777, but fine if this helps. I can't really test it but it looks ok.
Comment 78 Ivan Bútora 2006-04-29 17:28:32 PDT
(In reply to comment #73)
> I'm not sure how to explain it simpler than I did in comment #36.
> 

I think I understood comment #36. My question is whether the eventual "compatibility library" would be essentially be a continuation of the MZLU project? Or could someone who would be building for Win9x decide to use MSLU, and then an additional compatibility library for some of the newer functions used by Cairo? Currently, besides GetGlyphIndicesA/W and UpdateLayeredWindow, are there any other ones?

Comment 79 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-30 15:25:00 PDT
You'd probably want to use MSLU and then implement the extra functions that are needed. I don't have a complete list of those. AlphaBlend is probably another one.
Comment 80 Christian :Biesinger (don't email me, ping me on IRC) 2006-04-30 16:51:29 PDT
cairo can deal with a missing AlphaBlend; it falls back to doing the blending in software.
Comment 81 Benjamin Smedberg [:bsmedberg] 2006-05-11 13:23:54 PDT
Comment on attachment 220066 [details] [diff] [review]
subset of rv2.1 to fix mingw bustage on 1.8/1.8.0 branches (fixed1.8.1)

a=me, after ff2a2 is finished
Comment 82 u88484 2006-06-19 16:52:32 PDT
updating the title since this bug is constantly linked to and people don't seem to read the bug and post wrong info on front page sites/forums.
Comment 83 mhonline 2006-08-01 14:48:01 PDT
someone mind to correct the closing for this issue as as "Wontfix"
it does not make sense to name it fixed if there is not anything fixed 

thanks

Martin
Comment 84 Stuart Parmenter 2006-08-01 15:42:45 PDT
wontfix would imply that we aren't going to drop support for those platforms.  FIXED is the correct resolution.
Comment 85 Jungshik Shin 2006-11-07 08:03:17 PST
I filed bug 359808 to do the same for xpcom/io and uriloader.
Comment 86 tim 2007-04-17 09:48:02 PDT
These posts are all a bit old. firefox 2.0.0.3 is presumably using the latest rendering engine and certainly works fine on win98. Why no support for win98 ?. I recognise that only 70,000,000 users still use it, but if the rendering engine supports it, why not keep a full range of compatibility.

I'm tempted to write my own calender program and release it open source, but it would probably be in visual basic (ie windows 9x,nt,2k,xp,vista only) as my c programming isn't up to windows api. 
Comment 87 Boris Zbarsky [:bz] 2007-04-17 10:27:54 PDT
> firefox 2.0.0.3 is presumably using the latest rendering engine 

It's using a rendering engine from August 2005, with security and crash fixes.

> but if the rendering engine supports it

The rendering engine doesn't care.  The graphics layer in use on trunk (and hence for Firefox 3) does not support it.  Which is pointed out in this bug earlier.

Note You need to log in before you can comment on or make changes to this bug.