
VistaLover
MemberContent Type
Profiles
Forums
Events
Everything posted by VistaLover
-
PortableApps.com have just released Supermium-v126-r7 (they had skipped r5+r6 ) in PAF format: https://portableapps.com/news/2025-01-27--supermium-portable-126.0.6478.261-R7-released https://portableapps.com/apps/internet/supermium-portable The bulky package contains both the 32/64-bit Supermium variants; on a x64 OS, the 64-bit browser is launched by default, on a x86 OS, well, just the 32-bit one (in the latter case, you can free up disk space by deleting the ".\App\Supermium" directory) ...
-
Isn't that already available in Supermium via: chrome://flags/#rectangular-tabs ? ... Though the end result leaves much to be desired :
-
OT, so I'll keep it short ... @Mark-XP, many thanks for your kind interest in me and your genuine offer ; the thing is I haven't contemplated thus far a migration to one of the many Linux distros, but thanks anyway... I only spent ca. 3yrs on WinXP, so am not that much "attached" to it (not an "XP die-hard", IOW), but this is where I learned computing, which came very late in my adult years... By some coincidence (lack of one H/W driver for XP at the time), my personal first laptop that came with Vista OEM (SP0) x86 was never switched back to WinXP SP3; after SP1 was released, the OS became very trustworthy and over time I grew to really "love" it (hence my username here), despite the general negativity towards it... In my household there exist one Win7 SP1 x64 laptop (from 2011) and a 2020-bought one with Win10, the latter used mainly for financial online transactions... Win10 has WSL, so I guess I could get acquainted with "Linux" if the need really arises... Sadly, my RL has enough of frustration as it is, actually getting bigger by the month (personal things I won't disclose here); I'd rather do without so much frustration in my DL, too; plus, the adage "You can't teach an old dog new tricks" seems to suit me fine currently ... Over the years, of course, I have come across Linux related subjects in various forums, this isn't totally "alien-land" for me; as an exclusive Windows user I learned very quickly to use the Command Prompt and CLI software (while many of my Windows-using close friends, till this day, remain oblivious of non-GUI apps); so the "terminal" doesn't frighten me that much in itself; it's the steep learning curve I'm not inclined to deal with... PS: When Mozilla removed support for XP+Vista starting with Fx-53, Vista usage was tenfold the Linux usage, so I wrote to Mozilla and complained that they were OK to continue supporting the few Linux users, but NOT the Vista ones; I was more naive at the time, not fully aware of "planned obsolescence" and "agendas" by the big IT companies; Mozilla staff didn't bother responding, one community fellow user mentioned "lack of future OS security updates", but I wasn't convinced (by then, it was discovered already one could install WS2008 security updates on Vista, how about that?) ; from that time on, subconsciously at least, I began harbouring some aversion towards "lucky" Linux - this has waned now, FWIW... OT end (darn, I haven't kept it short )
-
But I couldn't get it working. ... This is a binary hack (HexEdited official binaries) that uses OCA wrapper DLLs (libkrnl.dll, libadv32.dll, libhlp32.dll, libns32.dll, libws32.dll, libxbc.dll, libxt.dll) and, as such, the patched python.exe will ONLY run on XP SP3, at best (e.g., it doesn't run under Vista SP2 32-bit, throwing: The procedure entry point ntdll.CsrNewThread could not be located in the dynamic link library libxt.dll ) ; I realise the thread's title mentions "WinXP" (but several other Windows versions have been mentioned already, I suppose OP wouldn't mind ), but it would be a great injustice if a solution for XP was eventually found but not one for Vista ... The way to go is to mod py3.10+ source and then build with a suitable compiler and flags so as to produce binaries that would run on NT 5.1 upwards natively (that's the procedure cmalex followed for his py3.9 offering, additionally targeting the SSE instructions set - but this last bit might be quite unrealistic for py3.10+) ... Another route I thought of is to hex-edit the adang CPython binaries, that already target NT 6.1, and link them to custom-made DLL wrappers, much like how Supermium 32-bit is able to run under XP and Vista - but this is all totally over my head ... FWIW, I think "embedded" Python distributions are inapt for producing yt-dlp Windows binaries via PyInstaller (as you've found out yourself ); not only is a working copy of pip needed, but also an "include" directory with header (.h) files... TL;DR: The task in demand needs experienced Python and C/C++ coders, with knowledge of the NT 5.x/6.0 kernel functions...
-
... Most sadly , I have no reason whatsoever to believe they'll do otherwise ; I remember I had quite a hard time myself to convince them to extend py3.7's support until its official EoL by the PSF and build yt-dlp_x86.exe on it (for the sake of Vista/Win7 32-bit users); and they didn't think twice one year later about deprecating py3.8, leaving the still quite numerous Win7 (32/64-bit) users stranded; and, God forbid, they wouldn't use adang's Win7 mods, of course not ; indirectly, "they" shifted the onus upon you to provide yt-dlp builds to the Win7 communities, which you did out of the goodness of your heart and your extreme altruism, for which you are to be highly praised ! ... I firmly believe that now is the time to "kindly" approach talented "retro" coders like adang or Supermium's win32ss and enquire the feasibility of producing py3.10/3.11 binaries compatible with Vista SP2 (that should be easier, I think ) and, eventually, XP SP3... Perhaps someone over at the MDL forums could do it, I've seen more difficult things getting ported (like an FFmpeg-7.1 32-bit build that runs on XP/Vista) ... Kindest regards, many thanks for holding the "retro" flag high ...
-
ProxHTTPSProxy and HTTPSProxy in Windows XP for future use
VistaLover replied to AstroSkipper's topic in Windows XP
... FWIW, password-protecting the uploaded archive only takes care of downloading the archive from MediaFire; in the event one's locally installed security solution still flags some of the files contained inside the then extracted 7z archive, it's still a "nuisance", as those files have to be manually put inside an exception list ... Let us NOT revisit the whole "K" discussion (beaten to death already), I still respect the views voiced by members here ; but let's consider that in places of the world where XP is still used (e.g. in ex-USSR states), "K" (v2018 Free?) might be also installed as a local Security Suite ; the best approach (apart from recreating the culprit files) would be to send those unjustly flagged files to Kaspersky Lab themselves, so, hopefully, they could lift their block on them: https://support.kaspersky.com/common/error/other/1870 https://opentip.kaspersky.com/ @Multibooter, would you consider this? Kind regards. PS: I suppose you're still being able to fetch definition updates after the Sep2024 US ban?- 920 replies
-
1
-
- TLS protocols
- HTTPSProxy
-
(and 3 more)
Tagged with:
-
https://chromewebstore.google.com/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo v5.3.3 is of the MV3 type and requires APIs found on Cr120+ : "manifest_version": 3, "minimum_chrome_version": "120", I looked at my own archives, where I had noted down that the last MV2 version of (stable) TM is v5.1.1 (requires Cr71+); the last TM BETA version in MV2 "manifest format" was v5.1.6194 (again, Cr71+); both can be acquired from crx4chrome ; NB: You'd have to use a more recent browser to get these, though, because crx4chrome has put self-hosted files behind a CF check that Cr86 is unable to pass ... Addition: The last MV2 stable version (5.1.1) of TM has been re-uploaded to CWS under a new name/extension-id: https://chromewebstore.google.com/detail/tampermonkey-legacy/lcmhijbkigalmkeommnijlpobloojgfn From cursory testing, both TM-5.1.1 and TMb-5.1.6194 seem to install and function properly under 360EEv13.5, even when "chrome://flags/#enable-experimental-web-platform-features" has been user-enabled (so definitely a plus compared to latest VM version): I couldn't reproduce , this is another riddle of yours I'm not willing to dive into (perhaps TM-5.1.1 is broken on your "dirty" profile because of something else? ) ... Cheers ...
-
... OK @Dave-H, I think I have solved this difficult riddle of yours, so I'd kindly ask for "preferential treatment" for the rest of the year ; joking aside, I bet you 100 quid you have toggled the following pref chrome://flags/#enable-experimental-web-platform-features to "Enabled", to squeeze more out of the old Chromium 86 JS+CSS engine, have you not? On an epiphany (pun intended, it's already Jan 6th here), I remembered a discussion inside the Supermium issue tracker, where Client Hints was the topic... The aforementioned pref, in versions of Chrome ranging in the mid-to-late 80s, enables an alpha/gestational form of the CH API, which was only finalised in the early-to-mid 90s (and sometime after Cr87 it was put behind its own flag, decoupled from experimental-web-platform-features) ... If you visit https://browserleaks.com/client-hints do you get under "Client Hints JavaScript API: API Support" -> True ? If yes, that's the origin of your VM issue; I can replicate your 360EEv13.5 VM issue myself if I do enable that pref ("Disabled" in a fresh/default profile), please see below: The behaviour you're experiencing is caused by Violentmonkey (and Tampermonkey ?) code but in defence of the VM maintainers, they couldn't possibly author code to cover ALL cases of users messing with the "you're-not-supposed-to-touch" Chrome's "Experiments", aka "chrome://flags/"; more so, when they're currently supporting Cr 61-131 (and each of those has its own, unique, set of "Experiments") ... Technical stuff: The culprit commit is the one below: https://github.com/violentmonkey/violentmonkey/commit/d2dda25d91e3718e5b20ba4648e82baf730e6178 from May 2024; this one assumes the browser comes equipped with the final iteration of the Client Hints API, which isn't true for Cr86/87; no CH API (the default in Cr86/87) doesn't break VM >= 2.19.1, but a draft/RC CH API does ... Mitigations: If you want to install and use the latest version of VM in 360EEv13.x (Cr86), you'd have to a) disable/never enable "chrome://flags/#enable-experimental-web-platform-features"; this will reduce, somewhat, web compatibility with certain sites that expect recent Chromium-based web engines... b) if you opt to enable "chrome://flags/#enable-experimental-web-platform-features" for webcompat purposes, then you should disable Cr86's draft CH API via the cmdline switch: " --disable-features=UserAgentClientHint" (e.g., add that to loader's "Parameters"); some recent websites which rely on sniffing UA CHs may break... If the website of interest remains functional ONLY when detecting some Client Hints (e.g., some sites "take you for a bot" and outright block you when no CHs are sent), then you'd have to enable "chrome://flags/#enable-experimental-web-platform-features" in 360EEv13.x but opt for an older version of VM, one < 2.19.1 (crx4chrome should afford those...). Well, that's it ; detective work concluded successfully: case filed! Best wishes ...
-
... First do as instructed: If you're using one of the "portable" (with X-Loader) distributions, it's quite easy to back-up your current profile (dir "USER DATA") and restore it when testing is over; also back-up your loader config file (360Loader.ini), if custom-modified, and use the stock version for testing; on the fresh profile, install just VM (stable or BETA), install some userscripts and test their correct functioning; if they do work as designed, then your predicament in your dirty profile is due to a) a custom browser setting, b) a custom chrome://flags/, c) a custom cmdline switch defined inside 360Loader.ini (under "Parameters"), d) an interaction with one of the rest of the installed extensions, e) something else I can't think off-the-top-of-my-head ... Almost all Web Extensions targeting Google Chrome will have to migrate, eventually, to MV3, which by itself requires Chrome 88+, and this is just for the simplest of extensions; many require even higher Chrome versions, because the needed MV3 APIs were introduced well after v88... Violentmonkey will also have to migrate, there's an open GH issue about it: https://github.com/violentmonkey/violentmonkey/issues/1934 Thus, if you need to keep using 360EEv13.x, you'd have to freeze extensions to their last MV2 iteration... PS: I inadvertently submitted this post before its conclusion, so your copy delivered through e-mail notification will have ended abruptly; apologies ...
-
... Can't remember where I snitched this from or where to test its correct functionality, but here you go : // ==UserScript== // @name Inject Promise.withResolvers() Polyfill [119] // @version 0.0.1 // @match *://*/* // @run-at document-start // @grant none // ==/UserScript== Promise.withResolvers || (Promise.withResolvers = function withResolvers() { var a, b, c = new this(function (resolve, reject) { a = resolve; b = reject; }); return {resolve: a, reject: b, promise: c}; });
-
Hi Dave, Happy New Year ! It's been a long while since I last launched my 360EEv13.x copies, but your post made me test things on my side; I seem unable to confirm nor reproduce your findings here ; in a quasi-fresh profile of v13.5.1022.0 I installed the latest BETA version of the Violentmonkey extension from the CWS, https://chrome.google.com/webstore/detail/violentmonkey-beta/opokoaglpekkimldnlggpoagmjegichg The "new" CWS is incompatible with Cr86, so I first downloaded the .CRX file of the extension via "Supermium+Get CRX" extension... As you wrote, VM-2.29.1b installed fine; I then imported a scripts+settings back-up I had previously exported from my VM installation under KafanMiniBrowser (Cr87-based); that backup was imported successfully in the 360EEv13.5 browser; all installed scripts were loaded without errors and upon checking them on the associated webpages, I verified they work as intended... I have many userscripts installed but, as two examples for you, below is the userscript https://github.com/Procyon-b/GitHub-sort-by-recently/blob/master/userscript.user.js working on the VM GH repo page (the script, unfortunately, ONLY works when NOT being logged-in to GH): and further down is the userscript https://greasyfork.org/scripts/479807-chrome-new-webstore-make-available-for-all-web-browsers-which-support-it working on the "new CWS" webpage for VM BETA: There have been many rebuilds of the 360EEv13.x browsers , unsure which flavour you're using yourself; TBH, since both 13.0 and 13.5 use the same Cr86 core, I never did bother myself with 13.5 and stuck, at that time, to a v13.0 (Russian) mod; roytam1's Serpent 52 was serving me well at that period, 360EEv13 was ONLY used by me for some Chromium-specific webpages... It's really sad that now both 360EEv13.x and St52 are inadequate for the sites I use (e.g. GitHub), so latest Supermium it has to be for me, mainly ; but when I was using 360EEv13, I had no issues with the Violentmonkey extension... Please try to troubleshoot with a fresh 13.5 profile; and try to familiarise yourself with all the VM settings; take extra care to leave the "script injection mode" to its default setting, i.e. "auto"... Cheers ...
-
... Obviously NOT the preferred practice among many here, but if you install the extension directly from the CWS and have not opted for Supermium's "Ungoogled" mode (or blocked extensions-update-check via a cmdline flag: " --disable-background-networking"), the extension will auto-update if a compatible newer version has been released since - to speed this up yourself, you can go to "chrome://extensions/", enable Developer Mode and click the "Update" button; I realise this forum is frequented mostly by haters of "auto-everything" , just stating the default Supermium behaviour for the rest of the members ...
-
... You've guessed it, there's already a third-party extension that does better than those Google Chrome devs did : https://chromewebstore.google.com/detail/local-audio-player/cdlcldfkcgmpndknbabgmhfkeeampkcn NB: To play local audio files, you have to go into the extension's settings: chrome://extensions/?id=cdlcldfkcgmpndknbabgmhfkeeampkcn#allow-on-file-urls and give it access to "file" URLs...
-
Set "chrome://flags/#close-window-with-last-tab" to "Never", then relaunch Supermium...
-
... Sounds surprisingly similar to a recently filed Supermium issue on GitHub: https://github.com/win32ss/supermium/issues/1105
-
Tampermonkey once used to be open-source, but at one point (summer of 2018) it turned into closed source ; if you'd care to read the fine prints, under https://www.tampermonkey.net/privacy.php , you'd find: Nothing to be overwhelmed about (they note it can be "user-disabled"), but "home-phoning" it is (the default setting for "Average Joe") ... Besides, TM were very eager to quickly drop support for FxESR-52.9.0 (XP+Vista EoS) and early versions of Google Chrome, so I couldn't even use it on roytam1's Serpent (52|55) forks ; likewise, on early versions of the 360EE Chinese forks... As of now, my default choice for a (WebExtension) userscript manager is the open-source Violentmonkey extension: https://chrome.google.com/webstore/detail/violentmonkey/jinjaccalgkegednnccohejagnlnfdag They're no longer supporting Fx52esr, but they're still supporting Chromium down to v61 (extension still being at MV2 ); latest stable (2.29.0) and even BETA (2.29.1) versions work fine in my Supermium profiles ; I feel most don't give it a chance because TM was/is more "hyped" ...
-
@hidao Already contained inside the SE entry posted by D.Draker, you can test your own browser's font fingerprint by loading: https://browserleaks.com/fonts (depending on your setup, the font scan and fingerprint calculation may take up to 15s; YMMV...) If you're really concerned about font fingerprinting (actually, only a fraction of browser fingerprinting techniques), some extensions are available: https://chromewebstore.google.com/detail/font-fingerprint-defender/fhkphphbadjkepgfljndicmgdlndmoke and a more powerful one (designed to tackle broader fingerprinting attempts, not just the one based on installed fonts): https://chromewebstore.google.com/detail/font-fingerprint-defender/fhkphphbadjkepgfljndicmgdlndmoke Read more: https://jshelter.org/fpd/
-
... However, the image uploaded by him isn't from an XP system: (bcryptprimitives.dll first appeared in NT 6.1), so why does ASLR not work in his case?
-
My Browser Builds (Part 5)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
That would be Mozilla's Bugzilla bug no. 151066 (archaic , opened 23 years ago + closed 22 years ago), thus: https://bugzilla.mozilla.org/show_bug.cgi?id=151066 -
My Browser Builds (Part 5)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
... FWIW, I can now access it here fine: In the PMForum link above, it was mentioned that: ... so, is your HK IP address blocked by Moonchild still? Do you have access to a VPN service with, e.g., European nodes? -
... (Official) UXP still supports "non-flat" Win7 SP1; I suppose this support also works (somehow) with "bring-aero-back" hacks under Win8+ ; official Chrome has abandoned Win7 SP1, and even Win8/8.1, support (in v110+), so "hardcoded flatness" is ALL they need to target "flat" (by default) Win10/11 ...
-
... If you are annoyed by that, you can always enable Supermium's dark mode, either via a cmdline switch (" --force-dark-mode") or internal flag "chrome://flags/#force-dark-mode" ; dark mode for web content can also be enabled via "chrome://flags/#dark-mode-settings" (Sm-v126-r6) ... ... Well, you can blame Microsoft for that, since they introduced "completely flat" with Win8 and later OSes; browser vendors had to follow and make their (browser) GUI blend with/appear native to the OS... ... When I load "chrome://settings/", I do see a left sidebar, where prefs are divided into 13+ sub-tabs, so I'd say they're "organised in some way" ; the prefs that do stand out/are easily discoverable are the ones Google deemed to be useful to the "average" Chrome user (i.e. the "masses", usually disinterested in even modifying the defaults ); settings an "advanced" Chrome user (like the MSFN members here ) would like to change are, sadly, mostly hidden behind many clicks and submenus ... If, OTOH, you're actually meaning "chrome://flags/" (aka "experiments"), then these are not supposed to be touched by "average Joe", they're akin to Mozilla's "about:config" (not to be touched, either), also presented in the form of a long list... This has been a standard Chromium feature for more years than I care to remember , even emulated by Mozilla in the Australis GUI/framework (first in Fx29, released on April 29, 2014, more than 10yrs ago), so not modern at all; it's been inherited (from Australis) in Serpent 52/55, does that make them "modern GUI", too ? You're simply being accustomed to the pre-Australis GUI of New Moon 28 (GUI of Fx24esr, released back on September 17, 2013), which is considered "legacy"... If you're in for a (nasty) surprise, try enabling Chrome Refresh 2023 flags in Supermium 124/126 ... In any case, there exist several "classic" flags in Supermium that restore some parts of the older Chrome GUI (e.g. trapezoidal tabs, rectangular omnibox, etc.) ... At the end of the day, and this is just me, I prefer a (modern) browser that can properly render the sites that are meaningful for me (e.g. GitHub) to a "beautiful", customisable, GUI of a browser that can properly render only the MSFN and Pale Moon forums (exaggerating here, but you get my drift ) ... Happy Holidays !
-
FWIW, that site loads and behaves as expected here: Latest Sm-v126-r6_x86, "dirty" profile with several extensions and "chrome://flags" customisations; OS is Vista SP2 32-bit...
-
In addition to what already posted, WinRAR v6.02 can compress to both rar/rar5, while WinRAR v7.01 can only compress to rar5 (as support for rar was removed in v7.00) ; however, versions compatible with Vista SP2 have the ability to decompress .zst archives, as this feature was only introduced in v6.10 ...
- 1,236 replies
-
2
-
- Server 2008
- software
-
(and 1 more)
Tagged with:
-
At present, yt-dlp devs have dropped support for any CPython version < 3.9; the one currently being used by nicolaas to compile the WinXP/Vista 32-bit builds is a custom py3.9_x86 SSE+ compile (by another person, cmalex), so with it the yt-dlp code "should" work if invoked directly from source... Building the yt-dlp source code into an x86 .EXE is another thing altogether; support for the py2exe module has also been dropped; PyInstaller is being used to build yt-dlp_x86.exe and that module, by default, inserts the SSE2 instructions set to the binaries produced; no way is known currently to build with PyInstaller with just SSE; older PyInstaller versions are either incompatible with py3.9 itself or (on the ones tried) the build process itself fails prematurely for undefined reasons/with no evident solution available ...