dblohm7

There are some pretty decent guides for VxD programming still floating around on the web that give a pretty good overview of how VMM32 worked.

You're splitting hairs, here, but fine: I'm referring to browser engines.

I don't think it's a good idea in general to install things that utilize unsupported functionality on other people's computers.

Chrome's font rendering is the outlier among browsers. The author of the article is seeing that difference and they want Firefox to look like Chrome.

I think the commentary is taking an issue with the suggestion that there's something "wrong" with Firefox's font rendering, when it's really Chrome who is the outlier.

The fully-capable version is regular uBlock Origin.

Optimizing for benchmarks tends to not work all that well for real-world sites. I wouldn't worry about it.

The problem with this IMHO is that most users who are trying to do this do not understand a couple of things:

* The NT kernel does not overcommit; and

* As a closed-source OS, client and server editions of Windows do not use build configurations targeting embedded systems; they essentially require ample swap space. They won't run well if users attempt to forcibly minimize or disable their page file.

> "Gamers" can be like audiophiles in the way the spread half-truths and even outright misinformation

If I had a dime for every time people were being told to manually manage their Windows page file "for performance"...

The closest thing right now is to pay for one of the products. Pocket Premium, Firefox Relay, Mozilla VPN.

> on behalf of the customer

Not on behalf of the website.

That’s indicative of poor bindings for those other languages.

The nice thing about COM is that it provides a well-defined, C-based ABI for calling object-oriented interfaces; if your language has a FFI that supports C, then you can call COM objects.

I’m a big believer that COM bindings for any language with automatic memory management should not expose refcounts directly to the programmer (at least in 90% of cases). It’s not far fetched — the original, pre-.NET Visual Basic did a very good job of this.

Apollo 8 is not a very good example; it's not like the hardware pipeline wasn't well on its way to be ready to go by the time the decision was made.

Don't get me wrong, Apollo 8 was an extremely risky and critical part of the program, but it's not like somebody conjured everything up from thin air in 134 days.

(I worked on Firefox for 9 years)

> Why is libxul a shared library?

A lot of this is historical and is now very difficult to change without negatively impacting users.

> It is not used by a bunch of other applications besides Firefox so there isn’t much saving from being shared.

In the 2000s it was designed to do so, via XULRunner. You're also forgetting about Thunderbird and SeaMonkey (though I don't think that either of those can actually share libxul.so with Firefox anymore, but I digress).

But as to why it is the case now, there are still compatibility considerations that fall out from the era when Gecko+XUL were written as a runtime environment for hosting applications.

For example, I recall that during the Electrolysis project, we wanted to get rid of the plugin-container executable on MacOS and just host all Firefox child processes using firefox. Some "security" software would break Firefox because it made certain assumptions about the way that various Firefox binaries interacted with each other.

FWIW, Gecko used to consist of a lot more separate libraries, but over the years we recognized that there were a lot of performance issues that we could mitigate by combining them, so most shared libraries were folded into libxul.

+1 - they're probably using the wrong compiler flags.

You beat me to it: "Liar! There's no Chicken Cannon on the $5 note!" (there should be, though)

x86 was not the original target processor for NT in the earlier stages of its development. This was intentionally done to ensure that x86-isms didn't weasel their way into the OS and harm portability.

Yeah, no. To this day Firefox developers building Gecko need a beefy desktop machine to be able to do it in a reasonable amount of time. I could do a clean build in 6 minutes with a ThreadRipper whose cores were all pegged, but forget doing the same in under an hour on a laptop.

And that was with unified builds enabled.

> I imagine Mozilla's thinking there was that they should position the feature so that people who already use Pocket will realize that Firefox isn't adding a separate reading list (like the Safari one nobody uses), but rather that you can just sign into your existing Pocket account in Firefox, and see your existing Pocket reading-list.

That was pretty much how it was viewed at the time (I worked at Mozilla during the Pocket acquisition). It was seen as, "we were going to build our own reading list, but let's just buy this instead and integrate it as /the/ reading list for Firefox."

I agree that the external perception was different, and remains so to this day.

> Meanwhile they have had consistently growing revenues and consistently declining number of developers.

Citation needed? And no, the 2020 layoffs don't count: It's 2023.

> Beats wasting time on an a commodity VPN service.

That service is what earns them non-Google revenue.

That's basically been the tone of every bit of Mozilla commentary for the past decade.

Yes! A lot of people don't realize that Windows compatibility is not just about binary compatibility, but source compatibility.

See also: SlySoft AnyDVD

The major Servo components that made it into Gecko were the style subsystem (Stylo) and WebRender.

Most arewe...yet sites are Mozilla sites. It's useful for Mozillians or other interested parties to be able to access a centralized list of all of them.

That is waaaay out of date on the Desktop front.

Over the past decade there has been a lot of half-baked Windows stuff that made it into production before needing a rethink.

/me glares at "per-monitor v2" API awareness. I hate spreading rumours, but the one I heard about this was that nobody within Microsoft itself had tried converting any of their first-party GUI apps to per-monitor DPI. Once they started to do so, they finally realized how bad their offering was and came up with v2.

You're fixating on very necessary changes to the addon ecosystem and selectively ignoring the huge underlying changes to Gecko that were made possible by doing so.

> We can still debate as to why they have been in a death spiral for the last 10 years, and part of it was that they did pretty much everything to avoid making a better browser that could have actually been a competitor to Chrome.

You clearly haven't been paying attention at all. Quantum 57 shipped in 2017 and was a huge investment.

Today's market share situation is mostly about the growth of mobile.