Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/10/2020 in all areas

  1. First thing I want to say is that I agree with @Vistapocalypse that your query ("How to get MSE running on XP SP3 in August 2020") does NOT belong in this thread... But having seen your failed attempts at this endeavour being spread at various places in the MSFN forums, let me "put you out of your misery" ( ) by offering you an abridged version of the story of MSE on XP (more detail can be found towards the last pages of the relevant thread linked to by @Vistapocalypse ) : 1. M$ continued to offer definition updates for MSE/WD on XP SP3 automatically through Windows Update for approximately two years after the OS was EoS'ed ! This fact alone upsets me tremendously to this day because we, Vista users, were not offered a single day of additional support by MS with regards to MSE! (the very last version of the app compatible with Vista contains a trigger/time-bomb that completely locks it after the OS EoS date! ) ; we're seeing the same thing again with EoS'ed Win7 SP1, which continues to receive MSE defs via WU! 2. When WU stopped offering MSE defs on XP, updated defs had to be manually downloaded from MS's Security Portal https://www.microsoft.com/en-us/wdsi/defenderupdates and applied by the user. Community enthusiasts and an esteemed member here in MSFN created automation for that procedure, so XP users were kept happy for a while longer... 3. Before I proceed with the story telling, let us focus on the offline defs file itself, mpam-fe.exe ; this is comprised of 6 constituents (you can extract the .exe with 7-zip) mpasbase.vdm mpasdlta.vdm mpavbase.vdm mpavdlta.vdm mpengine.dll MpSigStub.exe ALL these files are digitally code-signed by MS against MS root certificates and are verified by the OS that they haven't been tampered with before they are allowed to be applied/update MSE; any attempt to modify these files renders them invalid; but more of that later... .vdm files contain the actual antispyware/antivirus definitions, either in full (mpasbase.vdm, mpavbase.vdm) or delta (differential) formats (mpasdlta.vdm, mpavdlta.vdm); mpengine.dll is the most important constituent, i.e. the AV engine inside MSE which does get updated from time-to-time (and partly mitigates the fact that MSE itself hasn't been updated for quite a long while now... ) . 4. With a specific mpengine.dll update, M$ dropped a nuclear weapon on WinXP users of MSE, because the updated DLL contained new functions not found under XP, only under Vista+ (thankfully for us Vista users.. .) You can probe yourself the mpengine.dll file under XP with Dependency Walker... Hence, newer/updated versions of mpam-fe.exe would not succeed in installing, after that failure MSE would revert to the last working defs+engine. 5. MSE on XP was then stuck with a stale version of engine+definitions and, as time went on, started nagging about that fact... As with all signature-based antimalware solutions, the software itself becomes ineffective at protecting you from the ever evolving online threats... 6. A desperate solution was given some consideration, that is using the last compatible mpengine.dll file coupled with updated .vdm files (extracted from an updated version of mpam-fe.exe), but this was actually "a hole in the water" kind of thing, because updated .vdm files also demand an updated engine to work, i.e. both are interlinked! 7. So here we are now: MSE on XP dead and buried! 8. In the following months, M$ introduced further changes to the defs installer, mpam-fe.exe: 8a : The "Subsystem version" value in the PE header was raised to 6.0 (Vista+); this is the main reason you get the "is not a valid Win32 application" error on trying to launch it; lowering that SubSysVer to 5.1 (XP) will accomplish NOTHING, because of two reasons: one is the incompatibility of the mpengine.dll with XP's kernel, discussed in 4 above; the other reason is: 8b: Starting on the weekend of 19/20 Oct 2019, the standalone mpam-fe.exe file as well as all of its constituent files are ONLY being code-signed with a SHA-2 digest algorithm; no matter what you do, you can't get SHA-2 support under XP (and on Vista SP2 you must install select WS2008SP2 updates, as I'm sure you know by now...). Do you now see why this quest of yours is totally futile? Please, lay it to rest... As for some other points you made, M$ don't keep/offer an archive of deprecated mpam-fe.exe versions; in all honesty, what good would that be to anyone, security-wise? In a total hypothetic scenario, you would need first an XP Extended Kernel solution that will restore XP compatibility to mpengine.dll , plus backporting SHA-2 code-signing support to XP; I've seen stranger things happen, but you shouldn't hold your breath on both of these... For the benefit of the whole community, I have re-uploaded that at below link: http://s000.tinyupload.com/index.php?file_id=60954865039051356545 (included is a custom batch file; place the modified PE inside FixPEC folder and run .cmd; as with everything downloaded from the internet, please first scan with a reputed AV software; I can assure you the file that was uploaded by yours truly was safe...)
    2 points
  2. ... You must've gotten the wrong file, then... "mpas-fe.exe", whether 32 or 64-bit, is the standalone offline installer for updated anti-spyware (as) definitions; this file should only be used to manually update Windows Defender, Vista's native anti-spyware solution! "mpam-fe.exe", whether 32 or 64-bit, is the standalone offline installer for updated anti-spyware (as) + anti-malware (am) definitions; this file should only be used to manually update MSE (NB that when MSE is first installed, WD is being de-activated, so as not to conflict with MSE, which is both an anti-spyware and anti-malware solution!) You should probably only download from the (revamped) Microsoft Security Intelligence portal: https://www.microsoft.com/en-us/wdsi/defenderupdates Definitions for MSE there get updated 3-5 times during the course of 24h, but probably once a day is a sane frequency to manually update... You can read the Release Notes below: https://www.microsoft.com/en-us/wdsi/definitions/antimalware-definition-release-notes ... for latest as well as the previous 19 releases...
    1 point
  3. Hi @SIW2 When I first quickly read your post as an e-mai notification, I must have got it wrong , believing that the "is not working" bit meant that the whole app itself somehow stopped working ; this doesn't seem to be the case, most fortunately! The "it cannot install the definition update." bit I believed it to mean that the MANUALLY downloaded "offline" standalone defs updater, file mpam-fe.exe, ceased being able to be run/installed; that doesn't seem to be the case, either... By "It was fine yesterday" do you actually mean that before August 9th, 2020, MSE on your Vista SP2 install was able to (automatically/manually) fetch and install updated MSE definitions via Microsoft/Windows Update (that's what the big "Update" button does, it searches MU)? If affirmative, that would be the first such mention... On my own system, MS/WU quit fetching anything in mid-July of last year, and that included Windows Defender (WD) defs updates... Installing SHA-2 code-signing support to the system, alas, did not change things... You obviously have SHA-2 code-signing support installed, if you were able to get current (prior to Aug 9th) defs updates installed; but that support augments Vista's build number to 6.0.6003, and WU (when it worked) gave it the cold shoulder; that's why I'm quite sceptical of your report.. In any way, Error 0x80244019 when checking manually for defs updates in MSE is because dear M$ has shut down the WU infrastructure for Windows Vista ; this has been reported and detailed elsewhere in the MSFN forums... (EDIT: @Vistapocalypse posted while I was in the middle of composing this message...) The only solution is to download manually (e.g. once daily) the standalone updated definitions installer, mpam-fe.exe, from MS's security portal: https://www.microsoft.com/en-us/wdsi/defenderupdates and run that file to get you up to date... (Scroll down to the MSE section and select the bitness of installed MSE; download and run file mpam-fe.exe) Please report back, MSE on Vista SP2 shouldn't be dead yet! @Dylan Cruz , what is the situation there?
    1 point
  4. Official announcement: https://techcommunity.microsoft.com/t5/windows-it-pro-blog/sha-1-windows-content-to-be-retired-august-3-2020/ba-p/1544373 Opinion: https://virtuallyfun.com/wordpress/2020/08/04/microsoft-to-delete-legacy-updates-in-the-great-sha-1-purge What a sad day!
    1 point
  5. @Dylan Cruz Mse is not working on my vista system today 9th August. It was fine yesterdy. Gives a message that it cannot install the definition update. Perhaps MS have nobbled it.
    1 point
  6. Got the Chromium 72 built into the Oct 2nd 2019 Steam to work, but with one major issue I put the Windows 7 x64 CEF into the XP CEF folder, so Steam loaded it, then I used -no-cef-sandbox Will try this with Chromium 76 Steam
    1 point
  7. The updates that say pt-pt or ptg are in Portuguese. All others are language neutral. In fact, the Ultimate Extras are language neutral (forgot to change the folder names). I'd estimate only an extremely small amount of them are specific to my language. Just install the "cab" files through pkgmgr. Works just like you installed them through Windows Update. If you give that Ultimate Extras folder to your friend, he should know how to integrate them into the ISO. I did go multiple times through this list at the time I compiled it, but I'll try to see what daniel_k has.
    1 point
  8. Now that MSE 4.4 is seven years old, an opposing viewpoint on the importance of green colors comes along.
    1 point
  9. https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-redirection Just like the thing I did to fix SHA-2 encryption in Office 2007 in Windows 2000, you can create a *.exe.local file for each office application and copy dssenh.dll to the office14 directory, along with possibly older versions of crypt32.dll, schannel.dll and rsaenh.dll.
    1 point
  10. @Dave-H and @Dylan Cruz I've fixed it! Found an easy way to fix Office 2010 and not break TLS updates. Get KB3081320 from WU Catalog, extract it and copy dssenh.dll to C:\Program Files\Microsoft Office\Office14. That's it.
    1 point
  11. Turns out you CAN have your cake and eat it too, actually: Thanks to @daniel_k for figuring this out: Get KB3081320 from WU Catalog, extract it and copy dssenh.dll to C:\Program Files\Microsoft Office\Office14. If that doesn't work, copy it into system32 using Replacer and reboot
    1 point
  12. My first thought is that you should use an antivirus for XP that can still receive definition updates. My second thought is that you should be posting in the Windows XP forum instead of the Windows Vista forum.
    1 point
  13. New build of BOC/UXP for XP! Test binary: MailNews Win32 https://o.rths.ml/boc-uxp/mailnews.win32-20200808-abd05332-uxp-b5762c6c2-xpmod.7z Browser-only Suite Win32 https://o.rths.ml/boc-uxp/bnavigator.win32-20200808-abd05332-uxp-b5762c6c2-xpmod.7z source repo (excluding UXP): https://github.com/roytam1/boc-uxp/tree/custom Official repo changes since my last build. - [Mail] Remove telemetry hooks from application code (cfc6f01d) - Update platform commit pointer (1298d3a9) - [Mail] Remove unused showWhatsNewPage function from specialTabs (e0936181) - [Navigator] Move preferences to components (7bfe4247) - Update platform commit pointer (3e935f5b) - Issue MoonchildProductions/UXP#1625 - Enable MOZ_MAILNEWS_OAUTH2 in confvars.sh for Interlink by default (24506be3) - Remove the suite help viewer (ea91dcf4) - [Navigator] Follow up to ea91dcf4 - Remove suite help viewer from themes (c887dce0) - [Navigator] Remove some left over mail junk (f8c3b451) - [Navigator] Don't show the context separator for images on standalone image page (800c10fb) - Move block images context menu item (5fc40daf) - [Navigator] Remove more help related unused overlays (c8a42be8) - [Navigator] Move prefwindow binding to components/preferences (3629371a) - [Navigator] Move directory to components (0789c38f) - [Navigator] Follow up to 0789c38f - Move locale for directory to components (a79f037f) - [Navigator] Remove duplicate file (170da409) - [Navigator] Move security prefpanes to components/preferences (227f01f8) - [Navigator] Reorganize the preferences window (1191b51f) - Update platform commit pointer (be282eb6) - [Navigator] Change most Contract IDs (1f530ded) - Update platform commit pointer (dd43811e) - Issue MoonchildProductions/UXP#1628 - Remove extensions.update.background.url from mail preferences (fddb8cd1) - [Navigator] Branding prefs (d6ef0213) - [Navigator] Don't bi*ch about being old and insecure if there is no update service to be had. (41ffb47a) - [Navigator] Remove Shell Service and Windows Installer (abd05332) My changes since my last build: - Reverted "Issue MoonchildProductions/UXP#1628 - Remove extensions.update.background.url from mail preferences (fddb8cd1)" -- New build of IceApe-UXP for XP! Test binary: https://o.rths.ml/gpc/files1.rt/iceape.win32-20200801-id-eed056673-ia-41157bf-uxp-091749192-xpmod.7z for UXP changes please see above.
    1 point
  14. New build of Serpent/UXP for XP! Test binary: Win32 https://o.rths.ml/basilisk/basilisk52-g4.6.win32-git-20200808-57e81f0-uxp-b5762c6c2-xpmod.7z Win64 https://o.rths.ml/basilisk/basilisk52-g4.6.win64-git-20200808-57e81f0-uxp-b5762c6c2-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rths.ml/basilisk/basilisk52-g4.6.win32-git-20200808-57e81f0-uxp-b5762c6c2-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rths.ml/palemoon/palemoon-28.10.1a1.win32-git-20200808-5f05a0799-uxp-b5762c6c2-xpmod.7z Win64 https://o.rths.ml/palemoon/palemoon-28.10.1a1.win64-git-20200808-5f05a0799-uxp-b5762c6c2-xpmod.7z Official UXP changes since my last build: - Issue #1621 - Part 1: CSSEditUtils should use atom for CSS property if possible. (baa4b609d) - Issue #1621 - Part 2: Implement nsIAtom version of SetAttribute/RemoveAttribute/CloneAttirubte. (1c0c7cf58) - Issue #1621 - Part 3: Use nsIAtom to change attirbute if possible. (1115c63bf) - Issue #1621 - Part 4: Check whether node can be splited. (5f6ecd756) - Issue #1619 - Convert Intrinsic Ratio to Float (232f987cf) - Use an alt script to properly determine the OSX SDK version (c3ec6c613) - Add license header to media/webrtc/trunk/build/mac/find_sdk_uxp.py (02bd56c44) - Issue #1619 - Missing Dimension Computation (e664d4369) - Issue #1619 - Add Vertical Writing Testcase (ba0a2e796) - Issue #1619 - Nits Picked (a90b8d98e) - Merge pull request #1622 from RealityRipple/master (2e1c5dafc) - [js] Try to catch bad pointers for GC and bail if not valid. (8d38e3575) - Issue #1625 - Allow MailNews Oauth2 support to be configured in confvars.sh (7c6d822be) - Merge pull request #1623 from g4jc/libeditor_patch (267d32f4f) - Issue #1628 - Remove redundant PREF_EM_UPDATE_BACKGROUND_URL (d357eec56) - Pref and disable getRootNode() (b5762c6c2) Official Basilisk changes since my last build: - Update Back-end branch pointer (c15535d) - Issue MoonchildProductions/UXP#1628 - Remove extensions.update.background.url from preferences (57e81f0) Official Pale-Moon changes since my last build: - Update back-end branch pointer (2762ee9d5) - Issue MoonchildProductions/UXP#1628 - Remove extensions.update.background.url from preferences (5f05a0799) My changes since my last build: - Revert UXP issue 1628 related changes. (35f288dc4)
    1 point
  15. Who's "we"? MSFN's policy is simple: we do not propagate FUD. Period.
    1 point
  16. Original January 4, 2019 post title was "Update IE8 to TLS1.2 for (nearly) Last Skype 7.36.0.150 on Windows XP". Update title changed May 1, 2019. Readers wanting Skype-specific info should page or find down to the ORIGINAL INTRODUCTION. UPDATE INTRODUCTION: This compiled procedure, Instructions To Add TLS1.2 To Windows XP OS & IE8, turns out to be useful for non-Skype purposes, and may now be obsolete for the intended purpose of running Windows XP Skype 7.36.0.150 (see posts below). For convenience of other readers, I've reorganized the original post so that the procedure steps now start near the top. I've also edited OS registry variations in steps 9A and 9B, made a change in step 11, and added a 12th procedure step, each helpfully noted by posters below. ----------------------------------------------------------------- INSTRUCTIONS TO ADD TLS1.2 TO WINDOWS XP OS & IE8 (Compiled from MSFN source posts credited) ----------------------------------------------------------------- 1) If not already updated, download and install Microsoft's updated Windows Installer 4.5 (KB942288-v3) from https://download.microsoft.com/download/2/6/1/261fca42-22c0-4f91-9451-0e0f2e08356d/WindowsXP-KB942288-v3-x86.exe 2) Set a System Restore point marked, say, "Spoof POSReady ID registry edit" 3) Put the following POSReady spoof text (omit the hyphen lines) in POSReady.txt, rename to POSReady.reg, right-click Merge, Yes. ---------- Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady] "Installed"=dword:00000001 [<-- BLANK LINE] [<-- BLANK LINE] ---------- 4) Navigate to: https://www.catalog.update.microsoft.com/search.aspx?q=kb4019276 5) Find down to POSReady, Windows XP Embedded versions of KB4019276 Click Download button for that version. Click English in the opening language window (or other language). 6) Navigate to: https://www.catalog.update.microsoft.com/search.aspx?q=KB4230450 7) Find down to POSReady, Windows XP Embedded versions of KB4230450: Click Download button for that version. Click English in the opening language window (or other language). 8) For each KB file: click, accept install, reboot. (Both create restore points just in case.) 9) Edit the following Windows XP registry entries in 9A and 9B to read as shown. If you aren't sure how, look up Regedit 5 editor instructions. For convenient automatic registry edit-merge, these lines may be pasted into Notepad text files, renamed .reg ,then just click the file after closing it (expect no response). (But to be careful, I edited them manually with Regedit 5.) 9A) After navigating the chain of registry keys, click the key TLS1.1, in the right panel, right-click "OSVersion", click Modify, enter the Value data already shown (not sure why), click OK. (I had to change "3.6.1.0.0" to "3.5.1.0.0" shown in obvious German in the source.) (EDIT: Other posters report below that if this key is absent, this step may be safely skipped.) ---------- [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.1] "OSVersion"="3.5.1.0.0" ---------- 9B) Next click the key TLS1.2, in the right panel, right-click "OSVersion", click Modify, enter the Value data shown above, click OK. (Likewise I had to change "3.6.1.0.0" to "3.5.1.0.0") (EDIT: Likewise, if missing, skip this step.) ---------- [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\AdvancedOptions\CRYPTO\TLS1.2] "OSVersion"="3.5.1.0.0" ---------- 10) Click Start, hover Control Panel, click Internet Options, Advanced tab, pull the thumb bar all the way down. You should see new checkbox options for "Use TLS 1.1", "Use TLS 1.2". (KB4230450 will install these checkboxes, but they won't work without KB4019276.) 11) Check "Use TLS 1.2". Leave unchecked "Use TLS 1.1" (already obsoleted by TLS 1.2; and, TLS 1.3 was approved in 2018). (EDIT:) Leave checked "Use TLS 1.0". Click OK. The TLS 1.0's AES component is not insecure. TLS 1.0 may best remain checked for legacy websites needing AES or 3DES. (See explainers in posts below.) 12) (EDIT:) The following registry edits disable TLS 1.0's insecure cipher suites: DES, RC2, RC4, plus the insecure MD5 cipher hash. 3DES may be disabled optionally, but legacy websites without AES may need 3DES (Triple DES). TLS 1.0's secure cipher suite AES remains enabled, unchanged (no edit shown). Edit the following registry entries to read as shown: ---------- [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5] "Enabled"=dword:00000000 ---------- You may need Triple DES (3DES) at websites which don't (yet) support AES. Here is the optional edit (not yet recommended) to disable 3DES (0's mean Not "Enabled", equals Disabled): ---------- [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168] "Enabled"=dword:00000000 ---------- The above registry edits (manual for transparency) are included in a larger set of one-click automatic edits in a download .reg file posted below. Pardon any source text compiling errors. If you have problems, try reading the sources (long). Source posts credited: ● https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/ POSReady 2009 updates ported to Windows XP SP3 ENU By glnz, March 19, 2013 in Windows XP ● https://msfn.org/board/topic/177500-upgrading-ie8-to-tls-12/ Upgrading IE8 to TLS 1.2 By Thomas S., June 9, 2018 in Windows XP ● https://msfn.org/board/topic/178087-update-ie8-to-tls12-for-nearly-last-skype-7360150-on-windows-xp/ Update IE8 to TLS1.2 for (nearly) Last Skype 7.36.0.150 on Windows XP By Mathwiz, January 4, 2019 in Windows XP ---------- ORIGINAL INTRODUCTION: I'm posting a step-by-step fix to add TLS1.2 to IE8, so that Skype 7.36.0.150 (for a few months did) run on Windows XP-SP3. (While 7.41.x.x may be actual "last" for WinXP, it may or not nag you to "update", requiring a separate fix or version downgrade. My version 7.36 didn't get the nag, and 7.40 was also reported to lack the nag when it mattered before April 12.) I've compiled pieces of the fix puzzle I found elsewhere on MSFN, because the complete fix isn't obvious to WinXP Skypers searching from elsewhere on the web. The fix isn't that difficult, but the usual warnings that novices should back up the registry before editing it, do apply. The download KB file installs, and each set their own restore points. I hope just setting a Restore point before starting the edit will be adequate. I haven't used my desktop PC WinXP-SP3 Skype (mostly chat) for months while the power supply was down. Yesterday I fixed it. To my surprise, Skype errored with "Sorry, we couldn't connect to Skype. Please check your Internet connection and try again." But the internet was ok. Many Skypers aren't techies, and most of the posted complaints about "Sorry, we couldn't connect to Skype", don't have a fix other than get a new OS like Win7, or use web Skype. For good reasons, we don't want to give up WinXP, at least as a backup to Win7 (or even Win8.1 for my keytablet). I've thoroughly tested Win10, but I'm not interested in that control-freak bugfest. One elsewhere-posted answer with no fix, helpfully explained that Skype had switched to using the more secure https encryption protocol TLS1.2. Skype for WinXP uses the SSL/TLS protocols built into Internet Explorer 8, which is the last Internet Explorer version for WinXP. IE8 normally has a maximum version of TLS1.0. Skype servers apparently turned off insecure TLS 1.0 sometime after I had to quit using this Skype last year (2018). So the fix is to add TLS1.2 to IE8, and it did work for me. At MSFN I found the bitter-end holdouts on WinXP, same website where I found the Win98 bitter-enders. (Btw, one poster at MSFN said the famous Windows OS bitter-ender AXCEL216 aka MDGx aka George, is still alive!). One or more MSFN gurus noticed that Microsoft is still updating Windows XP embedded OS for computerized cash registers (etc.), a WinXP variant known as "POSReady" (POS= Point Of Sale). They figured out how to spoof WinXP-SP3's identity, so that it will pose as, and accept POSReady updates, including those which to add TLS1.2 to IE8. (If still relevant to Skype readers, do the procedure above. Even if another post-April 12 Skype for XP fix is found, this procedure will likely be needed as well.) When I did this procedure (in January of 2019), the "we couldn't connect to Skype" error went away. However, a new sub-login dialog appeared that only allows a Microsoft school or business account. This dialog went away after I clicked on an existing chat account. (See new Skype 7 login obsolescence described in posts below, first reported elsewhere as of about April 12, 2019.) I hope this helps. Al
    1 point
×
×
  • Create New...