Leaderboard

The task manager shows not only the memory consumption, but also virtual memory, the swap file. Therefore, applications can use a lot of virtual memory without consuming RAM.

IMO yes; it's safe. Older, "weaker" encryption is used between the browser (IE or Chrome) and the so-called "front" server, and data is unencrypted between the "front" and "back" servers; but all this takes place within your own PC. No unencrypted or weakly-encrypted data ever leaves the PC. Thus, the connection between your PC and the Web server you're using will be as secure as the Web server is configured to make it. It's conceivable that malware could be written to exploit ProxHTTPSProxy, but the number of folks using it is pretty tiny, so I doubt anyone would bother.

>> Works for Windows 10, Windows 8.1/7/Vista/XP 32-bit and 64-bit Should say "XP (sp3)". > it won't work - at least here - on XP (Major/Minor are 5.1 just fine) throwing an error on missing entry point "GetLogicalProcessorInformation" in KERNEL32.DLL Should say "on XP (sp2)".

Even with a default "full" install, the Embedded OSes often leave some piece out, and then again there are SKU specific add-ons required in some instances.

UPDATE! I have enabled some WebGL features that seem to improve the general performance of the browser, especially during scrolling. Keeping the WebGL implementation running at minimum capability mode seems to make scrolling less jerky in graphically intensive pages, making the entire browser feel faster. I also have reduced the amount of warnings to 0, reducing the CPU usage (when set at 32, there might be a sudden spark in CPU usage since the browser sends warnings related to the WebGL engine.). The build number of this new version of the UOC Patch is N2J. Please update to the newest version of the UOC Patch and happy RDDin'! EDIT: please redownload. I made a mess with the archives. EDIT 2: I have applied some minor updates to the 52 ESR and the New Moon 28 exclusive version of the UOC Patch. Please update.

He's edited his first post since it was first posted. I was pretty sure that Partition Wizard was in the list originally, and CPU-Z, and I thought it was a list of things that didn't work! Partition Wizard has now been removed from the list. Sorry if I misunderstood it!

With: map --mem (hd0,0)+1 (hdn) you are in theory mapping the first partition of hd0, i.e. (hd0,0) to a "whole" disk (hdn) So, the first sector of (hdn) would be the first sector of (hd0,0), i.e. a bootsector (or PBR/VBR) and not a MBR. whilst with: --map --mem (hd0)+1 (hdn) you map the whole disk hd0, i.e. (hd0) to a "whole" disk (hdn) In theory the first one shoudln't work , but grub4dos automagically (I believe this may depend on the specific version, I seem to remember that it was added somewhere in 0.4.5c, but I may be mis-remember) does a few things: 1) copies the MBR from the source disk to the mem disk 2) writes to the MBR on memdisk a new single partition entry (with an offset of 63 sectors, normally) for the volume, 00ing all the others (if any) partition entries 3) copies to mem the actual volume 4) corrects (if needed) the sectors before in the BPB of the volume I am attaching a couple of screenshots that should help explain the above, I am mapping, for the sake of the example to two different mem disks to show the differences. Everything is fine and dandy . jaclaz

It is always worth the five minutes it takes to try and change the major/minor OS in the executable. A number of executables are perfectly fine running in XP BUT they are compiled with a "default" setting targeting 6 (Vista). This results in the error "This is not a valid Win32 application". Get CFF explorer: https://ntcore.com/?page_id=388 Open with it the (copy of the) executable and select "Optional Header". Then change: MajorOperatingSystemVersion to 5 MinorOperatingSystemVersion to 1 MajorSubsystemVersion to 5 MinorSubsystemVersion to 1 and save. No idea if this applies specifically to Inno Setup executables, though. jaclaz

It gave some better performance on my Pentium M laptop, heavy sites load better without hanging the browser :)

While there's no doubt the ESET v12.2.30.0 range of products had been officially released on Oct 2nd 2019, as per @Vistapocalypse's link above, the second link of his only gives access to 64-bit builds (under the "Early Access" category, submitted on Sep 27th 2019 ). OTOH, the official ESET support site, when searched for older versions of ESET products, https://support.eset.com/en/download-and-install-eset-offline-or-install-older-versions-of-eset-products lists as latest v12 version the 12.2.23.0 one, where indeed an official download link for the 32-bit flavour is present: E.g. the direct link for the Antivirus product is The plot thickens by the fact the downloaded installers don't display a v12 file version, but a v10 one (!), e.g. file eav_nt32.exe from above link is of version 10.9.73.0 (a fine mess, if you ask me...); so, if anyone has official (/unofficial?) links to the 32-bit setups of ESET v12.2.30.0 products, do share!

@SkyySX You need to flip: gfx.webrender.dcomp-win.enabled to false in about:config, after this Yuo need piece of code in userchrome.css which enables aero support for Firefox. Ypu can find right code in Google in few secs.

Win 10 v1909 essentially IS v1903 with some run time switches thrown. Same underlying OS build. As those of you who have been through the upgrade have seen, it was only a minor install that didn't take long to download nor restart. Not an in-place upgrade at all, but just another update. I admit NOT swapping out the OS underpinnings is perhaps the first impressive thing Microsoft has done with Windows in a long time. Hurrah! It would be awesome if BigMuscle would rebuild an optimized version of Aero Glass for Win 8+ that loosened the compatibility check and allowed v1909 just the same as v1903, without the dialog, though we can of course hit the [Cancel] button for now as a workaround. Let's hope he still has the interest to continue to develop Aero Glass for Win 8+. BigMuscle, if you're listening, it would also be cool if you'd add a version check circumvention based on a registry entry (assuming you don't already have one) just in case something like this amazing continuation of Windows compatibility should ever happen again. Thanks! -Noel

Let's get this out of the way right off: I didn't touch the functionality of either AM! All I did was revert the Bugzilla "fix" in Serpent 52, restoring version numbers to its about:addons page. I didn't (and really, can't) turn Tycho into WebEx or vice versa. Serpent will continue to support the same limited WebEx add-ons; NM still will not. Nothing has changed except that one bit of information on about:addons. This is cosmetic surgery, not brain surgery But it did take me a while to figure out how UXP separates the two browsers. The UXP repo is a bit of a mess, since it has to support PM/NM, Serpent/Basilisk, and XULRunner (used by KM). Turns out under folder toolkit/mozapps there are two subfolders, extensions and webextensions. Each of those folders has a subfolder named "content," which in turn has a file named "extensions.xml." Under "extensions," that file matches the "before" code in Bugzilla, but under "webextensions," it matches the "after" code (the version number has been moved to a tooltip). Clearly, Serpent uses the code in "webextensions," so I just added back the code that the Bugzilla "fix" stripped out, essentially reverting it. This is the same thing the Waterfox folks did to restore version numbers to that browser (yes, I checked that commit too), except in the Mozilla repo there is only an "extensions" folder, not a "webextensions" one. Finally, I also added the one-line change from Waterfox that lets you turn the version numbers back off if you don't like them. I did that in both "webextensions" and "extensions," so that's the only change that will affect NM. Well, I'm a stickler for consistency, and implementing that pref required only a one-line change, so I implemented it in both browsers. The only thing the new pref does is suppress version numbers if it's created in about:config and set to false. IOW, NM 28 will continue to work exactly as it does now, unless you decide you don't want it to! Was that actually carefully examined? Well, I was as careful as I could manage to be in merging the code in. I'm confident I got the one-line change to check the new pref (in both NM and Serpent) right, but there were quite a lot of code that needed to be put back into Serpent's extensions.xml to revert the Bugzilla "fix." And I've done enough coding to know how easy it is to slip up and break something no matter how careful you are. Unfortunately, I don't have a system capable of building these browsers myself. So I wrote that comment in the hope that @roytam1 will do a test build of both browsers, and revert my changes if there are any problems. I don't see it that way. IMO something is broken in FF 40+, and in Serpent; it's just that, as a user of the CTR add-on, I never realized it because the add-on patches the bug! MCP and Waterfox both seem to agree with that assessment, as they both implemented the same fix. Unfortunately, in MCP's case, it was bundled with a much larger "fix" - removing all WE support - that actually did violate your adage, so the "cure" was worse than the disease. (Waterfox fixed it correctly, but of course it requires 64-bit Win 7; otherwise we'd all be using it and @roytam1 would have a lot less work to do every week!) As for CTR, I think you're blowing the Tycho vs. WebEx thing way out of proportion. Like my own changes, CTR is cosmetic surgery, not brain surgery. Neither of us care what's going on deep inside the browser; we're both just changing how things look to the user. The engine underneath doesn't really matter, because it's not interfacing at that level. If it did, how could you expect CTR to work with browsers as different as Basilisk (Tycho AM) and Waterfox (modified WebEx AM) and yet not work with Serpent 52 (WebEx AM with UI modified as in Waterfox)? I think this is your best point. As it happens, I did look for add-ons besides CTR that would put the version numbers back. After all, not everyone wants to install CTR just to fix that one issue. I didn't have much luck, but then, I didn't look very hard, since it seemed fairly simple and more sensible to just fix the problem at its source. At the end of the day, though, this is the same argument we've seen over other features that Mozilla or MCP have removed (container tabs come to mind): is it better to have the feature in the browser itself, or as an add-on of some sort? Usually, we've come down on the side of leaving the feature in the browser, and that's what I'm trying to do here. I'm not sure how I feel about removing Primetime support. On one hand, @roytam1 already builds in support for playing .mp4 files, so you would think Primetime isn't really needed any more. But OTOH, there have been reports of badly distorted audio when playing some .mp4 videos. Disabling the built-in support and installing Primetime fixes this issue, but that won't be possible with Primetime support removed. The distorted audio issue seems to be rare, but it does still seem to exist. Has anyone encountered it lately? If so, could you post a link to a video exhibiting the problem?

@TrevMUN Smart Defrag will assist you in Trimming your SSD Drives. That's what I use, and it's free too; simply run the program and click on Trim & Intelligent Optimize. Now, sometimes your SSD Device will show up as a Hard Drive instead of a Solid State Drive. Simply hoover over where it shows the HDD Icon and your Drive Name; and Two Arrows will appear, click up or down until you see it change your drive to SSD. As stated above, click Trim & Intelligent Optimize, just hoover your mouse over the arrow that's pointing right (It's next to the Trim button) and it will give you that option. I have yet to test Smart Defrag's Trimming abilities with NVME based drives but, I would expect it to work the same way; as long as windows sees it; it should also see it. Enjoy and Good luck!