VistaLover

@mraeryceos ... My previous assessment was based on your initial report, stating that: and I took (perhaps mistakenly?) "rebuild my browser from scratch" to mean build a new New Moon 28 profile from scratch; but you're now possibly contradicting yourself, as in: So, which was it? In any case, I'm more than happy you ended up with a smooth-running browser!

... This is better worded as follows: Windows XP is well alive in 2019 China since are ALL browsers offered by Chinese vendors (and mainly target mainland China users...; I won't even touch the privacy concerns associated with Chinese browsers in general ). The fact that XP still holds a strong market share among Chinese netizens is the very reason that gives incentive to these Chinese vendors to invest, no doubt, considerable resources to (probably manually) undoing all the many thousand lines of code Google have pushed after Chromium 49, so as to restore XP and, probably as a not intended by-product, Vista compatibility in their Chromium 69 & 70 forks. Being myself in the Mozilla camp, I would've liked for them to have similarly produced an XP/Vista compatible Quantum fork, but I suspect they were not interested in such an enterprise (technical limitations aside): Quantum currently enjoys only a small fraction of Google Chrome's usage share; and Google Chrome is already on its own a hugely more efficient spyware than Quantum, so why bother to begin with? Of the rest two browsers in your first list, Nano Browser (still in alpha testing phase) is an Indian product (another territory where XP is still abundant), while Lunascape is a Japanese product (which makes it the odd one out, I suppose; BTW, have you checked that the Gecko and Webkit engines inside Lunascape are indeed XP compatible? If not, Lunascape would be only able to use IE8's Trident engine under XP and that alone, as I'm sure you already know, won't get you very far in 2019's web ). PS: This is not an XP dissing post, I still love XP myself, having spent 6 years on it before sticking with Vista; but it is a reality check all the same...

Seems to work as expected here, under Vista SP2 32-bit

Highly unlikely ; you rebuilding your browser profile from scratch was what probably fixed your CPU issues (possibly some conflicting extensions/preferences/about:config settings were the cause of elevated CPU cycles in your original profile...). FWIW, --no-remote is just a cmd line switch that means "don't talk to an existing Firefox, start a new instance"; together with the -p switch, one is able to launch a new Firefox (or fork) instance loading the specified profile, so that the two Firefox instances one ends up with are completely separated! For anyone that cares, there exists an excellent article dedicated to the switch in question, found here

Not according to tests I conducted prior to my reply above... Steps to reproduce: 1. Start with a new pristine Serpent 55 profile, using latest binary package offered by Roy: basilisk55-win32-git-20190622-c2dfff698-xpmod.7z 2. Manually install https://github.com/gorhill/uBlock/releases/download/firefox-legacy-1.16.4.11/uBlock0.firefox-legacy.xpi 3. Switch to Addons Manager (about:addons) tab, select the entry for uB0 1.6.4.11 and manually check ONCE for updates (right-click => Find updates); it will get updated first to 1.17.4 (WE): 4. On the uB0 1.17.4 AOM entry now, just check again manually for an update; this time you won't be offered an additional update to a higher version; these have been my findings under Vista SP2 x86, where St55's default UA is Mozilla/5.0 (Windows NT 6.0; rv:55.0) Gecko/20100101 Goanna/4.0 Firefox/55.0 Basilisk/20190622 5. If I let Serpent 55.0.0 (new clean profile with only uB0, v1.6.4.11 manually installed and afterwards manually updated to v1.17.4) stay open but idle for a duration of, say, 15min, by coming back at it I find it has auto-updated to latest (AMO) v1.21.2: NB that 1.21.2 is totally broken on Moebius under that test profile,, without even a glimpse of a toolbar button (not even in "Customize" mode); the dashboard, accessible via about:addons => uB0 => Options, is totally empty, too... So, one's tests with uB0 WE on Moebius is probably a case of YMMV

@404notfound Everything is working as expected here: uBlock0-legacy v1.16.4.11 installed from GitHub: https://github.com/gorhill/uBlock/releases/tag/firefox-legacy-1.16.4.11 But the main thing to consider is that Serpent 55.0.0 on the Moebius platform can still connect to AMO (addons.mozilla.org) to check for extension updates, where St55 poses itself as Firefox 55.0; in reality, St55 has been forked from Firefox 53.0a1 and its WebExtension support is even inferior to stock Fx 53.0 (!). By default, St55 will update the legacy v1.16.4.11 of uB0 to v1.17.4 of the WE type, which, unfortunately, depends on WE APIs not (enabled/)found in Moebius (as pointed out by @roytam1), hence the issue you report... The way to workaround this has been posted many a times in this thread, by several members, including both me and @Mathwiz : install (from GitHub) the companion extension called uBlockOrigin Updater: https://github.com/JustOff/ublock0-updater/releases Its action is two-fold: 1. Thwart Serpent 55 from making uB0 (extension) update calls to AMO (so it won't peak the incompatible WE version) 2. Keep an eye on uB0's GitHub repository for the appearance of an updated "legacy" version and either auto-install it or notify/prompt the user to install manually (according to user preferences). Hope it's all clear now

@roytam1 Using latest Serpent52 win32 build, I loaded https://www.bbc.co.uk/taster/pilots/casualty-ae-audio/try but the embedded web player fails to load: For debugging purposes, I disabled uBlock0; no other content/script blocker used. OTOH, latest 360ExtremeExplorer (11.0.2140.0) has no issues loading it (and playing back the clip): The issue I experienced might well be Javascript and/or CSS related; the workaround I found is right-click the empty web player and select "This Frame => Show Only This Frame" : Any suggested fix would be welcome ; ultimately, if it is reproducible in official Serpent 52.9.2019.06.08, it should be submitted to the official forums; mind you, it is only available for a month or so...

Thanks ... So, it may well be just a case of increasing the time interval to, say, 45 or 60 (sec) ? Anyhow, first variant it is then...

... In the good ol' days (prior to July 2019) when Windows Defender in Vista would receive definitions updates via Windows/Microsoft Update, WU would create a System Restore Point before installing the new definitions file; that SRP would be named "Windows Defender Checkpoint" (or something similar, memory fails me now... ) and those automated restore points had saved my "behind" when I wanted to revert some unwanted/inadvertent change on my machine. I have also the following setting checked: but this is only to revert changes applied by WD (and I always have to "Permit" them myself beforehand...). Unfortunately, and I understand this is highly unwise, I'm not in the habit of creating manual restore points in a frequent schedule; of course, the OS itself would create one when it thinks it's needed, however I have found this task to be performed in a very fickle fashion; with me not receiving Windows Updates anymore, and not installing/uninstalling applications that often, I've found that it may take the OS many days to auto-create a RP... So I looked into ways of implementing the automated creation of a SRP alongside the automated (but manual!) update of WD via my WDUPD_Vista.cmd batch file, inspired by its MSE counterpart kindly offered by @dencorso (few posts previously...). Research has landed me on https://www.winhelponline.com/blog/create-system-restore-point-script-windows-10-8-7-vista-xp/ and their VBScript linked to in their "Method 3: Restore Point creation using Script" (slightly modified by yours truly!): '"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 'Script to create a System Restore point in Windows 10, 8, 7, Vista and XP 'Created on May 10 2008 - Revised on Oct 13 2016 '© 2008-2016 - Ramesh Srinivasan. http://www.winhelponline.com/blog '"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" If GetOS = "Windows XP" Then CreateSRP If GetOS = "Windows Vista" Or GetOS = "Windows 7" Then If WScript.Arguments.length =0 Then Set objShell = CreateObject("Shell.Application") objShell.ShellExecute "wscript.exe", """" & _ WScript.ScriptFullName & """" & " uac","", "runas", 1 Else CreateSRP End If End If If GetOS = "Windows 8" Or GetOS = "Windows 10" Then If WScript.Arguments.length =0 Then Set objShell = CreateObject("Shell.Application") objShell.ShellExecute "wscript.exe", """" & _ WScript.ScriptFullName & """" & " uac","", "runas", 1 Else const HKEY_LOCAL_MACHINE = &H80000002 strComputer = "." Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv") strKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore" strValueName = "SystemRestorePointCreationFrequency" oReg.SetDWORDValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName, 0 CreateSRP oReg.DeleteValue HKEY_LOCAL_MACHINE, strKeyPath, strValueName End If End If Sub CreateSRP Set SRP = getobject("winmgmts:\\.\root\default:Systemrestore") If GetOS = "Windows 10" Then sOut = SRP.createrestorepoint ("Manual Restore Point", 7, 100) Else sDesc = "Windows Defender Update Restore Point" If Trim(sDesc) <> "" Then sOut = SRP.createrestorepoint (sDesc, 0, 100) End If End If If sOut <> 0 Then WScript.echo "Error " & sOut & _ ": Unable to create Restore Point." End If End Sub Function GetOS Set objWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _ ".\root\cimv2") Set colOS = objWMI.ExecQuery("Select * from Win32_OperatingSystem") For Each objOS in colOS strOSName = objOS.Caption If instr(strOSName, "Windows 7") Then GetOS = "Windows 7" ElseIf instr(strOSName, "Vista") Then GetOS = "Windows Vista" ElseIf instr(strOSName, "Windows XP") Then GetOS = "Windows XP" ElseIf instr(strOSName, "Windows 8") Then GetOS = "Windows 8" ElseIf instr(strOSName, "Windows 10") Then GetOS = "Windows 10" End If Next End Function Of course, I then had to visit https://stackoverflow.com/questions/11899730/running-vbscript-from-batch-file to learn how to incorporate this in my batch file... The important thing here is that the SRP creation be fully completed prior to wget (finishing) downloading file mpas-fe.exe (or perhaps prior to file mpas-fe.exe being executed). I am torn between two variants: @echo off start /min /wait cscript "create_restore_point.vbs" if not exist mpas-fe.exe start /min /wait wget -O mpas-fe.exe https://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe if exist mpas-fe.exe start /min /wait mpas-fe.exe del mpas-fe.exe and @echo off cscript "create_restore_point.vbs" timeout /t 15 /nobreak if not exist mpas-fe.exe start /min /wait wget -O mpas-fe.exe https://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe if exist mpas-fe.exe start /min /wait mpas-fe.exe del mpas-fe.exe where file create_restore_point.vbs is placed adjacent to the .cmd script. @dencorso, your opinion on this would be highly appreciated (along with any other alternative you might be able to suggest ); many thanks in anticipation

... But he did already : The command prompt is in Italian, but I can tell you he passed the test (which is even more peculiar, given he can't access the hostname in a browser ); only difference to mine is I pinged IP 104.27.137.100 (from Greece), while he pinged the alternate IP 104.27.136.100 (from Italy) ...

Expected results here:

... I suppose politics isn't allowed here in MSFN (yes, according to rule 2.b: ), so I'll only skim the surface of things, limiting myself to the "technology/physics" of the issue: 1. The USA are a vastly industrialized country, its huge industry sector is responsible for a considerable percentage of global warming/climate change emissions. 2. The current US president, to my knowledge, has withdrawn the US from any global CO2-emissions control treaties, while "poor" Europe still has to honour them. 3. Global warming inducing emissions in one continent contribute to the whole planet getting warmer, as the "butterfly effect" applies here. 4. Using an air-conditioning device consumes major amounts of electricity, to produce this, more emissions are disseminated in power plants, especially if they are of the thermo-electric type (combustion of fossil fuels is used to generate steam, to drive generators). 5. Using an air conditioning device lowers the temperature in the inside, but excess heat is transferred to the outside, resulting in a change to the micro-climate of the area/town/city you live in (surrounding air gets even hotter). FWIW, I am poor (literally, i.e. I have only a reduced/unstable income), a European, but I do have AC in my apartment; for the record, highs up to 38°C are forecast for today, July 28th, where I reside, plus another spell of an African heatwave is about to strike, starting next Wednesday... This was not meant as an inflammatory post , I know what @glnz posted had a joking flavour into it ; still, I posted what I did as food for thought...

Thanks for the correction by @Mathwiz ; I guess I was too quick to suggest a disabled cipher suite ... Looking more closely at the screenshot posted: it may actually be an issue between the local (Italian, in Rome) Cloudflare node and the hosting server, o.rths.cf (IP check of 104.27.136.100 suggests another Cloudflare node in the Northern US); @Sampei.Nihira, can you perhaps try accessing the file via a non-Italian IP, acquired via a Proxy/VPN? Just another wild thought here (?)

@Sampei.Nihira No issues whatsoever here fetching file http://o.rths.cf/palemoon/palemoon-28.7.0a1.win32-git-20190727-9b0ff0e8b-xpmod.7z I suspect you may have to loosen up a tiny bit the tight security implemented in your browser configuration, probably some supposedly "weak" cypher suite needs to be re-enabled; just my 2 eurocents, of course https://www.ssllabs.com/ssltest/analyze.html?d=o.rths.cf e.g. https://www.ssllabs.com/ssltest/analyze.html?d=o.rths.cf&s=104.27.136.100

??????? (Help us to help you ; to pinpoint the culprit extension(s), apply binary search or install them one-by-one, until you discover the infringing one)

... Couldn't have said it better myself ; been a Firefox user since v2.0.0.16, up until v52.9.1ESR, when the Mozilla wizards cut support for my old OS (Vista SP2); have to use FxESR 60.8.0 for WidevineCDM enabled services, on my sister's Win7 SP1 laptop; has any of you trialed the new FxESR 68.0? How much worse is it to FxESR 60.8.0 (soon to be EoS'd)? ... and I say worse knowingly, because, currently, with each new Fx release useful features/functions are being axed ; e.g. does Fx 68.0 support userContent.css customisations?

This was a @roytam1 implemented "fix": https://github.com/roytam1/mozilla45esr/commit/0eaa212 (8 Jun 2018) "Nightly" in this case is the generic app name given to the browser when Mozilla Firefox forked code has been built as an unbranded build; much like New Moon is the default "unbranded" name for Pale Moon forks; so "Nightly" doesn't necessarily always designate a nightly development branch... I recollect reading/studying most SSUAO-related Bugzilla bugs one year ago or so, but blame the summer heat for me not wanting to search for/ track them down/ post them here ; what I distinctly remember is that the SSUAO feature in desktop stable & ESR releases of Firefox was re-enabled starting with Firefox 55.0.x and is still present (with possible limitations) in Firefox Quantum (I remember ESR 60.x.x did work when I tested it on a borrowed Win7 machine...); since @Mathwiz has ready access to Win7 SP1, perhaps he could verify my recollections!

... Only wget.exe needs to be in %PATH%; hence, you could have left the batch file (*.cmd) inside a directory of your choice (or place it on the desktop); but whatever tickles your fancy...

... But @dencorso did provide usage hints: When you unpack the attachment, you'll find a wget.exe binary; the way the batch file is written, wget.exe needs to be in your %PATH% (... environment variable, read more in Wikipedia ); if you don't want to manually add it to %PATH%, you can place that binary inside a directory already in %PATH%: @dencorso's suggestion was %windir% = %SYSTEMROOT% which should default to "C:\Windows", if your OS is indeed installed in the C drive... The second line of the .cmd file changes your working directory to your %TEMP% folder ("Temporary Files" folder, should default to "C:\Users\<YourUserName>\AppData\Local\Temp"), where, of course, there's no wget.exe to be found : pushd %temp% This is why it is imperative you place wget.exe in a directory Windows already has in %PATH%, so it would know where to invoke it from... Apologies for possibly sounding a bit harsh (... rest assured I mean well), but, unless you have some sort of learning disabilities (which if true, I profusely apologise for), almost everything new one wants to learn about is already there in the web, accessible with a bit of searching... Hope I've helped!

Very much like MSE 4.4.304.0 (manually) installed on Vista SP2, the native anti-spyware implementation, aka Windows Defender, ceased receiving definitions update via Windows Update itself sometime after the July 9th deadline; as posted here, the last def update (v1.297.531.0) I got through WU was on July 6th... Similarly, invoking a manual definitions update via the WD GUI: always results in So, currently, the ONLY way of updating WD def files on Vista SP2 is by manually downloading file mpas-fe.exe and then running it (probably "as administrator", but I wouldn't know differently, as I am already the unique admin of the machine!). The location for fetching the file is again https://www.microsoft.com/en-us/wdsi/definitions but in WD's case, it's the "Windows Defender in Windows 7 and Windows Vista" entries... Have you noticed the "Windows Vista" mention? Unlike Windows XP, M$ have still kept file mpengine.dll (inside file mpas-fe.exe) Vista compatible, so they kinda "silently" have continued to support Vista even past its Extended Support EoS, so I was genuinely taken aback (and then miffed) they broke automatic updates for Vista's WD... I have Vista SP2 Home Premium x86 (without the very recent ".6003" WS2008 updates) and hovering over the win32 link I see the following URI: https://go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x86&eng=0.0.0.0&avdelta=0.0.0.0&asdelta=0.0.0.0&prod=925A3ACA-C353-458A-AC8D-A7E5EB378092 What's really weird is that clicking that link (during the last 2 weeks or so) has not always fetched the version claimed to be the latest in the page; e.g. the page may announce v1.299.301.0 as available, but downloading from the win32 link may get me an older version on disk (usually 3-6 "units" older, e.g. 1.299.296.0 etc.). To mitigate this, I have found the link in article https://www.askvg.com/how-to-update-windows-defender-offline-install-latest-virus-definition-files-manually/ to be very reliable in faultlessly fetching the version advertised as the most current : https://go.microsoft.com/fwlink/?linkid=70631 Alternatively, I would manually construct https://definitionupdates.microsoft.com/download/DefinitionUpdates/VersionedSignatures/AM/1.xxx.xxx.0/x86/mpas-fe.exe getting the "1.xxx.xxx.0" string from the downloads page... @dencorso: Many thanks indeed for your .cmd file ; however, be advised you only considered the x86 flavour of the definitions update file; it won't do for MSE 64-bit, the preferred default on Vista x64 installations... I also took the liberty of mimicking it for my own purposes, creating a WDUPD_Vista.cmd variant: @echo off ::pushd %temp% if not exist mpas-fe.exe start /min /wait wget -O mpas-fe.exe http://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe if exist mpas-fe.exe start /min /wait mpas-fe.exe del mpas-fe.exe ::popd I commented out your second line, because that way one doesn't have to place wget.exe in the %PATH% variable, just leave it be adjacent to the .cmd file, both in a user writable directory! Again, this is for the 32-bit architecture only... Thanks a bunch !

... Just being pedantic here, but usually an SSLlabs Server test will reveal what's really wrong with https://tipsterarea.com/ https://www.ssllabs.com/ssltest/analyze.html?d=tipsterarea.com ... i.e. the server does support old TLS 1.0 protocol (so "TLS 1.1/1.2 checked" is irrelevant here) with 4 cipher suites, TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 2048 bits FS WEAK 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH sect571r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 2048 bits FS WEAK 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH sect571r1 (eq. 15360 bits RSA) FS WEAK 256 ... 2 of which don't use ECC, but the real breaker here is to be found, as correctly pointed out by previous posters, under the Handshake Simulation section: IE 8 / XP No FS No SNI Server sent fatal alert: handshake_failure

Well, actually "my" fault was my query arguments were simply worded as "change system drive letter" and the two links posted were harvested from only the first two result pages Google came up with... The original Microsoft help article you linked to uses the verb "restore", so that's probably why it was not suggested to me right away ... Once again, many thanks for a very erudite/informative post on the subject at hand!

... Does this mean Vista will be left out? Was the 7GB figure for both 32-bit/64-bit architectures? If affirmative, perhaps separate standalone uploads for only x86 and only x64 should be attempted... Thanks, regardless...

... NOT possible via Disk Management! Your search engine of choice is usually your friend in cases like these... Possibly helpful: https://www.itprotoday.com/compute-engines/changing-windows-system-drive-letter https://www.petri.com/change_system_drive_letter_in_windows_xp As stressed in the articles themselves, "make a full system backup of the computer and system state."

Mea culpa, then (memory betrayal to be exact) ... ... thanks for explaining!