Jump to content

VistaLover

Member
  • Posts

    2,115
  • Joined

  • Last visited

  • Days Won

    93
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. ... Well yes, sadly, this has also happened to me, especially when using Serpent 52 to post (only very rarely happens when using KafanMiniBrowser ) ... Well, after reloading the page (and praying during the page reload that whatever you've already written won't be lost ), do NOT immediately re-click the "Submit" button; first open in a new tab the MSFN thread you're posting to and inquire whether your post has indeed been uploaded, despite the browser hang; once you verify this is not the case, only then do click the "Submit" button anew ; FWIW, I had similar issues when using St52 to post comments on GitHub, but now, since MS made GH almost unusable in UXP-based browsers, I use KMB for GH (where that issue almost never manifests itself) ... Kind regards.
  2. ... Archived in Oct 2023 - the GH repo that is ... Development has been migrated to GitLab : https://gitlab.com/eyeo/anti-cv/abp-filters-anti-cv https://gitlab.com/eyeo/anti-cv/abp-filters-anti-cv#installation https://easylist-downloads.adblockplus.org/abp-filters-anti-cv.txt Kindest regards ... EDIT: It would appear this ABP list is compatible with uBO-legacy : but incompatible with the WE version of uBO (latest DEV here, i.e. 1.57.3b8):
  3. ... Or, more probably, using the same compiler but with different compilation scripts/configuration, depending on the OS the final binaries are targeting ...
  4. ... 99.99% of times , when the OS generates that error upon trying to launch an ".exe" file, it means that the "Sub System Version" value inside the EXE's PE Header has been set (by the compiler) to a figure higher than the one corresponding to the current OS (e.g. XP=5.1, XPx64=5.2, Vista=6.0, Win7=6.1, Win8=6.2, Win8.1=6.3, Win10/11=10.0); using special software to modify that field of the PE header to an appropriate value for the current OS will allow for the executable to launch, unless some other kernel dependency isn't being fulfilled (in which case the OS will generate an appropriate ERROR message, different to the initial one ) ... Below screengrab is with the AVX2 Thorium variant: TL;DR; ALL the builds you tried have been configured to require Win10+ out-of-the-box ...
  5. ... Leave your router alone ; it's NOT the root cause of this issue; a simple test on Qualys SSL Labs will reveal that the host is currently inaccessible via IPv6: https://www.ssllabs.com/ssltest/analyze.html?d=www.void.gr
  6. ... Not quite ; the list is actually being updated quasi-frequently, you can see so for yourself by visiting: https://github.com/kargig/greek-adblockplus-filter/commits/master/void-gr-filters.txt (most recent modification was just one week ago), however its maintainer is being remiss in also updating its version string, which appears to have been stuck at v2023112600 (Nov 26th 2023?) ; if one feels uncomfortable/vexed about this fact, the list's GH issue tracker is https://github.com/kargig/greek-adblockplus-filter/issues FWIW, with just an IPv4 VDSL+ connection inside Greece, the host "void.gr" can be successfully accessed here ...
  7. https://www.patreon.com/win32/about
  8. ... Ah yes ; all these are works of the Chinese developer "weolar" ... Actually called "XPChrome" (perhaps why the confusion with another Chinese project, CatsXP ) : https://msfn.org/board/topic/185914-chrome-115-working-on-windows-xp-32-bit/ https://msfn.org/board/topic/185939-chromium-115-for-windows-xp-without-one-core-api/ https://github.com/weolar/xpchrome/releases
  9. OT , but which specific version of CatsXP was XP-compatible?
  10. A new public release of Supermium by win32 showed up a few hours ago, still on the M122 Chromium core: https://github.com/win32ss/supermium/releases/tag/v122-r4 As always, read first very well all the associated Release Notes and finer details ... FWIW, take note of: https://github.com/win32ss/supermium/issues/531 that is, if you're gonna use the provided installer to perform an "on-top update" (update a previous Sm installation), better reboot your OS before doing so (registry-entries related issue ...).
  11. ... Over the course of several previous years, "we" (UXP-users) have witnessed how the platform, in agony, struggled to cope with whatever new Javascript "feature" Google devs came up with, the most notorious of them being the non-polyfillable "operators" ("?.", "??"; read this excellent write-up by @InterLinked); at the time, I was semi-convinced that JS operators such as those would deal the final blow to UXP; thankfully, some talented UXP coders came up with own implementations of these operators, thus UXP was "saved" - but for how long? I'll have to side with NHTPG and, to a good extent, AstroSkipper that the last nail on UXP's coffin will be a "new" CSS-related "improvement" (sprinkle with a generous dose of sarcasm here ), implemented in a mixture of CSS code inside/alongside JS code (which seems to be the trend recently ); in the case of UXP, MCP's upstream (Mozilla) have CSS features implemented in Servo/Rust, so MCP can't backport easily, if at all, Mozilla code for these and get away with it; CSS-related UXP issues will keep piling up inside their tracker, with very dim prospect ... Case in point is a CSS bug that has been affecting GitHub in particular for many months now, it was acknowledged exactly one year ago, but so far no activity at all towards a resolution ... This particular "feature" was implemented only in Chromium 99, so it does "invalidate" the popular 360EEv13 and/or KafanMiniBrowser variants on XP/Vista x86; only implemented in Firefox 97, thus putting Mypal68 out of the game, too; if it weren't for the new "additions" (Supermium and its semi-fork Thorium) that appeared at a most opportune time , "we" retro-OS-ers (I just devised this term, ) would have run out of options...
  12. ... Partial implementation inside latest (33.1.0) Pale Moon release:
  13. ... But, isn't this the case already for the past, say, 4-5 yrs? Most websites, at least those that matter the most to everyone this day and age (e.g. social media, media portals, government and state agencies sites, bank sites etc.), have been (and will continue to be) optimised to render best on Chrome and "associated" web engines (Firefox included); Moonchild himself has said that : so this "trend" of GH's will continue no matter whether I choose to stay with a UXP-based browser (St52) - and suffer constant distress when using GH "there" - or whether I move on to a Chromium-based browser that renders today's GH satisfactorily ...
  14. Many thanks for taking this "upstream" ; indeed, I now fully recollect that martok was/is responsible for creating that pref and the underlying code that is behind it (UXP #2030) ; actually, I had that pref toggled (to false) in my St52 "dirty" profile, but not in my "minimal" NM28 profile... Toggling that pref was necessary for me (in St52) for GitHub's "sake"; prior to Dec 2023, when a GH repo was being displayed in "Commit List View" (e.g. like that), a button is provided to the right of each commit entry to easily copy (with one click) the commit's HASH: Read more in a now closed Palefill issue ... However, after the mid-December 2023 "massacre" , GitHub have replaced their previous code (in many places, including the "Commit List View" mode) with "legacy-web-engines-excluding", "heavily-CPU+GPU+RAM-taxing" ReactJS scripts and, under the new status quo, toggling the referenced pref is no longer required for GH's re-iteration of the "Copy-SHA-button" ...
  15. ... IIANM , the last (stable) version of Mozilla Firefox that has "official" native support for Windows 7 SP1 (both 32 & 64-bit) is the ESR channel of v115, currently at version 115.10.0 ... ... Release channel Fx-115.0 does indeed lack that fix, however that's NOT the case for the ESR channel of 115 (patched version was 115.2.1): https://www.mozilla.org/en-US/security/advisories/mfsa2023-40/
  16. Currently, MCP are running a Gitea-v1.21.11 instance on their repo server to develop their platform+browser: ... but that version of Gitea is already somewhat broken when used in MCP's platform/browsers ; e.g., just navigate to the Home page of the PM source repo: https://repo.palemoon.org/MoonchildProductions/Pale-Moon and then try to download a tarball (or ZIP) of the source: It is impossible to perform any of the "More Operations" actions spawned when the ellipsis (...) button is clicked under UXP (latest NM28 tried), because they're not clickable/actionable-upon: ... the irony ; OTOH, I can use KMB (Chromium 87, released in mid-Nov 2020) to fetch that tarball (file "Pale-Moon-master.tar.gz") fine! ... Don't even get me started on HOW MUCH BROKEN Microsoft's "GitHub Web Client" is currently on UXP, all the more so for signed-in members ; GH on UXP is the reason that, since mid-Dec 2023, I practically abandoned my favourite (for many years) Serpent 52 for Kafan MiniBrowser (Cr87) and, at this time, also contemplating switching to either Supermium/Thorium ...
  17. @Ben Markson & @roytam1 : Although what I'll bring up concerns a different browser engine (360EEv13, based on Chromium 86), perhaps the time discrepancy is attributed to a Windows XP quirk/bug, especially if you take into account that upstream codebases (UXP by MCP, Chromium 86) were never meant to be run under Windows XP ... In the autumn of 2022, our dear @Dave-H complained about 01:00 discrepancies in the timestamps of the history entries of his 360EEv13 profile under XP, when the UK observes BST (UTC+01:00); this issue doesn't manifest itself when the same profile is launched under his Win10 partition; mitigation of the issue, though, under XP involved unchecking the "Automatically adjust clock for DST" control panel setting and manually selecting a region with a [UTC+01:00] timezone for the duration BST is being observed ; you can read the exchange between me and Dave by going to https://msfn.org/board/topic/182876-360-extreme-explorer-modified-version/?do=findComment&comment=1226930 and do read some posts after that (and the previous page, too, if you don't mind ) ... Best regards !
  18. ... Perhaps @Yordan wrongly assumed that "Windows Vista SP2 x64 + Vista Extended Kernel (by win32)" is on par with "Windows 7 SP1 x64", which, of course, is NOT the case ...
  19. @hidao : Refer to: https://msfn.org/board/topic/186133-thorium/?do=findComment&comment=1263668 that I posted already ; use a translator if the Release Notes in English is difficult for you to digest ...
  20. ... Well. you don't really have to own a GFX card with HEVC H/W decoding support to test; S/W HEVC decoding by the browser should suffice; navigate to https://tools.woolyss.com/html5-audio-video-tester/ and if the two HEVC entries are coloured in green, then support is implemented: (PS: Raw HEVC decoding support is not sufficient in itself for the above test; encapsulation of it inside the MP4 media container is also required...)
  21. Latest release published mere minutes ago; the first one (non-BETA) to officially support WinXP on both 32 & 64-bits, the same is true for Windows Vista SP2: https://github.com/Alex313031/thorium-legacy/releases/tag/M122.0.6261.168 As instructed, read all the Release Notes very carefully and then be extra meticulous on selecting and running the most suitable installation files (including Fonts) for your OS+bitness!
  22. ... I totally agree with you on this ; but you didn't have to convince me in the first place ... However, try to preach to the number of members here who are (still) under the impression that using a content blocker (such as uBO) will "significantly slow down" their browsing experience on their antiquated H/W ... Yes, uBO does consume a slight RAM portion to do its job, but if you're very low on RAM (< 512MB), you probably shouldn't face the current web with that machine of yours ...
  23. Indeed : https://github.com/bpc-clone/bypass-paywalls-clean-filters/raw/main/bpc-paywall-filter.txt userscript: https://github.com/bpc-clone/bypass-paywalls-clean-filters/raw/main/userscript/bpc.en.user.js ... However, this is GitHub now, much more prone to succumbing to DMCA requests, so expect this to also vanish soon-ish ...
  24. ... From reddit: ... But, sadly, it'll become less effective by the day, as "affected services" will defeat it sooner rather than later (see the comment about NYT in the screengrab above) ...
×
×
  • Create New...