Winternight-Classic development (Cancelled)

[BW134]

3.0.x would be a great start rather than getting 3.5 or 3.6. 3.6.x for example lacked support for legacy Java applets.

[Nicholas McAnespy]

13 hours ago, BW134 said:

3.0.x would be a great start rather than getting 3.5 or 3.6. 3.6.x for example lacked support for legacy Java applets.

What is the last version of Firefox to support legacy Java applets? Firefox 3.5.19 will be easier for me to work with than Firefox 3.6.28. As I have mentioned, I have a working Firefox 3.0a7 Windows GFX build, but it doesn't work properly on Windows 98 for a reason I haven't figured out yet.@K4sum1
I have tested every alpha version of Firefox 3.0, and of them, my favourite versions are alpha 2, alpha 4, and alpha 6. I haven't tested Firefox 3.0a5 other than producing a Windows GFX compatible build of it. The more I think about my predicament, the more I realize I may have to build every alpha and beta version of Firefox 3.0 so Windows GFX, and 95 support don't break too much on me. My picture display problems happen between Firefox 3.0a2, and Firefox 3.0a3. Should I fix the picture display problems first, or should I continue on with Firefox 3.0 builds, and then try to fix it? @roytam1  On my GitHub account, I have a build of Firefox 3.0a4 that works with Windows 98, but not 95 (os_win.c in sqlite3 if I remember the file name correctly?), and I'm sure colours don't display properly with it (bug 361154). As a confession, I believe you are in a much better position to support Windows NT4 with it than I am. Do you want me to upload my Windows 95 compatible Firefox 3.0a4 mod, and you can try your hand at Windows NT4 (preferably Windows NT 3.51) compatibility, or do you want to wait for me to get something closer to Firefox 3.0 working with Windows 95 first?

[K4sum1]

What I would do is grab 3.6.28, try to build for 9x, then start fixing issues. Since I suck at coding and debugging, I would bisect to find offending commits and fix or revert them until the browser works. Basically what I did for r3dfox.

I would give it a try, but I have many other projects I'd rather do currently.

[Nicholas McAnespy]

6 hours ago, K4sum1 said:

What I would do is grab 3.6.28, try to build for 9x, then start fixing issues. Since I suck at coding and debugging, I would bisect to find offending commits and fix or revert them until the browser works. Basically what I did for r3dfox.

I would give it a try, but I have many other projects I'd rather do currently.

I do have a build of Firefox 3.0b5 I do work on occasionally. My initial plan was to build Firefox 3.0b5 for Windows GFX toolkit compatibility, then transfer the changes to Firefox 3.0, and optionally 3.0.19. My build from last year crashes on startup, and I think part of my problem is I tried to use old code from the view, widget, and gfx directories, instead of reverting incompatible commits individually. Now I'm redoing the build, but with how long it takes, very slowly. I also suck at programming and debugging. Congratulations on your r3dfox project!

[K4sum1]

Yeah, it's a slow process. When I began, it would take me basically a full day to bisect to fix an issue. Part of that was that I was dumb and issues can be a bit finicky, I had to do it twice the first few times. I recommend when bisecting removing the alpha or beta identifier from the version number as that changes how some things work, and can better expose problems.

[Mathwiz]

On 6/25/2024 at 3:37 AM, Nicholas McAnespy said:

My picture display problems happen between Firefox 3.0a2, and Firefox 3.0a3. Should I fix the picture display problems first, or should I continue on with Firefox 3.0 builds, and then try to fix it?

I would try to find out what specific commit was added between 3.0a2 and 3.0a3 that caused the problem. Either start with 3.0a2 and add commits or start with 3.0a3 and revert them. You don't have to rebuild and retest after every individual commit - you could take a "binary search" approach, adding or reverting a bundle of commits, building, then going backward or forward depending on whether the problem is there or not. You'll probably also have some idea of which commits are less likely to be related to the problem and which are more likely. It would take a lot of patience but eventually you should be able to identify the commit that causes the problem. Then you could revert that problematic commit in a release version and see what other issues you need to deal with. (Ideally you might even be able to rewrite the changed code in the problematic commit to work correctly with Win 98.)

I fear if you try to jump too far ahead, you'll run into so many problems at once, you'll just be overwhelmed and not have any idea where to start making fixes. But if you're patient, you can eventually work your way up to 3.5 or even 3.6.

On 6/24/2024 at 1:52 PM, BW134 said:

3.6.x for example lacked support for legacy Java applets.

You could probably omit the commit that removed that support, once you find it.

[Nicholas McAnespy]

26 minutes ago, Mathwiz said:

I would try to find out what specific commit was added between 3.0a2 and 3.0a3 that caused the problem. Either start with 3.0a2 and add commits or start with 3.0a3 and revert them. You don't have to rebuild and retest after every individual commit - you could take a "binary search" approach, adding or reverting a bundle of commits, building, then going backward or forward depending on whether the problem is there or not. You'll probably also have some idea of which commits are less likely to be related to the problem and which are more likely. It would take a lot of patience but eventually you should be able to identify the commit that causes the problem. Then you could revert that problematic commit in a release version and see what other issues you need to deal with. (Ideally you might even be able to rewrite the changed code in the problematic commit to work correctly with Win 98.)

I fear if you try to jump too far ahead, you'll run into so many problems at once, you'll just be overwhelmed and not have any idea where to start making fixes. But if you're patient, you can eventually work your way up to 3.5 or even 3.6.

You could probably omit the commit that removed that support, once you find it.

1. I don't know how to apply/revert commits (at least well enough to make it worth it), so all the commits I reverted, I did locally and manually by getting the text file, then going through every line of code and reverting the changes. If I could reliably revert bug 177805 using an automated process, then applying all commits afterward on top of it, I would. 2. As far as jumping too far ahead, last year, when I was trying to figure out why a Windows GFX build of Firefox 3.0a6 was not displaying context menus, and why the text in the entire UI was ~1 pixel in size, I eventually found out it was because of bugs 377539, and 377947 if I remember correctly. It took me a build of a May 10th 2007 Firefox 3.0a5 snapshot to be led to a change (bug 377539) in dom/base/src/nsScreen.cpp. Also, my latest (local) Firefox 3.0b5 build has "374 unresolved externals" while trying to link gklayout.dll. Note to self: In Firefox 3.0, define MOZ_ENABLE_CAIRO_GFX in config/autoconf.mk.in, or else #ifdef MOZ_CAIRO_GFX will not work.

[Nicholas McAnespy]

1 minute ago, Nicholas McAnespy said:

1. I don't know how to apply/revert commits (at least well enough to make it worth it), so all the commits I reverted, I did locally and manually by getting the text file, then going through every line of code and reverting the changes. If I could reliably revert bug 177805 using an automated process, then applying all commits afterward on top of it, I would. 2. As far as jumping too far ahead, last year, when I was trying to figure out why a Windows GFX build of Firefox 3.0a6 was not displaying context menus, and why the text in the entire UI was ~1 pixel in size, I eventually found out it was because of bugs 377539, and 377947 if I remember correctly. It took me a build of a May 10th 2007 Firefox 3.0a5 snapshot to be led to a change (bug 377539) in dom/base/src/nsScreen.cpp. Also, my latest (local) Firefox 3.0b5 build has "374 unresolved externals" while trying to link gklayout.dll. Note to self: In Firefox 3.0, define MOZ_ENABLE_CAIRO_GFX in config/autoconf.mk.in, or else #ifdef MOZ_CAIRO_GFX will not work.

Update: Bug 377947 was the rewrite of Mozilla's system font handling. That means I did remember the bug number correctly.

[K4sum1]

3 hours ago, Mathwiz said:

I would try to find out what specific commit was added between 3.0a2 and 3.0a3 that caused the problem. Either start with 3.0a2 and add commits or start with 3.0a3 and revert them.

What I suggest (bisecting) is basically just an automated version of this. You tell git to start a bisect, give it a good and bad commit (the releases), and just build from there, marking good or bad as you go.

3 hours ago, Nicholas McAnespy said:

I don't know how to apply/revert commits (at least well enough to make it worth it), so all the commits I reverted, I did locally and manually by getting the text file, then going through every line of code and reverting the changes.

You're going to need to read up on git. Since this is Firefox, maybe you need the mercurial to git translator as well, but not sure what your source is. If you get a proper git clone, you can then just git revert (--no-edit) (commit) and fix any conflicts that may arise.

[Nicholas McAnespy]

If anybody wants to test my Firefox 3.0a4 mod, here it is: https://codeberg.org/Nicholas_McAnespy/Fx3.0a-VC6-mod/releases/tag/Fx3.0a4-Win95

[Nicholas McAnespy]

On 6/27/2024 at 12:11 AM, Mathwiz said:

I would try to find out what specific commit was added between 3.0a2 and 3.0a3 that caused the problem. Either start with 3.0a2 and add commits or start with 3.0a3 and revert them. You don't have to rebuild and retest after every individual commit - you could take a "binary search" approach, adding or reverting a bundle of commits, building, then going backward or forward depending on whether the problem is there or not. You'll probably also have some idea of which commits are less likely to be related to the problem and which are more likely. It would take a lot of patience but eventually you should be able to identify the commit that causes the problem. Then you could revert that problematic commit in a release version and see what other issues you need to deal with. (Ideally you might even be able to rewrite the changed code in the problematic commit to work correctly with Win 98.)

I fear if you try to jump too far ahead, you'll run into so many problems at once, you'll just be overwhelmed and not have any idea where to start making fixes. But if you're patient, you can eventually work your way up to 3.5 or even 3.6.

You could probably omit the commit that removed that support, once you find it.

I thought I could get away with partially reverting bug 371434 by simply changing nsLayoutUtils::DrawImage(&aRenderingContext, parameter 1, parameter 2, parameter 3) to aRenderingContext.DrawImage(parameter 1, parameter 2, parameter 3). It turns out I needed to fully revert bug 371434 in order to fix the picture rendering problem I have been having. After making the full set of changes to layout/generic/nsImageFrame.cpp (and nsImageFrame.h), pictures now display as intended. https://bugzilla.mozilla.org/show_bug.cgi?id=371434

Edited July 1 by Nicholas McAnespy
Add bugzilla.mozilla URL

[Leokids123]

Why cancel it?