Jump to content

VistaLover

Member
  • Posts

    2,128
  • Joined

  • Last visited

  • Days Won

    93
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. @Mathwiz : Seems this issue is unique to quotes generated by member @InterLinked ; e.g. https://msfn.org/board/topic/182647-my-browser-builds-part-3/page/62/?tab=comments#comment-1207515 Screenshot of post rendered by Serpent v52.9.0 (2021-10-08) 32-bit:
  2. Thank you both for testing and confirming ... Consistent with the digital SHA-2 signature date (2021-05-01) of the revised 4.6.2 setup; the page must've been edited soon after May 6th... Bingo! It's all clear now... The ESU plan for WS2008SP2 ends in Jan 2023, however security updates support for officially sanctioned .NET FW 4.6 will end, as said, in late Apr 2022; that would've created a period of ca. 9 months, during which installed 4.6 would have stayed unpatched... Possibly due to technical reasons, M$ deemed it easier to patch 4.6.2 (still supported past Apr 2022) to also install under WS2008SP2, rather than modify and offer 4.7.x (or higher) to existing WS2008SP2 ESU customers... And the omission of 4.6.1 from the linked article isn't an error; we already know that 4.6.1 installs successfully under NT 6.0, but it was never officially supported (as in via MU) there ; M$'s plan is to migrate WS2008SP2 ESU paying customers from 4.6 directly to 4.6.2 before/soon after Apr 2022 (till Jan 2023, when ESU ends); since 4.6.1 EOLs at the same time as 4.6, no reason for M$ to even mention it in that scenario... But another thing bugs me now: How is the revised (2021) 4.6.2 setup different internally to the first (2016) release? Does it embed ALL security updates issued for 4.6.2 from Jul 2016 to May 2021? File sizes are almost identical, so this fact isn't revealing anything ... Of course, MU would never work for 4.6.2 under Vista SP2, still, one has to know what updates to download manually from MUC; and then there's the "problem"/grey area of installing from local files ESU .NET FW 4.6.x updates... In any case, I understand this is the Windows Vista Extended Kernel thread, so I'm party responsible for (slightly?) derailing it ; however, this is info important to the broader Vista Community, so if the mods decide it should be better placed elsewhere (info = series of recent posts about .NET FW 4.6.2/Vista | WS2008), feel free to do so...
  3. https://github.com/ShareX/ShareX/releases/tag/v13.0.1 default ShareX.exe.config file: <?xml version="1.0" encoding="utf-8"?> <configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.2" /> </startup> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="Languages" /> </assemblyBinding> <AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" /> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.0.0" /> </dependentAssembly> </assemblyBinding> </runtime> <uri> <idn enabled="All" /> <iriParsing enabled="true" /> </uri> <appSettings> <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" /> </appSettings> </configuration>
  4. I was intrigued by your report , so I connected an external HDD in which I had archived a copy of NDP462-KB3151800-x86-x64-AllOS-ENU.exe originally downloaded Sep 14th 2016; that off-line installer was dual-signed (SHA1+SHA2) on July 15th 2016; running that installer now, after file extraction, generates the familiar error below: I closed that installation attempt and then went to https://dotnet.microsoft.com/download/dotnet-framework/thank-you/net462-offline-installer Direct link is https://go.microsoft.com/fwlink/?linkid=2099468 The latter fetched file ndp462-kb3151800-x86-x64-allos-enu.exe (in small letters this time ) which is only SHA-2 signed on May 1st 2021; my Vista SP2 32-bit system has SHA-2 support installed, so when I ran that second off-line installer, and after file extraction (takes a few seconds, because it scans ALL your drives to choose the one with maximum FREE disk space), I was, surprisingly, presented with: Now, I didn't click Install to go on with the 4.6.2 installation, because I wasn't yet ready to part with my existing, perfectly working, 4.6.1 setup... Perhaps the 4.6.2 installation would have aborted at a later stage, or perhaps NOT... The thing is the updated .NF462 setup doesn't immediately barf when it detects NT6.0; another kind soul with Vista SP2 in a VM could try that new installer to explore whether it "requires special procedures" to complete the installation... FWIW, since this revised setup targets WS2008SP2, I expect it would require a special minimum set of WS2008SP2 updates to be present in your Vista SP2 image...
  5. 34.0.0.201 is a pre-release/beta build; the official Chinese Flash distributor still advertises 32.0.0.192 as the latest stable/recommended release...
  6. Should be possible, if one of them is run as PORTABLE (so that their profiles remain isolated) - see previous post by @ArcticFoxie ; might need to rename the main executable of one of them to serpent.exe, if you absolutely need to run them both concurrently... Both are run as portables, St52's EXE has been renamed ...
  7. ... The old location in the WinXP subforum, and pardon me XP-users for saying so , wasn't very appropriate either, because: 1. The majority (if not all) of the roytam1 browsers can be run on WinOSes past WinXP (e.g. Vista SP2/Win7 SP1/etc.); apart from yours truly (on Vista SP2 32-bit), I am aware of MSFN members running e.g. St52 under Win7, despite that OS offering, at least at this time, a varied selection of supported recent/mainstream browsers... 2. Several roytam1 browsers can be run on WinOSes preceding WinXP (natively or via KernelEx) ... Thus, "Browsers working on Older NT-Family OSes" is fine by me... The key word here is "Older" which, as far as MS are concerned, should denote evey WinOS < 8.1 ... Being realistic though, I can acknowledge the vast majority of users falling into the WinXP group... That doesn't mean Vista users should be treated differently, does it? Browsers offer the bookmark function, so "latest XP news"? https://msfn.org/board/forum/34-windows-xp/ and, similarly, "latest Vista news"? https://msfn.org/board/forum/67-windows-vista/
  8. The plot mysteriously thickens... Package "palemoon-27.10.0.win32-git-20210904-d43e6f58e-xpmod"; Flash set to "Ask to Activate"; on https://get.adobe.com/flashplayer/about/ (my Flash test page), the plugin URLbar icon is "invisible": whereas on http://www.snailsanimation.com/benchmark08_play.php (your Flash test page) is there:
  9. ... Perhaps you're referring to the fact Adobe Flash Player had been the last NPAPI plugin for which Firefox support was removed (whereas support for other NPAPIs like PDF/Java/WMPlayer/etc. was axed quite earlier...) ? ... But, does it show up on package "palemoon-27.10.0.win32-git-20210904-d43e6f58e-xpmod.7z" and earlier builds? I think there are two related bugs here: 1. The "plugin icon" (what I called "plugin permissions control icon") not showing up in the left extremity of the URLbar (which, according to my test, precedes package "palemoon-27.10.0.win32-git-20210911-8d7b56d38-xpmod.7z"), and 2. "Ask-to-Activate" as a whole not working at all, which, as you said, manifests itself starting with package "palemoon-27.10.0.win32-git-20210911-8d7b56d38-xpmod.7z" ...
  10. Hi ; long time, no see (at least in this thread ...); well, what is it to be startled by? I, since long ago, consider Firefox Browser (as in post Firefox Quantum) to be a Chromium fork of sorts... Sure, Firefox 93.0 can open docs.microsoft.com pages without issues...
  11. I tested this with Adobe Flash Player v34.0.0.192 (set to "Ask to Activate") and the official test page: https://get.adobe.com/flashplayer/about/ While I can indeed confirm the findings reported by RainyShadow in latest NM27: 1. No Flash frame is displayed at all 2. The plugin permissions control icon is missing at the beginning of the URL bar , I'm afraid the "Ask-to-Activate" feature has been partially broken even before BuildID=20210910040612 (package "palemoon-27.10.0.win32-git-20210911-8d7b56d38-xpmod.7z"); e.g., with BuildID=20210903005445 (package "palemoon-27.10.0.win32-git-20210904-d43e6f58e-xpmod.7z") I get this: i.e. the "plugin" icon in the URL bar is still gone, and the grey Flash frame doesn't display the prompt to "Activate Adobe Flash"; for comparison, here's how latest St52 behaves:
  12. Below screengrab is from a visit to linked article in my dirty St52 profile: As I already wrote, M$ want you to use [Chr]Edge on their sites...
  13. https://docs.microsoft.com/ defaults to https://docs.microsoft.com/el-gr/ here , and the page does load in latest Serpent 52.9.0; for the rest of you not able to read Greek , the equivalent English page is: https://docs.microsoft.com/en-us/ The SyntaxError reported is still there, but refering to a different "*.index-docs.js" script ; what doesn't work is the searchbar on top of that page, because when you hit "Search", it redirects to https://docs.microsoft.com/el-gr/search (or https://docs.microsoft.com/en-us/search ) which is loaded blank , except for a footer; again, responsible is a SyntaxError in a different "*.index-docs.js" script... Incidentally, I only recently mentioned the https://docs.microsoft.com/en-us/search "issue" in the 360EE thread, ... 'T is the way Google Chrome devs want "things" to work now: ONLY in the latest version of THEIR browser (and forks of...); WWW? Nah, WWD (=dictatorship)... But this discussion belongs elsewhere....
  14. Thanks for the additional feedback... If I were to follow fully @ArcticFoxie 's way-of-doing-things, and let it be documented I have ZERO OBJECTION against, I should feel elated that I can load https://docs.github.com/en/rest/* URIs in both 360EEv11/v12 via blocking (in uBO) ALL scripts originating from "docs.github.com", without any perceivable dent(s) in the pages' expected performance ... However, the little sleuth in me wants my previous query answered: After some trial-and-error, it turns out the sole script responsible for the final page blank-out in said browsers is https://docs.github.com/_next/static/chunks/webpack-af28476a2e7790fd48db.js Blocking just the above script is sufficient for GitHub Docs pages to render fully in 360EEv11 (Ch69-based) and 360EEv12 (Ch78-based); in uB0, I just created the following static filter: ! https://docs.github.com ||docs.github.com/_next/static/chunks/webpack-af28476a2e7790fd48db.js$script,domain=docs.github.com "and whoala" :
  15. Thanks for testing! Unfortunately, I don't use NoScript (is this the one you're using?), nor am I inclined to install it for the sake of just this site... However, your input has been much appreciated ; I think I've achieved a similar effect by denying "scripting" on "docs.github.com" via uBO: and, e.g., https://docs.github.com/en/rest/overview/api-previews loads now in 360EEv12 just fine ! uBO's logger shows that a total of 12 scripts are being blocked, so my understanding is that one (or more) of them are incompatible with the JS engines of 360EEv11/v12 (but compatible with 360EEv13) ...
  16. I am unable to fully load GitHub Docs in both 360EEv11 and 360EEv12 ; https://docs.github.com/en/rest/reference/repos ... begins to load in an apparent "normal" fashion (it's a rather "elongated" page), but - just before load completion - it blanks out in the end! I have tried in both browsers to use a clean/fresh profile without any extension, but the issue persists ; the javascript console isn't telling much... The page eventually loads fully in 360EEv13 (and, FWIW, in latest St52+gh-wc-p), but if there's some workaround to enable it on either v12/v11, I'd much prefer it over v13 (v12 and, especially, v11 are much more "fluid" in this 13-yr old Vista laptop ) ... FTR. another Microsoft-owned page that demands at least 360EEv13 is Microsoft Docs Search : https://docs.microsoft.com/en-us/search/ ; I feel it's no coincidence either... I'm quite certain that after M$ adopted Chromium as the basis for their re-incarnated Edge Browser, they're making absolutely sure pages they have control on are fully working only on recent/latest Chromium-based browsers...
  17. http://web.archive.org/web/20201209013928/https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Working_with_multiprocess_Firefox
  18. The documentation was removed last December: http://web.archive.org/web/20200801000000*/https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Working_with_multiprocess_Firefox Relevant articles: https://blog.mozilla.org/addons/2016/08/02/multi-process-firefox-and-add-ons-a-call-to-action/ https://wiki.mozilla.org/Add-ons/developer/communication#Migration_paths_for_developers_of_legacy_add-ons https://extensionworkshop.com/documentation/develop/comparison-with-the-add-on-sdk/ I'm quite sure additional documentation has been spared from Mozilla's axe, it's just that one needs to hunt it down with determination...
  19. As I stressed already, GitHub pages do load when e10s is force-enabled in St52, but the gh-wc-p extension isn't e10s-compatible; this means that the majority of useful functions (especially for a logged-in user) in the GitHub web front-end simply fail to work... Read the relevant discussion over at https://github.com/JustOff/github-wc-polyfill/issues/33
  20. Technically, they're being distributed by Zhongcheng, the exclusive and official distributor of Adobe Flash Player (in mainland China): The form of distribution has shifted recently to an AIO executable called Flash Center: https://www.flash.cn/english (links to FlashCenter_Setup_1.0.6.43_silent_10001.exe) Individual plugin installers (be it only stub, i.e. on-line) are linked on: https://www.flash.cn/download-wins but unsure whether they'll be phased out completely, in favour of Flash Center... Due to the spyware nature of these Chinese Flash products, several recent filter lists (e.g. inside uBO) will flag "www.flash.cn/*" URIs as malicious and block them from loading in the browser...
  21. 34.0.0.192 works fine in 360EEv12 under Vista SP2 32-bit: No nags whatsoever...
  22. And, as far as upstream are concerned, the same stands true for the remainder of this month and the first week of November: https://forum.palemoon.org/viewtopic.php?p=220767#p220767 http://developer.palemoon.org/docs/release-engineering/ Pale Moon Version - CLOSED TREE - Intended Release Date - Type of Release 29.5.0 2021-11-02 2021-11-09 Major/Feature Release
  23. That fetches a .CSV file, inside which: ia64 Windows Server 2008,,,,,,, File name,File version,File size,Date,Time,Platform,SP requirement,Service branch Hal.dll,6.0.6003.20489,"428,264",21-Mar-19,1:32,IA-64,None,Not applicable File name,Ia64_hal.inf_31bf3856ad364e35_6.0.6003.20489_none_0726f69c1b902d52.manifest,,,,,, File version,Not applicable,,,,,, File size,"1,655",,,,,, Date (UTC),21-Mar-19,,,,,, Time (UTC),3:40,,,,,, Platform,Not applicable,,,,,, x86 Windows Vista,,,,,,, File name,File version,File size,Date,Time,Platform,SP requirement,Service branch Halacpi.dll,6.0.6003.20489,"137,960",21-Mar-19,1:53,x86,None,Not applicable Halmacpi.dll,6.0.6003.20489,"169,704",21-Mar-19,1:53,x86,None,Not applicable File name,X86_hal.inf_31bf3856ad364e35_6.0.6003.20489_none_072552a61b922456.manifest,,,,,, File version,Not applicable,,,,,, File size,"2,244",,,,,, Date (UTC),21-Mar-19,,,,,, Time (UTC),3:57,,,,,, Platform,Not applicable,,,,,, x64 Windows Vista and Windows Server 2008,,,,,,, File name,File version,File size,Date,Time,Platform,SP requirement,Service branch Hal.dll,6.0.6003.20489,"230,632",21-Mar-19,1:41,x64,None,Not applicable File name,Amd64_hal.inf_31bf3856ad364e35_6.0.6003.20489_none_6343ee29d3ef958c.manifest,,,,,, File version,Not applicable,,,,,, File size,"1,656",,,,,, Date (UTC),21-Mar-19,,,,,, Time (UTC),4:15,,,,,, Platform,Not applicable,,,,,, So, though not specifically mentioned, the KB does update HAL related files to v6.0.6003.20489
  24. This is just a guess, but since I see no sse/ia32 part in the package's filename, I suspect it's been compiled to expect at least SSE2...
  25. ... YES; remove the LAV dlls adjacent to basilisk.exe, exit browser, relaunch browser and test: http://demo.nimius.net/video_test/ https://tekeye.uk/html/html5-video-test-page http://camendesign.com/code/video_for_everybody/test.html http://www.html5videoplayer.net/html5video/mp4-h-264-video-test/ https://ophi.org.uk/test-html5-video/ These DLLs have been updated by roytam1 on Sep 25th, 2021 ; they are based on FFmpeg 3.4.9 Those were based on FFmpeg 3.1.1 What does that even mean? What type of CPU are you on? If it supports SSE2 instruction set, download the default package; if it supports up-to SSE, download the ia32 variant; for even older CPU, give the noasm variant a try... The links are for the 32-bit architecture; the extracted DLLs must be placed adjacent to palemoon.exe (for NM27) / arcticfox.exe (for ArcticFox-Win); the browser has to be restarted to successfully load the DLLs...
×
×
  • Create New...