VistaLover

... Well, you're absolutely right , I myself have fallen prey of attachment disappearance in many old posts on several web forums (i.e. not just here in MSFN) and it's quite frustrating when your Search Engine unearths a post from, say, 2005, only to find, upon arrival there, that crucial info meant to be found in a forum attachment is AWAL... Most often, the image hoster itself has gone bust , others tend to auto-delete files with prolonged inactivity... Were it not for attachment size quota here in MSFN, I'd have stayed completely away from third party services, but, things being as they are, I see it as a necessary evil... Guilty as charged for some of my personal screengrabs, but in most of those cases I do have specific reasons I want ALL to be displayed/conveyed... Else, I do bother to crop and upload only relevant image parts - PNG format is very good for detail, but to save bandwidth I also like to upload as JPG... Well, we all know (and feel sympathetic towards you ) you're currently browsing MSFN with an antiquated browser engine, but, speaking personally, I do prefer those "Forum share" embedding links (offered by the hosters) to DIRECT image links; direct links to images have very short lifetimes, the hosters then re-direct you to full-blown webpages (not just the original image itself) laden usually with an exorbitant amount of ads/nuisances (even video), not all are intercepted by an adblocker... I'm sure your "old" browser would not even render any ads, but modern ones do... Furthermore, when I paste a direct image link inside MSFN's post editor (with a modern browser that is), it auto-converts it into an inline image; there's still an option to "display as link instead", but I'd have to remember to scroll down to post's end and select that option; I usually don't, sorry...

@ArcticFoxie , @we3fan Being signed-in, just load: https://msfn.org/board/attachments/ There you'll see that as a "free" MSFN member, you're only entitled to a maximum size of ca. 2MB of file attachments: I can't seem to be able to find the link now, but, AIUI, once you make significant donation(s) and/or become an MSFN sponsor, that attachment quota may be upped, but, as @UCyborg said, the best thing to do is use external image/media/text hosters and use here just the "Forum share" links...

Direct links from vendor: XP SP2 64-bit https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/B75590149FA14B37997C35724BC93776F67E08BFF9BD5A69FACBF41B3846D084/VC_redist.x64.exe XP SP3 32-bit https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/0D59EC7FDBF05DE813736BF875CEA5C894FFF4769F60E32E87BD48406BBF0A3A/VC_redist.x86.exe Credit goes to @abbodi1406 (from content originally posted on MDL) . These are the last VC_redist.x*.exe packages that have been DUAL-signed by M$ (SHA-1[XP/Vista readable] + SHA-2 file signatures of Aug 13th 2020); also, read: https://forums.mydigitallife.net/threads/repack-visual-c-redistributable-runtimes-2021-01-14.76588/page-27#post-1630817

The fork below, made by a compatriot of yours , is being still maintained, latest update was 4 days ago... https://addons.palemoon.org/addon/ematrix/

Kinda off-topic, yet it speaks volumes about "upstream"... Moonchild is now blocking in (official) Pale Moon (recently updated to v29.0.0) an extension made by his ousted ex-associate JustOff (former head of PM localisation team): https://github.com/JustOff/moon-tester-tool/releases resulted in: https://repo.palemoon.org/MoonchildProductions/Pale-Moon/commit/1c163a1 which, in turn, resulted in: https://github.com/JustOff/moon-tester-tool/issues/10 PS: The MTT extension allows PM users to prolong the functioning of (otherwise still compatible) "originally-made-for-Firefox-only" legacy extensions (as the ones inside CAA), that are currently being hard-blocked in the latest versions of PM... The logic behind them being blocked is that PM users should move away from unmaintained, old, Firefox-exclusive extensions to "equivalent", maintained, ones from inside APMO ; the block is also used as a means to coerce the community of PM users into forking those old extensions to new ones, targeting PM... But the harsh reality is often times quite different to the devs' dreams/expectations, MTT offers a backdoor that Moonchild (and, no doubt, M.A.T. ) wants permanently shut...

Thanks, once again, for your erudite guidance! After more searching done on my part, the culprit is indeed the Adobe DTM SatelliteLib script ; this is compatible with Chromium (of course...) but not compatible with previous Mozilla Firefox versions (like the one UXP is derived from...); so, technically, this issue is still a UXP bug... That script is just a commercial tracking script developed (and served) by Adobe, thus one would expect it to be blocked by default in a content blocker (); I'm not a fan of many layers of browser content protection, that make it more difficult to use and/or increase RAM consumption, my standard usage involves just uBO; but the default settings/filterlist subscriptions there don't intercept that script ; even more, EasyPrivacy list (a default one) specifically whitelists it on oracle.com: so it's no wonder why turning uBO ON/OFF makes no difference... In all honesty, I don't consider myself an authority on uBO, so "blocking JavaScript from adobedtm.com" initially left me pondering ... At first I thought I had to add no-scripting: adobedtm.com true inside My Rules tab of the dashboard, but that didn't work ( ; what does work is www.oracle.com assets.adobedtm.com * block (block it when served on www.oracle.com only), or * assets.adobedtm.com * block (block it globally in the browser - it's the thing to do, as the script is incompatible with St52); My Rules supersede Third Party Filters, so can be used despite EasyPrivacy's whitelisting... Another approach to the same issue is to add a custom filter inside the My Filters tab: ! Block globally AdobeDTM scripts ||adobedtm.com^$third-party,important Credits for that last one go to @coffebreak on the official Pale Moon forums ...

OS: Windows Vista SP2 32-bit Browser: Serpent v52.9.0 (2021-01-27) (32-bit) BuildID=20210127235057 UA: Mozilla/5.0 (Windows NT 6.0; rv:68.0) Gecko/20100101 Goanna/4.8 Firefox/68.0 Basilisk/52.9.0 https://www.oracle.com/index.html does NOT display in latest St52 (and I suspect the same happens with the rest of the UXP-based forks...); even when I fully disable uB0 (v1.16.4.28) and then concede to accepting cookies (in the pop-up window), the page apparently loads fully, but no content is being displayed (blank white tab) ... No warnings/errors are being generated in WebConsole, which makes troubleshooting a pain ... I know that the site did work in the not-so-distant past in UXP, because I used NM28 to register there an Oracle account (so I could download archived Java JRE versions), but apparently Oracle have moved to Chromium-only JS/CSS code , that isn't rendered anymore on latest UXP... A kind soul should definitely pass the info along to "upstream", so they are made aware and possibly offer a solution (?) - though, if it involves Web Components/Custom Elements/Shadow DOM etc, we know it'll be a no go ... For the time being, I'll have to resort to 360EE (which, sadly, is something I do more often recently) :

Please see previous post in this thread: The last version of Foxit Products that unofficially supports Vista SP2 was 9.6.0.25114, from July 2019; later versions demand Win7 SP1 as minimum ... Foxit "Products" include both PhantomPDF and Reader:

On the subject of cipher suites used by 360EE, v12 & v13 (but NOT v11) are built with support for the Chinese-exclusive cipher suite 0xe013; yes, the Chinese are developing independently their own cipher suites for use inside their own Cyberspace ( ) - the one sanctioned by the GFW, of course! These Chinese-only suites are not (yet?) endorsed by the rest of the world, IOW they are not properly indexed/standardised... Of the three testing sites I use, https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html never identifies 0xe013, but https://browserleaks.com/ssl and https://www.howsmyssl.com/a/check occasionally/randomly do: When that "unknown" suite is detected, then the client always gets a bad rating... I haven't found conclusive info on that Chinese cipher suite, mere mentions of it on GitHub: https://github.com/guanzhi/GmSSL/blob/master/ssl/t1_trce.c More about GmSSL and the GM/T standards can be found on: https://github.com/guanzhi/GmSSL#about-gmssl http://gmssl.org/english.html In any case, I've taken up the advice of @Sampei.Nihira and disabled it in my 12+13 versions, via: --cipher-suite-blacklist=0xe013 FTR, that suite was first introduced in 360EEv12 build 1150 (12.0.1150.0) ...

If one installs the ImTranslator Chrome extension: https://chrome.google.com/webstore/detail/imtranslator-translator-d/noaijdpnepcgjemiklgfkcfbkokogabh then one can translate the inline Chinese (left-over) strings, so one can at least get an idea of what the settings are about: Not a permanent solution like the one detailed by @ArcticFoxie , but still, if you only want to , I guess it could be of great help...

E.g. https://www.zdnet.com/article/firefox-85-removes-flash-and-adds-protection-against-supercookies/

The Chinese RePacked/modded version 34.0.0.92 has been tested to function under WinXP SP3 (not by me, as I don't have that OS currently at my disposal, but I've been informed about XP SP3 compatibility, via PM, by another reputed MSFN member here ) ... To add/expand a bit to what already posted by @Dave-H , everything Google related (including Chrome browser, Drive, gmail, etc.) is off-access in mainland China, so a plain Chinese user would not know/care less what Google's plans are about Adobe Flash ... I haven't exhausted the whole Chinese Browser market, obviously, but most Chinese Chromium forks have ongoing Flash PPAPI(/NPAPI) support; even if future Chromium forks will have been rebased to Chromium >=88, it's not improbable to expect Flash support will have been kept/prolonged... I'm unsure as to whether other "western" Chromium forks like Opera (wait! it is Chinese-owned currently ), Vivaldi, etc. are accessible to Chinese users, but these lack an embedded Flash version, so a user has to install the PPAPI flavour system-wide (so, why not, PPAPI ZHS v34.0.0.92 ?)... Best regards!

I'm sorry, but you're not being meticulous enough... As most of you here already know, Google Chrome is/was the only flavour of Chromium-based browser that has/had (paid) rights to ship bundled with its own PPAPI version of Adobe Flash; Chrome v49 originally came with v21.0.0.213 (dual-signed DLL on 20160406); on the portable (PAF) edition, the path to that is/was: .\App\Chrome-bin\49.0.2623.112\PepperFlash\pepflashplayer.dll For the duration v49 was still supported by its vendor (Google), a user could manually update the Flash version by loading chrome://components locating the enrty for "pepper_flash" and pushing the Check for updates button underneath it ! The updated PPAPI flash would then be installed in a user-specific location, inside the browser's profile directory: .\Data\profile\PepperFlash\xx.x.x.xx\pepflashplayer.dll Upon launch, Chrome 49 simply ignores the originally shipped version and loads the one in the browser profile! So, to recap, unlike the popular practice, the proper way to manually update Chrome's Flash version is TO NOT EVER touch the Flash DLL inside the main program dir .\Chrome-bin\<Chrome_dotted_version>\PepperFlash\ but instead perform a profile-based installation, by placing (renamed) DLL (and manifest.json) inside .\profile\PepperFlash\<Flash_dotted_version>\ Applying the above procedure on Chinese RePack (modded) v34.0.0.92 and on my portable Chrome 49 installation, Flash is loaded from: and the Adobe test page reports success :

To dispel any eventual confusion, these are not MODDED packages at all , they are being hosted on the Official Chinese Flash distributor domain (flash.cn), they have their digital file signatures intact (both the setups as well as their contents), upon installation they would install the telemetry FlashHelperService , without which the standalone DLLs (e.g. NPSWF32_34_0_0_92.dll) are non-functional ... What they are, in fact, is official standalone (off-line) installers, as opposed to the stub (on-line) setups one is offered by default when downloading from the main page of the Chinese Flash site: https://www.flash.cn/ The standalone setups are (recently) being offered from https://www.flash.cn/compatibility NB: The truely modded Chinese repacks I mentioned earlier in this thread do not install the telemetry FlashHelperService and are free from geo-limitations ; if you're still interested, they are labeled as "Special Edition (特别版)" and the filenames you should search for are: Adobe_Flash_Player_ActiveX_34.0.0.92_特别版(Win7).exe Adobe Flash Player NPAPI 34.0.0.92 特别版.exe Adobe Flash Player PPAPI 34.0.0.92 特别版.exe

Once again, @UCyborg to the rescue! Since I don't currently have a Google Chrome version "properly" installed, the path above is translated as below for my portable Chrome 51 installation: "G:\PortableApps\GoogleChromePortable\Data\profile\Default\Pepper Data\Shockwave Flash\System\" NB, the "System" folder was not there by default, I created it manually and placed inside it a copy of file mms.cfg (from its default location, "%windir%\system32\macromed\Flash\"); then tested with the original, unmodified, PPAPI DLL v32.0.0.465 (see my previous post) and verified that portable pepflashplayer.dll does read/observe the portable mms.cfg file!

Some more observations, as result from testing on my Vista SP2 32-bit laptop: 1. The mms.cfg method with LATEST Flash 32.0.0.465 (unmodified) will work ONLY when that file is located in its designated location (for me it's "C:\Windows\system32\macromed\Flash\") and it will ONLY be observed/honoured by the ActiveX and NPAPI varieties... My file currently reads: DisableAnalytics=1 SilentAutoUpdateEnable=0 AutoUpdateDisable=1 EOLUninstallDisable=1 EnableAllowList=1[ignored] AllowListRootMovieOnly=1 AllowListUrlPattern=file:* AllowListUrlPattern=https://wwwimages.adobe.com/ AllowListUrlPattern=https://helpx.adobe.com/ AllowListUrlPattern=*://chat.kongregate.com/ AllowListUrlPattern=*://www.screamingstatue.com/ with SilentAutoUpdateEnable=0 AutoUpdateDisable=1 probably being redundant now... The NPAPI dll will read mms.cfg whether it's properly installed (in "%windir%\system32\macromed\Flash\") or from another "portable" location; the PPAPI dll, however, will NOT read mms.cfg no matter if it's properly installed (for Chromium browsers that don't bundle Flash) or itself part of Google Chrome (inside the appdir or userdatadir). What was somewhat not expected by me is the fact a patched NPAPI dll (e.g. "NPSWF32_32_0_0_465.dll"), regardless of location, will STILL observe mms.cfg ; so, if you have patched the NPAPI dll to remove the killswitch/timebomb, for it to work on ALL sites you'll have to rename/remove/delete your customised mms.cfg file! ["%SystemDrive%\Users\<username>\AppData\Local" = "%localappdata%" ] Under Vista SP2 32-bit [No ExtKernel], the highest version of Google Chrome that can launch is the first build of the 51 branch, v51.0.2679.0 (a hard-to-find release, it was shared long time ago by a fellow MSFN member in the Vista subforums...); I have it set up as a portable installation in the PAF format, so the folder hierarchy is G:\PortableApps\GoogleChromePortable\GoogleChromePortable.exe [=launcher] G:\PortableApps\GoogleChromePortable\App\Chrome-bin\chrome.exe [=main .exe] G:\PortableApps\GoogleChromePortable\App\Chrome-bin\51.0.2679.0\PepperFlash\pepflashplayer.dll [=originally bundled PPAPI Flash, v21.0.0.182] G:\PortableApps\GoogleChromePortable\Data\profile\PepperFlash\32.0.0.465\pepflashplayer.dll [=manually updated PPAPI Flash, located inside User Data dir, aka "profile"] With the last PPAPI v32.0.0.465 in place as detailed, Chrome 51 ignores the built-in old 21 version (which, obviously, does not contain a timebomb) and loads v32; but the DLL does not read mms.cfg file (if present), so I always get the following outcome: For latest PPAPI Flash to work inside Google Chrome (tested versions 49/50/51), I have to use a patched DLL: FTR:

Thanks! Fixed (Note to self: Replace battery in wireless mouse ...) !

The WidevineCDM (v1.4.9.1088) inside official Basilisk as well as in Serpent 52.9.0 has been broken since August 14th 2019 (!), because evil Google , the current owners, have de-authorised that deprecated version from receiving decryption licenses (i.e. keys) from sanctioned WV lic-servers... WidevineCDM has always depended (in Firefox-type browsers) on system provided patented decoders (IOW, WMF), thus it used to require at least Vista SP2 with Platform Update Supplement (PUS); when one visits a WV test page with latest Serpent 52 in Vista+, e.g. https://bitmovin.com/demos/drm , you sadly get: And the above is the good scenario ; some heavily DRM'd sites like the Spotify Web Player (https://open.spotify.com/browse) won't load at all once they discover you have a broken WV browser implementation... After the demise of v1.4.9.1088, Google have moved on to releasing WV series 4.10 (dropping the initial 1 in version numbering); Moonchild Productions were tracking WV v4.10 implementation in (practically only) Basilisk in UXP issue #962: https://repo.palemoon.org/MoonchildProductions/UXP/issues/962 But time went on... and on... and on... without a solution in sight... To add insult to injury, Google had retained Vista SP2 support in WidevineCDM up to (and including) v4.10.1196.0 (SHA-2 file sig of Oct 9th 2018), which was also revoked on 2019-08-14... Later 4.10 WV versions ALL call the KERNEL32 function TryAcquireSRWLockExclusive which doesn't exist under Vista SP2... So, all hope is currently lost for Vista SP2 users to have a future working WV implementation inside St52 (32-bit) - I'm leaving any Vista ExtKernel references out of the picture here, as we're nowhere even close to a fully functional x86 edition yet; but I feel the ExtKernel is OT for this discussion... If, and that is a very big IF, MCP somehow manage to port a working WV 4.10 implementation in Basilisk, then that would mean that Serpent 52 users on Win7+ could also profit... But, most sadly (but not unexpectedly, if you ask me), the above scenario won't ever happen: Dropping in-browser DRM from the platform @roytam1 : By the look of things, they'll be removing all EME supporting code from their tree (having removed a long time ago support for the deprecated Adobe Primetime CDM ); "we", OTOH, have kept support for Adobe Primetime inside Serpent 52 for the sake of very few users on Windows XP who prefer to use that CDM as a h264+aac decoder instead of the ffvpx patched library; @dencorso , do you still fall within that category? 1. What is the opinion of Serpent 52 users here? Is AP CDM still needed in 2021? 2. If the majority deems yes, will it be easy enough for you Roy to selectively remove ONLY Widevine supporting code (which should be purged one way or another, if it has no applicable uses anymore...) ?

NM27 (Tycho ~ Mozilla 38 platform) and NM28 (UXP ~ Mozilla ESR 52 platform) profiles are, in essence, non-interchangeable; I had always preached in the past in these forums that the only safe/sane way to upgrade to NM28 (from NM27) is to create a fresh pristine NM28 profile and then selectively transfer items from the NM27 one... If you won't adhere to that advice, then be aware that the profile-upgrade-process works only one-way (27->28); once a NM27 profile has been touched by NM28, it is rendered in many aspects corrupted for NM27 use... As others have said, the workaround is to launch via command-line arguments: NM27: "path-to-palemoon.exe[27]" -no-remote -profile "path-to-NM27-profile" NM28: "path-to-palemoon.exe[28]" -no-remote -profile "path-to-NM28-profile" Paths to profiles can be absolute or relative to the respective .EXEs; just to be on the safe side, I'd use absolute paths... If you don't include the -no-remote switches, then you won't be able to launch both; but I strongly discourage simultaneous running of both versions - and accidents do happen, so back-up profiles regularly... ... But you are forgetting that they are different applications, more specifically St52 uses Australis while NM28 doesn't (and this is app-specific code you're requesting to change...). To elaborate some more, the infinitely wise Mozilla devs () first crippled the browser.allTabs.previews Firefox feature, see https://bugzilla.mozilla.org/show_bug.cgi?id=844952 and its many duplicates, and then, in a fashion we've been very accustomed to during the massacre that led to Quantum, they were unable to fix back, so they axed the pref altogether, along with supporting code: https://bugzilla.mozilla.org/show_bug.cgi?id=670684 While this isn't exactly what you asked for, in Serpent 52 you can enable the pref browser.ctrlTab.previews (default is false) and by clicking CTRL+TAB you get a graphical preview of 6 of your (many) opened tabs: ... but when you select "Show all XX tabs" (29 in my screenshot), this will only trigger the "List All Tabs" drop-down menu (which, incidentally, doesn't include pinned tabs ) ...

@Dixel : Having been from the very start a Mozilla Firefox person, I only recently (last 2-3 years) had to turn to Chromium-based browsers still supporting Vista (Maxthon, UCBrowser, Slimjet, YandexBrowser, 360EE), after Mozilla EOL'ed Firefox in Vista SP2 and there were Chromium-only sites not properly rendered in the UXP forks (which is, sadly, a very frequent occurrence lately) ... As such, I'm not ashamed to admit I still have serious knowledge gaps where it comes to manipulating/custom-configuring Chromium browsers... In my Firefox-trained mind, I equated about:config to chrome://flags/, thinking that every possible "flag" is to be found inside that pre-defined list... And because every "flag" there is translated at runtime into a command-line switch (as can be seen in 360EE's chrome://version/ internal page), I mistakenly thought that for setting "--process-per-site" "flag", I had to search for a similar entry (e.g. containing the process | site strings) within chrome://flags/, thus I ended up enabling the devilishly similar "#enable-site-per-process" => "--site-per-process" one... Many thanks for putting me back in order... FWIW, "#enable-site-per-process" is only available in the Chromium 69 based 360EEv11, not available in 360EEv12/13... So, your suggested "flag" is in fact a commandline switch, as explained more verbosely (for Chromium ignorants like myself) in: https://www.ghacks.net/2015/02/08/save-memory-in-chrome-by-using-one-process-per-site/ Because I'm using a "portabilised" edition of 360EE, I added the switch inside the portable launcher's .ini config file, in the Parameters section: Parameters=--user-data-dir="%Profile%" --disable-logging --no-default-browser-check --disable-component-update --disable-background-networking --allow-outdated-plugins --ssl-version-min=tls1.2 --process-per-site and after relaunching I verified that all tabs loading URIs from the same domain share a single process ; however, overall browser RAM consumption was not reduced to an impressive extent, perhaps that's because I tend not to use more than 15-20 tabs in a session (TBH, I've never been a tab hoarder, in any browser, I prefer to use Bookmarks to store URLs, not tab-sessions - but to each his own...). I'll keep that switch enabled, despite, thanks again for suggesting it... Best wishes

Well, I surely do know that Russia expands to vast territories , but perhaps @Vadim could enlighten us more as to which version of Chinese Flash v34 he's been using (and, to a second degree, his actual whereabouts ) ... @ED_Sln , have you only tried the "official" stub (on-line) Chinese installers? Perhaps related, but today I finished my Chinese Flash tests and upon more thorough inspection of the re-packaged setups, I discovered that the DLLs have been patched, because their SHA-2 digital file signatures have been invalidated: So, it is my educated guess, the Chinese repackers may have lifted the officially imposed geo-restrictions...

This is specific to Mozilla-type browsers, and what it does is disable ALL NPAPI plugin (includes, among others, Java JRE) scanning: http://kb.mozillazine.org/Plugin_scanning and http://kb.mozillazine.org/Flash However, that particular pref has no effect on Flash installed in a "portable" fashion (i.e. no Flash references in the Windows registry...) Thanks , but the Browserleaks tests I uploaded were performed in 360EEv12, a Chromium 78 based fork; do you happen to be aware of an equivalent "flag"/commandline switch there?

Yes, I'm merely testing it for now, not planning on adopting it in the long run... BTW, besides https://get.adobe.com/flashplayer/about/ I only tested it on http://chat.kongregate.com/gamez/0009/4075/live/myth_rider_cs3.swf which also loads fine: Further cautious examination of the downloaded standalone setups (.exe) revealed they are indeed Chinese Repacks in the InnoSetup format, comprising payloads for both x86 & x64 OSes, with, what appears to be, the official FlashHelperService excised... The executables were never properly run, but extracted with UniExtract, then main DLLs simply harvested and tested in portable mode ... I have no doubt they probably do connect to one or more Chinese IPs, being Chinese "products" and such, let alone when I tested it inside a Chinese-made browser, 360EEv11 (and 12), but who's to say which one of them is dodgy or not (probably many members here are of the conviction that every Russian and/or Chinese IP is "dodgy") ? ; however, I'm not well versed in conducting the kind of tests you demand, so leaving that to others am afraid...

Test for PPAPI: Test for NPAPI:

Various non-official Chinese sites are already redistributing (modified?) standalone installers and re-packaged versions of Chinese Adobe Flash Player v34.0.0.92 (official site https://www.flash.cn/english only offers stub installers ) ... I won't post any links here, of course , but - depending on your searching skills - you might be able to stumble upon them ... Getting to actually download these off-line installers from the various Chinese hosting services is an exercise on its own, though... Anyhow, I successfully fetched (and malware-scanned): The .7z archive contains only the extracted PPAPI 32-bit DLL (+ needed manifest.json file) and when I load this in "portable mode" in 360EEv11, it works out-of-the-box in my location, too : Some important announcements from the Chinese Flash distributor: https://www.flash.cn/notice/notice?id=153 https://www.flash.cn/notice/notice?id=144 So it appears (if my translator is correct ) that Windows XP and Vista will only be partially supported by Flash >=34 ...