certainly Link21 has been a disgrace and an embarrassment to the Win9xME forums here and needs to pay the price [or should I say "suffer the consequences"] for his foolish comments. If he says he wants Firefox 3 to work only under NT-based versions of Windows, this is not the right place to say that.

all right for those who have gotten Firefox 1.5.0.5 and have installed it under Win9xME, upgrade to 1.5.0.6 immediately as the makers of Firefox fixed other bugs that were not patched in 1.5.0.5.

Beta 2 of Firefox 2.0 should be ready sometime next week.

I tested Portable Firefox Bon Echo on a Win98SE box at work. Works perfectly.

I'm going to test out Portable Firefox versions 1.5.0.6 and 2.0 beta 1 under Win95 SR2 and Win98 FE to see if they work OK. I'm going to ditch the Bon Echo "nightly" builds which seem to crash immediately under Win95 after the FF browser loads.

another "light-weight" app similar to Portable Firefox is K-Meleon:
http://kmeleon.sourceforge.net/
works even under slow intel 486 machines with less RAM

beta 2 of Firefox 2.0 now available here:
http://www.mozilla.org/projects/bonecho/all-beta.html

and beta 2 of Portable Firefox 2.0 here:
http://portableapps.com/apps/internet/firefox_portable/test

Firefox 2.0 Release Candidate 1 is now available here:
http://www.mozilla.org/projects/bonecho/all-rc.html
and so is Firefox Portable 2.0 RC1 and 1.5.0.7 from the Portable Apps site

Bad news for Win95 users: Firefox 2.0 beta 2 and RC1 are incompatible under Win95 as FF 2.0 B2 and FF 2.0 RC1 crash at startup. problem is noted here:
https://bugzilla.mozilla.org/show_bug.cgi?id=353537

however, Firefox 2.0 beta 1 does work correctly under Win95.

erpdude mentioned k-meleon, a browser I used to keep up with, I would recommend K-ninja.

http://www.geocities.com/grenleef/

It's based on k-meleon and should be 100% 9x compatible.

K-Meleaon and its variations will have the same problem as Firefox and anything based on Gecko, if they will want to use Gecko 1.9.

Release candidate 2 for Firefox 2.0 is released:

Firefox RC2

Current users of firefox release candidate 1 can automatically update it to release candidate 2.

Firefox 2.0 RC2 I've heard has been buggy. RC3 now released:
http://www.mozilla.org/projects/bonecho/all-rc.html

K-Ninja 2.04 released:
http://www.geocities.com/grenleef/

and K-Meleon 1.02 was posted a few weeks ago:
http://kmeleon.sourceforge.net/wiki/index.php?id=Download

It's nice that you keep posting these links, although also somewhat redundant IMO. The point of this whole thread should have been, and still is, to discuss Firefox 3 and Gecko 1.9 support for Windows 98. I have yet to witness a discussion in this regard.

Yeah, I'm also still waiting for a discussion on this. Here's something I learned about. Apparently you can have support for Unicode applications on Windows 95 if you install the Microsoft Layer for Unicode, known as Unicows. So that's one thing out of the way.

not possible, BenoitRen. Firefox 2.0, both the RC and final releases, crash under Win95.
so forget about using Unicows under Win95, use it under Win98 or WinME instead to run Firefox 2.0 or 3.0

BTW - final release of FF 2.0 posted here:
http://www.mozilla.com/en-US/firefox/





well, ivanbuto, there hasnt been much of talk about Firefox 3 and Gecko 1.9 stuff because nobody, I mean NOBODY has done some ACTUAL testing of FF 3.0 and have mentioned how well FF 3 does on a Win9xME system! perhaps you should start testing out FF 3.0 in your spare time and tell us how FF 3 runs on your Win9xME machines.

Go here and start testing the latest "nightly" build of FF 3.0 alpha 1:
http://ftp.mozilla.org/pub/mozilla.org/fir...y/latest-trunk/

personally, I'll hold off until Mozilla releases a public beta of Firefox 3.0 which may happen either near the end of 2006 or in early 2007

If you had done some reading, you would know that the trunk no longer works on Windows 98.

Please reread my initial post, and especially go over the stuff at bugzilla and in the mozillazine folders, before you make further comments and give out further advice.

I really can't see Win98 being supported in FF3. I am just not sure there is the interest in doing so.

In saying that it will be a shame that we arn't left with a Firefox browser for Win9x that passes Acid2.

Whilst I am a Firefox 2.0 user (On my trusty Pentium Pro 200MHz) , I have already begun using alternative browsers on occasion like Opera 9.02 (it passes Acid2 and is getting better and better all the time).

I guess the real question to ask is.... how hard would it be to integrate support for Win9x into Firefox 3?

1. Is it possible
2. Is it feasible
3. Is it worth the effort?

1. Yes. Again, people, please read the links and the stuff that has already been posted before making comments!!
2. Opinions may vary on this one. I, for one, can't judge. How difficult the effort would be can only be judged by somebody competent in C++ and programming.

Part of the reason why Firefox 2.0 crashes under Windows 95 is that it doesn't understand Unicode. It can help, though I would have to test my theory.

Who says I'm using Firefox? I use SeaMonkey, thank you very much. SeaMonkey 1.1 Alpha ran just fine under Windows 95, and I would assume the Beta nightlies do too.
People should obsess less about that test. It is not an indication of being standards-compliant. Look it up, Gecko supports 90+% of CSS. That's actually quite good. The Acid2 test was primarily made to show the most common CSS flaws of rendering engines.

Considering that most people are going to use thexe Win9x boxes for at least a couple more years, I'd say yes.

WRONG, BenoitRen! You have NOT been paying attention as to why FF2 doesnt work under Win95:
LOOK HERE!
https://bugzilla.mozilla.org/show_bug.cgi?id=353537
even if the unicows.dll file is installed on a Win95 system, FF 2.0 STILL crashes when attempting to run FF2
perhaps I wasnt clear on that earlier, sorry for the inconvienience

BTW - I'm beta testing the latest nightly build of Seamonkey 1.1b under WinME/XP - stable
same with K-Meleon browser found here:
http://kmeleon.sourceforge.net/

Someone should just tell those d*mn developers to stop using 2K and above -specific APIs.

Why would they have wanted to anyway - it's not as if there's some revolutionary functionality there.

yeah, absolutely right, LLXX! I mean, what's so special for them to make Firefox3/Gecko 1.9 specifically use W2k/XP API/DLL files; a real pain below the waist for w98/me users!

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

Question no.1 : Is this bug resolved or not. I mean have all the missing libraries are patched or fixed or not, or are they still in testing phase, or is the work halted?

Question no.2 : When will the FF 3 testing releases be released?

Answer 1: This bug is resolved, it means that the support for pre-Win2k platforms (Win9x/Me/NT4) for Gecko 1.9 (Firefox 3) had been dropped.

Answer 2: Nightly builds of FF3 are available here: ftp://ftp.mozilla.org/pub/mozilla.org/fir...y/latest-trunk/

Petr

Thats sad. Anyway thanks for replying. One more query

Question: What are those patches for at the beginning at this bug: Drop support for Pre 2K

I don't know, just rough guess: probably these patches implement "Drop support for Pre 2K".

Petr

Here's what I can make out of the patch:

Replaces mPeekMessage calls by PeekMessageW calls.
Replaces mDispatchMessage calls by DispatchMessageW calls.

Pulls out support for Win9x print drivers. For WinNT it's WINSPOOLER, for Win9x it's NULL.
It does this by removing the Windows version check and always using WINSPOOLER.

Replaces mSHGetPathFromIDList calls by SHGetPathFromIDListW calls.
Replaces mSHBrowseForFolder calls by SHBrowseForFolderW calls.
Replaces mGetOpenFileName calls by GetOpenFileNameW calls.
Replaces mGetSaveFileName calls by GetSaveFileNameW calls.

The KeyboardLayout::LoadLayout procedure got modified so that it doesn't compensate anymore for Win9x' inexistant Unicode support. Before, it would use ASCII for Win9x.

Removal of ANSI version of a certain procedure in favor of Unicode.

Something to do with calling APIs for multiple monitors that are only available on Win98 and Win2000.

Implements GetMonitorInfoW in favor of other detection methods.

Removes winmm.dll loading, which seems to be used to play back certain sounds.

Next it removes all the Win9x support calls that were used before from nsToolkit. Here's parts of it the functions defined:


I guess this is enough food for thought for anyone interested. The patch is huge.

Why would they want to make such a patch anyway?

Well... Firefox is open-source, so if it doesn't work for you go ahead and change it...

Thats nice info. I was thinking that those patches were there to add windows98 support, i was going to download FF3 and test it with those patches installed on Windows98SE. Certainly i would have ended in .



Thats very cruel of them to write those patches, making it completely impossible to run it on windows98 or ME.

1. But browsers other then I.E have a tendency of being more stable. I was browsing a site with I.E 6.1 SP1 and got hit by ntkernel.exe trogen which freezed my system for 2 minutes, increased the size of my swap file from 50MB to 250MB and then tried to connect to internet but Zonealarm caught it... On that same site with firefox there was not even a single slow down or freeze and no trogen activity.

2. The system becomes very low on resourses with I.E usage for long periods of time, it starts to freeze with multitasking.

3. All browsers based on I.E have the same tendencies.

Hello!



msg #36 from http://bugzilla.mozilla.org/show_bug.cgi?id=330276


Regards, Roman

Wow... after reading through some of the code and comments of their programmers I feel like wanting to rewrite all of it... it's as if they were coerced by M$ or something to drop support for 9x!
That's a horribly inefficient and roundabout way to do it... Why not just replace PeekMessageW with PeekMessageA and be done with it? Sometimes I really do question the intelligence of these open-source 'programmers'...

Well, Firefox must be internally Unicode, and thus must use unicode APIs. If they'll use ANSI strings and ANSI apis, there will be much more headaches.

^^^ Thats wonderful.

What I meant was to have a compiler directive or something that completely changes Firefox to use the A APIs when compiled with appropriate options.

What's with the popularity of all this 'unicode' anyway... even WinXP can't display multiple languages in the same dialog box using unicode strings in the resources, and it's just a huge waste of space (TWICE).

you're not going to believe this guys but reading this Bink.nu article:
http://bink.nu/Article8777.bink
there's a "microsoft firefox"? wahahaha! funny!

Man, my heart almost stopped for a few seconds . Then I started to read... That's a really good one !

yup. no wonder why this "unicode" stuff requires much more resources and more HD space

it looks like seamonkey 1.5 browser will also be based on the gecko 1.9 runtime

that Microsoft Firefox site I mentioned earlier is still working [hehehe]

Firefox 2.0.0.1 now available here:
http://www.mozilla.com/en-US/firefox/2.0.0.1/releasenotes/
same with Firefox 1.5.0.9:
http://www.mozilla.com/en-US/firefox/releases/1.5.0.9.html

Win95 users should get FF 1.5.0.9 as FF 2.x crashes under Win95.

the "MS Firefox" site I mentioned earlier is still working...

I think part of the reason they suggest to do it in this way is that it's not just about the Unicode APIs. It's about some APIs used in Cairo which are entirely unimplemented in Windows 9x. It seems that so far there are only few such APIs (check the bugzilla thread for reference).

Great, BenoitRen, thanks for digging into this!
It seems that as a start, it would be good to follow the proposal of Robert Callahan by doing the following:

1. Writing the file wincompat.h, which would define all the functions that are missing in Win 9x, including the ones that were modified by this patch. (Example given by R. Calahan: "PeekMessageW gets #defined to Win9x_PeekMessageW") This should include all the APIs present on the current 1.9 trunk that do not work on Windows 9x. It seems like this is mostly mechanical work, anyone with some knowledge of C++ programming could do it.

2. Writing the wrapper, by defining all the Win9x_functions. All the functions removed by the patch would simply be "put back" in this wrapper.

This would be a great place to start, and could also attract the attention of Mozilla developers once it's finished.

Additional functions which will need to be created for Win9x are some that exist in Cairo and that use APIs not available in Windows 9x. Thus far I know of the following:
- GetGlyphIndicesA/W
- UpdateLayeredWindow
- AlphaBlend (not clear whether this one is needed)
- SetWorldTransform


I really believe this can be done. Just think about how great it would be to have Firefox 3 ready for Windows 98.

I think some of the Cairo functions are going to be very difficult to implement.
I have just installed Opera 9 which still supports Win95 and is freeware (according to tucows anyway), and at the moment I am very impressed by its speed. I do hope it takes some of the market share from firefox and remind them how many users still run Win9x. Goodbye firefox

There's more out there than Firefox using Gecko, dammit! I use SeaMonkey, and am a fan of K-Meleon.

So what? Difficult works too. No one said this was going to be easy.

I don't know why every major open-source software seems to gradually get more bloated and less compatible.

I'll keep my IE 6.

Well, although it is likely Opera will keep support for Win9x for some time to come, you never know when they will cut it off. The power of open source is that anyone can contribute, i.e. there is an opportunity here with Firefox and continuing support for Win9x.

IE 6? Ugh... You know, I thought I would start arguing, but there is no point. I see, LLXX, that thus far you have been rather skeptical and critical about this whole thing... which is OK, to each his/her own... however, I think it would be best to remain constructive and try to move things forward. That's why I don't even want to argue about IE/Opera/Firefox, and matters of that sort...
As you have shown, you have some very good knowledge of programming, and should you choose to contribute, I am sure you would be very helpful...

GetGlyphIndices could be worked via a binary buffer search
UpdateLayeredWindow i am not sure what you might do with this and others, but good luck I hope you succeed, as mentioned why they add more bloat is very puzzling. They perhaps got the idea when co-operating with ms when trying to get it to work with vista perhaps

You must like s***.

Which bloat? Cairo is not bloat.

Currently, they have to maintain three different librairies to get Gecko to render on the major platforms. GDI for Windows, and whatever they use for Linux and Mac OS X.

With Cairo, they'll have to maintain just one library to get Gecko to render on all platforms. Easier, less time-consuming, and makes for less code, so it's actually less bloat. As an added bonus, it allows for better rendering. Gecko passes the Acid 2 test since early December on trunk!

I'm sure we wouldn't be complaining about how Cairo seems to bloat Gecko if it didn't make Mozilla drop Win9x support.

"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.)"
"That it can be disabled is temporary. We'll remove that once we're on and good
on all win,mac,linux"
Moving to cairo for more rounded corners etc to pass acid 2 tests, disable the Cairo bloat and it might work, but only temporary because they will disable this, seems a very smart move, when opera works on 9x and passes the test.

The reason for the bloat is because they decided to make it cross-platform.

Generality decreases efficiency.

I haven't had any problems with a secured IE6... if you do you must be doing something wrong.

It's not only a security nightmare, it also has a f***ed-up behaviour when it comes to rendering web pages. Additionally, it's quite ancient in its support of web standards.