
Mathwiz
MemberContent Type
Profiles
Forums
Events
Everything posted by Mathwiz
-
My Browser Builds (Part 1)
Mathwiz replied to roytam1's topic in Browsers working on Older NT-Family OSes
@redfoxcz would need an SSE build of FF 48. That may be possible since 48 < 49, but IDK for sure -
That was broken by a buggy update back in 2014: Link: https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?page=15&tab=comments#comment-1085089
-
In FF or any of its forks, that's exactly what happens: if you enter the URL of a .css file, it gets displayed as text (and if you enter the URL of a .woff file, it gets saved to disk). But for some reason IE8 always seems to interpret .css files as styles, even if you just type the URL in yourself. That's not a problem for Eudora though; when displaying an email, any .css files it downloads are supposed to be interpreted as styles, otherwise the email wouldn't display properly! As for .woff files, IE8 does not support them (and doesn't even form the URL to download them correctly, due to a bug). If it can't download a supported .eot font file, it uses the fall-back font specified in the .css (happens to be Arial in sky.com's case). Since .woff files are unsupported, it would be reasonable to strip any @font-face rules specifying .woff files (or any font file other than .eot format, for that matter) from the HTML, so IE8 doesn't waste time trying to download them. But (I know I'm repeating myself) if one simply inserts "https:" in front of the //'s at the start of those three URLs at the end of the .htm file, it then opens without any long delays, even though (as can be seen from the ProxHTTPSProxyMII window) IE8 is still trying (and failing) to download those unsupported .woff files.
-
I hope @jumper can come up with something! That's probably best. A .css file by itself would probably be just a blank screen in IE8. But if you open any of the HTML email files @Dave-H has posted, you can open them in IE8. If it's not your default browser (which it probably isn't these days), right-click the file and select "Open With..." and Internet Explorer should be listed as an option. When IE8 opens a .htm[l] file, there are often links in the file which cause it to download more stuff from the Internet, such as .css files linked in the .htm[l] file. I use ProxHTTPSProxyMII in "debug" mode to monitor what it's doing. Here are the config.ini settings I use: [GENERAL] ... LogLevel = DEBUG ### Bypass Proxomitron and the Rear Server, Proxy setting still effective ### This section supports URL matching [BYPASS URL] http://* ... An http: request will then look something like this: [08:25] 032 [BP] "GET http://update.microsoft.com/microsoftupdate" 301 167 (The [BP] stands for "Bypass Proxy") ... while an https: request will look something like this: [10:53] 006 [P] "GET https://otm.xpo.com/images/mail/xpo_logo.gif" 200 2256 (The [P] stands for Proxy, of course) The two numbers at the end are the server's response code and the length of the data returned. If IE8 pauses, but you don't see either of the above, it must be attempting a protocol other than http(s), such as file:. Unfortunately I know of no way to proxy these requests; otherwise it'd be a simple matter of failing them immediately instead of having to wait for them to time out.
-
AFAICS everything is OK, except that one and Office 2010 update KB4462174. I was also forced to hide KB4486463, but only because MU kept offering it even though it doesn't apply to my single-core VM. AFAIK the update itself is fine although you may need to install it manually with /overwriteoem.
-
Only needed for the update catalog, not for the regular WU or MU site. I should've made that clear....
-
Adobe Flash, Shockwave, and Oracle Java on XP (Part 1)
Mathwiz replied to dencorso's topic in Windows XP
To clarify, it works fine now; as @bluebolt pointed out, Adobe finally fixed the thing. It didn't work last month, or for several months before, on most browsers on either XP or Win 7. At least not for me; I guess not for @bluebolt either. The only exception for me where it did work before this month was IE8! -
I had to add the following lines to config.ini in ProxHTTPSProxyMII: [SSL No-Verify] www.update.microsoft.com download.windowsupdate.com Download.windowsupdate.com is using a security certificate that doesn't specify download.windowsupdate.com as a valid domain for the certificate
-
I'm afraid I'm having problems with KB4486463. Ntkrnlpa.exe is as v. 5.1.2600.7581, but so is ntoskrnl.exe. My XP is on a VM with a single processor core assigned to it, so those version numbers may be correct for single-core; I don't know for sure. But MU keeps offering me the update no matter how often I install, even if I install the update manually with the /overwriteoem switch.
-
My Browser Builds (Part 1)
Mathwiz replied to roytam1's topic in Browsers working on Older NT-Family OSes
One problem introduced by the PM team's change is that Basilisk will will now accept add-ons that won't work anymore since it identifies as 52.9.something. So to keep Basilisk from auto-updating legacy add-ons to now-incompatible WE add-ons, the PM team changed the "get add-ons" site from AMO to a new one they're setting up (not ready yet) for Basilisk: http://addons.basilisk-browser.org. But @roytam1's builds retain Basilisk's original WE support , so the change to "get add-ons" keeps any WE add-ons from auto-updating properly. But I think this can be fixed by just changing these about:config prefs: extensions.update.background.url and extensions.update.url, back to addons.mozilla.org. -
My Browser Builds (Part 1)
Mathwiz replied to roytam1's topic in Browsers working on Older NT-Family OSes
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. -
My Browser Builds (Part 1)
Mathwiz replied to roytam1's topic in Browsers working on Older NT-Family OSes
The most charitable explanation I can think of is that they're trying everything they can to, uh, "encourage" add-on developers to maintain legacy add-ons, since PM/NM doesn't support WE at all, and the Basilisk support they keep trying to remove is limited. If that's the explanation, though, I think it's a losing battle. Add-on developers aren't going to start maintaining their legacy code again just because of Basilisk, so this would just make Basilisk a less useful FF 52 fork. @roytam1 is correct to revert these changes. It seems unlikely, given how "ideological" MC et al. can be, but maybe they'll figure that out one day, and put the limited WE code from FF 52 back in to not only Basilisk but also PM. -
My Browser Builds (Part 1)
Mathwiz replied to roytam1's topic in Browsers working on Older NT-Family OSes
I think the idea is, it's supposed to update you to the next legacy version whenever gorhill releases one. If you just use Basilisk Serpent's own auto-update it will keep updating you to 1.17.4 (Baslisk Serpent 52) or the current WE version (Basilisk Serpent 55), so you just have to turn auto-update off. It may not be needed in PM/NM/Basilisk because those browsers only support legacy add-on versions anyhow, but it's useful in FF 52 ESR or Serpent, where some WE add-ons are also supported. -
My Browser Builds (Part 1)
Mathwiz replied to roytam1's topic in Browsers working on Older NT-Family OSes
Thanks. I never could get version 1.6.5 to work; I just had to check and update uBO manually. I hope this version works better. -
My Browser Builds (Part 1)
Mathwiz replied to roytam1's topic in Browsers working on Older NT-Family OSes
Yes they're old. Did you pull them from the server for some reason? -
Beware of Office 2010 Updates!
Mathwiz replied to Dave-H's topic in Pinned Topics regarding Windows XP
Oops: two more just appeared today: Are either of those installed? I'm testing KB4018313 now. Edit: KB4018313 seems safe. But KB4462174 updates mso.dll so it may have the same problem as KB4462157. -
Adobe Flash, Shockwave, and Oracle Java on XP (Part 1)
Mathwiz replied to dencorso's topic in Windows XP
Ironically, for me IE8 is the only browser where the Version Information window DID work. Didn't work in Basilisk, Opera 12.18, or IE 11 on Win 7. -
Beware of Office 2010 Updates!
Mathwiz replied to Dave-H's topic in Pinned Topics regarding Windows XP
Well just uninstall KB4462157 again. You don't need the Japanese calendar in Lithuania do you? -
My Browser Builds (Part 1)
Mathwiz replied to roytam1's topic in Browsers working on Older NT-Family OSes
Links are now getting 502 errors -
(FIXED) How to watch Amazon Prime Video on Windows XP
Mathwiz replied to sdfox7's topic in Windows XP
Microsoft's version numbers make no sense. Vista is 6.0, "7" is 6.1, "8" is 6.2, and "8.1" is 6.3. With Win 10, they put the numbers back in sync, so 10 is indeed 10.0. But at present there's not much reason to spoof a later version of Windows than 7, er, 6.1. That may change, though, when Win 7 EOS arrives next year :( -
My Browser Builds (Part 1)
Mathwiz replied to roytam1's topic in Browsers working on Older NT-Family OSes
It was removed from their nightly builds a few weeks ago, but this is the first "official" release since that happened. NP; I just switched to @roytam1's build on my Win 7 home system. Everything seems to be working exactly the same. -
Thanks; looking at it now. It looks a lot like an old program I used to use for ad-blocking called DNSKong. But it's not a Eudora plug-in, so it doesn't help here. (Incidentally, it's "incontrovertibly" English can really suck at times.) Something must have gotten lost in translation. The only reason I mentioned ad-blocking is that you mentioned: I didn't even know Eudora supported plug-ins! But if it does, your idea sounds good to me. I'm aware of .woff files, and it's true that, as of IE8, mshtml.dll didn't support them: But that's not the only problem with sky.com's HTML emails! To prove this, try editing @Dave-H's original HTML, changing url("//www.sky.com/assets/fonts/sky-regular.woff") format("woff") url("//www.sky.com/assets/fonts/sky-medium.woff") format("woff") to url("//assets.sky.com/fonts/sky_regular.eot?") format("embedded-opentype") url("//assets.sky.com/fonts/sky_medium.eot?") format("embedded-opentype") Those .eot files do exist on sky.com's servers - I checked - and .eot is supported; but IE8 will still open it with a progress bar that "stalls" for several seconds. But if you instead change @import "//helpforum.sky.com/html/assets/toolkit.css" url("//www.sky.com/assets/fonts/sky-regular.woff") url("//www.sky.com/assets/fonts/sky-medium.woff") to @import "https://helpforum.sky.com/html/assets/toolkit.css" url("https://www.sky.com/assets/fonts/sky-regular.woff") url("https://www.sky.com/assets/fonts/sky-medium.woff") merely adding "https:" in front of each double-slash, IE8 will now open the file without the progress bar stalling, even though you loaded unsupported .woff files! Seems obvious that the delay is caused by protocol-relative URLs, not by unsupported font files.
-
I'd probably be a bit less aggressive in my spoofing. The ESR release of FF should be supported for several more months, so try: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Firefox/60.0 That way, you won't have to update it every month or two. (You can change 60.0 to 60.5, the latest ESR version, if you wish.) Whatismybrowser.com may not like it, but it should work pretty much everywhere else. But, don't be totally surprised if it still doesn't work with Amazon. There are other ways besides the user agent string that Web sites can use to ferret out your browser version. In the case of Amazon Music, I bet there's third-party DRM code Amazon's looking for, and it may not even be possible to get that code working on FF 52.9.1 or earlier, or any of @roytam1's forks either for the simple reason that it's likely not XP-compatible. DRM is the one area where pretty much every XP-compatible browser disappoints nowadays. But if anyone can do it, I'd bet on @VistaLover
-
Didn't know plug-ins were an option for Eudora. Sounds like that's the way to go - in fact, while at it, it could even, you know, block ads.... But actually the problems IE8 has with that .css code snippet above go way beyond not being able to handle .woff files. It doesn't even manage to download them because of a bug: it tries to download something named "//www.sky.com/assets/fonts/sky-regular.woff")%20format("woff")" which obviously doesn't exist and would trigger a 404 error - if it used http: or https: to try to download it to start with! (You can prove this by editing the email, adding https: in front of the //'s, and monitoring what IE8 requests when it opens the edited file with ProxHTTPSProxyMII.) But actually it uses file: instead, which is unlikely to work because there's probably no NFS server named www on your home network, and your network probably isn't using a domain of sky.com either....
-
My Browser Builds (Part 1)
Mathwiz replied to roytam1's topic in Browsers working on Older NT-Family OSes
So go ahead and try the latest version and it should be OK now.