Mathwiz

Yes; just start a new topic and click "Poll:"

As usual, Microsoft's version numbering is ridiculous and confusing. If you open RDC, you can right-click the top left corner and click "About" to see version info. RDC 7.0 (the last for XP SP3) looks like this: Naturally it says Version 6.1.7600, not 7.0. The only thing that says 7.0 is "Protocol 7.0 supported." If you don't have the version above, you can get it by installing KB969084, which Microsoft has naturally removed, but you can still download it from the Wayback Machine at: https://web.archive.org/web/20130721164659/https://download.microsoft.com/download/A/D/B/ADB61C11-6705-437A-ACAD-CAA9C0200C4C/WindowsXP-KB969084-x86-enu.exe Once you install it, you'll need to install KB2813347, which is available via MU even though RDC 7.0 itself isn't available anymore. (Apparently KB2813345 is for RDC 6.1 and KB2813347 is for RDC 7.0.) M$ sure makes it complicated!

Glad you figured out a way to fix the FF issue! (Usually I'm the one who can't get things working when they're working for everyone else.) When I first tried to open the .jnlp test file I got the same error in jp2launcher. I'd had some other crashes in jp2launcher, so I copied jp2launcher.exe from the old 152 install, tried again, and it worked. I didn't replace javaws even though, you are right, opening a .jnlp file calls javaws. (I guess javaws calls jp2launcher.)

Of course, after installing WMP10, I wanted to re-install Windows Media Format 11 run-time on @heinoganda's recommendation: ... but the installation program, wmfdist11.exe, wasn't on my system! I found a link to wmfdist11.exe at https://softfamous.com/postdownload-file/windows-media-format-runtime/4431/884/. Note: this site is slow! But the file seems to be genuine; Microsoft's digital signature is present. Note: wmfdist11.exe seems to obviate the need for most of the above updates, including the hot-fix. I ran Microsoft Update before installing it, and all the above updates (except the hot-fix) were listed. But instead of installing the updates I installed wmfdist11.exe and ran MU again; afterwards only KB973540 & KB973540 were listed, and when I tried to install the hot-fix, it said it was already installed.

Thanks @sdfox7, I do have the Windows Media Format 11 Run-time installed. I was wondering if that might be the problem, but the error message did nothing to point me in that direction, and I didn't want to just randomly start uninstalling things that might be the problem, only to discover it didn't help. Edit: That worked.

Classic Add-Ons Archive is for FF 45 - 56 (also Pale Moon 27 - 28).

I went through and collected most (can't guarantee all) of the names suggested early on as permanent replacements for "New Moon." Many reference XP, or at least allude to it (Bliss Moon, Luna). A couple (NyXP, Pale Mimas) refer to moons of planets other than Earth (including dwarf planet Pluto), providing an easy copyright- and trademark-safe source of icons. I suggest we organize a poll. Or @roytam1 can just pick one and we can get to work on artwork. Mimas (image from Cassini spacecraft): Nix/Nyx (image from New Horizons spacecraft): Name Suggested by Black Moon @98SE MoonFade @burd Waning Moon @Damnation Bright Night @dencorso NyXP @dencorso XP Moonshine @dencorso Darkmoon @Dibya Bliss Moon @heinoganda Bold Moon @jaclaz XPM @jumper (Lunar) Xpale @mixit Luna @NT Five Pale Mimas @roytam1 (There has to be a better way to insert tables on this forum! But this will do for now) BTW, I've seen no suggestions so far for Serpent, so I'll start: Apophis!

Well, I'm stumped. I just downloaded and installed FF 52.9.1 and Java works for me, the same as in Basilisk. The only thing I did to the new 8u202 install was to copy jp2launcher.exe from the old 8u152 install. Everything else is exactly as installed. Edit: I'm uploading one more .reg file. It's only needed if the Java applet isn't in your control panel. That happened to me after I uninstalled an earlier Java version. javacpl.reg

New versions of jp2launcher don't seem to be compatible with Windows XP. I've been copying jp2launcher.exe from 8u152 and using that. I'm not sure what, if any, functionality I'm losing, but it seems to work.

For New Moon, there were numerous suggestions near the start of this thread - even some logos IIRC. It started to remind me of the running subplot on Star Trek: Voyager where the emergency medical hologram couldn't come up with a name for himself. At the end of the 7-year series, he finally settled on "Joe." If it were me, I'd just pick one of those and be done with it. We all knew New Moon was only supposed to be a temporary name anyway. As for Serpent, MailNews, and Navigator, I'm sure we can come up with something.

Hmm ... I haven't tried it with FF 52.9.1 yet. I'll download it and give it a try. Perhaps Mozilla broke something....

Wasn't @dencorso working on some artwork of his own for Serpent? Perhaps he'd be willing to share

Both of your test sites use certificates signed by untrusted roots, so you have to add them as exceptions in the Java control panel applet. If you do that the CMU applet still has problems, but the other works fine on Roytam1's latest Serpent build: Oracle's "Verify Java Version" page also works. Did I leave something out of those .reg files? You should see something like this in Tools / Add-Ons / Plugins: HTH

That's very strange. Should work straight off in New Moon (XP), just as it does in FF 52 ESR and SeaMonkey. (Basilisk & Serpent require a little extra work, as @VistaLover explained.) Didn't know Silverlight was available on the Pale Moon (Linux) build but if it is, I'd think it would work there too. Maybe the Netflix SSUAO is missing from the Linux build? BTW, Waterfox sounds interesting, but it targets 64-bit Windows 7. I don't know if it's even feasible to recompile it targeting 32-bit XP (or even Vista) instead.

Sorry @VistaLover; I saw your post as soon as I submitted mine. The S/N ratio on this thread seems to have dropped precipitously today for some reason....

Sounds like you need to install Silverlight.

It works for IE8, but if you want it to work with Mozilla-family browsers (FF 52 ESR, NM, Basilisk, SeaMonkey), you need more entries to register Java as an NPAPI plug-in: DTPlugin.reg JavaPlugin.reg

OK, this is strange. I'm at WMP 9; when I try to install WMP10, I get this error dialog: Clicking "Details" brings up this screen: Clicking the link in that brings me to a page that offers me WMP11. I'm guessing I have something installed that makes WMP10 think I have Windows Vista or 2000 or something instead of XP, but these messages give me no clue....

Since the system boots in normal mode, but not safe mode, presumably it's either: A bad driver or service loading in safe mode that isn't loaded in normal mode (shouldn't happen, but something to look for), or A needed driver missing from safe mode. I don't think it'll be easy to troubleshoot.

That sounds like overkill to me. They only signed one DarkMatter certificate; presumably the vast majority of certificates signed by QuoVadis are fine. If DarkMatter makes it into Microsoft's, New Moon's, or Basilisk's trusted root store, you could start deleting their certificates. (If DM makes it into Mozilla's trusted root store, presumably it would have no effect on XP users since we aren't getting updates from Mozilla anymore anyway.)

From the article: On FF 52 and its forks, the Certificates tab is on Advanced preferences, not Privacy or Security preferences. You would then click "View Certificates," select the one(s) to be distrusted, click "Delete or Distrust," and confirm your choices. Of course, if you use @roytam1's builds of New Moon or Basilisk, you'll have to repeat this process each time you update (or else convince him to remove the certificates from his builds preemptively). That's not correct. If that were the case, a big CA like DigiCert could decrypt half the Internet! A root CA generally cannot decrypt traffic of the certificates it signs. Each certificate contains only the public key, not the private key needed for decryption. The real concern is that a root CA could sign certificates of sites that haven't kept their private key secret (due to carelessness, theft, or coercion from the UAE), thus causing Mozilla browsers to trust those sites to be secure, when in fact they are not. I suppose a rogue CA could be an agent of such coercion, but I'd think whistle-blowers working for the certificate owners would soon expose such a scheme. From the EFF article: That's true as far as it goes, but issuing a fraudulent certificate is only part of what's required. It would also be necessary to redirect, say, google.com to a phony website using the fraudulent certificate. That might be doable if, say, your ISP was also compromised, but you're starting to involve a lot of actors to pull off such a scheme. I could see that in China, the UAE, or Saudi Arabia, where all the ISPs are pretty much inherently compromised in order to do business in those countries at all, but it would be a lot harder to pull off in Europe or America.

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?

To test what would happen in this situation, I modified the start of @Dave-H's original HTML email to look like this: <BASE HREF=HTTP:><HTML><HEAD><STYLE> BODY {font-family="Arial"} TT {font-family="Courier New"} BLOCKQUOTE.CITE {padding-left:0.5em; margin-left:0; margin-right:0; margin-top:0; margin-bottom:0; border-left:"solid 2";} </STYLE></HEAD> <BODY> <Span CLASS=EUDORAHEADER> Date: Sat, 2 Feb 2019 05:07:12 +0100 (CET)<br> </Span> <Span CLASS=EUDORAHEADER> From: Sky Community &lt;mailer@lithium.com&gt;<br> </Span> <Span CLASS=EUDORAHEADER> To: dave_hawley@yahoo.co.uk<br> </Span> <Span CLASS=EUDORAHEADER> Subject: Sky Community Community: Daily Digest<br> </Span> <br> <div> <br> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html> <head><BASE HREF=HTTPS:> Note two BASE tags: one specifying HTTP: at the very beginning, simulating a prepended tag, and one specifying HTTPS: after the email's <HEAD> tag, as it might be if the email had been sent with a BASE tag included. (Confusingly, Eudora wraps the entire HTML email with its own HTML so it can display the email's headers; thus the first HEAD and BODY tags in the file were added by Eudora and weren't part of the email that Sky sent.) The results were mixed. The email still opened without delay, and the toolkit.css file was still downloaded twice, but this time it was downloaded once using HTTP: and once using HTTPS:. Since the LINK tag near the top of the email explicitly specifies HTTP: and was not redirected, the HTTPS: download was apparently triggered by the @import rule near the bottom of the email. So in this case, the second BASE tag seems to have been used, which is what we want. However, the two @font-face rules near the bottom still triggered (buggy) HTTP: downloads as before. So in these cases, the first BASE tag seems to have been used! Conclusion: prepending <BASE HREF=HTTP:> is probably fine for the vast majority of emails one might receive, but to be safe, one should first scan the email for a BASE tag, then only prepend <BASE HREF=HTTP:> if another BASE tag weren't found.

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!

This is typically done using code that looks like this: Content-Type: multipart/related; boundary="------------090303020209010600070908" This is a multi-part message in MIME format. --------------090303020209010600070908 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15"> </head> <body bgcolor="#ffffff" text="#000000"> <img src="cid:part1.06090408.01060107" alt=""> </body> </html> --------------090303020209010600070908 Content-Type: image/png; name="moz-screenshot.png" Content-Transfer-Encoding: base64 Content-ID: <part1.06090408.01060107> Content-Disposition: inline; filename="moz-screenshot.png" [base64 image data here] In this case, the src attribute of the image tag is a cid: (content ID) reference to the embedded MIME image. It doesn't look like a <base ...> tag would interfere with this method, so it should be safe to use with emails with embedded images, but the only way to be sure is to try it out. Unfortunately, I don't see how this method can be tested by opening the HTML portion in IE8. One would probably need to test the effect of a <base ...> tag on this method in Eudora itself. Another possible problem I can foresee is that there could be a <base ...> tag already in the email. In that case I don't know if prepending another <base ...> tag would just be ignored (which would be OK), or if it would override the one in the email, causing problems.