Dactyloidae Browser (Basilisk fork)

[Mæstro]

I'm assuming that an advantage of forking from that project is that you can support some ancient OS's. But probably the disadvantage is that you won't be able to support some modern OS's. You may have to decide which timeline you want to plant your flag in, and whichever one you choose you could be stuck there for the long run.

Has Windows 11 really diverged enough from XP for that? React OS’s developers are surely quite familiar with this.

[andyprough]

Has Windows 11 really diverged enough from XP for that? React OS’s developers are surely quite familiar with this.

I would assume so, just based on the fact that Pale Moon itself cannot support both Windows XP and Windows 11, and I suspect Pale Moon cannot support both Windows XP and the latest GNU/Linux distros or BSD offerings.

[ownedbywuigi]

I'm assuming that an advantage of forking from that project is that you can support some ancient OS's. But probably the disadvantage is that you won't be able to support some modern OS's. You may have to decide which timeline you want to plant your flag in, and whichever one you choose you could be stuck there for the long run.

Has Windows 11 really diverged enough from XP for that? React OS’s developers are surely quite familiar with this.

Serpent and New Moon (RT1) both technically work on 11 but the themes are buggy. It’s only when you step outside of Windows that you realise that they don’t really support non-Windows.

[athenian200]

Yet another reason why I shouldn't have forked off roytam1. Cannot get past this, no matter what I do.

It's looking like their patched version of NSS is completely busted on non-Windows. Also, I would assume on Unix it would try to compile nsinstall.c rather than use the Python version? Everything looks just a little wrong there...

Yeah, that is one question I never thought anyone would ever ask... what happens if you try to compile roytam1's fork on NetBSD? Probably he didn't think anyone would try that either.

Hmm... take a look at this commit roytam1 reverted.

https://repo.dactyloidae.xyz/Dactyloida ... 2aedc710b9

Also check who the author was on it.

Not that I am sure it would fix anything... but I'm suspecting he reverted (or never took) a lot of random commits that fixed the build system on non-Windows because he had no idea what they do, and maybe they caused some minor issue because he was missing other patches. And I honestly have no idea what version of NSS is in there... hopefully newer than I am thinking.

[ownedbywuigi]

Yet another reason why I shouldn't have forked off roytam1. Cannot get past this, no matter what I do.

It's looking like their patched version of NSS is completely busted on non-Windows. Also, I would assume on Unix it would try to compile nsinstall.c rather than use the Python version? Everything looks just a little wrong there...

Yeah, that is one question I never thought anyone would ever ask... what happens if you try to compile roytam1's fork on NetBSD? Probably he didn't think anyone would try that either.

Hmm... take a look at this commit roytam1 reverted.

https://repo.dactyloidae.xyz/Dactyloida ... 2aedc710b9

Also check who the author was on it.

Not that I am sure it would fix anything... but I'm suspecting he reverted (or never took) a lot of random commits that fixed the build system on non-Windows because he had no idea what they do, and maybe they caused some minor issue because he was missing other patches. And I honestly have no idea what version of NSS is in there... hopefully newer than I am thinking.

I tried forcing NetBSD to use the python NSS thing because nsinstall wouldn’t work as is (as in the arguments and stuff were borked), and clearly that didn’t do anything. Will try and revert this revert commit

[Basilisk-Dev]

Not that I am sure it would fix anything... but I'm suspecting he reverted (or never took) a lot of random commits that fixed the build system on non-Windows because he had no idea what they do, and maybe they caused some minor issue because he was missing other patches. And I honestly have no idea what version of NSS is in there... hopefully newer than I am thinking.

It seems like he skipped anything that modified the build system in any way outside of very minimal fixes. For example, he skipped the autoconf 2.13 removal that was mentioned earlier in this thread.

[Moonchild]

And I honestly have no idea what version of NSS is in there... hopefully newer than I am thinking.

Code: Select all

#define NSS_VERSION "3.48.6"

It's ancient.

[Basilisk-Dev]

Code: Select all

#define NSS_VERSION "3.48.6"

It's ancient.

LOL wow.

@ownedbywuigi you should really consider porting your changes to a fork of our tree instead. It'll be a pain to get everything copied over, but I think you are screwing yourself over by continuing to base your fork on Roytam's.

[athenian200]

Yeah, I think the real dealbreaker for anyone using roytam1's tree for anything besides XP is probably going to be realizing how out of date NSS is in there. Like, I can't really fault them for not testing non-Windows... that's not the purpose of the fork, and expecting roytam1 to take time to document that fact and remove all the other operating systems would be unreasonable. I'm not even on their side and I wouldn't be that harsh or petty. But... well, that NSS version is probably the number 1 red flag here. Honestly, I think the reason he can get away with it is simply because anyone running XP today probably doesn't need or want security updates. And more generally, people on the MSFN forums don't believe in security updates even if they run newer versions of Windows, so they don't mind running his fork on Windows 11 to show solidarity with XP users (or to spite us, not sure which it is). But yeah... most people on modern Windows or another OS have no reason to use this version of the codebase.

[ownedbywuigi]

And I honestly have no idea what version of NSS is in there... hopefully newer than I am thinking.

Code: Select all

#define NSS_VERSION "3.48.6"

It's ancient.

Code: Select all

#define NSS_VERSION "3.48.6"

It's ancient.

LOL wow.

@ownedbywuigi you should really consider porting your changes to a fork of our tree instead. It'll be a pain to get everything copied over, but I think you are screwing yourself over by continuing to base your fork on Roytam's.

Yeah, I think the real dealbreaker for anyone using roytam1's tree for anything besides XP is probably going to be realizing how out of date NSS is in there. Like, I can't really fault them for not testing non-Windows... that's not the purpose of the fork, and expecting roytam1 to take time to document that fact and remove all the other operating systems would be unreasonable. I'm not even on their side and I wouldn't be that harsh or petty. But... well, that NSS version is probably the number 1 red flag here. Honestly, I think the reason he can get away with it is simply because anyone running XP today probably doesn't need or want security updates. And more generally, people on the MSFN forums don't believe in security updates even if they run newer versions of Windows, so they don't mind running his fork on Windows 11 to show solidarity with XP users (or to spite us, not sure which it is). But yeah... most people on modern Windows or another OS have no reason to use this version of the codebase.

Oh no.

Honestly, I'm just scrapping the current iteration of Dactyloidae and re-basing on stock UXP starting tomorrow.

I want to support both XP and new Windows, but with how roytam1 handles his fork, I don't think that will be possible.

Stay tuned.

[ownedbywuigi]

First of all, I need a better name. Please drop suggestions.

[Moonchild]

First of all, I need a better name. Please drop suggestions.

Previously the suggestion "Kirin" was dropped. I kind of like that.

[ownedbywuigi]

https://repo.palemoon.org/wuggy/Kirin

Done.

[athenian200]

I want to support both XP and new Windows, but with how roytam1 handles his fork, I don't think that will be possible.

Yeah... you may actually have to keep two versions of the tree if you want to do XP. One for Windows XP (and earlier if you go that route), based on roytam's work... and another for everything else, based on ours. We use a lot of newer libraries and such that are known not to work on XP. In fact, them continuing to use that old version of NSS may well have been partly because newer versions can't be made to work on XP or earlier easily.

It's just... NT5 is too old. We can still support Windows 7 and later for now because later Windows versions are not too different under the hood, and we haven't seen a lot of newer versions of libraries we use refuse to work on 7 so far.

Let's put it this way. Hypothetically if I wanted to release a version of Epyrus for Windows XP (and I don't)... I'd just build against roytam's fork for that one version and keep using real UXP for everything else. Granted, I wouldn't do that because I feel like supporting XP requires compromises I am not comfortable with, but that is what I think would be needed. I'd probably also include a nag screen reminding them exactly what version of NSS is in use, what the latest version is, describe in detail all the compromises made to support XP in the worst possible light, and beg them to use a newer version of Windows, LOL. Or least a quick "This software has several known vulnerabilities. Use with caution." written in red text, maybe flashing a bit that the user would have to click away.

The roytam1 version might be a good foundation if you're wanting to do something like you were thinking earlier... like take it back further, make it compile on Windows 2000... then NT4, then maybe NT3.5 (for the cool Windows 3.x look), etc. But that's really all it would be good for, and really a thing like that is more something that should be done to show you can do it because it's cool, not something people should be relying on as a daily driver.

[ownedbywuigi]

I want to support both XP and new Windows, but with how roytam1 handles his fork, I don't think that will be possible.

It's just... NT5 is too old. We can still support Windows 7 and later for now because later Windows versions are not too different under the hood, and we haven't seen a lot of newer versions of libraries we use refuse to work on 7 so far.

Vista support at the very least shouldn't be too hard, 7 and Vista (fully updated) are similar API-wise

[ownedbywuigi]

lol mozbuild really hates me, it think i have msvc2022 enterprise and not community, aaaa

Kirin 13.3a1 coming soon, Dactyloidae 13.2 will still be in development until it is finished

[Moonchild]

Vista support at the very least shouldn't be too hard, 7 and Vista (fully updated) are similar API-wise

I'd recommend you stick with 7 as a minimum. Vista is in a half-way state and never got fixed because its kernel just isn't in a sane place for NT6+ compatibility, and it's simply setting yourself up for some subtle and some less-than-subtle traps. UXP on NT6.0 requires several nasty hacks to even be stable enough for daily use, and even with those there are issues that can't readily be solved. Just save yourself the pain; you'd be going out on a limb for literally a handful of users and no more. It's just not worth the compromise required.

[athenian200]

Vista support at the very least shouldn't be too hard, 7 and Vista (fully updated) are similar API-wise

I mean, technically I'm sure it could be made to work. If I'm not mistaken, I think some people already figured out how to run our binaries on Vista, using tricks that are apparently fairly standard for people trying to run Windows 7 stuff on Vista. It basically boils down to this:

1. Vista was not very popular or well-liked.
2. Most who do use Vista know how to get Windows 7 software running on it through hacks (back in the day, I managed to run some Windows XP software on Windows 98 using KernelEx, and Vista->7 is way less of a difference).
3. It's been standard industry practice to drop support for XP and Vista at the same time for most other software packages, and sticking with that makes things easier.

But yeah... I would say in an alternate universe where Vista was a very popular OS and we had a bunch of angry users clamoring for Vista support instead of Windows XP support... there's a bigger chance we would have grudgingly come to a compromise and found a way to give them what they wanted. XP was a no-go... Vista just wasn't pursued because it was an inconvenient place to draw a line, and there was basically no one asking for it.

My advice: Just build Windows 7 binaries and let Vista users figure out how to run it. Anyone still using Vista in 2026 probably knows the drill by now and has found a way to run newer Windows binaries.

[ownedbywuigi]

I got it compiled, still for the most part compiles as Basilisk, got to figure that out soon.

[ownedbywuigi]

I need some feedback.

Do you want the old Dactyloidae theme back by default, or have it as a separate add-on?