Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×

Mathwiz

Member
  • Posts

    1,188
  • Joined

  • Last visited

  • Days Won

    38
  • Donations

    $0.00 
  • Country

    United States

Mathwiz last won the day on July 26

Mathwiz had the most liked content!

2 Followers

About Mathwiz

Profile Information

  • OS
    Windows 7 x64

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Mathwiz's Achievements

623

Reputation

  1. That's an old version of K-Meleon, but I don't think it would hurt to try. Follow the instructions I posted here: If you have any problems just remove the extracted files and you'll be back to normal. If you're using an older browser, I'd guess you have an older PC. Personally, the only thing I've noticed that may be a problem with older PCs is that the patch sets the browser to a frame rate of 120 fps, which may overload slower CPUs on sites with lots of animation. If you have CPU-related issues, try removing layers.offmainthreadcomposition.frame-rate and layout.frame_rate from the .js files with a text editor.
  2. So which videos aren't working now? Oh, now I see 7 months elapsed between those posts, so maybe I should ask, are any videos not working now?
  3. Just download, extract to a drive or folder of your choice, and create a shortcut to palemoon.exe. A couple of suggestions for running it portably: For maximum compatibility with modern web sites, 360EE might be a better choice. Google keeps re-inventing the Internet, Moonchild Productions has had trouble keeping up, and @roytam1's browsers are based on MCP's....
  4. With the Covid-19 pandemic still smoldering, and occasionally flaring up, many of you may be working from home, and using Microsoft's Remote Desktop or something similar to access your work PC. I've been doing that for a year and a half now, although since getting vaccinated I do occasionally go to the office. One major nuisance I kept running into was that, when using any Firefox-derived browser (I generally use @roytam1's Serpent but they were all affected), certain Web sites would freeze Remote Desktop up. The only thing I could do was click to hide the browser window, disconnect, reconnect, and hope that it wouldn't lock back up again as soon as I brought the window back. A very frustrating way to work, and forcing me back to the office more than I'd like. The other day I found a solution. I was in the office, and experimenting with the setting layout.frame_rate in the about:config page. It had somehow gotten set to 240 on my Serpent browser, I think as a result of the "UOC Patch". I reduced that to 60, my monitor's actual refresh rate, and got a noticeable performance improvement at work (where I was not running Remote Desktop, of course). But once back home, I still had problems with Remote Desktop. Apparently too high a setting overloads the Internet connection, causing the desktop to slow down or even stop for long periods. And Remote Desktop has no way to "dump the queue" other than disconnecting and reconnecting. So I decided to try reducing it further. When I went down to about 12, my Remote Desktop problems went away! Animations started looking pretty jerky, though, so I did some more experimentation: in my case, 20 was still too high, but 15 was just right, giving animations that didn't look too jerky without Remote Desktop freezing up. I'm guessing the ideal setting depends on many factors, with the speed of your Internet connection probably being the most important. So if you're in the same situation, you'll need to experiment to find the best setting of layout.frame_rate for your environment.
  5. Github-wc-polyfill seems to work with Serpent 55, at least, although as mentioned in the "Multiprocess Mode" thread, only in single-process mode. (I have a single-process mode profile for just this sort of situation.) And again, you need to modify install.rdf to allow version 52.9 through 55.* to be installed. Edit: Spoke too soon. With GitHub, some things work but several are still broken with Serpent 55. GitLab doesn't really work at all. Same goes for FF 52.9.1 and FF 53.
  6. Yes, I've experienced that myself. I have one tab open that has JavaScript to auto-refresh every 5 minutes; when the auto-refresh happens, certain other tabs will freeze until the refresh completes (on both XP and Win 7!) I guess I just need to stuff in more RAM and bump the process count. BTW (and slightly OT), I found unrelated preferences whose setting can be changed for improved performance: layout.frame_rate and layers.offmainthreadcomposition.frame-rate. The defaults are -1, which AIUI means refresh the screen as fast and often as possible; clearly a waste of CPU if yours can refresh the screen faster than your monitor refreshes! I had mine set to 240; probably a holdover from the "UOC Patch," which wasn't much better for performance than -1! I changed them to my monitor's refresh rate, 60, and got noticeably improved performance on a website that's particularly heavy on "cute" animations (like fading windows in/out, rotating "Please wait" wheels, and the like). I see; the "XP" in the macro is merely a coincidence. I'm sure there's no Mac OS XP or LinuXP! (Probably stands for eXecution Platform or some such nonsense.) It would have made sense to condition the code not just to Windows but to the specific version, since there's no need for the test at all, if the code can only run on Vista+ anyway (think FF 53+); so naturally I thought XP_WIN meant Windows XP; oh, well, you can't win them all.... Luckily, it's irrelevant to the point I was making two years ago, which is that there was code (at least in FF 49) that checked the app.update.channel pref at run time, and disabled e10s if it was set to "release." We were searching for alternative ways to enable e10s, and if for some reason you happen to be running FF 49, changing the update channel pref may work. (I never tried.) But by the time of FF 52 (the basis for all UXP browsers, including St 52, and of course the basis for FF 53, which in turn was the basis for St 55), the app.update.channel pref had no effects other than those which @VistaLover noted in the post I replied to.
  7. I would probably phrase it as, a developer un-crippling newer versions of Flash. It's still Adobe releasing them, but they're region-restricted to only run in China, and of course they have all the China-mandated spyware. Darktohka is stripping all that out so the rest of the world can use the updated (and presumably more secure, although who really knows) versions. But it's still Adobe's copyrighted product, and legally, they have the right to say "no" to what darktohka is doing. You'd think they wouldn't care - if folks are that determined to keep using their free product, why not let them - but maybe they made an agreement with the other members of the "Anti-Flash" consortium (chiefly Google, I suspect) to do everything they can to keep this old, not particularly secure, but popular browser plug-in dead & buried outside of China.
  8. Now that the two of you mention it, that makes sense. Flash v34 is targeted at China, and 360EE is a Chinese browser, so it's reasonable that it allows Flash to run without nags! And of course it's the only remotely recent Chromium-based browser that runs on XP. As some of you are aware, I also use Win 7, which can run "straight" Chromium 87 (but which unfortunately contains the aforementioned nags). I'll check the Win 7 forum for answers, but for some reason, it's not as well-populated with experts as the XP forum.
  9. Thanks @VistaLover. I was out of the loop for a while and just saw that Adobe filed a DMCA take-down against Darktohka. I suspect (s)he will have to find a non-US host to escape the DMCA and keep this project available long-term. Evidently Adobe really doesn't want users outside of China running Flash any more! (cf. my rant at the end of this post): Get 34.0.0.192 from the Wayback Machine while you can; it may become the last Flash version you can get! Link for github-wc-polyfill: https://github.com/JustOff/github-wc-polyfill/releases/download/1.2.5/github-wc-polyfill-1.2.5.xpi Note well @VistaLover's mention of UXP. This is only compatible with UXP-based browsers: PaleMoon/New Moon/MyPal 28 (for New Moon, you need to go into the .xpi archive with 7-Zip and modify install.rdf to specify 28.10 vs. 28.14 as the MinVersion), Basilisk/Serpent 52.9, and SeaMonkey 2.49.5 2.53 (which doesn't work on Win XP). I'm unsure if it can be modified to work on FF 52.9 or Serpent 55. Pretty sure it won't work on other FF-based browsers (e.g. PaleMoon 27). BTW, I tried Flash with the last compatible version of Chromium (87, on Win 7; haven't tried the 360EE version on XP yet). It works, but Chromium really doesn't want you running it! You have to manually enable the extension (and it won't save your preference if you exit the browser), then click the icon of each Flash component on the Web page, then again tell it you're sure you want to run that Flash component! I'm unsure of the latest Chromium version that allows "hassle-free" Flash, nor do I know if that version is new enough to be usable on the modern Web. If anyone knows, please educate the rest of us!
  10. Are @mixit still around? They always seemed to come up with fixes for these sorts of issues....
  11. I wonder if Instagram is using a new video codec now (perhaps h.265/hevc/av1)
  12. Yes, that's what he'd have to do: create a new key pair, publish his new public key, and start signing his builds with his new key. Probably not practical to recover the old private key from a crashed SSD; data recovery services are expensive, and there'd be no guarantee of getting it back anyway. And I'm not sure how HK's new government would react to one of its citizens publishing a public key, since it could be used to send him encrypted messages. May not be worth the potential trouble.
  13. Thanks for that! That annoying warning banner comes up almost every time I visit my bank's (Chase) web site, and I've long wanted to get rid of it! Clicking "wait" makes it go away for a few seconds, but it usually comes back before the script is finished. You don't actually have to click on "wait;" once their Javascript finishes downloading whatever info I asked for (e.g., checking account transactions), the banner goes away on its own. It's just annoying to have it pop up every time! Edit: Unfortunately, it didn't work! After a restart, the banner no longer comes up; but a dialog box pops up with the same options. There's a "don't show this again" checkbox, but it doesn't work either. However, I believe I discovered the correct pref to get rid of it for good: set dom.max_script_run_time to 0. That seems to have banished the dialog box for good.
  14. A couple of years ago, I wrote a batch file to download & install @roytam1's browser builds. Surprisingly, it still works - the only thing I had to change was the set domain= line because he had to change his hosting domain name again. One of its features was to verify the signature of the downloaded file using gpg. Needless to say, this throws a big monkey wrench into that feature - there's a lot more to do after verifying the signature than just pausing so you can see the results! I'll give the cmd /c trick a try. Hopefully it will crash just the second invocation of cmd.exe, allowing the first (the one running the batch file) to continue. Might look a bit ugly, but as long as it works.... Edit: Well, looks like it's a moot point anyway; Roytam1 stopped uploading gpg signatures about a year ago. Edit 2: Here's what happened: His SSD crashed.
  15. As of today, latest Flash version at both links is 34.0.0.184. Confirmed to install and run on Windows XP.

×
×
  • Create New...