Jump to content

VistaLover

Member
 View Profile  See their activity

  • Posts

    2,245

  • Joined

  • Last visited

  • Days Won

    93

  • Donations

    0.00 USD 

  • Country

    Greece

 Content Type 

Everything posted by VistaLover

  1. VistaLover
    @Mathwiz : The @roytam1 UXP browsers are built from the https://github.com/roytam1/UXP/commits/custom branch, itself derived from the corresponding master branch: https://github.com/roytam1/UXP/commits/master itself forked from the upstream master branch: https://github.com/MoonchildProductions/UXP/commits/master The upstream master branch, in terms of code development, can be likened to the Mozilla trunk branch, https://hg.mozilla.org/mozilla-central/ on which the (twice-daily updated) Firefox Nightly builds are built (currently at version 71.0a1); so, that makes a staggering 730 Nightly builds released per year! The 52 (or less) UXP-based browser releases per year (from Roy) is really a small number compared to the above figure... With such short development cycles, there's really no room for proper testing and evaluation by beta/nightly testers - expect more bugs to be released in the wild on unsuspected Release Channel users, which would in turn require more frequent "point" and/or "chemspill" bugfix releases! But I think the driving force behind this inane change is to surpass Google Chrome in absolute version numbers; Mozilla is now targeting more and more younger users (who already stay clear of desktop browsers - the web to them means mostly mobile devices - or use the prevalent choice [Chrome] when they don't) who, in their naivete, may think a larger version number actually means a more recent/updated application (say, Firefox 110 vs Chrome 92). If I'm not mistaken, that was Mozilla's main argument when, back in the day, they switched to the 6 to 8-week release cycle... In all honesty, I'm not surprised by any of Mozilla's recent moves - their ship is sinking, they'll do any gimmick to keep it afloat for just a little longer...
  2. VistaLover
    ... And if anyone's in need of it, the Greek installer for WinRar 3.80 (x86): wrar380el.exe (originally saved in this old Vista laptop on June 3rd 2009 ; however, its modification timestamp dates to Oct 7th 2008! )
  3. VistaLover
    @sukistackhouse is right ; simply head to and read: https://www.atlantiswordprocessor.com/en/help/ebook.htm#kindle Best wishes
  4. VistaLover
    ... FTR, I did report the two contained in this thread (I suppose there exist site logs that can confirm my claim), sadly only after I had also posted about them (twice... ; but to my defence, the spammer did strike back, out of spite no doubt, after I had flagged his/her first attempt...); anyhow, thanks for the cleanup (and next time, I'll be wiser ) !
  5. VistaLover
    I just tested this on NM28/UXP and it still does! Test site to verify: http://browserspy.dk/browser.php (Please note this pref doesn't modify the reported Windows NT version contained in the User Agent String (navigator.userAgent), so a website checking both strings via JS may get conflicting results: )
  6. VistaLover
    ... Yet another spamming post (disguised as a help plea) right before this one, from - most probably - the same spammer, under a newly created account and associated user name... If you read this, move your spamming activities elsewhere ; most members here are smart enough not to click your spamming links ; I trust the site admins will soon take care of you...
  7. VistaLover
    MSFN rule 2.e might apply here: ... and possibly rule 4.a: @dencorso, what are your thoughts on this?
  8. VistaLover
    ... This isn't always a definitive test - many a times, lowering the subsystem string (to < 6.0) in the main executable will get it to launch, despite this initial warning; the only definitive test is to use dependency walker x64 on the 64-bit program executable (and, possibly, on the program DLLs it depends on) and look out for API calls to missing functions in the XP x64 kernel...
  9. VistaLover
    ... But I did say: ... and I did keep my promise more than 24h ago : You just hadn't revisited my edited post prior to posting... ... I opted for the original Adobe link: Hope everyone's content now...
  10. VistaLover
    The CSS fix posted by @mixit is indeed needed in FirefoxESR 52.9.1 and Serpent 55.0.0/Moebius, but not needed in the UXP browsers (NM28, Serpent 52.9.0, Bnavigator) and latest SeaMonkey 2.49.5, because this issue is fixed in the respective platforms - don't forget that in NM28 and St52 browsers (at least), SSUAOs are needed for instagram.com (with a Firefox version < 57.0).
  11. VistaLover
    Exactly! Just to confuse things further, Google have done some re-versioning to their WV CDM and what were to be versions "1.4.10.xxxx" are now versions "4.10.xxxx.xx", 10 being the interface currently supported. Interface 9 CDMs were revoked, as announced, on Aug 13th 2019 (14th, if - like me - you're in Europe) and thus official Basilisk/Serpent 52.9.0, with internal support for only WV CDM v1.4.9.1088, was broken by Google Widevine license servers (they won't serve decryption keys any longer to revoked versions of the CDM); unlike e.g. NPAPI Adobe Flash Player, you can't just upgrade the CDM and expect things to continue to work, especially when only newer "interfaces" of the CDM are current; the "guts" of the browser have also to be updated accordingly, to support the newer Widevine CDMs. EME and WidevineCDM support in UXP (in practice, in Basilisk only) is being tracked in https://github.com/MoonchildProductions/UXP/issues/962 Their "media" (and Linux) dev, @trav90, appears to be having some serious issues in real life, which keep him still away from contributing code in the project; despite Moonchild's plans, he had to release Basilisk 52.9.2019.09.03 without fixing its broken Widevine implementation; for Netflix and Adobe Prime, Basilisk/Serpent users will have to use SSUAOs to fake older Firefox versions and then install/use the Silverlight NPAPI plugin (more in the official forums); of course, other DRM services without a Silverlight fallback provision will be simply BROKEN! Before Aug 13th, @roytam1's Serpent 52.9.0 (with WV v1.4.9.1088) and 360 Extreme Explorer (with WV v4.10.1196.0 manually installed) were, AFAICT, the only two working implementations of Widevine under the Vista SP2 OS; both these two WV versions have been now deprecated/revoked/blacklisted, the one current and whitelisted by WV lic servers is v4.10.1440.19; most sadly, the corresponding widevinecdm.dll file has been compiled by Google with optimizations targeting the Win7+ kernel only, so it won't work under Vista (this is easily verifiable via dependency walker in Vista); since the WV source code is a tightly kept secret, no-one can recompile it and make it again Vista compatible; so, WidevineCDM is henceforth a DEAD technology under Vista
  12. VistaLover
    ... Please accept my most sincere apologies, both of you In my dirty SM profile, the AP CDM does indeed show up in both about:plugins and about:addons/Plugins; prompted by your reports, I then created a new, clean, SM profile and applied my instructions from here to install the CDM; lo and behold, I, too, couldn't see the CDM installed in either about:plugins nor about:addons/Plugins, though, as you both confirmed, the CDM does appear to be working as intended in "silent" mode! After comparisons between the prefs.js file on the dirty profile and the same file on the new profile, I did manage to find the culprit: My original instructions are missing one additional about:config pref: media.gmp-provider.enabled;true (boolean) I had added that pref in my dirty SM profile many months ago, in an attempt to install and use the WidevineCDM on SM under Vista SP2 (NPAPI Widevine on XP doesn't install/show up/work); SM, like the upstream Fx ESR 52.9.1, only supports version 1.4.8.903, which is now severely outdated and blacklisted by Google Widevine license servers ); this is the reason the mentioned pref was pre-existing (and overlooked ) when I started my Adobe Primetime CDM experiments in SM! The original instructions will be soon edited to remedy this omission... Sorry again!
  13. VistaLover
    Some points to be made: 1. If on Win7, you don't really need Adobe Primetime CDM as a HTML5 MP4 video decoder (on Serpent and/or SM); Win7 comes already equipped with WMF and M$ provided patented decoders for H264+AAC. 2. To test the successful functioning of Adobe Primetime CDM (as a decoder) on either Serpent (52+55) or SM under Win7 (actually Vista SP2 and higher), don't neglect to first turn off WMF in the browser's about:config ; in Serpent's case (as opposed to SM), don't also neglect to turn off the ffmpeg provided patented decoders, by setting media.ffvpx.enabled to false!
  14. VistaLover
    @TechnoRelic : I have the answer to your SM 2.49.5 issue of not being able to playback HTML5 instagram videos under WinXP: 1. Via the Adobe Primetime CDM a. [LATER EDIT: I was kindly asked to provide here a download link for the AP CDM files; links for those do exist in the "Enable MP4 (H.264 + AAC) HTML5 video in Firefox on Windows XP without Flash" pinned thread, so it isn't like it's hard to find them; however, I have opted to provide the original official link, straight from Adobe's servers: https://cdmdownload.adobe.com/firefox/win/x86/primetime_gmp_win_x86_gmc_40673.zip The link is still live and tested mere minutes ago - if you're wondering how I got there (because, tried as I might with web searches, I wasn't able to find it), it's by loading the following URI: https://aus5.mozilla.org/update/3/GMP/51.0.1/20170125094131/WINNT_x86-msvc-x86/en-US/release/Windows_NT%206.0.2.0%20(x86)/default/default/update.xml ... which is the URI queried by the internal gmp-manager of stable Firefox 51.0.1 32-bit under Vista SP2! ] Just make sure you do install the CDM properly inside your existing SM profile: ./<ProfileDir>\gmp-eme-adobe\17\[3 files, one of which is eme-adobe.dll] b. Create/modify accordingly the following prefs: media.gmp-provider.enabled;true (boolean) browser.eme.ui.enabled;true (boolean) browser.eme.ui.firstContentShown;true (boolean) media.eme.apiVisible;true (boolean) media.eme.enabled;true (boolean) media.gmp-eme-adobe.abi;x86-msvc-x86 (string) media.gmp-eme-adobe.enabled;true (boolean) media.gmp-eme-adobe.forceSupported;true (boolean) media.gmp-eme-adobe.lastUpdate;1500000000 (integer) media.gmp-eme-adobe.version;17 (string) media.gmp-eme-adobe.visible;true (boolean) media.gmp.decoder.enabled;true (boolean) media.gmp.decoder.h264;2 (integer) media.gmp.decoder.aac;2 (integer) c. Restart SM 2.49.5; head over to about:addons/Plugins and configure the CDM to Always Activate: If everything was done right, heading to https://www.instagram.com/p/B2Nb4FGFQZ8/ and pressing the white PLAY button, you should be able to view the video inline... (I tested this successfully under Vista SP2 by first toggling media.wmf.enabled to false, thus simulating XP) 2. Dirty hack, by using @roytam1's modified DLLs. All this was inspired from: http://forums.mozillazine.org/viewtopic.php?f=40&t=3040639 a. Download latest Serpent 52.9.0 package by Roy Tam b. Extract the .7z file to a folder, copy the following 3 files: mozavcodec.dll mozavutil.dll vcomp140.dll c. Locate your SM 2.49.5 installation folder - rename and back-up the original files mozavcodec.dll & mozavutil.dll (of version 52.9.1.7156) d. Place there the 3 aforementioned files, extracted from the Serpent package. e. Launch SM Now SM 2.49.5 should be able to use the patented decoders contained in the modded DLLs; so HTML5 MP4 should be playable! (not tested by me, though... EDIT: Just tested, and it works!) Best wishes
  15. VistaLover
    ... It's all because of upstream changes: https://github.com/MoonchildProductions/UXP/issues/1124 This was again code clean-up, conceived and executed by Matt A. Tobin: Specifically, the DevEd Theme GUI breakages are due to: [Basilisk] Remove Dev Edition theme. Like you, I also happen to like the Dev Edition Theme over the default Australis one, even in my Firefox days; did you know there's also a light Dev Edition theme in FxESR 52 (with square tabs)? You just have to first install the legacy extension DevEdition theme enabler (v1.0.1), which then adds a Developer Edition entry in about:addons/Appearance; enabling that and restarting the browser will give you the light theme (attached snapshot); to change to the more familiar dark DevEdition theme, just modify in about:config the pref devtools.theme to dark (instant application). Mozilla in Firefox 53.0+ (not compatible with XP/Vista) had added the two DevEdition theme flavours as default themes, they had simply rebranded them as Compact Dark and Compact Light: https://www.askvg.com/2-new-themes-compact-dark-and-compact-light-added-to-mozilla-firefox/ But to achieve the same in Fx 52.0.x-52.x.x, you had to employ the help of aforementioned extension; I should also mention at this point that the maintainer of the now defunct browser project called Cyberfox had successfully backported this Fx 53.0+ feature to his v52.9.1 browser, forked off Mozilla ESR 52 code: ... i.e. whereas other developers liked to backport additional Firefox features, it is, once again, demonstrated how fixated the MCP team is at removing inherited Firefox features (Container tabs, Web Extension support, to name just some recent beheadings in Basilisk...) Given the underlying supporting code has now been axed, I don't expect the DevEdition theme enabler extension to work now with latest Serpent (52.9.0) builds (it was, with older builds such as 2019-05-31).
  16. VistaLover
    ... It appears your chosen username is indeed reflected in the verbosity (or lack of... ) of your last post! Can you please tell us (... pun intended!) whether it is actually the x64 edition of latest mumble-1.3.0 that can't be launched under Vista SP2 64-bit? Thanks
  17. VistaLover
    ... Actually, I could not reproduce this on my Vista SP2 32-bit Home Premium installation; grabbing MSIs from their GitHub repository, all versions 1.3.0rc1, 1.3.0rc2 and the stable final release 1.3.0 had no issues installing and (at least) launching properly under my OS : As I'm not a gamer myself, I can't really tell if the application works fully as intended! Seeing you're on Vista Ultimate x64, perhaps what you report is true for the x64 OS, when the mumble-1.3.0.winx64.msi installer is being used; other Vista x64 users may have to test, too... But on Vista x86, all appears OK thus far... (BTW, I believe the x86 mumble version can surely work in your x64 Vista OS, wouldn't it? )
  18. VistaLover
    Hi ; what you report is to be expected, not a surprise at all... ; let me explain: 1. SM 2.49.x is built on the Mozilla ESR 52 platform, same as Firefox ESR 52.x.x; for legal and cost reasons, Firefox doesn't come bundled with its own patented decoders (h264, aac), unlike Google Chrome (Google can afford the huge sums of money needed for the licenses payable to the MPEG group to bundle their patented decoders with the Chrome binaries). In order to decode HTML5 MP4 video, Firefox must access the OS-provided patented decoders (the cost of which is included in the price of the OS, i.e. Microsoft, rather than Mozilla, paid for it...) Unfortunately, the mechanism that gives access to these OS-provided decoders is Windows Media Foundation (WMF) framework, available only in Vista SP2 (with Platform Update + Platform Update Supplement) and higher, NOT in WinXP ; hence, SM 2.49.5 on XP can't decode HTML5 instagram video (or any other HTML5 mp4 video for that matter), as XP lacks WMF and associated M$ provided decoders. And no, installed codec packs won't do the job! If you like, you are faced with the same predicament as in the pinned thread below: This is just an educated guess on my part, but since SM 2.49.5 is FxESR 52.9.1 based, you could try and implement what is currently valid for enabling HTML5 MP4 playback in FxESR 52.9.1 under XP in the linked thread; not tested myself, SM 2.49.5 has no issues here (Vista SP2 x86) playing back [h264+aac] MP4 files... 2. The bnavigator fork has been built on the UXP application platform; but @roytam1 has long ago patched the platform to fallback to its own patented decoders when WMF is unavailable (the case of XP); the patented decoders in UXP, provided via FFmpeg libraries, are contained within a custom patched version of the ffvpx third party library; it's the same reason the other two UXP browsers, NM28 & St52, can also decode HTML5 MP4 files under XP... I hope it's clear now!
  19. VistaLover
    ... It could just be a case of artificial blockage by increasing the subsystem version string in the binaries to 6.1; editing it back to 5.2 might make them work in XP+ x64; better check with the zip packages, if the installer is also blocked under NT < 6.1... But then again, it could be compiler optimizations targeting Win7+; in any case, dependency walker x64 (under XP/Vista x64) will reveal what the true case is...
  20. VistaLover
    ... Yes, a major c*ck-up ; the links should have pointed to https://archive.mozilla.org/pub/seamonkey/releases/2.49.5/langpacks/win32/ instead of https://archive.mozilla.org/pub/seamonkey/releases/2.49.5/langpack/ (a plural number "s" is what makes all the difference in this case! ) BTW, you did mention in passing win64 SeaMonkey builds for v2.49.5, they state they require Win7+; it'd be challenging if someone made them install/work under WinXP/Vista 64-bit! Best wishes
  21. VistaLover
    ... Did I not provide links to latest SeaMonkey 2.49.5 language packs in my previous post?
  22. VistaLover
    Hello ; I am indeed quite familiar with that project, though running it on Vista SP2 32-bit, for which minimal official support does exist (but the lead developer there is quite keen on axing Vista support soon... ); as far as I'm aware, the app is just a Python script that does support Python versions 2.7.x and upwards - Python 2.7.16 to 3.4.4 is, as you may already know, XP compatible, so one just has to install Python and then install SL via pip (which will also fetch all needed dependencies). How so? In most cases, SL uses native Python libraries/dependencies to extract stream URIs from pages and then either feed (stream) them to a media player of choice (I think the current default is VLC, but they are keen on switching to mpv (no longer XP+Vista compatible ) or save them to disk; in most cases, FFmpeg is just being used as a muxing application, to place elementary (raw) streams into a media container (usually Matroska) that can be handled by the player's input API... Please provide examples where FFMpeg+OpenSSL support is required for normal operation. FWIW, the provided FFmpeg binaries have been compiled with --enable-mbedtls, mbedtls being a rebrand of PolarSSL; it is a crypto open source library able to handle all the tasks managed by its OpenSSL counterpart... OpenSSL has a restrictive (non-free) license, so builds with it enabled statically can't be redistributed; using a build script to build custom binaries one will use on one's own machines, it is necessary to configure the build script with "--enable-nonfree --enable-openssl" (that's what I had to do with the media-autobuild_suite when it was still Vista 32-bit compatible - ca. spring 2017); @Reino does provide openssl win32 binaries in https://rwijnsma.home.xs4all.nl/files/other/ perhaps when placed alongside his FFmpeg binaries, they are being loaded in a dynamic fashion? (Added later:... probably NOT - just misled by the behaviour of the libfdk-aac DLLs... ) EDIT: When I started composing this post, @Reino's reply wasn't live; thanks for the detailed info there...
  23. VistaLover
    When Basilisk was first conceived as a Moebius Platform test bed browser application, the language packs from Firefox 53.0 did initially work (for their most part); but as MCP started deviating from the Mozilla code by deleting/relocating/adding GUI strings, the Fx 53.0 LPs (installed in Bk55/Moebius) quickly broke ; users did complain: https://forum.palemoon.org/viewtopic.php?f=61&t=17876 but the final word from Moonchild himself was: https://forum.palemoon.org/viewtopic.php?p=131106#p131106 Their view on things did not change when their Moebius "experiment" backfired and they had to start all over again with Basilisk (52.9.x) on UXP... Time now for me to be overly pedantic, but since 2.49.5 has been properly released, one had better look into the "releases" directory for official signed binaries and language packs: https://ftp.mozilla.org/pub/seamonkey/releases/2.49.5/win32/de/ LPs only: https://ftp.mozilla.org/pub/seamonkey/releases/2.49.5/langpacks/win32/ (FTR, I doubt the RC3 builds are any different to the final (released ones), apart from the signature, that is...) Perhaps @TechnoRelic has that link handy, since I know he's one of the few (?) users here of that fork... ; in any case, let us first hear what @AndreasB. is really after... Best regards
  24. VistaLover
    There are NO (official or otherwise) language packs for Basilisk! (and NO, FirefoxESR 52.x.x's ones won't work either...) - see my previous reply to @AndreasB. : ... And according to @AndreasB.'s wording, the query was for @roytam1-only maintained browsers; to this, I may point out the availability of the FirefoxESR 45.x.x fork, intended basically for SSE-only older processors; I faintly recollect weeks ago I directed one user of that to the Mozilla provided language packs, I think his response was positive: https://archive.mozilla.org/pub/firefox/releases/45.9.0esr/win32/xpi/ OTOH, I'm not following closely the development of the KM Goanna fork, perhaps users such as @siria can shed additional light on the availability of updated, working, language packs for that!
  25. VistaLover
    ... Yes, posted links unfortunately yield last week's packages; may happen to the best of us! Correct links: 32bit https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190907-c6d625af7-xpmod.7z 32bit SSE https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190907-c6d625af7-xpmod-sse.7z 32bit noSSE https://o.rths.cf/palemoon/palemoon-27.9.6.win32-git-20190907-c6d625af7-xpmod-ia32.7z 64bit https://o.rths.cf/palemoon/palemoon-27.9.6.win64-git-20190907-c6d625af7-xpmod.7z
×
×
  • Create New...