VistaLover

... I was always intrigued by these Win7->WinVista transformation packs, although applying them appeared to me to be a tad over my skills; also was/am unsure of their impact on the whole OS performance. With Win7 reaching EoS in 5 months, they sort of look as moot to me now... My 2007 Toshiba laptop (originally with Vista 32-bit OEM) is now on its dying bed ; hardware is quite outdated compared to 2019 requirements (embedded gfx card doesn't even have h264 hardware decoding capabilities, so all video decoding is delegated to the CPU ) and despite some 2015 hardware upgrades (replacement of the original 128GiB HD with a 500GiB one, RAM augmented to 3GiB from 2GiB, repair of the screen etc.), the OS has become corrupted and sluggish; I am not prepared to invest more money on the machine/OS (also taking into consideration the miserable state of Vista with regards to current software support), the only realistic option would be to, sadly, move on to a recent laptop model with, no doubt, Win10 ()... Now, I know that a Win8[.1]->WinVista transformation pack does exist, because @WinClient5270 was using it on his machine, although I'm not sure a video tutorial has been created for it ; if a Win10->WinVista TP had been available by now, it would be an idea I would gladly entertain, as I simply and utterly loathe the abomination that is the Win10 interface! But then I wake up and realize one is not likely to appear, given the nature itself of Win10, "Windows As A Service", not a finished product, rather a constantly evolving "beta" OS (for which updates are massive and difficult to control; with every major OS update, the TP would probably break... ).

Thanks; it is essentially a SSUAO (UA the same as the one I'm using, for URL[site] https://web.skype.com/) issued via command line switches... Yes, Chrome and forks, without specialised extensions, rely on the proxy management wizard provided by the OS (the one under IE's Tools -> Internet Options -> Connections tab); the same is true, as I'm sure you're aware, about the certificate store/management... Never a Chromium fan myself, TBH...

... At the risk of sounding repetitive and/or tiring, I can confirm, once more, that Web Skype works as expected in my FirefoxESR 52.9.1 32-bit copy, under Vista SP2 32-bit: The date/time at the tray area reads Friday Aug 16th 2019, 17:39 EEST (= UTC+0300, BST+0200) No UA modifying extension used, but the two ".js file" method and the SSUAO reported here @Dave-H: As advised, please test either Serpent 55.0.0 or Serpent 52.9.0 (both by @roytam1) with a SSUAO (either mine or the one proposed by @Mathwiz), so you/we could gather additional info; if you experience the same Skype failures in Serpent (while for others, including myself, Serpent does work for web.skype.com), then we can safely assume the issue is not specific to FxESR 52; FWIW, the fact Google Chrome 49 does work (I suspect with a UA changing extension, no doubt!) excludes ISP/IP address related issues...

I don't have the exact answer to your query, but Wikipedia suggests the last version that would run in Windows 2000 is 4.11 (released on Feb 2012); then you could use trial-and-error with the winrar versions > 4.11 available in their ftp server: ftp://ftp.rarlab.com/rar/ to precisely locate the last versions compatible with XP RTM/XP SP1 ; be advised, old winrar versions have known unpatched (and exploitable) vulnerabilities, but I suspect this isn't high in your priorities... Regards (OT: What an exotic place to live in )

@Dave-H, @Mathwiz I conducted several tests with Firefox ESR 52.9.1 x86 (on Windows Vista SP2 x86) and I concluded that I had no issue whatsoever loggin' in and connecting to a skype account, starting from the web.skype.com URI First, loading the URL with my dirty profile, without a SSUAO: As expected, I get the "Browser not supported" message . As posted elsewhere in these forums, in my FxESR 52.9.1 copy I'm not using any extensions to apply SSUAOs, instead I have implemented the two .js files manual patch, to re-initialise the dormant relevant browser module. As such, in about:config I simply created the following string user pref: general.useragent.override.skype.com;Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36 BTW, @Mathwiz is right: Also, I did not have to create a SSUAO for the "*.live.com" domain, either... Just trying anew the web.skype.com URL, I am now presented with the login.live.com sign-in prompt: After the skype username and skype password have been (successively) successfully input, I had no issues connecting: I very much doubt this is an XP vs Vista case, my tests solidify my opinion that the predicament under which @Dave-H finds himself is probably caused by something at his end... I would restart router to get a new IP, restart the OS (this seems to be a cure-all ), restart browser, clear again browser cache and cookies; if all fails, then I would suggest starting with a new, clean, browser profile and testing there (obviously, at least one UA changing extension must be installed, or the .js files method applied). Often times, simply disabling content blockers and/or security extensions is not enough on its own... Also, has attention been paid to my previous tip: Cheers

I won't take an oath, but it's highly probable! Having grown up in Greece, I don't harbour such discriminatory preconceptions; in the grand scheme of geopolitical/historical things, Greece as a nation/state hasn't had a true ally (and you just have to simply study the last 300 yrs of European/global history to easily conclude that); has always been a pawn on the world's chessboard; the big powers of each era just manipulated Greece in a way to better suit their agendas, with Greece ending up being the party with the bigger losses... To return to the topic, using Windows 10 (possibly previous versions, too) and/or a Google product, some of your sensitive data are bound to be stored in some US-owned server, the NSA/FBI/CIA or any other federal agency would have little trouble accessing it if you somehow found yourself under their spotlight. Similarly, some of the Russian software may store sensitive user data to Russian servers and make them accessible to state agencies, that is if you somehow attracted their interest; of course, it is broadly known that this phenomenon (regime spying on internet users) is much more widespread with Chinese browsers, so one should always keep this in mind... I am not likening Trump's USA to Putin's Russia, certainly none of them to Jinping's China; but to me, "superpowers" are just that, more or less they'll have their way irrespective of my beliefs... And really, in the year 2019, do you still consider Russia as an adversary nation? In fact, I quite like Yandex.Browser and have even installed it in my sister's Win7 machine, instead of Google Chrome. The GUI is pleasing (also has a dark theme in the Win7 compatible version), has compatibility with both Opera and Google Store (for installing extensions), the English localisation is quite good and it's very easy to de-Russify (which isn't the case with the Chinese browsers). All in all, quite pleased with it (... and President Putin can freely read all of my MSFN posts, I don't mind ). About Torch browser: Latest offline installer is of version 69.0.0.1674, as posted; of course, I didn't try to run it, instead unpacked it like @win32 with 7-zip; the chromium binaries are deeply buried in the directory tree, after several more decompressions, I was finally able to test chrome.dll with Dependency Walker: As you can see, many missing functions in three implicitly dependent modules (kernel32.dll, shell32.dll, user32.dll), missing delay-load dependency modules, missing functions also in some of them; in other words, it won't run in Vista. Now, some previous versions forked on Chromium <=50, if were to be found, might actually run in Vista but, frankly, I'm not interested...

... And I'm so tired reading that same ol' mantra there: As if they (third party software developers) would give one nickel whether someone's setup is secure or not; what is the underlying truth inside this PR talk is that Microsoft themselves make it gradually impossible for third party software developers to target older OSes with their (M$'s) updated Windows SDKs! ... and it always comes down to that! Win7 will soon reach End of Extended Support, hence it'll also be "outdated and unsupported by Microsoft", with no more "security patches"; what is their stance on Win7? Security reasons my... behind!

"web.skype.com" logs in and works as expected in Serpent 52.9.0 using the following three "Chrome73 on Win10" SSUAOs: general.useragent.override.skype.com;Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36 general.useragent.override.skypeassets.com;Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36 general.useragent.override.live.com;Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3163.100 Safari/537.36 In times of trouble: 1. Wait and re-try, if possible, at a later time; more often than not, I have found it to be some intermittent issue with their servers 2. Clear cache and skype related cookies, restart browser, wait a minute and re-try... 3. Clear any skype related folders in your browser's "<ProfileDir>\storage\default" directory, restart browser and re-try... Hope I've helped

Buone vacanze! ... I see ... and no worries, software debugging can certainly wait!

@Windows Vista Welcome to MSFN forums Yandex.Browser already covered in the first post of this thread: The link provided in that first post, as well as the link one gets when visiting https://browser.yandex.com/ with an XP/Vista User Agent string (*NT 5.x*/*NT 6.0*) is for a stub (on-line) installer! Official download link for off-line (Full/Standalone) installer, for version 17.4.1.1026: http://download.cdn.yandex.net/browser/update/17_4_1_1026_2644_w_s_m/yandex.exe 17.4.1.1026 is built on Chromium 57.0.2987.1026 source and is the last officially supported version on Vista; however, it is not the latest version that can be reliably run on Vista (but not XP); that one is version 17.6.0.1633, built on Chromium 58.0.3029.1633 source: Most sadly, it has proven impossible to locate a stub and/or full installer for that version, thankfully a third party portable (PAF) package has been archived in SourceForge (and is the one used here ): https://sourceforge.net/projects/thumbapps/files/Internet/Yandex%20Browser/YandexPortable_17.6.0.1633_on_Chrome_58.0.3029.1633.paf.exe/download Considering latest Yandex.Browser (19.6.1.153) is based on Chromium 74.0.3729.15 source, version 17.6.0.1633 should be considered deprecated/insecure by today's web standards; be that as it may, I find most websites render OK, with the exception, of course, of github.com (since they insist on always using the cutting edge version of Javascript code); if you spoof your UA to being FirefoxESR 60.x.x, even github works OK (but I suspect this hack will soon break, as FxESR60 will reach EoL towards the end of this month...). Cheers

... But you do have access to a Win10 machine, you've posted screenshots of it (running latest Chrome...) ; does latest PotPlayer work as intended there?

Cliqz is just a German Mozilla Firefox fork, based on release branch source; they follow upstream development with religious dedication and are keen on removing older versions from the web, for security reasons; yet their notion of privacy/security as implemented in their product can attract lots of criticism; infamous was the Cliqz test pilot experiment pushed in Germany in 2017 by Mozilla to several unsuspected Firefox users: https://www.zdnet.com/article/firefox-tests-cliqz-engine-which-slurps-user-browsing-data/ As you can imagine, latest (and only one offered) version is Quantum based, excluding any Vista compatibility ; Vista/XP are not supported since 2017, as per their statement: https://cliqz.com/en/support/support-ende-windows-xp-und-vista Use Fx ESR 52.9.0 with the "Cliqz extension for Firefox" ? Thanks, but NO thanks... As for lawlietfox, it's just as it is described in the SF link: ... So the developer (I think he's Chinese) has implemented basically PGO on top of vanilla Firefox, where: PGO = Profile Guided Optimization (more here ) ... All in all, nothing really exciting about either lawlietfox or Cliqz browsers, at least for the Vista community...

Many thanks for testing! (... but sorry for the negative result on XP ; would it even install at all?) ? I kind of lost you there When I visit https://www.kaspersky.com/free-antivirus I now get offered the same product as when visiting page: https://www.kaspersky.com/free-cloud-antivirus (this wasn't the case some weeks ago...) Both DOWNLOAD NOW buttons (red in the first URL, green in the second one) offer the same free product, labelled Kaspersky Security Cloud – Free (not KFA 2020, not SAAS), one ends up downloading a stub installer named ks3.020.0.14.1085aen_18801.exe Some localised Kaspersky sub-sites, e.g. the UK (and Greek) one, haven't yet updated, so on https://www.kaspersky.co.uk/free-antivirus you are still being offered Kaspersky Free (Antivirus), this is KFA2019 (19.0.0.1088aben, includes patches a+b, en-GB GUI), the stub installer downloaded is named just startup_14833.exe Where have you accessed KFA2020 ? ... and about SAAS; do you mean SaaS (Security as a Service) ? Which other free Kaspersky product is that? Thanks for any elaboration... In practice, mostly true, with two exceptions: 1. installing: Though hidden by Kaspersky Labs, one might find off-line installers, too (both official and RePacks); e.g. the link for KFA2018 provided by @pcalvert yields an off-line (full) installer. 2. activating: You only need activate (probably) once a year - I can't seem to find literature on off-line activation (was possible with older Kaspersky products, which used key files; might be still possible by using third party tools like KRT Club). 3. updating: See my post here for a way to update KAF2018/KAF2019 off-line Best regards

... Maybe not officially, but it has already been reported as running fine there: KFA2019 = v19.0.0.1088 As pointed out already, both KFA2018 & KFA2019 require .NET FW 4.0 on XP... FWIW, there isn't going to be a KFA2020 version, the free product has been rebranded as "Kaspersky Security Cloud - Free" recently: https://www.kaspersky.com/free-cloud-antivirus https://www.kaspersky.com/downloads/thank-you/try-free-cloud-antivirus It also doesn't support XP officially; any brave person here with a curiosity to test it on XP?

Oddly enough, the Cloudflare representative there (member @sandro MVP) suggested the following test: http://sitemeer.com/#o.rths.cf which claims that among European locations, o.rths.cf is being inaccessible from only the UK (Slough) CF node, with Italy (Arezzo) supposedly in the clear! It'll be a tough one to crack, for sure...

Many thanks for checking this out With all due respect, how is this going to contribute to current/future bug resolution on the UXP platform, that we also share here? 1. Moonchild won't accept bug reports if they came from unbranded forks (NM28+St52) users (if you ask me, he himself should test if present in his official builds, before dismissing those users, but all parties here realize this is never gonna happen!) 2. Effort has been taken recently in these forks (with initial requests by @TechnoRelic and other members, put in place by PRs kindly authored by @Mathwiz) to direct all issue reports here and, ultimately, to have them reviewed by the forks' maintainer, i.e. you 3. I'd argue that the majority of the fork(s) users do so because, either by choice or necessity, find themselves using an OS not sanctioned by the upstream devs (namely XP and Vista), and who (which is currently the case with me) don't have immediate/easy access to the officially sanctioned/supported OSes (Win7+). 4. Moonchild, in general, dislikes people posting issues directly in his GitHub issue tracker (apparently only reserved to a team of selected developers/"sidekicks"), instead prefers his users to post first to the official forum, and then he could "triage" them there as he sees fit . My humble opinion is that you should post the issue in the forums, with concrete proof it was diagnosed in an official build (so, no references or links to here); that way, Moonchild will have no justification to dismiss the bug report, even if it came from his worst enemy on this planet (which, obviously, you're not! ). I see only two other approaches: 1. Somehow push code yourself to your custom UXP branch to rectify reported issue(s) on your own. 2. This broader community is otherwise in need of a person/member that: a. Has a (whitelisted) official forum (forum.palemoon.org) account b. Optionally, has also a GitHub account c. Is a user of a UXP forked application, namely New Moon 28 and Serpent 52.9.0 d. Has easy access to an OS that supports the official counterpart applications, i.e. Pale Moon 28 and Basilisk 52.9.20xx.xx.xx) e. Is able to reproduce/confirm bugs (found initially in the forks) in the official builds. f. Is able to post a no-frills coherent report in the forums, and then let MCP et co. do the rest FWIW, last time I asked a favour from such a person, he kindly declined (and I have no right whatsoever to blame him...). Again, this is NOT about my petty bug (for which I've already found and posted a working fix); it's about the course of actions one is supposed to follow with regards to meaningful UXP bug report and hopeful resolution! Thanks again for your time reading this, thanks eternally for your efforts and binaries (... back now to deploying a strategy on how to combat a 42 Celsius heatwave pestering us for the next two days )

@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