Closed Bug 330276 Opened 18 years ago Closed 18 years ago

Drop support for pre-Win2k platforms (Win9x/Me/NT4) for Gecko 1.9 (Firefox 3).

Categories

(Core :: Widget: Win32, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9alpha1

People

(Reporter: emk, Assigned: emk)

References

Details

Attachments

(3 files, 5 obsolete files)

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.
Attached patch Patch rv 1.0 (obsolete) — Splinter Review
Assignee: win32 → VYV03354
Status: NEW → ASSIGNED
Attachment #214849 - Flags: review?(emaijala)
Comment on attachment 214849 [details] [diff] [review]
Patch rv 1.0

Asking masayuki for review about IME stuff.
Attachment #214849 - Flags: review?(masayuki)
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.
Attached patch Patch rv 1.1 (obsolete) — Splinter Review
biesi:
Could you take a look?
Attachment #214849 - Attachment is obsolete: true
Attachment #214907 - Flags: review?(cbiesinger)
Attachment #214849 - Flags: review?(masayuki)
Attachment #214849 - Flags: review?(emaijala)
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
Attachment #214907 - Flags: review?(cbiesinger)
Attachment #214907 - Flags: review?(emaijala)
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/

(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 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 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.
Attachment #214907 - Flags: review?(emaijala)
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.
please. lets move forward, not backwards :)
Assignee: VYV03354 → win32
Status: ASSIGNED → NEW
er, whoops
Assignee: win32 → VYV03354
Attached patch Patch rv 2.0 (obsolete) — Splinter Review
There is no longer weird #ifdefs.
This patch not only saves the code size but also makes the source much more readable.
Attachment #214907 - Attachment is obsolete: true
Attachment #215781 - Flags: review?(emaijala)
Summary: Stop compiling pre-Win2k support when cairo is enabled. → Drop support for pre-Win2k platforms.
Attached patch Patch rv 2.0, unbitrotted (obsolete) — Splinter Review
Attachment #215781 - Attachment is obsolete: true
Attachment #216187 - Flags: review?(emaijala)
Attachment #215781 - Flags: review?(emaijala)
Comment on attachment 216187 [details] [diff] [review]
Patch rv 2.0, unbitrotted

Ok, but need to check this doesn't break WinCE.
Attachment #216187 - Flags: review?(emaijala)
Attachment #216187 - Flags: review?(dougt)
Attachment #216187 - Flags: review+
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.
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.
Depends on: 331723
Comment on attachment 216187 [details] [diff] [review]
Patch rv 2.0, unbitrotted

so, is this the patch that will break windows 98 support?
no, we already broke win98 support when we changed to cairo on the trunk.
So, this bug is only about reducing codesize?  What happens if someone wants to add support for win9x?  What would we do then?
(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."
(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.
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.
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.
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?
(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 on attachment 216187 [details] [diff] [review]
Patch rv 2.0, unbitrotted

i will fix up WinCE after the landing.
Attachment #216187 - Flags: review?(dougt) → review+
Attached patch Patch rv 2.1Splinter Review
resoleved nits in comment #16
Attachment #216187 - Attachment is obsolete: true
Attachment #216511 - Flags: superreview?(roc)
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.
(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.
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.
(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?
(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.
(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 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.
Attachment #216511 - Flags: superreview?(roc) → superreview+
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.
checked-in, thanks.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Since more code was removed after the original pactch, what is the final codesize reduction?
Debug gkwidget.dll: 664K to 636K.
I didn't measure about release build because static build requires much longer time.
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
Attached patch Fix sunbird bustage (obsolete) — Splinter Review
Copied from mozilla/mail/app/Makefile.in that is checked in by pavlov to fix Thunderbird bustage.
Attachment #217279 - Flags: superreview?
Attachment #217279 - Flags: review?
Attachment #217279 - Flags: superreview?(dmose)
Attachment #217279 - Flags: superreview?
Attachment #217279 - Flags: review?(dmose)
Attachment #217279 - Flags: review?
Depends on: 332830
(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 on attachment 217279 [details] [diff] [review]
Fix sunbird bustage

r=dmose; no sr required for Sunbird
Attachment #217279 - Flags: superreview?(dmose)
Attachment #217279 - Flags: review?(dmose)
Attachment #217279 - Flags: review+
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
(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.
(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".
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".
(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 on attachment 217279 [details] [diff] [review]
Fix sunbird bustage

Please check in the patch to fix sunbird bustage.
Comment on attachment 217279 [details] [diff] [review]
Fix sunbird bustage

Sorry, I have no check in priv.
Please ask calendar owners.
Comment on attachment 217279 [details] [diff] [review]
Fix sunbird bustage

Sunbird bustage fix checked in on the trunk.
Attachment #217279 - Attachment is obsolete: true
Blocks: 332737
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.
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. 
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.
Thank you, Dainis Jonitis.
Attachment #217429 - Flags: superreview?(roc)
Attachment #217429 - Flags: review?(roc)
(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.
(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.
Attachment #217429 - Flags: superreview?(roc)
Attachment #217429 - Flags: superreview+
Attachment #217429 - Flags: review?(roc)
Attachment #217429 - Flags: review+
Depends on: 333105
Depends on: 333118
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...
I don't know that NT4 is dropped. But NT4 cannot run thebes, because thebes uses after Win2k API.
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).
Summary: Drop support for pre-Win2k platforms. → Drop support for pre-Win2k platforms (Win9x/Me/NT4).
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
*** Bug 333525 has been marked as a duplicate of this bug. ***
*** Bug 333810 has been marked as a duplicate of this bug. ***
Why 333525 and 333810 are dup of this? They are dup of 330208 (or 331723), I think.
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 ?
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.
(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.

> mean with "netscape team"

(I meant with "integrate the netscape team")
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
(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.)
(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.
I'm not sure how to explain it simpler than I did in comment #36.
Attachment #220066 - Flags: approval1.8.0.5?
Attachment #220066 - Flags: approval-branch-1.8.1?
Attachment #220066 - Flags: superreview?(roc)
Attachment #220066 - Flags: review?(emaijala)
Attachment #220066 - Flags: approval1.8.0.5?
Attachment #220066 - Flags: approval-branch-1.8.1?
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 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 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.
Attachment #220066 - Flags: review?(emaijala) → review+
(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?

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.
cairo can deal with a missing AlphaBlend; it falls back to doing the blending in software.
Attachment #220066 - Flags: superreview?(roc) → superreview+
Attachment #220066 - Flags: approval-branch-1.8.1?(benjamin)
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
Attachment #220066 - Flags: approval-branch-1.8.1?(benjamin) → approval-branch-1.8.1+
Attachment #220066 - Attachment description: subset of rv2.1 to fix mingw bustage on 1.8/1.8.0 branches → subset of rv2.1 to fix mingw bustage on 1.8/1.8.0 branches (fixed1.8)
Attachment #220066 - Attachment description: subset of rv2.1 to fix mingw bustage on 1.8/1.8.0 branches (fixed1.8) → subset of rv2.1 to fix mingw bustage on 1.8/1.8.0 branches (fixed1.8.1)
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.
Summary: Drop support for pre-Win2k platforms (Win9x/Me/NT4). → Drop support for pre-Win2k platforms (Win9x/Me/NT4) for Gecko 1.9 (Firefox 3).
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
wontfix would imply that we aren't going to drop support for those platforms.  FIXED is the correct resolution.
I filed bug 359808 to do the same for xpcom/io and uriloader.
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. 
> 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.
You need to log in before you can comment on or make changes to this bug.