Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

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. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


VistaLover

Member
  • Content Count

    792
  • Donations

    $0.00 
  • Joined

  • Last visited

  • Days Won

    47

VistaLover last won the day on September 20

VistaLover had the most liked content!

Community Reputation

743 Excellent

7 Followers

About VistaLover

Profile Information

  • OS
    Vista Home Premium x86
  • Country

Flags

  • Country Flag

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That test page is no longer valid, as pointed out by its webmaster himself: (and IIRC, that matter has been reported in detail previously in this thread; I just don't have the time at this moment to find that post...) Just use another test page to verify h.264 browser support... I don't think the CDM is downloaded automatically anymore, one has to download and install manually; some differences may be present between Fx 49 & Fx 52; just consult again, being perhaps more attentive, first post of this thread... Others may chime in with more current details, if any...
  2. With great respect, we aren't/shouldn't be doing that here... TL;DR: Previous upstream unofficial branding name for Pale Moon forks: New Moon Updated (by upstream) unofficial branding name for Pale Moon forks: Browser
  3. ... Though the author himself, in a red-lettered top notice, recommends instead to migrate to his more current utility, WinUpdatesView (v1.13) ...
  4. I'm sorry to admit that the above expectation borders with Utopia... The general consensus on "their" camp seems to be that "we" are in essence practically stealing code "we" were never meant to lay "our" hands on, that "we" are just acting selfishly, full of entitlement... I think that part was explained previously by M.A.T; hosting the source code of one project covered by MPL-2 in a private repo does not make it Closed Source; whenever the code author releases an executable form (binary) of the code, he has the obligation to provide, by reasonable means, access to the source code that was used to compile the executable form; "reasonable" means could very well be a link to a source tarball or, upon user request, dispatch of the used source via a physical storage medium (the cost of which should be covered by the user requesting it...); what's more important is the fact that the publicly revealed source code does not carry the "buildability" obligation, that is any additional "hack" used by the author to compile the source into an executable form can remain private... I see this discussion (here in this thread) quickly exploding, again, to Rebranding Roytam1's browser offerings ; so I agree with @TechnoRelic that any additional content to that end be posted in the existing specific thread, not here... My initial comment here was to highlight the fact the unofficial Pale Moon branding (upon which NM28 is built) has been changed upstream but not adopted by "us", and the eventual ramifications (if any) that decision (by "our" maintainer) may entail... I hope it's clear now...
  5. ... And this is something we've all been informed about... I'm sure it will be acted upon when convenient...
  6. I'll remind people here that I'm not actually an authority on Google Chrome and Chromium derived browsers, having been from the very start a Mozilla Firefox user, first (2005-2008) on a WinXP desktop and then (2008-2018?) on this Vista laptop... This is to clarify that I haven't followed closely Chromium's development during that era... I've learned quite a few things from XP users of Chrome 49, and it's true that specific [old] version (officially the EoS one for XP/Vista) does rely on OS resources/libraries for secure connections (which involve both available TLS protocols and available cypher suites). Contrary to what Google (the No.1 enemy of the Vista OS, by far ) believed, WinVista != WinXP, so having a fully updated Vista SP2 OS with TLS 1.2 support will grant you more accessible websites using Chrome 49 on Vista, thanks to Vista supporting more cypher suites by default and, on top of that, having SNI support that WinXP lacks... But all this is probably a moot point already, because Chrome 49's rendering engine is antiquated by now... To conclude, yes, Chromium 49 can only go up-to TLS v1.2 on an updated Vista system (with KBs targeting WS2008 originally ) At some point further down its development, Chromium disengaged to a degree from OS libs where TLS support is concerned, so that Chromium 57/58, upon which Yandex Browser (YB) 17.4/17.6 builds, comes with bundled/native support for the TLS protocol. I haven't used YB 17.6 (portable) here for many months, having long ago switched, first to 360EE v11 (Chromium 69 based), then to 360EE v12 (Chromium 78 based) and currently testing (beta channel of) 360EE v13 (Chromium 86 based). YB 17.x has other significant shortcomings by now, affecting Google Web Store (GWS) support , but that is part of a future post about YB 17.x ... By default, YB 17.6 supports TLS 1.0+1.1+1.2, provided by its own (Chromium) libs (i.e. non-dependent on OS TLS support, kinda like Firefox); but there is latent TLS 1.3 support, too, which can be enabled via a browser flag; The problem is that YB 17.6 was released at a time when TLS 1.3 hadn't been finalised yet, so it only supports a TLS 1.3 draft preceding the final one (i.e. RFC8446) Testing on dedicated TLS testing sites you get mixed results, depending on whether the test site detects pre-final TLS 1.3 drafts or not; SSL Labs client test picks up pre-final TLS 1.3: ... but Browserleaks ... and pinterjann DO NOT! As a closing note, if you want to disable lower, deemed currently insecure, versions of TLS, you can launch YB via a shortcut containing the following flag: --ssl-version-min=tls1.2 or --ssl-version-min=tls1.1 if you want to disable just TLS 1.0 ...
  7. The last release channel version of WSUS Offline with Vista support was v10.9.2, released on 2017-03-19; the last release channel version of WSUS Offline with WS2008 support was v11.8.3, released on 2019-11-14. Vista users should probably use the ESR channel of WSUS Offline; the last/most recent version advertised on their download page with any Vista support is v9.2.5, released on 2019-06-04: https://download.wsusoffline.net/ => Archive However, there's still a more recent v9.2.6, not being publicly advertised, released on 2019-11-08: https://download.wsusoffline.net/wsusoffline926.zip
  8. Thanks for the explanation! How do you intend on pursuing this? Will you be going back to a --disable-accessibility build config flag for your future NM28 builds, continue as things stand now or is this simply now out of your control? ... OK then, pretty much as I had it figured out myself...
  9. Let me begin by thanking you for continuing to deliver updated builds of your browsers, despite the recent major hardware hardships... (pun intended! ) Starting with last weekend's New Moon 28 package (linked-to above) and including this weekend's latest NM28 offering, I've noticed that 3 compiled files, all previously associated with Serpent 52.9.0 builds, have somehow slipped into New Moon's main app directory; these files are: Accessible.tlb AccessibleMarshal.dll IA2Marshal.dll I browsed quickly your custom UXP branch and did not find any clues there as to why these 3 files now appear inside NM28's main appdir ; if it's any info, these 3 files also do not appear inside upstream official compilations of Pale Moon 28.13.0/29.0.0a6; but since our fork has deviated somewhat from upstream, that fact may or may not be relevant... Mentioned files, as pretty much expected, continue to reside inside Serpent 52.9.0's main appdir (as well as in upstream official Basilisk 52.9.2020.09.11 ) Now, as a test, I went along and deleted those 3 "errant" files and latest New Moon 28.10.2a1 32-bit (buildID=20200918232718) launches and runs fine here (Vista SP2 32-bit, build 6.0..6003) without them... It looks as if those files are generated via a first stage Serpent/UXP compilation and are then added, by mistake, with other compiled files that are common/shared with the New Moon 28/UXP compile/build (possibly to expedite compilation of both UXP browsers...); if that's by design (and may I note that this wasn't the case with the previous [now lost] building environment), perhaps it would be best to remove those 3 unneeded (for NM28) files post compilation and prior to packaging/uploading... https://github.com/MoonchildProductions/UXP/issues/1653 Clean up Windows widget code https://github.com/MoonchildProductions/UXP/commit/6f5cd8a [widget] Clean up Windows widget code some. Can you please elaborate a bit why upstream UXP#1653 was not merged? Would it have broken WinXP compatibility if it had? Being on Vista here (NT 6.0), could this have been handled slightly differently if it provides performance improvements on Vista+? (e.g. ifdef'd to load the code under Vista+ but not under XP?) Apologies if I'm asking something that can't be done... I'm really sorry to have to bring this up, but don't you expect "upstream" to hear about that? You are, at the end of the day, still building "unofficial" Pale Moon builds and upstream have modified that branding (which is their prerogative, it appears...). I won't pretend I understand fully the Open Source licensing schemes, but I smell (additional) trouble coming from upstream, this time from Moonchild himself With all said and done (and undone) in the past, I'd hate to witness any further escalation between "us" and "them", especially if it results in more restrictive action(s)/sanctions from upstream... What do others think on this? Finally, I don't use any of these forks myself, but out of pure (healthy) curiosity, what source do you actually use now to produce updated builds of? AFAIAA, upstream have moved to a private repository, so are you now just updating the platform (UXP) submodule/component, which is still public? Thanks for all your hard work and efforts , thanks in advance for any answers received... Best greetings
  10. MSE offline definitions file (mpam-fe.exe) and WD offline definitions file (mpas-fe.exe) both share the same engine, file mpengine.dll (currently at version 1.1.1730.5); no need to wonder anymore...
  11. ... Now you hush, "young" gentleman! Those people are already extremely p***ed that you, single-handedly, created the Vista Extended Kernel project, so much so that they fear their "support channels" will get overwhelmed by Vista users running their official builds: https://forum.palemoon.org/viewtopic.php?p=198116#p198116 As the saying goes, "No good deed goes unpunished" ...
  12. In yet another move, MCP have just modified specifically the unofficial branding for their Pale Moon web browser application: https://github.com/MoonchildProductions/Pale-Moon/commit/54aeb54 with updated graphics and nomenclature ... The overhauled graphics resembles that of the Mozilla Firefox recent Nightly channel, in blue-purple colours: ... but the new name given to unbranded unofficial builds (like what has been till now @roytam1's New Moon 28) is just... Browser ! No doubt a attempt on their part to coerce things to move to the direction they want... So, come this weekend (with the hope @roytam1's hardware issues are somehow rectified), be prepared to say hello to Browser 28.10.2a1 ...
×
×
  • Create New...