Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×

VistaLover

Member
  • Posts

    1,131
  • Joined

  • Last visited

  • Days Won

    77
  • Donations

    $0.00 
  • Country

    Greece

Everything posted by VistaLover

  1. ... Continued here, as being OT for this thread...
  2. ... Picking up from a "relevant" WinXP thread/post The first (v13.0.1) of the v13 series is also the last built on .NET FW 4.6.2, so with 4.6/4.6.1 installed on Vista SP2, I expect this specific (portable) version of ShareX to have the best compatibility with such an "installation scenario" (i.e. Vista SP2+.NF461) ; as noted previously, you'll have to modify the ShareX.exe.config file (adjacent to ShareX.exe) for the app to even launch: v13.0.1 sports a new dark theme (over previous v12.4.1) and generally, in my limited testing, works as expected (including update checks); one thing that doesn't work is the ffmpeg.exe binary auto-download (you should get a confirmation dialogue when selecting "Tools -> Video thumbnailer"), because versions before 13.2.1 were hardcoded to fetch from the now defunct Zeranoe builds repo (see attachment) ... In any case, that Zeranoe ffmpeg build was not Vista-compatible ; to rectify these issues, download manually a Vista-compatible ffmpeg.exe binary and place inside the following directory: "PortableRootDir\ShareX\Tools\" On launch, the app should pick up the existence of the binary and an entry should be created inside file "PortableRootDir\ShareX\Tools\ApplicationConfig.json", in my case, it's "FFmpegOptions": { "OverrideCLIPath": false, "CLIPath": "G:\\PortableApps\\ShareXPortable\\ShareX-13.0.1-portable\\ShareX\\Tools\\ffmpeg.exe", Because I was feeling adventurous , I decided to also test the latest ShareX version, i.e. v13.5.0; as @Vistapocalypse correctly pointed out here, this is built on .NET FW 4.7.2 (not 4.6.2), so I was quite curious to explore the possibility of it running on already installed 4.6.1 ; after, again, modifying ShareX.exe.config file (4.7.2 -> 4.6.1), I was surprised but pleased to discover the app did launch : Update checks do still work (the app reports it's up-to-date), as most other aspects of the program, but I must admit I haven't tested extensively... In contrast to 13.0.1, ffmpeg.exe auto-download works (it is now fetched, as a zip file, from a dedicated ShareX GitHub repository), but installation fails under my setup , because the extraction of the ffmpeg.zip file is delegated to functions only found on .NET FW 4.7.2+; the downloaded (zipped) binary is a saved copy of a ffmpeg-4.3.1-win32-gpl Zeranoe build, not launching under Vista (because of libx265 NUMA code), so it wouldn't accommodate even if extraction succeeded ; the "manual" installation route has to be followed here, too... What was the initial reason the devs dropped official Vista (and XP) support? Well, "they" had stated that on Vista update checks wouldn't be possible... So glad the Vista community proves them wrong!
  3. ... This isn't actually true , and it has been covered already in the Vista subforums (but am now lazy to track down that post...) . Unlike WinXP SP3 x86, for which the last supported .NET FW version is 4.0.3, Vista SP2 x86 can natively (though unofficially...) support up to .NET FW 4.6.1 (official support stops at v4.6.0) ; below is a screengrab from my Vista SP2 32-bit laptop, running happily ShareX 12.4.1 portable: The trick is to modify L4 of the ShareX.exe.config file so as to read: <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" /> (.NET FW 4.6.1 has to be installed, of course... ) ; and if you are to use ShareX functions requiring FFmpeg, then you have to swap the provided ffmpeg.exe binary (requires Win7+) with a Vista-compatible one ; FWIW, as can be seen, Update Check works as expected ! BTW, I haven't tested any of the ShareX v13 series yet...
  4. Are you using the version advertised as Basilisk compatible below? https://addons.basilisk-browser.org/addon/tab-mix-plus/ ... By the looks of things, this extension has become sort of "abandonware" , since its last update was back in June 2019...
  5. Two adages : 'What you don't know can't hurt you!" and "Bad news travels fast..." i.e. I'm not losing sleep (or more hair ) myself over eventual end of Vista support; when that time comes, I'll probably find it the hard way , assuming they (VLC) haven't disclosed a definitive cut-off date by then...
  6. Just for the fun of it , and intrigued by this latest "revival' of the e10s/Serpent topic, I went ahead and enabled e10s in my latest St52 [v52.9.0 (2021-07-16) (32-bit)] working profile, having it properly backed-up beforehand... This is an old, 2008 era, Vista SP2 32-bit laptop, with a Core2Duo CPU, an integrated GPU (with no h264 H/W decoding support) and a blacklisted, vendor customised, gfx driver, that can't be updated any further; in essence, an under-resourced PC by today's standards... I witnessed no crashes at all, but the expected increase in RAM consumption: I don't frequent facebook, instagram, twitter, tiktok, discord, etc. (the main villains ) and I only occasionally visit "GoogleTube" (because it's Google's, not yours... ), so the browser remained responsive on most sites I use ... HOWEVER, as part of my daily workflow, I must have several GitHub tabs open in Serpent 52; GitHub (and recently GitLab) is unusable in UXP browsers, unless JustOff's GitHub-WebComponents-Polyfill legacy extension is installed: https://github.com/JustOff/github-wc-polyfill/releases But said extension IS NOT electrolysis (e10s) compatible, so, sadly , I'll have to return to my single-process profile to continue using it on GitHub... Happy experimenting to the rest of you , I'll be still keeping an eye on this thread (though in a silent manner, I'm afraid) ... Best wishes
  7. Those with an existing installation of uBO-legacy should have been updated automatically via GitHub; those (like me) who have auto-update turned-off, manually check for available updates and you should be offered new v1.16.4.30; lastly, those who want to install for the first time or experience auto/manual GitHub update "issues", the URI to the XPI file is found below: https://github.com/gorhill/uBlock-for-firefox-legacy/releases/tag/firefox-legacy-1.16.4.30 This last release aims to mitigate the security vulnerability mentioned just previously in this thread by our security guru, i.e. @Sampei.Nihira
  8. ... At the risk of sounding like a broken record (and I'm sure our "younger" members here don't even know what I'm talking about...), Serpent 52.9.0 != Firefox ESR 52.9.x Basilisk 52 (by upstream) and, hence, its child/fork Serpent 52.9.0 was developed as a single process application, because "upstream" don't "believe" in e10s... Most of the e10s supporting code in MozESR 52.6.0, the fork-point for UXP, was excised early on by Moonchild and co., because their default browser application, Pale Moon, doesn't support multiprocess by design; what is left in Serpent 52 currently is just some vestigial remnants of the bulk e10s code to be found in FxESR 52.9.0... Official Basilisk has ALL e10s supporting code removed fully, "our" UXP tree has kept some of it as "experimental", disabled by default... and I have posted about this previously, if you decide to force-enable e10s in Serpent, you are "on your own" and my best advice is to make a profile back-up beforehand, before you go down on that path; believe me, I have tried e10s extensively in St52 in its early days, profile corruption is a dead certainty with e10s force-enabled... Let us not also forget that e10s demands more out of your hardware, notably your CPU and RAM; don't try it on old/low-resourced hardware... I understand the web of 2021 presents serious challenges to UXP and especially to those using the XP-compatible UXP browsers (usually on older H/W), users who are now more desperate to explore other "available" avenues to better their browsing experience... YMMV, of course, but my testing has proved (to me) that e10s on St52 isn't worth the trouble...
  9. ... If you search my posts' history with "Serpent 55" as a search filter, no doubt you'll find I posted about this repeatedly... "55" as an appVersion was chosen by upstream for their ill-fated Moebius platform purely for "sensational-istic" purposes... The platform code itself was forked off a code snapshot of an early version of Mozilla Nightly 53.0a1, so not even close to release channel Firefox v53.0.x ...
  10. It is/was the API+GUI of Mozilla Firefox's Download Manager that existed up to version 25.0.1 in the release channel (and v24.8.1 in the ESR channel); and even there, it was not the default setting, but had to be enabled via an about:config pref: browser.download.useToolkitUI;true Here is a screengrab from FxESR 24.8.1: FWIW, NASA Launch third party complete theme, on Vista SP2 32-bit, with aero turned on... TDM had its own "download history", stored in file downloads.sqlite inside the browser's profile, and was decoupled from the browser's "browsing history"... The underlying code that enabled TDM in Fx 24/25 (the default in earlier Fx versions) was finally removed in Fx 26+, in favour of an async, JS-based, Download Manager API, that integrates DM with the "Library" API; as a result, "download history" became part of "browsing history", stored in file places.sqlite inside the profile... In the screengrab below, the GUI of JS-DM (most are familiar with...) in FxESR 24.8.1, with the default setting browser.download.useToolkitUI;false How is that relevant to UXP now, I hear you ask? Well, our "beloved" Matt A. Tobin is bringing the old TDM back, at least where his Binary Outcast UXP applications (Borealis Navigator+Interlink Mail & News) are concerned: https://forum.palemoon.org/viewtopic.php?p=217500#p217500 https://forum.palemoon.org/viewtopic.php?p=217567#p217567 For those harbouring a liking to TDM's GUI (over the new one), one of my most favourite "legacy" extensions, Downloads Window, does its best to simulate that GUI (while the underlying engine/API remains unchanged): https://addons.basilisk-browser.org/addon/downloads-window/ https://addons.palemoon.org/addon/downloads-window/ caa:addon/downloads-window/versions (v0.6.8 is to be found here) It's a pity the original "bitbucket" source repository by author ungram has been now withdrawn...
  11. Hi @roytam1 , I do hope you're well I just noticed the following commit, that found its way into the custom branch of your UXP fork: Issue #1793 - Only use Glass on the Toolkit Download Manager on Windows 7 margin-top: 3px; } -@media (-moz-windows-compositor) { +@media (-moz-windows-compositor) and (-moz-os-version: windows-win7) { #downloadManager { -moz-appearance: -moz-win-glass; background: transparent; I understand this was merged as-is from upstream (mattatobin), they only support Win7+; but Glass (aka Aero) is also extant in Windows Vista, will that specific commit "break" the UI of toolkit download manager under Vista? If yes, could you include Vista there (e.g. (-moz-os-version: windows-vista) ) ? ... Thanks for your unwavering efforts thus far
  12. FWIW, today @RainyShadow's site does load fully/as expected even from my default Greek IP : This is from latest St52, 32-bit; by the looks of it, they ("avb.bg") must have suffered a temporary glitch with their CDNs, serving different parts of the world... Hopefully, the issue has been also rectified for RainyShadow, so probably crisis averted (for now?) ...
  13. @RainyShadow : This all appears to be IP related ... I am posting now from my 360EEv11 profile (fork of Chromium 69), on my Vista SP2 x86 laptop, and when loading https://www.abv.bg from my (default) Greek IP, or from a UK IP (via a "VPN" extension), I get exactly what you get: But when accessing your URL from a US (or Dutch) IP (via the Browsec "VPN" extension), I get the expected result: So I guess that is why @XPerceniol can load OK that homepage, being in the US himself... The plot thickens...
  14. ... Freedom of expression? My... behind! (pardon my French ... Pun intended, as OPer is from France ). Loading the linked URI in latest Serpent 52.9.0 32-bit, I'm seeing the following: ShadowRoot is part of Google Chrome's WebComponents framework... Shaka Player is a Google-owned web player framework, in the posted screengrab it's looking for EME (Encrypted Media Extensions), i.e. DRM support (aka WidevineCDM, another Google "asset" ) in the browser... Finally, apart from the CORS issue spotted by @roytam1 , the site produces two more errors: To sum up, this is yet another site coded in a way to cater exclusively to latest Chrome and variants ; I wouldn't call this "freedom", would you? (at least where user freedom to choose a browser is concerned... ); in the same vein, citing that 360EE and (Chr)Edge can handle the site/web player fine is a redundant thing to say; the web of 2021 revolves solely around Chrome, period...
  15. ... All this has already been explained in fine detail last March 30th: TL;DR If you first download to disk an XPI file of the extension (github-wc-polyfill), in order to install in Serpent 52.9.0 you have to first patch its install.rdf file; if you, OTOH, manually install the latest release (currently it's v1.2.0) direct from GitHub, or you already have an older version installed, no patching is required to update to the latest release; the GitHub update.xml file is responsible for this behaviour...
  16. ... An English speaking user of 360EE v13 has apparently posted in their official forums, 3 days ago, alerting them about that specific misspelling, along with other shortcomings of the "Speedup" utility: https://bbs.360.cn/thread-15985856-1-1.html ... Any chance you are user "652961752", dear friend? (just joking, of course...) They seem to want to fix things, that's good to know ... After reading some past comments in their official forum, I got the distinct idea it was generally frowned upon to post in English there, so at least that notion must have changed since then...
  17. That URI only links to deprecated v11 (final build 2251); they haven't made an English page for later versions... https://browser.360.cn/ee/ (only in Chinese) currently links to v13 (final build 2250) - previously, it used to hold links to v12 ... On the header of that page, v13.5 (beta build 1030) is also linked...
  18. As hinted, to even attempt an installation on Vista SP2 64-bit, you'd need to modify the x64 MSI installer of JRE 16.0.1 with Orca, in order to lower the LaunchCondition from 601 to 600; see pic below: After installation, you'd need the Extended Kernel, for JRE 16 to run successfully (hopefully ) on that Vista SP2 x64 machine...
  19. I can confirm... I downloaded OpenJDK16U-jre_x86-32_windows_hotspot_16.0.1_9.zip extracted it and probed .exe and .dll files inside the bin dir with DependencyWalker (DW); many DLLs look for K32* functions inside kernel32.dll (where they normally are in Win7+), but in Vista SP2 these function reside, IINM, inside psapi.dll ...
  20. Well, I tried to run OpenJDK16U-jre_x86-32_windows_hotspot_16.0.1_9.msi on my Vista SP2 x86 laptop, this is what I was met with: Probably something that can be mitigated via Orca. but not gonna try it now... Also, https://adoptopenjdk.net/installation.html?variant=openjdk16&jvmVariant=hotspot#x86-32_win-jre suggests: i.e. the MSI installer will install the 32-bit variant of JRE 16 only on a Win7+ 64-bit host ; so, even when using Orca, I probably won't be able to install on my Vista x86 OS ... In any case, if @winvispixp is to try AdoptOpenJDK on his Vista SP2 64-bit machine, some tinkering of the installer might be needed...
  21. Thanks for that ; also nice to see that 32-bit support hasn't been abandoned by them ! However, https://adoptopenjdk.net/releases.html?variant=openjdk16&jvmVariant=hotspot suggests only Windows2012r2 or later is supported (?) ...
  22. JDK 16 bundles JRE 16; Java compiled apps will just use the JRE, as pointed out by @SigmaTel71 ... AFAIK, Oracle no longer supply standalone JRE installers past JRE 8 (8u291 is the latest official release); as you might already know, 32-bit support was also dropped past 8 ...
  23. It appears the official 360 forum thread pertaining to this new 13.5 beta development cycle is located in the URI below (all in Chinese): https://bbs.360.cn/thread-15980045-1-1.html latest beta build already at 13.5.1030.0... Release Notes history posted towards the end of the initial post; below a screenshot, inline-translated into English:
  24. GitLab have started implementing the Google-devised Web Components JS framework, en route to their annual, major, software upgrade... So, "monkey see, monkey do" , i.e. following close in the footsteps of major competitor, GitHub... Application platforms with non-existent or half-baked WC support (UXP in "our" case) will fail to load GitLab pages correctly, hence https://github.com/JustOff/github-wc-polyfill/issues/25 was filed... If you care to read, JustOff initially declined to indulge us (I suppose his ousting from the core of the UXP devs doesn't help in such cases ), but further input from users affected (me included) has, fortunately, caused him to rethink things... FWIW, this is the original issue opened in the GitLab tracker: https://gitlab.com/gitlab-org/gitlab/-/issues/333598 As you'd imagine, this is still OPEN, with no official response from any GL representative; probably another "WON'TFIX"...
  25. ... Well, indeed, "the proof is in the pudding" : But please, let's not turn this thread into "which VPN/Proxy service works best for you?" debate...

×
×
  • Create New...