Arctic-Fox for Windows builds

[ClassicNick]

Another goal of mine is to fork Arctic-Fox, and make it Visual C++ 2005/2008, and Windows 2000 compatible. Presently, Arctic-Fox requires Visual C++ 2013, and Windows XP SP2. There exists a Pale Moon 27.x fork by @roytam1
that includes Arctic-Fox commits, that is in the process of becoming Visual C++ 2010/2012 compatible by roytam1 and I.

[ClassicNick]

To go from Visual C++ 2010 to 2008 compatibility, UniquePtr references need to be changed or removed. Auto as a type specifier needs to be replaced, along with move/forwarding semantics. Then support will need to be added for the Windows Vista and Server 2008 SDKs, which I expect will result in some code being deleted.

[roytam1]

even if you want to "downgrade" from 2013 to 2012 requiring lots of effort.

Tried your VC10 tree (imported to https://github.com/roytam1/palemoon27/commits/pm2796-vc2012) and I tried to fix some build issues, but some of them can't be resolved like MOZ_WEBGL doesn't work in some moz.build files.

ended up having a binary but it crash in pkix for unknown reason.

Edited May 2 by roytam1

[roytam1]

regarding crash in pkix, because MOZ_DEFAULT is broken here.

rewrite this part properly and works: https://github.com/roytam1/palemoon27/commit/93e149145d572d7d81f26af312379c6485cc4803

... and more fixes in branch: https://github.com/roytam1/palemoon27/commits/pm2796-vc2012

and now it crash in elsewhere when browsing to PM forum.

Edited May 2 by roytam1

[roytam1]

BTW I can't make VC2012 to stop spitting out CMOVcc even if -arch:IA32 is specified, maybe I really need to use VC2010.

[ClassicNick]

1 hour ago, roytam1 said:

BTW I can't make VC2012 to stop spitting out CMOVcc even if -arch:IA32 is specified, maybe I really need to use VC2010.

As I understand it, CMOVcc is a conditional move instruction set supported on Pentium MMX and newer CPUs with some exceptions. Why do you not want CMOVcc? I don't personally care either way, so I'm just curious why you don't want it.

[roytam1]

14 minutes ago, ClassicNick said:

As I understand it, CMOVcc is a conditional move instruction set supported on Pentium MMX and newer CPUs with some exceptions. Why do you not want CMOVcc? I don't personally care either way, so I'm just curious why you don't want it.

CMOVcc requires Pentium Pro and later (i.e. i686) not Pentium MMX(it has no support to CMOVcc). In i586 world, only Cyrix 6x86MX/MII supports it.

[ClassicNick]

8 minutes ago, roytam1 said:

CMOVcc requires Pentium Pro and later (i.e. i686) not Pentium MMX(it has no support to CMOVcc). In i586 world, only Cyrix 6x86MX/MII supports it.

The first thing I thought of when I read CMOVcc was i686 compatible, lacking that will probably mean i586 CPU support, and if I need an OS target for an i586 CPU, I'll go for Windows 95...

[ClassicNick]

@roytam1
I should admit the reason why I want an Arctic-Fox fork to work with Windows 2000 is because your builds work with Windows XP SP2 and later. That means users will request a browser that works on "Windows XP". Since I don't like the idea of restricting service pack compatibility, if someone wants a browser that works on Windows XP, and they get it from me, they'll get something that works on the original version of Windows XP. Since Windows 2000 and XP require the same versions of Visual C++ to be used (2008 or earlier), I just as well try Windows 2000 support too. If for some reason you are no longer able to publish your browser builds, it would be nice to offer this community something newer than a fork of Pale Moon 26.5.0. Also, Firefox 31+ and Arctic Fox is much faster at compilation than Pale/New Moon 26.5.0, and UXP browsers (for now).

[roytam1]

19 hours ago, roytam1 said:

it crash in elsewhere when browsing to PM forum.

alright fixed. https://github.com/roytam1/palemoon27/commit/4b17002b2d927dc83ff92d8b0bd2005398fb5816

[ClassicNick]

If you get any crashes in freebl, security/nss/lib/freebl/verified/FStar.c is probably the reason why.

[ClassicNick]

3 minutes ago, ClassicNick said:

If you get any crashes in freebl, security/nss/lib/freebl/verified/FStar.c is probably the reason why.

- return (

- (FStar_UInt128_uint128){

- .low = a.low + b.low,

- .high = a.high + b.high + FStar_UInt128_carry(a.low + b.low, b.low) });

+ FStar_UInt128_uint128 c;

+ c.low = a.low + b.low;

+ c.high = a.high + b.high + FStar_UInt128_carry(a.low + b.low, b.low);

+ return c;

 

What may need to be done in this example is change return c to return c.low, c.high.

[roytam1]

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

[ClassicNick]

I'm okay with that for now, although I'm also sitting on a local build of Firefox 38.8.0esr that works on Visual C++ 2010, but is much more reliable than New Moon 27.9.6-20190223. Stable as far as I remember might be a stretch to say, but it does work. Officially, Firefox 35.0.1 is the last one that works properly, although with changing delete operators to MOZ_DELETE, 37.0.2 will work, but without unified sources.