Dactyloidae Browser (Basilisk fork)

[ownedbywuigi]

https://www.webbrowserdirectory.com/bro ... actyloidae

Someone needs to explain to me why we think Dactyloidae was launched in 2018 and is 8 years old...

It’s probably because its upstream (RT1 Serpent) launched in 2018

[webbrowserdirectory]

https://www.webbrowserdirectory.com/bro ... actyloidae

Someone needs to explain to me why we think Dactyloidae was launched in 2018 and is 8 years old...

It’s probably because its upstream (RT1 Serpent) launched in 2018

Yes, that's right. I saw the oldest file in the repo: "gradle/wrapper" which was committed in January 2018 and went with that date. Sorry, I'm not sure how to find when a github repo was forked. If you can tell me the date I'd love to update it. I'll remove "2018" in the mean time!

[ownedbywuigi]

https://www.webbrowserdirectory.com/bro ... actyloidae

Someone needs to explain to me why we think Dactyloidae was launched in 2018 and is 8 years old...

It’s probably because its upstream (RT1 Serpent) launched in 2018

Yes, that's right. I saw the oldest file in the repo: "gradle/wrapper" which was committed in January 2018 and went with that date. Sorry, I'm not sure how to find when a github repo was forked. If you can tell me the date I'd love to update it. I'll remove "2018" in the mean time!

Feb 27th 2026

[walmar]

Just stay tuned.

Don't worry — I'll be there in case something happens.

I will be restoring Australis in this new project, though the old Dactyloidae theme will be an add-on.

Good to know. With well-maintained software, sticking to the same design over many years is nowadays almost a feature in itself.

Will be researching how themes work in the FX add-on store, as they act like extensions for some reason.

Alright, but I have to add that changing the theme is not a high priority for me: a simple default theme would be entirely sufficient for now, until the more urgent issues are resolved.

There's a bunch of stuff you mentioned I will add, but one thing I cannot add is a Widevine Content Decryption Module plugin.

That’s fine by me. I think I’ve occasionally encountered Widevine DRM-protected SoundCloud tracks and news videos in the past — nothing that carries much weight for me. I merely mentioned it to ensure complete transparency regarding what WF56 can do and what Dactyloidae cannot.

A Widevine license sets me back around £3000

Are you sure? Google itself states: A license agreement is required for the use of Widevine products or services. Widevine does not assess any fee for use of its products and services.

and I am a 17y/o student.

This — and not being a disenfranchised EU citizen — seems nowadays to be the fundamental prerequisite for being able to even contemplate such a hopeful web browser project. Just my completely baseless opinion.

I literally cannot afford that, and neither can most organizations (even Pale Moon!)

If I am reading this correctly, the biggest obstacle lies simply in getting Google to respond to a request in the first place. Which comes as no great surprise to me — considering how one receives support whenever problems arise with a Gmail account. But perhaps, indirectly and in the distant future, it might be possible to add basic Widevine support.

[ownedbywuigi]

I love wasting my time lol

Was working on eUXP (No idea if upstream will want this), but turns out Vista compat wasn't that hard lol

https://github.com/Eclipse-Community/eUXP/pull/28

[athenian200]

I love wasting my time lol

Was working on eUXP (No idea if upstream will want this), but turns out Vista compat wasn't that hard lol

https://github.com/Eclipse-Community/eUXP/pull/28

Kind of figured it wouldn't be insanely difficult, just more trouble than it was worth for a very small number of users. LOL. And I think we also weren't too fond of dealing with old-school critical sections instead of SRWLock type functions, but that was fairly minor in comparison.

I'd probably push back on XP support, but this... doesn't look as bad. It ultimately depends on whether we are more concerned with dirtying up the codebase with critical section code, or eUXP getting out of sync with UXP. Ultimately, it's up to MC. I don't imagine many people will care either way on Vista support, if I am being totally honest. The retro Windows community tends to split on XP/7 lines with Vista being considered the "bad one," and XP being just too old to support without pain.

The ugliest part of all this is that native Vista support means no DirectX 11 for those users (at least from what I am seeing), and critical sections come back. Though I seem to recall there was a way to get DirectX 11 working on Vista anyway?

[ownedbywuigi]

The ugliest part of all this is that native Vista support means no DirectX 11 for those users (at least from what I am seeing), and critical sections come back. Though I seem to recall there was a way to get DirectX 11 working on Vista anyway?

I don't recall Vista ever supporting DX11, no?

[athenian200]

I don't recall Vista ever supporting DX11, no?

https://techgage.com/news/installing_di ... ows_vista/

https://www.pcworld.com/article/520649/ ... vista.html

For gamers, a major technology came pre-installed with Windows 7, that of course being DirectX 11. Although once rumored to be a Windows 7 exclusive, that was put to rest shortly after the OS’ launch. Don’t expect to install it on XP, though… this is Vista and 7 only.

There was a platform update to Vista to support it, actually. So on Vista, you may or may not have DirectX11... whereas on 7+ it's guaranteed. That's another reason why Vista is slightly annoying to support. Old Vista was stuck on DirectX 10, newer Vista really felt like beta Windows 7 even down to DirectX 11 support. Used to complain after 7 came out and I had to buy it, that it felt like Microsoft used Vista users for beta testing rather than doing proper beta testing. I had a 64-bit system with hardware just a little too new for XP, so I was stuck with Vista for a while. It worked fine on that hardware, but it needed ReadyBoost and RAM was cramped at 4GB... it really needed 8GB just like 7 and later, IMO.

[ownedbywuigi]

There was a platform update to Vista to support it, actually. So on Vista, you may or may not have DirectX11... whereas on 7+ it's guaranteed. That's another reason why Vista is slightly annoying to support. Old Vista was stuck on DirectX 10, newer Vista really felt like beta Windows 7, to the point that I complained after 7 came out and I had to buy it, that it felt like Microsoft used Vista users for beta testing rather than doing proper beta testing. I had a 64-bit system with hardware just a little too new for XP, so I was stuck with Vista for a while. It worked fine on that hardware, but it needed ReadyBoost and RAM was cramped at 4GB... it really needed 8GB just like 7 and later, IMO.

I had to lock out DX11 to 7+ because of compiler errors, was I accidentally targeting Vista RTM lol

I'd probably push back on XP support, but this... doesn't look as bad. It ultimately depends on whether we are more concerned with dirtying up the codebase with critical section code, or eUXP getting out of sync with UXP. Ultimately, it's up to MC. I don't imagine many people will care either way on Vista support, if I am being totally honest. The retro Windows community tends to split on XP/7 lines with Vista being considered the "bad one," and XP being just too old to support without pain.

I knew all of you would push back on XP but I knew Vista isn't too bad to port from if the app already supports 7, considering as you said, Vista was just beta Win7 API wise, especially later on in it's life. This is also why r3dfox supported Vista without much hassle, compared to XP.

[athenian200]

I had to lock out DX11 to 7+ because of compiler errors, was I accidentally targeting Vista RTM lol

Yeah, the issue is that platform update that added DX11 was kinda late in the Windows Vista lifecycle... most stuff will assume Vista doesn't have it unless you explicitly target Vista SP2, I think. And unfortunately, some stuff doesn't have that level of granularity.

I knew all of you would push back on XP but I knew Vista isn't too bad to port from if the app already supports 7, considering as you said, Vista was just beta Win7 API wise, especially later on in it's life. This is also why r3dfox supported Vista without much hassle, compared to XP.

Yeah, there was as I recall no major structural reason why Vista was off the table, purely lack of demand and a lot of annoying edge cases that had to be handled, like DX10/DX11 depending on service pack, a couple of useful missing APIs that left critical sections in the code, etc.

EDIT: Actually, I looked into this... the reason you can't target DirectX 11 or use SRWLock stuff is solely because the normal Windows SDK doesn't expose them for Vista, even though later Vista has the APIs... you apparently have to target the Windows 7 API and then test the compiled binary on a fully-patched Vista with the platform update to see if you're actually doing anything Vista can't handle. So it's even closer than I thought... you may not even have to do half the stuff you did to support Vista.

So yeah, now we have the shape of it exactly. Vista RTM is kind of a weird, transitional OS that resembles Windows 7 but lacks SRWLock stuff and still uses critical sections, plus it only has DirectX10 and not DirectX11. Vista SP2 with platform update and such is so absurdly close to Windows 7 that it's better to target Windows 7 RTM when trying to compile stuff for it. The platform update for DirectX11 contains most of what should have been Service Pack 3 for Vista, but since it wasn't a true service pack and just a platform update, there's not really anything an SDK could target, leaving Vista stuck in a weird transitional space that makes it hard to develop for.

[ownedbywuigi]

So yeah, now we have the shape of it exactly. Vista RTM is kind of a weird, transitional OS that resembles Windows 7 but lacks SRWLock stuff and still uses critical sections, plus it only has DirectX10 and not DirectX11. Vista SP2 with platform update and such is so absurdly close to Windows 7 that it's better to target Windows 7 RTM when trying to compile stuff for it.

Problem is, targeting 7 SP0 will make the binaries’s minimum subsystem version NT 6.1 to run, meaning I’d either:

A) have to modify the binaries to make the minimum subsystem version NT 6.0 (hacky)
B) make an app that spoofs Vista as NT 6.1 (even more hacky)

[ownedbywuigi]

Also, since eUXP is a direct fork of the Basilisk UXP mirror repo on GitHub, we sync upstream commits every couple of days or so to avoid becoming out of date.

[athenian200]

Problem is, targeting 7 SP0 will make the binaries’s minimum subsystem version NT 6.1 to run, meaning I’d either:

A) have to modify the binaries to make the minimum subsystem version NT 6.0 (hacky)
B) make an app that spoofs Vista as NT 6.1 (even more hacky)

Well, actually the subsystem version is controlled by the linker, not the SDK target.

So you can do...

_WIN32_WINNT=0x0601

To expose Windows 7 APIs in the SDK.

And then link with:

/SUBSYSTEM:WINDOWS,6.00

Basically, you can target the Windows 7 APIs and still link the binaries in such a way that the subsystem version is valid for Vista, if you really want to.

I did tell you this was complex. If you ship it the way you have it, Vista users will be locked out of DirectX 11 even if they have it, and might actually be a worse situation than Vista users were in with binaries that just target Windows 7.

I mean, in the end, I guess you're free to do it the way you're doing it... but doing it that way locks you into supporting old, unpatched Vista and missing out on features that later Vista did support.

EDIT:

vista.jpg

Proof of concept, from a VM. I have Dependency Walker's kernel32.dll exports pulled up in a Vista VM, and also dxdiag displaying DirectX 11. Which proves Vista is not reliably a DX10-only platform, and it may or may not support SRWLock style functions.

Honestly, my opinion here is... it doesn't seem very logical to try and support Vista RTM and SP1, when the platform can be updated to support most of the Windows 7 baseline functionality (DirectX 11 and SRWLock stuff to avoid the old-school critical sections) that is desired anyway. I mean, if that's a goal you have, then doing it your way makes sense for that, but I think that even if we did want to support Vista, this likely isn't the approach we'd take.

And I suppose proper Vista support, like if someone were serious about it... well, that would require detecting what the kernel exports as far as SRWLock functions (falling back to critical sections only if they're not available) and being able to fallback to DirectX 10 only if DirectX 11 isn't available. That would probably be overkill in 2026 when we can probably safely assume anyone on Vista has installed all the updates that make it almost Windows 7 RTM, though.

[ownedbywuigi]

Honestly, my opinion here is... it doesn't seem very logical to try and support Vista RTM and SP1, when the platform can be updated to support most of the Windows 7 baseline functionality (DirectX 11 and SRWLock stuff to avoid the old-school critical sections) that is desired anyway. I mean, if that's a goal you have, then doing it your way makes sense for that, but I think that even if we did want to support Vista, this likely isn't the approach we'd take.

And I suppose proper Vista support, like if someone were serious about it... well, that would require detecting what the kernel exports as far as SRWLock functions (falling back to critical sections only if they're not available) and being able to fallback to DirectX 10 only if DirectX 11 isn't available. That would probably be overkill in 2026 when we can probably safely assume anyone on Vista has installed all the updates that make it almost Windows 7 RTM, though.

I was attempting to support baseline SP2 as I could not get any of the updates after that working even with Legacy Update.

[ownedbywuigi]

after maining dactyloidae 13.1 on macOS (super hack job for me) for like a month or two, I can say it's alright lol

some pages don't render (to be expected), but other then that it Just Works