Leaderboard

I actually had an "extended discussion" with Moonchild some time back and attempted to point out just how illogical his position was in regard to older OS'es. It of course fell on deaf ears and he ended the discussion without even attempting to answer any of my points. I tried to get across to him just how irrational it was to be committed to preserving an older "browser interface/UI" while at the same time being determined to discard support for any older operating system as soon as possible. With one hand he pushes the "latest and greatest" and insists people should "upgrade" and not use "outdated" operating systems; and with the other hand he promotes an "outdated" browser interface now built on "outdated" code and now using "outdated" addons (in the eyes of the same people who push similar "latest and greatest" rubbish), purposely breaking the already existing support for older systems that was already in place. How one can contort themselves into such a strange position and consider themselves as having a reasonable standpoint on the issue is beyond me. When PaleMoon eventually starts bleeding off its users who subscribe to the flawed logic of "latest and greatest"; or when those remaining are left without options for addon/plugin compatibility and compatibility with the "modern" web, then I've got a feeling those of us here will have the last laugh, and can tell Moonchild and company "Welcome to the party, pal!"

Good grief. Hyperbole much? An anti-vaxxer? Because, I guess, "everyone knows" computer viruses are still written and tested to target the 3% or so of Windows users still running XP, and "everyone knows" none of those users ever update their AV software What an ignorant statement. That quote wasn't from Matt Tobin, by any chance?

They can do whatever they want, and so do I. It is a smorgasbord and I'll pick whatever I want to my dish.

A 3 and 1½ year old binary respectively. I'd recommend a more up-to-date binary.

MC's post is a lot less hostile than Tobin's, and it sort of makes sense: if you're going to develop add-ons for PM, you need to test your add-ons with the "stock" PM build, because that's the version 99% of PM users will use your add-on with. And that, of course, means testing on a Win 7+ system, so that "stock" PM will run on it. It doesn't mean you have to prefer the stock build - only that you have to test with it. It's Tobin who seems to blow a gasket anytime he sees the letters "XP" together. Chill out, man! Whatever your feelings about XP, and however justified you believe them to be, it's not worth having a heart attack over. Let other folks make other choices for their own reasons. Freedom! As for MC's sig, I sort of sympathize; I often find myself rewriting some program that was cloned from another program, and in the rush to get it running, a lot of unneeded code from the "original" source code was left in. Or the programmer used a generic structure better suited to a much more complex program than the one she actually wrote. Either way, you can make the program much easier to read, understand, and debug by removing all that extra code. Where MC takes his sig too far is when he decides to remove functionality just for the sake of removing code, as in his recent decision to remove working WE APIs from Basilisk. Sure, that too can make your program easier to read, understand, and debug; but it also makes your program less useful!

All A while ago I discovered that Amazon Prime Video stopped working on Windows XP. Attempting to open it in Google Chrome or Mozilla Firefox fails with "Unsupported Operating System." Additionally, spoofing the browser as Firefox 53 or newer on XP will then tell you that Firefox is missing a DRM component. However, today I discovered that Amazon Prime Video works perfectly in SeaMonkey on Windows XP. Using SeaMonkey forces Amazon to use Silverlight, and it works flawlessly! This is very surprising to me since Silverlight has been mostly deprecated across the web. I'm surprised Amazon Prime Video is compatible with it. To download Silverlight 5.1.50907 (the final release), you can download it from my FTP here: http://sdfox7.com/xp/sp3/EOL/Silverlight5.1.50907.exe To download Sea Monkey 2.49.4, you can download the full version on my FTP here: http://sdfox7.com/xp/sp3/EOL/SeaMonkey Setup 2.49.4.exe

Maybe here? https://web.archive.org/web/20170826223448/http://www.msfn.org/board/topic/175486-wpa2-for-windows-9x/

A person can probably find common ground with any other person on at least something. Sure, no problem.

I had the same problem before. Analyzing with Bootvis, there's driver delay related to *smb*, so I deleted all desktop link to remote directories (like \\host\folder\), it gets quicker, but not enough until I totally changed "workstation" service to "manual" ("computer browser" and "tcp/ip Netbios helper" have already changed to "manual" before). That reduces boot time to 30s or so, and no stuck after showing the desktop anymore. The side effect is, if you need to visit remote folders afterwards, you should run "workstation" service manually.

That's hilarious.

18 Wheels of Steel - Extreme trucker

It's this kind of ridiculous nonsense that, in part, has caused the situation where we only have ond or two mainstream options when it comes to browsers. If he'd be a bit more open minded and do what some other developers have done ("we don't support XP or Vista anymore; our software may still work, but it's untested, so try it at your own risk, and don't expect us to help you if anything goes wrong") PM could've been much more open. Instead, his attitude is, "I refuse to let my software run on anything not supported by MS, and anyone trying to do so is banned from any discussion". What an excellent way to push users away! c

Unfortunately Skia support doesn't work good in this last version. Before I used gfx.content.azure.backends = direct2d1.1,skia,cairo and all was alrght, but now it leads to wrong Palemoon interface. If you use direct2d1.1,skia,cairo = direct2d1.1,cairo (default), it is OK, but fonts are pale and thin (compared vs direct2d1.1,skia,cairo). Correct it, please. Thanks.

All extensions working well for me on Win 7 and XP in the latest build. Thanks again to Roy for reverting the unnecessary changes. As I said earlier in the thread these versions of basilisk are what Firefox 52.9 should have been.

Updated my server-side file to allow the unofficial installer to install the latest NM and BK builds. PLEASE NOTE: I fixed a bug with the old installer. Please download the new installer, as upgrades were broken in the old one. The latest installer is always available here: http://i430vx.strangled.net/files/XP/RoyTam Browser Installer.exe As always -- Please let me know of any bugs you find with my installer!

New build of basilisk/UXP for XP! Test binary: Win32 https://o.rths.cf/basilisk/basilisk52-g4.1.win32-git-20190216-77e1b07f3-xpmod.7z Win64 https://o.rths.cf/basilisk/basilisk52-g4.1.win64-git-20190216-77e1b07f3-xpmod.7z diff: https://o.rths.cf/basilisk/UXP-xp-gitdiff-20181110.7z PM28XP build: Win32 https://o.rths.cf/palemoon/palemoon-28.4.0a1.win32-git-20190216-77e1b07f3-xpmod.7z Win64 https://o.rths.cf/palemoon/palemoon-28.4.0a1.win64-git-20190216-77e1b07f3-xpmod.7z Official repo changes since my last build: - Expose TLS 1.3 cipher suite prefs. (8beab28bf) - Allow empty string on `location.search` setter. (487afe9f4) - Add "check for updates" to main menu and AppMenu v2 (dd418226c) - Restore app.update.url.override preference. (71c81eb90) - Remove webextensions conditional code from Basilisk. (6bb02d95f) - Remove WebExtension support from the platform. (43d44975b) - Remove the WebExtension Add-on Manager from our tree. (1e0da1994) - Move "No proxy for" control down to clarify it is a global effect. (8e0fdf931) - Fix line endings (0e80d10f4) - Implement origin-clean algorithm for ImageBitmap. (91799767e) - Use C++11 thread-safe statics with MSVC. (f595579f0) - Disable "helpful" MSVC warning about AVX instructions. (9a090b794) - Bump goanna version for updated canvas handling. (4ec8be4ae) - Use C++11 thread-safe statics with MSVC. (js) (71d32272e) - Update browse URL for AM search to Phoebus 2.0 (0d88098e3) - Port several Skia upstream fixes. (a6ddde909) - Preserve transparency when copying a DIB to/from the clipboard. (77e1b07f3) My changes since my last build: - nspr: update nspr to hg rev 753fe0f7964c - nss: update nss to hg rev 395a93dbc02e with vc2013 patch applied - reverted following changes: - Remove webextensions conditional code from Basilisk. (6bb02d95f) - Remove WebExtension support from the platform. (43d44975b) - Remove the WebExtension Add-on Manager from our tree. (1e0da1994) - Use C++11 thread-safe statics with MSVC. (f595579f0) - Use C++11 thread-safe statics with MSVC. (js) (71d32272e)

That sort of sounds like what Google is saying about the API that uBO uses. Of course, restricting that API happens to benefit Google financially, so there's reason to distrust Google on that. But I can't see how removing WE APIs would benefit the PM team. So I have to take MC at his word that he at least believes that. Which makes me wonder: does he have a point? Could a malicious WE add-on do more damage than a malicious legacy add-on? Seems unlikely, but I don't know enough to say for sure. Edit: Even if MC is right, I'd still prefer to take my chances. Just make WE a Boolean in about:config and let users decide for themselves; I wouldn't force my own paranoia on everyone else. (BTW, looks like Schmaif made the same point on PM's forum.) Edit 2: MC's post on the question is quite vague: Point 1 seems to be "we don't intend to expand WEs because we think doing so is unnecessary;" that's fine, but it hardly seems like a reason to remove them. Just leave them as they are. Point 2 is, you can "steal browser data through WEs." But is there data you can steal through WEs that you can't steal through legacy APIs? And my previous comment still stands, in any case: let end-users decide. Default it to off but if folks are willing to take their chances, let them turn it on. The benefits, although limited, still seem to outweigh the risks to me. Point 3 does make a bit of sense to me: even if they never expand WE functionality, it would be irresponsible not to address and fix security bugs in the existing APIs as they are identified. But I can't imagine that implementing security patches to the limited WE APIs in FF 52.9 and Basilisk has been a significant burden to the PM team. Points 4 and 5 seem merely to expand on point 1: it's not practical to expand WEs given the XUL code base, and it's not necessary anyway because the legacy APIs provide all the same functionality. To be blunt, these don't seem like compelling reasons to remove the existing WE functionality, even when taken all together.