Jump to content

VistaLover

Member
  • Posts

    2,156
  • Joined

  • Last visited

  • Days Won

    93
  • Donations

    0.00 USD 
  • Country

    Greece

Posts posted by VistaLover

  1. 6 hours ago, NotHereToPlayGames said:

    fairly common when sites allow the user to pick their own "theme" or "skin" which isn't applied until signed in.

    In the case of GitHub, and I'm talking here strictly about a dark vs light theme, not the new "Global Navigation Update :puke:", they respect the browser's default/custom setting (provided the browser has such a setting) with regards to anonymous visitors.

    In Serpent 52, that setting is:

    browser.display.prefers_color_scheme

    and when left to its default value of 1, GH will serve their Light Theme to (anonymous) visitors; change that pref to a value of 2 and they'll serve their Dark Theme...

    A signed-in GH member can control the type of Theme served via custom "Appearance" settings inside his GH profile, where more than two Theme selections are offered, and can thus override the aforementioned browser setting...

    In contrast to GitHub, GitLab only offer their anonymous visitors a Light Theme variant (see my previous post); to change that, you'd have to sign-in ;) ...

  2. On 10/17/2023 at 8:47 PM, Mathwiz said:

    Why on Earth does their GitHub UI change if you sign in?
    I would expect the only change to be the words "Sign in" change to "Sign out."
    But, I guess not in Micro$oftLand.

    It's worse than that :realmad: ; the sign-out option (not a button anymore, either :angry:) is tucked away inside one's "avatar" menu, which now opens as a right sidebar:

    ZfbVTMW.png

    OT ;) : On the 360EEv13+ variants (which have better support for GH compared to current UXP-based browsers), my "avatar menu", instead of opening as a right sidebar, travels all the way to the left and displays as a left sidebar; this is annoying, because I then have to move the mouse cursor towards the left (vertical) tab border to access that menu's entries :( ; can others reproduce? A fix for that would be most welcome!

    Yes, most sites (including GH) want you permanently signed-in, so that they would track/monitor you more efficiently :realmad: ... I do spend a lot of online time on various GH pages and need to use members-only features (e.g. comment on issue trackers, react to comments, download GitHub Actions artifacts, etc.), and what with the "hoops" of signing-out and then signing back in (especially when your ISP has "given" you a new dynamic IP address in the interim ;) ), I tend to stay mostly logged-in and protect those signed-in GitHub cookies in my browser profile via a dedicated extension...

    BTW, GitLab also serve different CSS files to anonymous visitors Vs logged-in members:

    Signed-out:

    ycgV3NA.png

    Signed-in (dark theme offered/selected):

    EtwGmRo.png

    On 10/17/2023 at 8:47 PM, Mathwiz said:

    Follow-up: where are the defaults (if "Use Default" is checked) stored and can the defaults be modified?

    You are shown the "default" vendor selection for a said site permission when the "Use Default" square has been ticked; e.g., for "Access Your Location", the default permission is "Always Ask" (and that default is again stored inside permissions.sqlite); if the user unticks the "Use Default" box, then he/she(/they-them :)) can choose one of the two other (non-default) available selections (i.e. Allow/Block), which are now non-greyed-out; finally, ticking anew the "Use Default" square will reset the permission to "Always Ask" and grey-out the other two...

  3. As posted already, file "Login Data" inside 360EE's profile is where login credentials for user accounts are stored; the file is actually of the sqlite format, but without that file extension (in contrast to Mozilla Firefox, where similar files come with the .sqlite extension); inside that file, ONLY actual password strings are being encrypted, not the sites for which you have created accounts for, nor the actual usernames/e-mails you're using on those sites to log-in; so, be careful with that info, too :sneaky: ...

    Password string encryption is tied to the machine/OS where the password was first saved/created, because parts needed for their decryption (salt?) are stored, encrypted, inside the host's registry; this is different to Mozilla Firefox, where you just need logins.json+key*.db profile dir files to transfer account credentials between Firefox profiles! In any case, profiles in recent Chromium versions are really not portable across different machines :(  ...

    360EE also doesn't offer you an option to actually see saved passwords when

    chrome://settings/passwords

    has been loaded, nor does it allow you to export saved account credentials in an unencrypted form (.txt, .json, .csv, etc.) - recent Chrome versions (XP-incompatible, of course) do come with such a feature ;) ...

    What worked for me to manually transfer account credentials from an old 360EE profile to a new one, on a second, different, machine (from Windows Vista SP2 32-bit to Windows 7 SP1 64-bit) was the NirSoft utility called ChromePass ;) .

    Depending on the type of your 360EE installation (e.g. "proper" or "portable"), you may have to point ChromePass to the actual 360EE profile dir account credentials are to be extracted from; if you don't have a lot of created site accounts (say, less than 20), then you can manually transfer those accounts to other browser profiles, on the same or different machines...

    NB: Be sure to first read the CP documentation on its site - for 360EEv13+, Chr86-based, you'd need versions > 1.50 ...

    Quote

    Version 1.50:

    Added support for the new password encryption of Chromium / Chrome Web browsers, starting from version 80.

    Be aware that the 'Local State' file, located inside the 'User Data' folder (Parent of your Chrome profile folder), is needed for decrypting the passwords of Chrome 80 or later.

    In most cases, ChromePass will find your 'Local State' file automatically, but if it fails to find this file from some reason, you can manually type the 'Local State' filename in the 'Advanced Options' window.

    Hope I've helped ;) ... Cheers :)

  4. 21 minutes ago, luweitest said:

    Where is the Serpent 52's location sharing permission to websites stored?

    Site permissions are stored inside the permissions.sqlite file, inside St52's profile directory;

    https://support.mozilla.org/en-US/questions/1091830

    Quote

    You can use the SQLite Manager extension in Firefox to inspect SQLite database files.

    https://addons.mozilla.org/firefox/addon/sqlite-manager/

     // should be now findable inside CAA

    permissions.sqlite stores site specific permissions (Site Preferences) as you can see by its name.

    If you're asking how to modify the "location sharing permission" on a given website, then the article above also covers that scenario:

    Quote

    You can inspect and manage permissions for the domain in the currently selected tab via these steps:

    click the "Site Identity Button" (globe/padlock) on the location/address bar

    click "More Information" to open "Tools > Page Info" with the Security tab selected

    Go to the Permissions tab (Tools > Page Info > Permissions) to check the permissions for the domain in the currently selected tab.

    6JZ4hHK.png

    (View) Page Info is also available via the browser's Context Menu :P ...

  5. Since last May 3rd, GitHub's layout is rendered considerably BROKEN under UXP-based browsers, but, at the same time, remains 95% usable... The breakage in the layout is caused by UXP not supporting max()/min() CSS functions, first implemented in Fx75:

    https://developer.mozilla.org/en-US/docs/Web/CSS/max

    https://developer.mozilla.org/en-US/docs/Web/CSS/min

    This is being tracked by upstream in #2230 :P (read PM Forum entry here); since Mozilla implemented that in Stylo, it's a Herculean task to backport this to UXP, hence that issue hasn't seen any activity whatsoever over the last 5 1/2 months :( ...

    Until June 16th, it was still possible to revert to the old layout, that rendered OK in UXP, by blocking several so-called "primer-primitives" GitHub CSS files, but that trick stopped working past the aforementioned date :angry: ...

    To add insult to injury, Microsoft today shoved down GitHub users' throats :realmad: another layout abomination in the shape of the "Global Navigation Update", which was, until today, just a "Feature Preview" one was able to toggle off...

    People are, of course, just hugely dissatisfied, e.g.

    https://github.com/orgs/community/discussions/52083#discussioncomment-7297619

    https://github.com/orgs/community/discussions/52083#discussioncomment-7297646

    https://github.com/orgs/community/discussions/58295

    but, as ever, big companies like MS will simply force their own "vision of progress" :puke: ...

    Here's an archived screengrab taken on 2023/05/01:

    AfkvlDX.png

    whereas below is the same GH URI as it renders now in St52:

    8uy4kjX.png

    The red rectangle highlights the broken area :realmad: in the new GitHub "header" :angry: :( ; this, I found, can be mitigated for now by blocking another set of "primer-primitives" GitHub CSS files, and I did that via a custom filter inside uBO-legacy:

    ||github.githubassets.com/assets/primer-primitives-$stylesheet,domain=github.com,important

    Result:

    NjALbbK.png

    Of course, the new layout abomination also broke several custom userstyles/userscripts I have installed for GitHub that target its header, thus exacerbating my overall frustration :o over this unwarranted change (for the worse) ; it's final :(: "desktop" web page design has ceased to exist; convert everything to a mobile-friendly layout, with ceaseless page scrolling :angry: added on top as cake frosting :realmad: (Google Search :realmad: did exactly that some weeks ago, abolishing search result pagination) ...

  6. 11 hours ago, roytam1 said:

    ... Yes, it appears dbsoft (aka Brian Smith), the leading MacOS upstream developer :P, is (occasionally?) monitoring this thread :thumbup :

    https://repo.palemoon.org/MoonchildProductions/UXP/issues/1442#issuecomment-38212

    Even Moonchild himself got involved ;) ; however, as I stated in my original post, MCP's Stream API implementation is still in an "embryonic" state (FxESR 68 levels) and, despite the linked "partial fix", vk.com video clips will remain mostly incompatible:

    Quote

    dbsoft wrote:

    So, either readable streams needs to be toggled off for vk.com or we need to push the spec past Firefox 68's implementation.

    Quote

    Moonchild wrote:

    ... but I think we need to prioritize our stability here before looking at satisfying Russian Facebook, and having broad compatibility. This is the initial implementation after all, we know it's not complete -- quite possible it wants later spec changes or WriteableStreams as well

    TL;DR: Even when that "partial fix" lands on our UXP forks, @Mehmed will have to keep the Streams API disabled, if he's a frequent user of VK ;) ...

  7. 23 hours ago, j7n said:

    It's the "55" version. I don't know what the differences between them are exactly, and assumed that is sligthly newer and better.

    ... You assumed wrong! :( I have practically run out of breath :angry: in these threads saying that just because St55 has an appVersion (55) greater than St52's (52), that doesn't imply at all "it's slightly newer and better"...

    St55 is a "relic" browser application, initially seeing the light of day as a fork of upstream Basilisk test browser application, built on UXP Take 1 platform (aka moebius); moebius was mainly based on a Mozilla Nightly 53.0a1 platform snapshot (which, to this day, no-one among "us", even roytam1, is able to trace exactly ;) ), with bits of Mozilla 54 and 55 squeezed in; appVersion 55 was chosen for purely "sensationalistic" :whistle: reasons...

    When upstream killed moebius in favour of UXP Take 2 (i.e. current UXP), roytam1 kept that tree and occasionally (monthly) updated it with code from other repos, like Mozilla itself, TenFourFox, IceWeasel53 and UXP; during one of the CoVid19 lockdowns in Hong Kong, roytam1 found the (huge) amount of time needed to realise the task of bringing his St55, engine-wise, "closer" to his UXP-based browsers, i.e. St52 and NM28; let me assure you that, by that time, UXP had progressed so far from its initial fork point of Mozilla ESR 52.6.0, that St55 was lagging way behind it...

    After that task was (mostly) completed, St55 tries to keep up with upstream UXP and St52, hence weekly updates for it are back, but even now St55 isn't 100% on par with St52, feature-wise ;) ...

    If you ask me, the two reasons to prefer St55 over St52 are:

    1. You're using (the otherwise unsupported) forced multiprocess mode in the browser, since, by inheritance from Fx-53.0a1, St55 has slightly better e10s support compared to St52 (which it inherited from Fx52 - upstream have, by now, eradicated all traces of e10s from their "official" UXP tree).

    2. You have a need to use some WebExtensions which target/work with Fx53+, but don't with Fx52 - WE support, as inherited from Fx-53.0a1, is "slightly" better to the one currently extant in St52 - again, MCP have, by now, eradicated all traces of WE support from their "official" UXP tree...

    In the future, when people in these threads report issues with "Serpent", they should definitely "clarify" which one they're talking about :whistle:...

    On 10/16/2023 at 4:50 AM, roytam1 said:

    As you might have guessed by now :P, my reason for arriving at #1361475 was solely the generated error inside the log @j7n had posted previously; you (and I) assumed he was using the UXP-based St52 and the "upstream fix" (from 2019) you linked to is relevant just for UXP; has this "fix" been ported over to your Basilisk55 tree already/is it present since the moebius very beginning? If not, I'm still right pointing the finger at Bugzilla #1361475 for generating:

    Quote

    TypeError: Argument 1 of AudioContext.constructor '[object Object]' is not a valid value for enumeration AudioChannel.

    Respectful regards :) ...

  8. Hi @nicolaasjan :), hope you're doing great and that the Dutch weather hasn't turned very cold yet ;) ...

    In yt-dlp/commit/8a8b545 , PR #3668 was merged; this one adds an optional dependency to the requests python module, itself depending on the urllib3 python module; here's the latest yt-dlp requirements file:

    mutagen
    pycryptodomex
    websockets
    brotli; platform_python_implementation=='CPython'
    brotlicffi; platform_python_implementation!='CPython'
    certifi
    requests>=2.31.0,<3
    urllib3>=1.26.17,<3

    The "official" yt-dlp_x86.exe file has those already bundled, e.g.:

    [debug] yt-dlp version nightly@2023.10.15.085452 [4e38e2ae9] (win_x86_exe)
    [debug] Python 3.7.9 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 1.1.1g  21 Apr 2020)
    [debug] exe versions: none
    [debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, requests-2.31.0, sqlite3-3.31.1, urllib3-2.0.6, websockets-11.0.3

    and so does the latest yt-dlp_x86.exe file you provided yourself :thumbup (compiled via GitHub Actions):

    [debug] yt-dlp version nicolaasjan/yt-dlp@2023.10.14.034319 [8a8b54523] (win_x86_exe)
    [debug] Python 3.7.9 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 1.1.1g  21 Apr 2020)
    [debug] exe versions: none
    [debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, requests-2.31.0, sqlite3-3.31.1, urllib3-2.0.6, websockets-11.0.3

    HOWEVER :(, the py3.8 based ,

    [debug] yt-dlp version nightly@2023.10.14 [8a8b54523] (win_x86_exe)
    [debug] Python 3.8.13+ (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.1.0-dev )
    [debug] exe versions: none
    [debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, sqlite3-3.35.5, websockets-11.0.3

    and py3.9 based,

    [debug] yt-dlp version nightly@2023.10.14 [8a8b54523] (win_x86_exe)
    [debug] Python 3.9.13 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.1.0-dev )
    [debug] exe versions: none
    [debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, sqlite3-3.37.2, websockets-11.0.3

    latest offerings do NOT :no: ; as the official 32-bit yt-dlp builds will soon move to py3.8 :} , I'll have to rely more on your own py3.8/py3.9 builds (at least until I set up myself an environment to produce mine ;) ); is it technically possible to add requests+urllib3 to those builds of yours :P ?

    Kindest regards :) ...

  9. 1 hour ago, j7n said:

    Timestamp: 10/15/2023 4:52:02 PM
    Error: uncaught exception: TypeError: Argument 1 of AudioContext.constructor '[object Object]' is not a valid value for enumeration AudioChannel.

    I don't know web development and how to interpret these errors.

    This is probably Bugzilla bug #1361475 :dubbio:; Mozilla fixed it in Firefox 55.0a1:

    https://hg.mozilla.org/mozilla-central/rev/68543862570f

    https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/55#web_audio_api

  10. 19 hours ago, UCyborg said:

    Download link for the curious, needs to be extracted in the folder of an actual web server
    as browsers' security protocols prevent access to certain resources through file:///.

    It loads without "an actual web server", if file "Lights.html" is drag-n-dropped on a Serpent 52 New Tab, provided you temporarily disable (from true to false) "security.fileuri.strict_origin_policy" pref: 

    Nb4WufI.png

  11. 20 hours ago, WSC4 said:

    The minimum requirements that your computer must meet to install your Panda product are as follows:

    ..., Windows XP (32-bit with SP3 or later), ...

    However, they do say they supported XP 64-bit for Panda for Desktops and Panda for File Servers.

    11 hours ago, AstroSkipper said:

    Panda Free Antivirus is unfortunately not fully compatible with Windows XP 64 bit editions. smilie-denk-17.gif The installer doesn't seem to detect the already existing .NET Framework 4 installation. A .NET Framework reinstallation via the installer also fails.

    ... If I were asked :whistle:, I'd definitely say that Panda artificially blocked :angry: their Panda Dome (i.e. Free Antivirus) setup from successfully initiating+completing installation under XP SP2 64-bit; if you download the latest off-line installer (via already provided links) and then open/extract file FREEAV.exe with 7-zip, then you'll find below directories:

    FREEAV.exe\System64\drivers\2003\

    FREEAV.exe\System64\drivers\XP\

    containing 64-bit application drivers for WS 2003 x64/XP x64; why put them there if the application isn't supposed to install under those OSes? :dubbio:The fact those 64-bit drivers exist inside the installer probably explains why forced installation on XP x64 works; as for the app itself after installation, I'll quote AstroSkipper:

    11 hours ago, AstroSkipper said:

    Whether Panda Free Antivirus will run stably under Windows XP 64 bit is currently unclear and has yet to be confirmed.

    Regards :)

  12. On 10/12/2023 at 4:47 AM, AstroSkipper said:

    the file size of FREEAV.exe matches nearly the one you posted: 93181864 B (88.9 MB).

    19 hours ago, AstroSkipper said:

    To be more precise 93181864 B corresponds to 88.8652 MB ≈ 88.87 MB ≈ 88.9 MB. So, @VistaLover , ... & ... are definitely right.

    ... Since we all know by now that you are a mathematician :P, some additional attention to detail should be exercised (because mathematics, like physics and chemistry, is an "exact" science); what I did post was:

    On 10/12/2023 at 1:46 AM, VistaLover said:

    This will get you the latest version of the off-line installer (88.9 MiB),

    Notice the unit I used!

    https://tecadmin.net/difference-between-megabyte-megabit-and-mebibyte/

    So,

    93,181,864 B ≈ 88.86515 MiB ≈ 93.1819 MB

    It might be, in the end, that your Android tablet was correct ;) , reporting a file size of 93 MB (if MB was taken at its exact, scientific, value) ; actually, I think Microsoft (and, possibly, other vendors) are mistakenly using MB instead of MiB; Windows Explorer is indeed calculating file sizes in binary prefixes, but it displays the units used in their decimal prefixes; MediaInfo, which can be used on all sorts of files, not just "media" ones, displays file sizes explicitly in MiB:

    Windows Explorer's Context Menu:

    tL9JNCJ.png

    MediaInfo (simple) Context Menu:

    EtVMySg.png

    Hope I helped :P !

    Best regards.

  13. 2 hours ago, Mehmed said:
    TypeError: The ReadableStream reader was released.

    It's related to the newly implemented Fetch Stream API by upstream:

    https://repo.palemoon.org/MoonchildProductions/UXP/issues/1442

    (details about the API itself:

    https://developer.mozilla.org/en-US/docs/Web/API/Streams_API

    )

    Their code is still incomplete/bugged - those two prefs you mentioned simply turn that API off... FWIW, the same crash occurs on latest NM28 (32-bit) on the very same VK clips you referenced (later edit: @anton12 beat me on that ;) ) ... As a side-note, since you're well known to run St52 in e10s mode (completely unsupported by upstream), the fix on St52 itself (with multiprocess force-enabled) might involve additional codepaths, too :whistle:...

  14. 17 minutes ago, AstroSkipper said:

    Or, one can use this link I have fetched from the online installer (93 MB) and provided im my post about Panda Free Antivirus
    http://acs.pandasoftware.com/Panda/FREEAV/193309/FREEAV.exe

    Dear Astro :), we had the same discussion in the past, without any conclusive result :whistle:; the link you re-posted just now,

    http://acs.pandasoftware.com/Panda/FREEAV/193309/FREEAV.exe

    , is still valid, I just tried it mere seconds ago, but from my location it just fetches the exact same binary (sized 88.9 MiB, not 93) as the link I posted in my previous post,

    http://acs.pandasoftware.com/Panda/FREEAV/Promo_pd/FREEAV.exe

    , with the exact (dual, i.e. SHA1+SHA2) digital sig of 2023/09/17 !

    In any case, "the more the better" :P, interested MSFN members can try both for themselves!

    Kindest regards :) ...

  15. Something ignored so far by previous posts:

    1. The screenshot posted by @j7n has a blank page rendered on the plain HTTP version of "archive.org":

    http://archive.org

    I can replicate here on my "dirty" St52 profile:

    DrPn820.png

    But the screenshot posted by @AstroSkipper (in NM28) has the secure version of "archive.org":

    https://archive.org

    Indeed, that one loads as expected in my St52 (dirty) profile; @j7n, does it also load for you when you specifically request the HTTPS version of AO?

  16. 11 hours ago, WSC4 said:

    Do I need the 32-bit version on a 64-bit OS?

    Although that was a question of a more general nature (at least that was how I perceived it), read below:

    https://learn.microsoft.com/en-us/dotnet/framework/64-bit-apps#running-32-bit-vs-64-bit-applications-on-windows

    Quote

    All applications that are built on the .NET Framework 1.0 or 1.1 are treated as 32-bit applications on a 64-bit operating system and are always executed under WOW64 and the 32-bit common language runtime (CLR). 32-bit applications that are built on the .NET Framework 4 or later versions also run under WOW64 on 64-bit systems.

    If the question was specific to .NFW4, then yes, you do need both architectures of it:

    https://learn.microsoft.com/en-us/dotnet/framework/64-bit-apps#compiler-support-for-creating-64-bit-applications

    https://learn.microsoft.com/en-us/dotnet/framework/64-bit-apps#determining-the-status-of-an-exe-file-or-dll-file

    Adding to what others have said, it really depends on the actual .NET framework version+architecture a said application was built against (OT: On Win Vista SP2+, 4.x versions are mutually exclusive and backwards compatible - upgrading, e.g., 4.5 to 4.6 will overwrite the 4.5 previous installation)...

  17. 16 minutes ago, mina7601 said:

    And note that this is also on a fresh St55 profile.

    As I've told you in the recent past :P, I only use a fresh browser profile when troubleshooting browser issues, otherwise I'm normally found on my working "dirty" profile (as is, I should hope, the vast majority of Serpent 52/55 users :whistle:) ; but just to humour you :), a pristine/newly created St55 profile has no problem here loading quasi-instantly your referenced website:

    SHG81oO.png

    My "dirty" St52 profile as well as latest NM28 (minimal profile with just uBO-legacy installed) ALL load that website just fine! If you hadn't added the fact 360EEv13.5 works OK for you, I would have suspected some sort of IP pool ban, but now I'm all out of ideas... TL;DR: I can't reproduce myself, sorry... :(

  18. @roytam1 : Hi, hope you're doing well :P ...

    Very recently, Basilisk-Dev committed some clean-up code with regards to the unused Mozilla Crash Reporter feature and, additionally, to Mozilla telemetry, iOS and android unused remnants; basically, look inside: 

    https://repo.palemoon.org/Basilisk-Dev/Basilisk/compare/6e626eb9e...d2d6c6c79

    Do you think those ones that are applicable to "our own" Serpent 52.9.0 can be included in this weekend's St52 imminent release? Thanks for your hard efforts! :worship:

  19. 48 minutes ago, AstroSkipper said:

    My statement about Malwarebytes' lifetime licence was meant only as an explanation why I prefer to use Malwarebytes Antimalware Premium under Windows XP, no more, no less.

    ... Yes, I perfectly understood that in the first place :P, you were crystal clear, but I used your "statement" as a basis for my follow-up question(s), "no more, no less" ;) ; couldn't imagine that, in itself, would be a "potential problem", is it? (FWIW, I get the overall sense one should "walk on eggshells" when replying in this thread :whistle:...)

    58 minutes ago, AstroSkipper said:

    This kind of licence can't be obtained anymore

    Thanks for the confirmation!

    59 minutes ago, AstroSkipper said:

    As far as I know, the current premium licence to be purchased is valid for all versions, i.e. also for v1 and v3. This was always the case in the past, too. So if you buy a licence today, you can also use it for MBAM v3. This is the statement I received in the Malwarebytes forum from the moderators/administrators.

    Thanks, too, that is very comforting to know :) ... How does this fact make the MBAM online support articles I linked to look then? :dubbio:

    31 minutes ago, Dave-H said:

    I'm on a rolling subscription with Malwarebytes, which I renew every two years.

    Thanks Dave for your detailed reply! :thumbup ; hopefully, by the time you'll be up for the next renewal, you'll face no problem "re-activating" MBAM v3.5.1 on your two (thought it was just one ;)) XP partitions!

    Cheers.

×
×
  • Create New...