VistaLover

@TechnoRelic @roytam1 has absolutely NO CONTROL over the mentioned URI; http://www.palemoon.org/unofficial.shtml is hosted on the "www.palemoon.org" domain, which is owned by Moonchild Productions; as you said, a tab with that URI loaded is triggered after an unbranded Pale Moon build (New Moon in this case) has been successfully updated (app version change). Actually, what gets displayed in that post-upgrade tab is controlled by the value of pref: startup.homepage_override_url For official builds, value is (string): http://www.palemoon.org/firstrun.shtml and, as stated, for unofficial (unbranded) ones: http://www.palemoon.org/unofficial.shtml What you suggest implies @roytam1 setting up (and hosting) a dedicated webpage with the changes you proposed; this can be a "minimal effort" solution with just some text and links, more effort required if artwork is involved (background and foreground images, logos etc.); the link to that webpage should be then set as value of mentioned about:config pref... In any case, you obviously lean towards "proper" rebranding of New Moon; MCP already direct unbranded build users to so those "clueless" ones are already informed (still, all these who can't be arsed to read any disclaimer of any form will continue to "irritate" Moonchild and company even if a specialised post-upgrade page is set up ). Even if New Moon becomes fully rebranded to Goldie Locks (haven't decided whether to include the 3 bears or not ) with completely new artwork and redirections to non-MCP related support sites, I don't think MCP will be totally freed from the random Goldie Locks user landing on their forum/github tracker (and this is what seems to be the only one and poignant issue they have with the rest of us...); just look at what happens with MyPal and (to a lesser degree) Centaury...

Same version, run on Windows Vista SP2 x86: 9 (!) handshake failures... Grazie ; might have to do with me having Windows Taskbar placed on the far right of the screen (i.e. vertical, not the default which is horizontal and in the bottom) ...

... FWIW, v0.41b runs fine under Vista SP2 32-bit ; previous v0.39b checked against 100 hosts, this newer version checks against 200 ! (0 detections in my system ) ... Might be also worth to "communicate" the app's bugged GUI, at least in Vista : very elongated window, with no-way to resize, minimize and/or maximize...

The "advantages" of "more secure" and "signed" WE-API based Firefox Quantum add-ons: https://www.ghacks.net/2019/05/29/another-malware-wave-hit-the-mozilla-firefox-extensions-store/ Relevant discussion in reddit: https://www.reddit.com/r/firefox/comments/buahte/a_wave_of_malware_addons_hit_the_mozilla_firefox/ Probably of lesser interest to us running still (?) Firefox ESR 52.9.x and/or Serpent 52.9.0/55.0.0, one has to wonder though...

... What is the actual meaning of this message? Will installing your way totally break Windows Update itself on the machine? If, OTOH, you mean that the installed version of .NET FW (> 4.6.1) won't receive any additional security & performance updates directly from WU, this is an already known limitation that applies even to 4.6.1 (which will install simply by running its default installer); only 4.6.0 is officially supported by Microsoft on Vista/Server 2008, as such is the last version that would receive updates the "normal" way; for any version higher than this, the user has to hunt down provided updates for 4.x.x in Microsoft Update Catalog, download and install manually... Also, have you tried a slight variant to your method? 1. First decompress the provided 4.6.2 official installer with 7-zip, as detailed previously in the "Last versions of software for Windows Vista and Windows Server 2008" thread. 2. In the created directory, locate file ParameterInfo.xml, patch as instructed and save the modifications (perhaps one other possible workaround could be to overwrite the original file with the one provided inside 4.6.2 Preview; the "Preview" does install normally in Vista). 3. Then, instead of running the .MSI file (as instructed in the mentioned thread), just run the Setup.exe file; it should read the modified ParameterInfo.xml file adjacent to it, allowing for a successful installation... ... Do you actually mean netfx_Full_x64.msi in the decompressed installer directory (NB, this is for Vista SP2 64-bit, only!) ? At least one person has reported some problems with 4.6.2 Final when installed via the ".MSI" method: My response: Presumably, @Win2000Fan's method simulates better a "proper" install as if original 4.6.2 installer (NDP462-KB3151800-x86-x64-AllOS-ENU.exe) had been Vista compatible from the start...

... Thanks, but as I already explained in detail, this is indeed the default setting, but has no practical effect under Windows XP; wouldn't matter whether it be true (the default) OR false, since XP doesn't have WMF... Many thanks, too ; as feared, this appears to be a limitation/bug in the way Vista's native h264 decoder handles the 9:16 video stream... Such is life

OK, follow-up : @Tangy: Many thanks indeed for your tests on NM28, St52 and FxESR52; the fact the clip played back fine in these browsers on XP provided additional clues for me (see below...). I am on Windows Vista SP2 32-bit myself, with Platform Update Supplement installed correctly; this means I have a working implementation of Windows Media Foundation (WMF) media framework, which, in layman's terms, means compatible browsers (Firefox and forks) have access to system (OS) decoders for patented formats (h264 for video, aac & heaac for audio); to be more precise, h264 decoding in HTML5 videos is delegated under Vista SP2 to system file mfh264dec.dll (file version on my setup is 7.0.6002.18392, "7" indicates this was a Win7 feature backported via PUS to Vista SP2). In Firefox ESR 52.9.0 under Vista SP2 (with PUS) I don't have to install and enable the Adobe PrimetimeCDM to achieve h264 decoding in HTML5 video (which is the case for WinXP), because the browser, as explained above, has direct access to OS decoders; this works 99% of the time, but, apparently, NOT for this specific video . In Media Source Extensions (MSE) capable browsers, Facebook serves the video via MPEG-DASH streams (fragmented .mp4 files); it is my conviction, after extended testing, that the default system h264 decoder can't cope with this video's unorthodox dimensions (being in "portrait" rather than "landscape" form, 9:16 instead of 16:9). If in FxESR 52.9.x I disable WMF by toggling media.wmf.enabled to false (and with no AP CDM present), then the browser has no way to decode the video stream; fortunately, facebook can still fall back to using the Adobe Flash Player NPAPI plugin (v32.0.0.171) for playback purposes and this does play the clip in question (but in a pop-up, not in-page): The situation is a bit different in the case of the UXP forks; to cater to WinXP users who, as stated, have no access to OS decoders via WMF, @roytam1 has patched the ffvpx library to include (ffmpeg provided) patented decoders for h264/aac; in Vista+, both following prefs are set to true by default: media.wmf.enabled;true media.ffvpx.enabled;true but priority is given to the WMF decoders; that is why I can't play back properly the mentioned video clip in either NM28/St52 (screengrab is with NM28) : If I toggle media.wmf.enabled to false, then h264 decoding is being delegated to the native ffvpx (ffmpeg decoders) implementation and, as things stand, can properly decode the "portrait" video (NM28): And, as expected, if I toggle both cited prefs to false, NM28 will use Flash (in a pop-up): ... Before I classify this as an obscure Vista bug (with no hope of ever getting fixed), I need to know the results of some additional tests: Many thanks for your time spent, especially during "office hours" ; but don't bother testing on WinXP, according to my troubleshooting and @Tangy's feedback, it will certainly work when ffvpx is the decoding module ... When given the chance, can you please re-test with media.ffvpx.enabled;false ? If it plays, then Win10's system decoders can handle OK the 9:16 h264 video stream... Lastly, I need some kind soul to test for me how latest New Moon 28.6.0a1 on Win7 performs on this clip when, again, media.ffvpx.enabled;false and media.wmf.enabled;true ; if it doesn't play, repeat the test with an official Pale Moon binary (ffvpx there doesn't have h264 decoding support); in the small chance the video doesn't play, it's a UXP bug on Win7 (which means it could be reported to the official devs and, down the road, be fixed eventually...); if the clip plays fine with only Win7's system decoders, it's definitive: my case is a fatal Vista bug I'll have to live with Many thanks for the attention and precious time of this forum's fine members PS: As to the mystery why the video plays back fine in NM 27.9.6 on my Vista setup, I think the answer coincides with my findings so far: facebook serves MPEG-DASH, this requires MSE; on Roy's Tycho fork, MSE+h264 decoding is handled by the supplied LAV dlls, not by the system decoder (as proven by a "youtube.com/html5" test without those files...).

I personally avoid Facebook like the plague, but, via e-mail, I was recently given a link to a specific facebook video (two orphaned bear cubs being given milk): https://www.facebook.com/arcturosgr/videos/2355323964725837/UzpfSTU2MzI1NjMwNjoxMDE1NTgyNzQ4OTUzNjMwNw/ I had latest Serpent 52.9.0 32-bit open at the time I received the e-mail but when I tried to watch the linked video (without loggin' in to facebook - I have no account with them, thank God! ), the page and the embedded player would load OK, however, as soon as I pressed the play button, I would only get sound but no video (player turns to black ). I decided to investigate and the other UXP-based browser (latest New Moon 28.6.0a1 32-bit) as well as Serpent 55.0.0/moebius and Firefox ESR 52.9.1 all three exhibit the exact same behaviour, i.e. the video stream isn't displayed! Browser Console in St52 gets populated with many Type, Syntax and Reference Errors... To my great surprise, New Moon 27.9.6/Tycho would play that specific facebook video fine! Both New Moon 27/Tycho and New Moon 28/UXP have by default the same SSUAO for facebook: general.useragent.override.facebook.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:99.9) Gecko/20100101 Firefox/99.9 (Pale Moon) so the difference between them should not be UA related... What did not come as a surprise, of course, was the fact that Google Chrome (49.0.2623.112, 50.0.2661.102, 51.0.2679.0) also played that facebook video fine (it's no secret that, in recent years, the web is tailored to suit mainly Chrome and not the other way round; especially when Google's own devs dictate themselves how the web should be; but this is a discussion for another forum... ). The person who sent me the video link was using Firefox Quantum 67.0 on Win7 SP1 and she could watch the video on her setup without issue; so, this appears to be a bug afflicting pre-Quantum Firefox versions and, to what concerns us XP+Vista users, the UXP platform... I took the extra step of creating a new clean St52 profile and even trying Safe Mode there, but the issue persists ; @roytam1 can you replicate and if yes, any insight/solution offered? In the meantime, I used youtube-dl to fetch the clip to disk, the resulting MP4 file has a Display Aspect Ratio (DAR) of 9:16, which is non-standard; perhaps this is somehow relevant?

... I don't think that @roytam1 has taken steps to change minimum system requirements for his FirefoxESR 45.9.x builds - the main purpose for the release of these builds is that 45 ESR is the last Firefox ESR version to run on (maximum) SSE CPUs . As with any ESR branch build, it has the same System Requirements as its stable (release) branch counterpart: https://www.mozilla.org/en-US/firefox/45.0/system-requirements/ https://www.mozilla.org/en-US/firefox/45.0esr/system-requirements/ So, if standard XP 32-bit is being discussed here, SP2 is mandatory! AFAICT, the last Firefox ESR that would run on XP x86 SP1 is v10.0.x (10.0.12esr the last to be released); the last stable release to run on that configuration was v12.0: https://www.computerworld.com/article/2502032/mozilla-sets-end-of-firefox-for-win2k--early-xp.html

"xpmodsse" is meant for people on older CPUs which only support the SSE instruction set (not SSE2 or higher...). Just "xpmod" is a more generic build for relatively newer CPUs that do support at least SSE2; and, though you didn't ask, the ia32 builds are for even older CPUs that have no SSE support at all... https://en.wikipedia.org/wiki/SSE2 https://www.mathworks.com/matlabcentral/answers/93455-what-is-the-sse2-instruction-set-how-can-i-check-to-see-if-my-processor-supports-it NB: UXP browsers (NM28, Serpent 52.9.0) as well as Serpent 55.0.0 require a minimum of SSE2

... Many thanks for this new set of updated UXP browser builds ; but... https://github.com/roytam1/UXP/commits/master appears to have been synced with official upstream prior to compilation of updated builds (e.g. 9843f04 pushes code identical to upstream 315ffd5 ), however the custom branch that you mention in your post, https://github.com/roytam1/UXP/commits/custom doesn't reflect the changes present in the master branch and hasn't been updated to contain the "May 24, 2019" code ; is this a simple omission on your part or something else ? Yes, this is c72afc3...315ffd5 ; but, as you said, this is only the official UXP changelog; it was your habit to include in the end of your post your personal/custom changes on top of the official changelog; I suspect the latest builds do include custom changes, especially because you announced so in another thread: and, if I'm not mistaken, part of these custom changes should be the ones included in: https://github.com/roytam1/UXP/commit/11ce2e0 ... but you haven't made any mention of those (?); please be kind enough and explain how things stand (?) ; and excuse me for being pedantic , but I (usually) do study GitHub changelogs and do compare the official one to your custom one; I probably belong to a very small (and, dare I say, "perverse") minority, but I can't help it... As always, huge thanks to you

... And while you were at it, you could have also used a slightly modified id string for Tab Tally 1.3.0 (or 1.2.0 etc.) for it to install in either Serpent 55.0.0 or Serpent 52.9.0: }, "applications": { "gecko": { "id": "@tab-tally-st" } } St55 still contacts AMO to check for WE add-on updates, so, based on your settings, you'll be either upgraded automatically to v1.4.0 or be prompted to do so manually... St52 currently doesn't check AMO for WE updates (due to MCP implemented changes), but this can be partially or fully restored (search one of my previous posts in this thread for how-to-do it ). Installing Tab Tally with a different to the default extension id means you won't ever be offered any additional updates from AMO (and this is a known hack if one wants to stay at a specific version of an extension without having to disable extension updates in the browser)... ... and that is why you can also remove the whole META-INF directory!

Good morning! Is "PM27's XPIProvider and friends" what is referred to as TychoAM in the UXP GitHub repo? Was that change implemented early on in UXP development (I was under the impression WebExtAM was only removed towards the end of 2018/start of 2019, when WE support in Bk52 was obliterated )? From a comment by Moonchild himself exactly a year ago: https://forum.palemoon.org/viewtopic.php?p=141539#p141539 https://forum.palemoon.org/viewtopic.php?p=141641#p141641 Best regards

... I spent the better part of last hour researching and reading on this ; the ability to install id-less extensions from AMO into Basilisk was lost (what is called a regression) when the MCP devs decided to remove the internal platform mechanism that effectuated extension signature verification; this happened early on during Basilisk's development, when the (experimental at the time) application was "baking" on top of the (now deprecated) Moebius platform... Put very simply, id-less extensions acquire first a temporary (internal) id and then a permanent one, whose strings are derived from their verified signature hash; you need to have a working internal mechanism to process the add-on's signature and then generate valid id strings for the installation to succeed; but the devs in Moebius wanted to remove that mechanism altogether and not just allow the installation of unsigned extensions, because then unsigned installed extensions would produce warnings inside about:addons (Add-ons Manager, AOM); this is indeed what happens when you install unsigned extensions in FxESR 52 with the pref xpinstall.signatures.required set to false (NB that, as I have posted in another thread, extension signature verification - in FxESR 52 - is still performed in the background for already installed signed extensions and will also be triggered when a new signed extension is about to be installed!). There wasn't uniform agreement between the dev team which features inherited from Mozilla should be kept and what regressed functionality should be restored; Moonchild himself wanted to cut-off reliance on Mozilla-issued certificates (in hindsight, he was probably right, given the recent - May 3rd - armagaddon-2.0 Mozilla debacle), that meant removing the signature verification code; an "incomplete" workaround was implemented in PR #279 (see below); in any case, the focus of the team was always on Pale Moon (which, by design and choice, doesn't support WEs at all), as for Basilisk's inherited WE support, it wasn't very high on their agenda at the time (and we all know how that ended! ). If you've got spare time to spend, some Moebius era GitHub issues and pull requests are linked below: Addons - Can't install some addons: https://github.com/MoonchildProductions/moebius/issues/238 Add ID from a signature if it isn't included in manifest.json: https://github.com/MoonchildProductions/moebius/pull/251 Fix signed extension checks: https://github.com/MoonchildProductions/moebius/issues/277 (emphasis should be put on Moonchild's comment below: https://github.com/MoonchildProductions/moebius/issues/277#issuecomment-356231470 ) Get IDs for ID-less WebExtensions without breaking normal libJAR signature checking: https://github.com/MoonchildProductions/moebius/pull/279 Then the Moebius platform was left to rot... When Basilisk was later ported to UXP Take 2 (now just UXP), the issue of id-less WEs resurfaced: https://github.com/MoonchildProductions/UXP/issues/373 but Moonchild decreed: and he "WON'TFIX"-ed that issue... ; moot point now in the case of official Basilisk, still an issue with the Serpent 52 fork... =============================================== Disclaimer: Had a rough day today , so I might have not grasped 100% correctly what was contained inside the devs' exchanges in the linked issues/PRs; I have the sense the "general idea" is there, but anyone is free to correct any misunderstandings on my part...

... Let us just revisit Tab Tally, shall we? https://addons.mozilla.org/en-US/firefox/addon/tab-tally/versions/ All versions currently listed on AMO are, of course, of the WE format; version 1.0.0 is advertised as being compatible with Firefox 49.0+, versions 1.1.0 through to 1.3.0 advertised as being compatible with Firefox 48.0+; I was particularly interested in one of those older WE versions, because they duplicate the functionality of the XUL ("legacy") version 0.1.1, now removed from AMO (but is recoverable via the CAA extension). All (WE) Tab Tally versions 1.0.0 to 1.3.0 install and function properly in Firefox ESR 52.9.0[1] ; "properly" is actually the "desired-by-me" way (constant visual display of the number of tabs, updated in real time when that changes...); of course, the latest version 1.4.0 also installs there, but with a slightly degraded (IMHO) functionality... But trying to install any one of Tab Tally versions 1.0.0 to 1.3.0 in Serpent 52.9.0, you'll be met by a failure to install in the form of message: That's because v1.0.0 to 1.3.0 are id-less WEs (one only has to inspect their manifest.json files) and Serpent 52 lacks the API to allow installation of id-less WEs (but FxESR 52 does support that API). In version 1.4.0 of Tab Tally, the author re-introduced the "WE-id" feature inside the manifest.json file: "applications": { "gecko": { "id": "@tab-tally" } } and made it compatible with even older Firefox versions (min version lowered from 48.0 to 42.0) and, probably unbeknownst to him, also restored St52 compatibility; 1.4.0, as discussed previously in this thread, would install fine in St52 (but not v1.0.0-1.3.0, which do install and work fine under Firefox ESR 52.9.0... )

seems possible, will have a look later. This is most excellent news! Once again, really grateful for such stupendous support Addendum: Relevant GitHub commit: https://github.com/roytam1/UXP/commit/f4af0a7

A simple forum search could have easily taken you there :

Doesn't seem to matter though. I never claimed (or implied) that staying at NSS 3.44 Beta (instead or reverting to 3.43 Stable) would have allowed for the UXP browsers to successfully connect to the linked test server, i.e. https://tls13.1d.pw As I was already talking about the NSS library, I simply found an opportunity to mention the version downgrade I had observed; just that ... Today I borrowed briefly sister's Windows 7 SP1 64-bit laptop, where I updated stable Firefox (Quantum) to latest release 67.0 and Firefox ESR (Quantum) to latest release 60.7.0; to my great astonishment, both these Firefox versions connect successfully to the TLS 1.3 test server being discussed in this very thread; I dug around and found v60.7.0 comes with NSS 3.36.7, while v67.0 comes with NSS 3.43, the same one to be found inside the latest UXP forks released by Roy; so, despite my initial assessment, the "bug" observed here ("SSL_ERROR_RX_MALFORMED_SERVER_HELLO" error code when trying to connect to test server with latest New Moon 28/Serpent 52.9.0) doesn't appear to be only dependent on used NSS version and has been already fixed in latest Firefox Quantum releases! I persevered with my searches and, in the end, I stumbled upon a similar issue that was also affecting the Waterfox fork: https://github.com/MrAlex94/Waterfox/issues/783#issuecomment-458907249 So it looks as though the proper fix for this issue lies inside Bugzilla bug #1430268 fixed in mercurial commit: https://hg.mozilla.org/mozilla-central/rev/fafb731 @roytam1: Do you think you can somehow backport bug #1430268 to the UXP platform and thus apply it to both NM28/St52? Is a test-build even possible? If yes, then the OP (@Bersaglio) won't have to use a Chinese browser to connect with... OT: I don't mistrust myself the Chinese browsers any more than I do American ones like Google Chrome or Russian ones like Yandex Browser; all government security agencies are pretty much the same in my eyes... ; in this day and age, there's no such thing as privacy if you decide to connect to the live web...

... This doesn't add up; the New Moon 27 64-bit crash was first reported by @mockingbird in the following post: The crash was indeed due to module nss3.dll, but the reporter specifically mentioned package: https://o.rths.cf/palemoon/palemoon-27.9.6.win64-git-20190427-a09f31062-xpmod.7z as the one the crash occurs with... As you said, that build is the one where the NSS lib downgrade took place, https://github.com/roytam1/palemoon27/commit/a09a17de63be6e059e60559e15cca3448d362428 but still that 64-bit build would crash for the reporter... Furthermore, @roytam1's fix for that crash was announced here: soon after the 2019-05-10 New Moon 27.9.6 builds were announced; @mockingbird verified the fix: ... But looking at the posted changelog for these builds, I don't see a change in the NSS lib version, which I assume still remained at 3.43 (final), the same one inside the crashing build of 2019-04-27 ; am I missing something obvious here?

Well, the title of this thread (in the form of a question) is a tad misleading ; if the real question was Can you establish TLS 1.3 connections under Windows XP? then the answer, of course, is YES . Both UXP browsers (New Moon 28, Serpent 52.9.0), the Moebius fork (Serpent 55.0.0), the Tycho fork (New Moon 27) and probably other @roytam1's forks all support the final TLS 1.3 draft (RFC8446), as well as all three cipher suites associated with TLS 1.3: TLS_AES_128_GCM_SHA256 (0x1301) TLS_AES_256_GCM_SHA384 (0x1302) TLS_CHACHA20_POLY1305_SHA256 (0x1303) ; you can test TLS 1.3 support of these browsers with https://tls13.pinterjann.is/ https://swifttls.org/ https://cert-test.sandbox.google.com/ (and a few other test URLs...). BTW, the NSS library in these browsers was recently downgraded from v3.44 Beta to v3.43 stable release; perhaps @roytam1 could share a word (or two ...) why that was necessary ... Additionally, I was recently informed that the excellent project ProxHTTPSProxy by @heinoganda has indeed achieved TLS 1.3 support under XP for the type of browsers (IE8, Google Chrome 49 and, possibly, earlier) that don't come with their own TLS support but rely upon system libraries for secure connections; so TLS 1.3 in itself shouldn't be an issue... But what is indeed specific is the configuration of linked test server, https://tls13.1d.pw/ It is no coincidence that a Russian member of this forum brought this up, because, it turns out that, the administrator of said test server is a Russian guy, Александр Венедюхин ! In fact, he maintains a blog where he documents this project and the TLS 1.3 test configuration of the server; original articles can be found at: https://dxdt.ru/2018/08/05/8597/ https://dxdt.ru/2019/01/26/8672/ As I'm not at all fluent in Russian (), I had to enlist the help of (evil ) Google, but what the heck... : https://translate.google.com/translate?hl=en&sl=ru&tl=en&u=https://dxdt.ru/2018/08/05/8597/ https://translate.google.com/translate?hl=en&sl=ru&tl=en&u=https://dxdt.ru/2018/08/05/8597/ I don't consider myself proficient in the field of cryptography and/or secure connections, but what I gathered from the translated text was that the server is configured to send a special HelloRetryRequest response to force a renegotiation of connection parameters; the implementation of Encrypted Server Name Indication (ESNI) along with non-ECDH manifested a bug in Mozilla's NSS library, so that is probably why the Firefox forks won't connect currently to that specific test server! (they yield a SSL_ERROR_RX_MALFORMED_SERVER_HELLO error code ). Hopefully, the reported bug will be fixed in a future NSS version, if/when that is applied to UXP, we'll have successful connection in the UXP forks... Frankly, TLS 1.2 is still predominant, but with 1.3 steadily gaining ground; this specific connection test is but a margin case where 1.3 is involved, so I won't be losing any sleep over it...

IIRC, that was because Oracle decided they would no longer support the 32-bit OS architecture on JRE 9 and higher http://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-59701F80-5BB1-416D-835D-C39A9112FC1E

The latest version of Qihu's 360 Extreme Explorer (v11.0.2086.0, released May 16th 2019 - its default UA declares a Chromium 69.0.3497.100 compatibility ) will also pass the test : But this is on Windows Vista SP2 32-bit, not on XP SP3 32-bit (hence, one of you XP users would have to test... ) EDIT: Make sure in "flags" that chrome://flags/#tls13-variant is set to "Enabled (Final)"

Latest FileZilla 3.42.1 32-bit won't launch under Vista SP2 because of only one missing function in Vista's shell32.dll system file: ... and, actually, the very last Vista SP2 compatible version of FileZilla is 3.40.0-rc2, released on Jan 22nd 2019: You can download this Vista EoS version from the official repository at https://download.filezilla-project.org/client/ Final 3.40.0 was released three days later (Jan 25th 2019) but, as you've found out, it would run only on Win7+ FileZilla is open source, so perhaps one could recompile more recent source code to again target at least NT 6.0; here's hoping

This is most probably caused by the fact 4.6.2 Preview can be properly installed via the provided installer, while 4.6.2 Final can only be installed via a hack-ish way ; it is possible running just the .MSI (in the unpacked original setup) does not write all of the necessary registry keys and/or modify ENV VARs; most sadly, I'm not a coder so can't provide any substantial help, but googling the issue I found: https://stackoverflow.com/questions/5980847/visual-studio-2010-startup-type-initializer-for-module-threw-an-exception https://blogs.msdn.microsoft.com/rajakedar_ganta/2012/06/12/the-type-initializer-for-module-threw-an-exception/ Hope they make sense to you! Regards

... But I did say I stopped updating manually at the end of October 2017; also, some previous 4.6.1 updates were not included in my "Snipping Tool" screengrab (I would need to scroll down and take a second one to include all installed in chronological order.) ...