Closed Bug 321795 Opened 19 years ago Closed 18 years ago

Seamonkey 1.5a installer nightly builds crash on first startup on Windows98SE

Categories

(SeaMonkey :: Build Config, defect)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: KKuhlemann, Unassigned)

Details

(Keywords: crash, regression) 

User-Agent:       Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.9a1) Gecko/20051229 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Win98; de-AT; rv:1.9a1) Gecko/20051229 SeaMonkey/1.5a

After complete custom installation of seamonkey 1.5a nightly installer build (last 20051228) on Win98SE seamonkey crashes on first startup without to start talkback. Clean installation directory and new profile dont change anything.

This is only on Win 98, the same installation file works on Win2000 and XP.

The issue concerns only the (daily) nightly builds, hourly tinderbox builds from
creature-trunk work well.

I saw this first about 20051214. 


Reproducible: Always

Steps to Reproduce:
1.Download a nightly installer build from ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/seamonkey-1.5.a.win32.installer.exe
2. Install this build after uninstall of a previous build.
3. Crash at the first startup

Actual Results:  
The installed build crashes any time trying to start it.

Expected Results:  
Normal startup.

Talkback was installed but didn't start.
Version: unspecified → Trunk
Keywords: regression
Keywords: crash
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051230 SeaMonkey/1.5a

normally I use zips, in a different location. This is build ID:20053009, installed from full exe installer into default location, quickstart not enabled.
Win98 SP1, no crash at first start.
First start wasn't really 1st start, as I had used before the zip build with the same buildID and the same profile. I also didn't have to uninstall as there was no Seamonkey build installed. I'll deinstall and install next nightly.

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060101 SeaMonkey/1.5a

deinstalled preceding nightly default installed in comment 1, custom installed todays nightly, started, no problems.

Klaus, how custom is your "complete custom" install? All options selected, default paths for program and profile, or do you have special locations for profile and/or program? Do you use Quickstart? What does happen if you don't deinstall but install ontop (there should be an automatic deinstall).
Do you use extensions, or a homepage specified in preferences?


(In reply to comment #2)
I tried it out again with the 20060101 nightly.
To give further information, here is the stack and the installer-configuration:

SEAMONKEY verursachte einen Fehler durch eine ungültige Seite
in Modul MSVCRT.DLL bei 018f:78026da9.
Register:
EAX=00014370 CS=018f EIP=78026da9 EFLGS=00010287
EBX=00000000 SS=0197 ESP=0065fa28 EBP=0065fa40
ECX=00000029 DS=0197 ESI=00014370 FS=1337
EDX=00000046 ES=0197 EDI=07861f80 GS=0000
Bytes bei CS:EIP:
89 51 14 99 bf 80 51 01 00 f7 ff bf 5c cd 03 78 
Stapelwerte:
0065fa78 0065fa5c 00000001 78026eb2 0065fa5c 000005a0 0065fa54 78027125 0065fa5c 0076ba58 0085b180 0065fa9c 78026fa5 00014370 00000001 60e541d0 

Setup Type:
    Custom

Selected Components:
    Navigator
    Mail & Newsgroups
    Spellchecker
    Chatzilla
    Debugger
    Inspector
    Roaming
    Website Reporter
    Quality Feedback Agent

Destination Directory:
    C:\Programme\mozilla.org\SeaMonkey

Program Folder:
    SeaMonkey

The startpage in preferences is about:blank, the homepage www.traki.de

This is the same with my profile with extensions and themes and after removing anything about Mozilla: profile, mozilla.org program directory, mozilla-directory ind the %windir% folder, any registry entries.

Today, the profile manager in latest hourly build was boken, too, I filed a new bug #322116 about it. 

 



A downgrade of the msvcrt.dll (build 8797)to the Win98SE default (8397) did not change anything, crash again.
(In reply to comment #4)
> A downgrade of the msvcrt.dll (build 8797)to the Win98SE default (8397) did not
> change anything, crash again.

I've got Win98 (1st Edition), but a more current msvcrt.dll in Windows\system\
6.10.9844.0 may be the runtime of Visual C++ 6.0  or younger. Build Date is Freitag, 20. Juni 2003 07:00:00.

Nod32 installed 6.00.8397.0 in it's program folder, Build Date 1999

Perhaps you can try to download a younger one?
Bug 276515
Installer quickly and silently crashes on Windows NT 4.0 without version 5.80 or newer of Comctl32.dll

This bug was seen on NT only, and only on installer builds of Firefox. 
Anybody having installed IE5.5 had the necessary updated comctl32.dll, so nobody noticed what was wrong, for a long time. It also prevented installing totally, not only crash at first start and then running smoothly.
Can you try installing a zip build?
It's easy, just download and unzip somewhere, where no directory seamonkey exists. A directory named seamonkey is created, and files and folders in it.
There isn't a separate GRE or such, you don't have to deinstall other browsers.
If you want to get rid of it, simply delete the folder, if you want to hold it,  rename the directory before unzipping the next, or unzip the next one into another directory. 
Make a shortcut to seamonkey.exe, or seamonkey.exe -Profilemanager, if you want to select a profile at start.
Does a zip build crash also at first start?
(In reply to comment #5)

> Perhaps you can try to download a younger one?

After 2 hours of search and control of the version of about 20 downloaded msvcrt.dll files I found a 6.10.8924.0 which allowed installation without crash.
I don't want to set the bug "worksforme" because this is an inofficial file from anywhere in the internet - the official updates from Microsoft have 6.00.8337.0
or 6.00.8737.0 . I think seamonkey should work without special installations of
dll from inofficial sources or Visual Studio or .net. This file is used genererally by Win98 - it is able to stop booting of Win 98 if wrong.
If seamonkey needs a specific msvcrt.dll, it could be included like other programs do.
Assignee: general → nobody
Component: General → Build Config
QA Contact: general → build-config
Do "contrib" builds from the branches (1.0b) work? I think they should include a working msvcrt.dll, but I never could try on such an old system...
(In reply to comment #8)
"Contrib" builds from the 1.8 branch (1.0b)work fine but don't include any mscvrt.dll.
I tried it out restoring my old 6.00.8737.0 msvcrt.dll version first before I installed the seamonkey 1.0b 2005121900 build from ftp.mozilla.org .

Could anyone who still uses Win98 confirm this bug? It is not much work to replace temporarily a newer msvcrt.dll with the Windows default file using sfc. The crash concerns only seamonkey, nothing else will be damaged.  
Well, good to know that it doesn't happen on branch, but I wonder why you used an older branch build... Or is that the official Beta? I may have activated the inclusion of msvctr.dll only shortly after the rrelease, not completely sure...
I've got Win98 (1st Edition), but a more current msvcrt.dll in Windows\system\
6.10.9844.0 and downgraded to Win98SE standard msvcrt.dll 6.00.8397.0 but got no crashes, so WFM.

I had SP1 installed, IE5.5 and MSI 2.0, MSXML4, MSVCP71.DLL and MSVCR71.DLL, so the system isn't a really old system, but I can't downgrade this for testing.

I deinstalled BuildID 2006010108 and installed BuildID 2006010210 and didn't see a profile in profilemanager so I canceled. Started manually my profile last used was loaded after I denied making seamonkey the default browser. I quit, couldn't deinstall from Properties/Software but had to use the link in the seamonkey uninstall folder.
I installed/started/deinstalled Build 20051230 and 20060101 and had no problems.
(In reply to comment #10)
> I may have activated the inclusion of msvctr.dll only shortly after the release, > not completely sure...
I used the latest available official german build, the bete release. The latest branch build (english) 1.0b 2006010202 has no included msvcrt.dll .
(In reply to comment #11) 
> I had SP1 installed
There is no official service pack 1 for Win98. I don't know whether it works due to these inofficial updates or due to the difference Win98 - 98SE or due to the other IE (I have 6 SP1). Here the crash is dependent from the msvcrt.dll version, any elder 6.00 version crashes seamonkey.
> didn't see a profile in profilemanager so I canceled
This is bug #322166 which is not yet fixed. 
Seamonkey 1.5 nightlies, both zips and the current full installer, crash on startup on my Win98SE system. I'm running the 2005-12-13 build now, and first noticed crashes with a build of about 12-23. The crashes occur without Talkback starting. I haven't tested Seamonkey regularly in the past month or so, but just started working with it again to check into another possible problem. Here's the data from my latest crash.

SEAMONKEY caused an invalid page fault in
module MSVCRT.DLL at 0167:78026da9.
Registers:
EAX=0001c200 CS=0167 EIP=78026da9 EFLGS=00010283
EBX=00000000 SS=016f ESP=0065fa1c EBP=0065fa34
ECX=00000029 DS=016f ESI=0001c200 FS=2e7f
EDX=00000046 ES=016f EDI=07861f80 GS=0000
Bytes at CS:EIP:
89 51 14 99 bf 80 51 01 00 f7 ff bf 5c cd 03 78 
Stack dump:
0065fa6c 0065fa50 00000001 78026eb2 0065fa50 000005a0 0065fa48 78027125 0065fa50 0072e658 0085bbe0 0065fa90 78026fa5 0001c200 00000001 60e541ca 

(In reply to comment #13)
> Seamonkey 1.5 nightlies, both zips and the current full installer, crash on
> startup on my Win98SE system. I'm running the 2005-12-13 build now, and first
> noticed crashes with a build of about 12-23. 

Seems you are aeeing this bug, but nightlies of Jan, 2nd and Jan 3rd are havin profile problems, fixed in current tinderbox or next nightly, Jan 4th.

Bug 322116 Seamonkey is unable to load profile and to create properly new profile

> Here's the data from my latest crash.
> 
> SEAMONKEY caused an invalid page fault in
> module MSVCRT.DLL at 0167:78026da9.

Please don't paste windows register reports, nobody knows what's the meaning of it... If you post a Talkback ID, people can have a look at the source code leading to the crash. See http://talkback-public.mozilla.org/talkback/fastfind.jsp

Can you please retry using a current tinderbox built or the next (Jan 4th) nightly? Also, what's the version of your msvcrt.dll? You can use the freeware http://www.sysinternals.com/Utilities/ProcessExplorer.html to seewhat is running on your system.
OK. My MSVCRT.DLL version is 6.00.8797.0.
Which branch? I added the relevant files on 1.8.0 branch just yesterday, 1.8 brnach has them longer already...
Following the suggestions of comment #14, I got tinderbox version Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060103 SeaMonkey/1.5a running, fine so far.
(In reply to comment #17)
John, please tell us the version number of your msvcrt.dll. Go to your ...\Windows\system\ folder, find msvcrt.dll, click right on it, under properties you find a register card "versions" with the version number.
Please see comment #15.
(In reply to comment #17)
> Following the suggestions of comment #14, I got tinderbox version Mozilla/5.0
> (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060103 SeaMonkey/1.5a running,
> fine so far.

Sorry, when making that suggestion I didn't remember that comment #0 mentioned the bug is seen in nightlies only, tinderbox builds are working well. So it would be fine if you could test the comming nightly also.
While a 1-4 tinderbox build worked except for a crash on exiting, the 1-4 nightly I tried (built around 6:30) crashed like previous nightlies.

I also confirmed that nightlies starting with 12-14 are the crashers. The 12-13 build was OK.

My Win98SE has nearly all upgrades installed from local files downloaded several years ago. These perhaps include an upgrade of MSVCRT.DLL from the original included in Win98SE.


(In reply to comment #21)
> While a 1-4 tinderbox build worked except for a crash on exiting, the 1-4
> nightly I tried (built around 6:30) crashed like previous nightlies.
> 
> I also confirmed that nightlies starting with 12-14 are the crashers. The 12-13
> build was OK.

so the installer.exe from here doesn't crash,
http://mozilla.osuosl.org/pub/mozilla.org/seamonkey/nightly/2005-12-13-10-trunk/
and that from the next folder does?
http://mozilla.osuosl.org/pub/mozilla.org/seamonkey/nightly/2005-12-14-10-trunk/

Started 12/13 08:38, finished 12/13 10:42
Started 12/14 08:36, finished 12/14 10:40
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey&hours=24&maxdate=1134561958&legend=0
shows a lot of red..

checkins in the regression window according to comment 21:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-12-13+08%3A00&maxdate=2005-12-14+09%3A00&cvsroot=%2Fcvsroot

The problem I saw isn't with installers. It's with Seamonkey builds starting with 12-14. Most of the several builds I tried were zips. The one installer I tried was OK. But the Seamonkey installed with the installer crashed like the others.

I'd guess that there are bad parameters being sent to a subroutine in msvcrt.dll. Since msvcrt.dll didn't change, what about the VC compiler? Were any updates to Mozilla's compilers put in place just before the crashes? Has anyone tried a Cygwin/Mingw build that worked? If not, there must be a coding error that would show up in those checkins.
What's the difference between the tinderbox and the nightly code? This tinderbox mostly works. The differences in program startup should show where the bad code is.
(In reply to comment #21)
Same here on 2 different Win98SE systems. Official nighlies: With msvcrt.dll 6.00.8737.0 crash. With msvcrt.dll 6.10.8924.0 parts of seamonkey stayed in memory after first start and after installation of the german language file, after removing with the taskmanager normal function.
Absolutely no problems with tinderbox-build.

Could someone set the bug status to "new" ?
(In reply to comment #24)
> What's the difference between the tinderbox and the nightly code? This
> tinderbox mostly works. The differences in program startup should show where
> the bad code is.

This bug is about crash after first start when using installer builds.
It's a bit more complicated because nightlies from Jan 2nd and 3rd were crashing or didn't install because of another bug. Please reread the bug comments in regard of installer builds.

There are two completely different issues:

1. The difference between zip buids and installer builds:

- the zip build unpacks into one new directory with subdirectories, you should take care that it is new, not existing. To deinstall simply delete this directory. The zip build doesn't make entries into windows registry.

- the installer build creates and changes windows registry entries, so it has to be deinstalled. The installer build creates a GRE in another directory.

2. the difference between nightlies and tinderbox builds
tinderbox builds may contain patches which are not in the CVS, 
nightlies I suppose (but don't know) use CVS code.
With Mozilla/Seamonkey it used to be that talkback was packed with the nightly only, as the talkback server must hold a symbol table for each build using talkback. A nightly is used a day or some days, a hourly tinderbox build will be replaced some hours later, who downloads from a tinderbox?
Firefox hourlies do have talkback installed, so you get some hundred symbol tables a month, so they are culled from fortnight to fortnight. 
(In reply to comment #26)
> 2. the difference between nightlies and tinderbox builds
> tinderbox builds may contain patches which are not in the CVS, 
> nightlies I suppose (but don't know) use CVS code.

Wrong assumption. Both are built from the same source tree on the same tinderbox (creature), both from what actually is in CVS and by the same compiler.
Theortetically they should be more or less exactly the same - but...

> With Mozilla/Seamonkey it used to be that talkback was packed with the nightly
> only, as the talkback server must hold a symbol table for each build using
> talkback.

That's actually the only difference I know about - and I'm running some tinderboxen myself...
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #27)
> (In reply to comment #26)
> > 2. the difference between nightlies and tinderbox builds
> > tinderbox builds may contain patches which are not in the CVS, 
> > nightlies I suppose (but don't know) use CVS code.
> 
> Wrong assumption. Both are built from the same source tree on the same
> tinderbox (creature), both from what actually is in CVS and by the same
> compiler.

O.K. now I know. I didn't realize there is a difference between 
'CVS Checkins Checkins to module SeaMonkeyAll'
and
'CVS Checkins Checkins to module MozillaTinderboxAll'
and that nightlies are also built from MozillaTinderboxAll.

The difference can be seen sometimes, if names in the 'Guilty' column of 'Tree Status' don't show up in 'CVS Checkins Today'

I noticed Nightlies and Tinderbox builds are started from different scripts, looking at Bug 305233 pacifica tinderbox builds have wrong buildID.


no, MozillaTinderboxAll is just used for the checkin list on the tinderbox webpage. The actual code used by the builds is the normal code (not limited to SeaMonkeyAll though). tinderbox builds and nightlies should use the same code... nightlies are just specially labeled tinderbox builds these days.
There's got to be some difference in the builds if tinderboxen don't crash and nightlies do. Why would the presence of symbol tables suddenly start causing problems?

The one installer build that I tried was dated about 12-23 as I recall. I deleted it and a 12-19 zip build as they were useless to me as soon as I verified that they wouldn't run.

Yes, I'm aware of the difference between installer and zip builds, and about deleting the entire folder to uninstall zip builds. That's why I like them, as I kept an installer 1.7.12 in service until just recently.

Sounds like differences in the build scripts would be the first place to look. The differences I was thinking about looking for would be right in the binary code, or perhaps in the symbol table that was mentioned, or a cross-reference table that includes symbolic values as well as addresses. They're very handy. A program like diff should be able to compare such files and produce a file of just differences to examine. The crash also occurs with whatever code is done at the start of the program, well before the splash logo is displayed. A program tracer might be helpful too.




re: comment 22 link to checkins---do any of these sound like they might cause crashing?  

>Bug 319917 roaming profiles crashes on startup, no way to disable roaming [@ >nsBinaryOutputStream::Write]

>Set NO_INSTALL as well as NO_DIST_INSTALL

>fixes bug 319068 "problems with older compilers" r=bsmedberg


(In reply to comment #31)
> re: comment 22 link to checkins---do any of these sound like they might cause
> crashing?  

I'm using win98 and don't crash as seen in my comments before, so I can't test.

You wrote in comment #21
>I also confirmed that nightlies starting with 12-14 are the crashers. The 12-13 build was OK.

So I was assuming you are using installer builds, as this bug here is seen
ONLY on installer builds. If you are seeing this on a zip build, you are seeing another bug.

You wrote in comment #23 you are mostly using zip builds, and were using one installer build only, not crashing.

Sorry, the regression range I told in comment #22 was based on my wrong assumption you have specified this range using installer builds.
Could you please retest uisng installer builds, and tell build IDs of a working and a failing build?
If you look into the title bar, you also see the hour of the build, I'm using BuildID: 2006010409 now, downloaded from the 2006-01-04-10-trunk folder.

I can't confirm the regression range as I don't know if you tested INSTALLERs 

did the installer.exe from here not crash at first start?
http://mozilla.osuosl.org/pub/mozilla.org/seamonkey/nightly/2005-12-13-10-trunk/
and that from the next folder does crash at first start?
http://mozilla.osuosl.org/pub/mozilla.org/seamonkey/nightly/2005-12-14-10-trunk/

> >Bug 319917 roaming profiles crashes on startup, no way to disable roaming [@ >nsBinaryOutputStream::Write]
> 
> >Set NO_INSTALL as well as NO_DIST_INSTALL
> 
> >fixes bug 319068 "problems with older compilers" r=bsmedberg
> 


Another reason why I like zip builds is that there's no risk of system files being over-written, or system folders being cluttered with non-system files. That's one of the things I hated about Windows programs. Particularly, if a program is suposed to work with a file msvcrt.dll, it should work with what the original file can do and put any additional functions in proprietary files stored in the program's own folder.

I just retrieved the 12-14 file, am fetching the 12-13 file, and will try to get the results of these posted today. 
Good news for the installer builds. The 12-13, 12-14, and 1-4 builds all work for me. It's a mystery why the zip builds had problems. I think an installer build in December crashed for me too, but I'd have to research that.

Next question: why did the zip builds crash in msvcrt.dll?

Here's some info on the msvcrt.dll versions that might be around. I found them in various locations on my system including a Win95 partition. Only the top 3 are used by the Win98 system and major applications.

6.00.8797.0     278,581 bytes---this is the version in the system directory
6.00.8337.0	266,293
6.00.8397.0	266,293
6.00.8168.0	254,005
5.00.7128	280,576
4.20.6201	267,536
I reverted to msvcrt.dll version 6.00.8337.0, restarted Win98SE, tried Seamonkey and it's working with this older dll. 
More installer build crashes. I was using the 2006-1-4 build with no problems, removed it and installed the 1-5 build, and it crashed. On re-installing the 1-4 version, it crashed on startup.

I'm back to using the 12-13 build.


The 2006-1-8 installer build crashed for me, in msvcrt.dll under Win98SE, with no splash page or talkback appearing. The only visible activity was a permissions request from my firewall, then the crash.

(In reply to comment #37)
> The 2006-1-8 installer build crashed for me, in msvcrt.dll under Win98SE, with
> no splash page or talkback appearing. The only visible activity was a
> permissions request from my firewall, then the crash.

That build is bad for looking for a crash, as it normally hangs on Win9x:
Bug 322764
Win98SE and WinME problem: Can't start trunk FFv1.6a1 or SMv1.5a tinderbox zip or exe builds as of 08 Jan with old or new profile,

Please don't comment which builds are still failing, 
if you don't find something new, 
as they are *not* failing for most other users of Win98, maybe the number of 'most other users' is 1, but I doubt, must be at least 10 ;-)
 
Both the Seamonkey Win32 nightly zip build and installer build for Jan 31 crash for me. I'm posting this with the Feb 1 tinderbox zip build.
Improvement! The nightly installer build of Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060404 SeaMonkey/1.5a installed fine and runs under Win98S after a first-run glitch. It hung on selecting a profile. Also, Seamonkey turns on the keyboard caps light when it starts.
Gecko developers have decided that it's too much work for them to maintain compatibility with any Windows version before Windows 2000 on trunk (i.e. on Gecko 1.9) and yesterday or today the first patches went in that ended supported for those old Windows versions, including Win9x.
This also means that any SeaMonkey versions based off that code can not support older Windows. This affects SeaMonkey 1.5 and later, all of which won't be released to the public before 2007. (SeaMonkey 1.0.x and 1.1 will continue to support even Windows 95, but will be the last versions to do so.)

Note that this is not our (i.e. SeaMonkey devloper's) decision, it is forced upon us by the people creating the framework we are building upon. See more about those recent chenges in bug 330276
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
Then why would the tinderbox builds go on working? I understand they are built from the same code as the nightlies?
John: the removal of pre-Win2k support has been first done in the code at 2006-04-04 13:57 PDT, so the builds of April 4th should probably be the last trunk builds that run on older Windows versions, builds from April 5th may fail badly.

For sure, as long as noone develops a "shim library" (see bug 330276 comment 26) for older Windows versions, noone will care anymore if they do fail on trunk.

Once again, note that the Gecko-1.8-based branches still support Win98, and probably will do so for their whole lifetime (which means that Firefox 2 and SeaMonkey 1.1 also will still run there), only starting from the Gecko-1.9-based releases that support is being dropped (Firefox 3 / SeaMonkey 1.5).
(In reply to comment #43)
> John: the removal of pre-Win2k support has been first done in the code at
> 2006-04-04 13:57 PDT, so the builds of April 4th should probably be the last
> trunk builds that run on older Windows versions, builds from April 5th may fail
> badly.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060404 SeaMonkey/1.5a
is already failing to start reliably, you got to change profiles until it starts (BuildID 2006040411), the profile manager doesn't close.

> For sure, as long as noone develops a "shim library" (see bug 330276 comment
> 26) for older Windows versions, noone will care anymore if they do fail on
> trunk.

I didn't here a single technical reason why it was necessary to break the code, Win9x was working.

> Once again, note that the Gecko-1.8-based branches still support Win98, and
> probably will do so for their whole lifetime (which means that Firefox 2 and
> SeaMonkey 1.1 also will still run there), only starting from the
> Gecko-1.9-based releases that support is being dropped (Firefox 3 / SeaMonkey
> 1.5).

This means Firefox 2 will stay half-fixed as Firefox 1 stays, and Firefox 2 users won't get the improvements made in Download that Biesi planned for 1.9.
> I didn't here a single technical reason why it was necessary to break the code,

win9x doesn't have SetWorldTransform (and probably others). additionally, it doesn't have any of the *W APIs. does that suffice as technical reasons?
I don't know anything about WorldTransform APIs. I do know that Microsoft declared end-of-support for Win98 sometime in 2005, and perhaps considered that people were running it on late-model hardware instead of buying newer versions. I'm not in gravy and can't afford to keep MS in gravy. So perhaps it's time to focus on Linux and test trunk builds there.
You need to log in before you can comment on or make changes to this bug.