Arctic-Fox for Windows builds

[roytam1]

  

On 5/4/2024 at 8:24 AM, ClassicNick said:

I'm also sitting on a local build of Firefox 38.8.0esr that works on Visual C++ 2010

it will nice if you can upload the source

On 5/3/2024 at 9:39 PM, roytam1 said:

tried to build with VC2010, it builds, but I can't get it work like official 35.0.1.

alright, building 35.0.1 with VC2010 works.

with VC11, a strncmp CMOV removal patch is needed for running in non-CMOV capable processors. (like what I did to VC12 dll)

BTW, ported NSS 3.42 Beta works.

and even works on a 486:

Edited May 23 by roytam1

[roytam1]

trying to port NSS 3.42 Beta to VC2005, it builds but seems not working.

[Nicholas McAnespy]

1 hour ago, roytam1 said:

trying to port NSS 3.42 Beta to VC2005, it builds but seems not working.

And I tried to port Firefox 3.0.19 to Visual C++ 5.0 SP3 with the Windows Server 2003 R2 SDK, and failed because of browser/app/Makefile.in using wmain, which as is, Visual C++ 5.0 SP3 sees as an unresolved external. I also couldn't figure out how to make Visual C++ 5.0 SP3 accept Mozilla's places implementation, so I tried to use Mozilla's browser/bookmarks, and history code without success because it broke most browser functionality, such as typing URLs. More recently, I'm starting to try porting Mozilla bug 317375 to RetroZilla.

[Nicholas McAnespy]

This will derail the thread, but my Dell Inspiron 600M has a broken EIDE adapter, so I can't boot from an internal hard drive. I can theoretically boot from a USB storage device, but the only success I've had with that is configuring a flash drive to work as a bootable startup disk, and installing Windows 95. The problem with that is none of the hardware drivers work with Windows 95, the oldest OS it will work with is Windows 98 (possibly 98 SE). The default operating systems were Windows 2000 or XP. The computer could also run Windows Vista or 7, but I rather not try to do that. For my use case, the best operating system to use is Windows 2000, with XP being a close 2nd. My task presently is getting either Windows 2000 or XP booting from a USB storage device.

[roytam1]

23 hours ago, roytam1 said:

trying to port NSS 3.42 Beta to VC2005, it builds but seems not working.

with more fixes, it works. after porting/restoring something for RNG, it even works in Neptune!

[Nicholas McAnespy]

@roytam1 Would it be possible for you to create a New/Pale Moon 27.10.0 branch on your GitHub repository (2021-02-26 I believe), and then transfer our pm2796-vc2012 changes to that branch?

Edited July 4 by Nicholas McAnespy

[roytam1]

24 minutes ago, Nicholas McAnespy said:

@roytam1 Would it be possible for you to create a New/Pale Moon 27.10.0 branch on your GitHub repository (2021-02-26 I believe), and then transfer our pm2796-vc2012 changes to that branch?

this is still a tall order. BTW I'm almost complete putting all pm2796 changes on top of fx38vc10, but still some way to go.

[Nicholas McAnespy]

3 hours ago, roytam1 said:

this is still a tall order. BTW I'm almost complete putting all pm2796 changes on top of fx38vc10, but still some way to go.

As I understand it, if my order is a tall order, it means I gave you a difficult or impossible task. If so, is it difficult because GitHub won't allow you to force merge commits/pull requests ("conflicting files/commits"), or because our Visual C++ 2010/2012 compatibility changes relevant to New Moon 27.9.6 2019-02-23 will still fall short of proper Visual C++ 2010/2012 compatibility in a New Moon 27.10.0 2021-02-26 build? I ask because I fear the first scenario much more than I do the 2nd one. That's why I can't rely on Codeberg to help me with my Firefox 3.0 Windows GFX/Windows 95 mods, so I have to apply all the changes manually.

[roytam1]

1 hour ago, Nicholas McAnespy said:

As I understand it, if my order is a tall order, it means I gave you a difficult or impossible task. If so, is it difficult because GitHub won't allow you to force merge commits/pull requests ("conflicting files/commits"), or because our Visual C++ 2010/2012 compatibility changes relevant to New Moon 27.9.6 2019-02-23 will still fall short of proper Visual C++ 2010/2012 compatibility in a New Moon 27.10.0 2021-02-26 build? I ask because I fear the first scenario much more than I do the 2nd one. That's why I can't rely on Codeberg to help me with my Firefox 3.0 Windows GFX/Windows 95 mods, so I have to apply all the changes manually.

even using git's merging function, for merging some already-accumulated commits you still have to merge only 2 or 3 commits a time to make you possible to trace commit differences.

you can't just merge the last commit because those commits changes everything and you can't handle and fix them properly.

thats why I can't finish last ~50 commits in short time for PM2796-vc10.

Edited July 5 by roytam1

[roytam1]

finally got a working PM2796-vc10 (and also bring back webrtc, webgl, and mediasource): https://github.com/roytam1/palemoon27/commit/5d5e647b63c1b729e937a1bdd70a4fc18bff6d90

binary for testing: http://o.rthost.win/gpc/files1.rt/palemoon-27.9.6.win32.vc10.7z

 

and still working with my kernelxp wrapper on XP RTM:

Edited July 6 by roytam1

[Nicholas McAnespy]

41 minutes ago, roytam1 said:

finally got a working PM2796-vc10 (and also bring back webrtc, webgl, and mediasource): https://github.com/roytam1/palemoon27/commit/5d5e647b63c1b729e937a1bdd70a4fc18bff6d90

binary for testing: http://o.rthost.win/gpc/files1.rt/palemoon-27.9.6.win32.vc10.7z

I will admit that I finally tested our New Moon 27.9.6 build from May 24th 2024, and I got 1 crash in XUL.DLL during my ~1 hour of testing. I hope me requesting the changes from pm2796-vc2012 be ported to a pm27100-vc2010-WIP branch (2021-02-26) is not too much to ask... Also, I think I finally produced a working build of Firefox 33.1.1 without UniquePtr references in the source code. However, I messed around in the js directory because I got errors when switching to Visual C++ 2008 "no rule to make target js-config.h", so I'll soon try a Firefox 35.0.1 build without UniquePtr references. Congratulations with your Firefox 38 and New Moon 27.9.6 builds!

[roytam1]

22 hours ago, Nicholas McAnespy said:

I hope me requesting the changes from pm2796-vc2012 be ported to a pm27100-vc2010-WIP branch (2021-02-26) is not too much to ask...

so you want a 27.10.0 "point-release" that works on VC2010, which are ~330 already-accumulated commits yet to be merged. I can only do this on my extra free time and doing it in my usual "merging 2-3 revs a time" pace. Thus there is no ETA when it is done, but I hope I can make it happen "later".

Edited July 7 by roytam1

[Nicholas McAnespy]

2 hours ago, roytam1 said:

so you want a 27.10.0 "point-release" that works on VC2010, which are ~330 already-accumulated commits yet to be merged. I can only do this on my extra free time and doing it in my usual "merging 2-3 revs a time" pace. Thus there is no ETA when it is done, but I hope I can make it happen "later".

If you're worried about too many breaking changes between February 2019, and February 2021, then let's split it down the middle. Create a public PM2797-VC2010-WIP 2020-02-XX branch, then merge our existing changes from pm2796-VC2012 if GitHub allows that. Then, I can have fun making the newer build work with Visual C++ 2010 without applying all the previous changes manually. Confession: I struggle with keeping priorities straight, so I don't know if I should try Visual C++ 2008 compatibility first, or make the newer Arctic-Fox/New Moon builds compile with Visual C++ 2010 first.

[roytam1]

5 hours ago, Nicholas McAnespy said:

too many breaking changes

it is always breaking in every merge, and you have to deal with them(fix, test build and test run) before running `git merge --continue` and try a next merge.

Edited July 7 by roytam1

[Nicholas McAnespy]

3 hours ago, roytam1 said:

it is always breaking in every merge, and you have to deal with them(fix, test build and test run) before running `git merge --continue` and try a next merge.

I know that doing work of that nature properly can take a long time, so I hope there is still enough time have a special New Moon 27.10.0.9794 (should probably have a 27.11.0 version number, and at that time, specifically 27.11.0.9794) build that is based on Arctic-Fox 41 (which is effectively based on Firefox/Gecko 45/46) that works with Visual C++ 2010, and Windows XP if you can use your kernel wrapper for it. I say this because having a Gecko 45 compatible New Moon 27.10.0.9794 build running on Windows XP (RTM if I must specify it this way) on the 25th anniversary of it's retail launch (October 25th 2026) is very interesting if not amusing to me. Also, since I'm using Windows XP SP3 right now, I can't test whether pm2796-vc2012 compiles using Visual C++ 2013 still. If it does, and if the changes are breaking the builds in every merge, is that because the later Arctic-Fox commits have Visual C++ 2010/2012 incompatible code, but will work fine using Visual C++ 2013, or is it because our Visual C++ 2010/2012 compatibility changes interfere with changes already present in the newer branches, meaning if Visual C++ 2013 still works with pm2796-vc2012, it will no longer work with a pm2797-vc2010-WIP, or pm27100-vc2010-WIP branch due to the breaking changes?