Leaderboard

Thanks a mil for your patch and compiled executable If you had been following my previous posts (most of them now gone with the server crash ), you'd have known I am a fan of portable apps/installations; well, if one renames your Rufus executable so it ends in "*p.exe", it just turns itself into portable mode and saves its settings in an adjacent .ini file! Works like a charm on Vista SP2 x86 All in all, a sterling job for the Vista community

Since there's not much info out there on the web unless you spend a considerable amount of time googling, I thought i'd post the solution so more people can find it quickly. Update Late 2019: Several months after i posted this Microsoft fixed the problem but I believe it was a side effect of them updating their certificates due to an industry shift, so there’s no guarantee they will continue work in future also in the last update i mentioned a batch file, I ended up getting busy and my adhd made me forget, I’ll still post it once I get organised and find it again as it’s useful. Update: The latest problem with activation affects both XP and Vista however it’s relatively easy to fix, you need to update your root Certificates (The same issue causes problems browsing the net too) I have created a Batch script that will download and update the Root Certificates accordingly but it will be a couple of days before I can post it. Below is the Original Fix I posted Turns out it's exceedingly easy to restore Windows XP Online Activation Open the Start Menu Right Click on Internet and choose "Internet Properties" Goto the Advanced Tab Scroll down near the bottom to the Security Section and uncheck both: "Check for publisher's certificate revocation" "Check for server certificate revocation" Now you can activate online as normal or use the "Windows XP Product Key Change Tool" I would reccomend re-enabling both options afterwards even if you dont use Internet Exploder (which you REALLY REALLY should not be) If you’re still having problems: I highly recommend downloading the “Windows XP Product Key Change Tool” it’s an official Microsoft tool and you should be able to download it from majorgeeks worked in every other instance for me where the built in one didn’t. (And in think it also lets you use different type of keys from the media the OS was installed from, such as Retail on OEM and such) Also make sure your clock is set correctly (A common source of TLS problems)

Hey VistaLover, I noticed some of the same things except the ones that stopped working for me were google-calendar-dark-style by Devo and gmail-dark-1 by TheArkive. I temporarily worked around it by changing my GMail theme but it is not a true dark theme because when reading emails they show in white background hence why I changed in the first place. Instead of Stylish I was using Website Theme Manager 0.1.1. Like you using the 6-16 version it still worked. However I noticed Gmail is faster without the styles so I might go on the hunt for something better. Either way thank you Roy for all your hard work. It is appreciated. Leland :D

Hi Roy Your efforts to breathe new life into the Moebius repo, deprecated by its maintainers since Mar 18th 2018, are highly appreciated and praiseworthy ; I understand it is a very tedious and time-consuming task to port-over security fixes from Mozilla... Although always a consideration, I'm not that paranoid about browser security as I am about browser features and continued functionality (acknowledging, as you state, Bk55/Moebius being "experimental" software ). I was one of the people to highly praise Basilisk(55)/Moebius during the time it was actively maintained by Moonchild, of course through your Vista compatible forks/builds, especially in comparison to the early releases of Basilisk(52) /UXP-T2, which then presented many issues; Bk55, on Vista at least, was/is more "fluid", had/has a better rendering engine and richer webextension APIs and its native theme has better integration with Vista's Aero. But then MC dumped Moebius, because it was no longer serving their original needs, and focused developing on Bk52/UXP; so I ultimately had myself to revert to your Serpent 52.9.0 builds (and accept its various shortcomings on Vista), if I was to use an actively maintained browser where existing bugs had some chance of a fix by MC... But I have kept a (portable) installation of Basilisk (now Serpent) 55 for tests; further down in this post I'm going to talk about my "adventures" with using your latest Serpent 55.0.0 offerings... (Web)Notifications bug: This was first reported by our Polish friend @kitaro1 in a now lost post; it was quite annoying especially because it used to affect this MSFN forum, too! The browser wouldn't save between sessions (browser restarts) notification exceptions (sites allowed to display webnotifications) and every time one logged in, one had to (re-)allow notifications for msfn.org (and, of course, other sites with the notification feature). FWIW, this bug was not present in the last official build of Bk55, Basilisk-55.0.2018.03.21-git-20180321-g6afc1c7.en-US.win32[buildID=20180321093734]. I had carried out regression tests (but sadly I never posted those) and determined that the bug was first introduced by you in Basilisk-55.0.0-git-20180308-g3da3c97-xpmod.en-US.win32[buildID=20180306151332] by updating NSPR to 4.18 and NSS, first to 3.35 and then to 3.36; in the profile, cert8.db changed to cert9.db and key3.db to key4.db. That bug was finally rectified with Basilisk-55.0.0-roytam1-git-20180616-gde24cec.en-US.win32[buildID=20180616141358], with the update of NSS to 3.36.4; cert9.db and key4.db reverted to cert8.db and key3.db again... But that fix came with a small price: I am not using a third party password manager, after the update from buildID=20180413153516 to buildID=20180306151332 I just found out all my stored login accounts (for ca. 15 sites) in about:preferences#security could not be read/recovered and I had to manually re-input them ; so, for those wishing to update from Basilisk-55.0.0-roytam1-git-20180413-gee7cd5f.en-US.win32[buildID=20180413153516] to a more recent build of Bk55, take care to first export/back up your saved login credentials! Extensions installed from AMO won't pick-up available updates/won't auto-update (according to your settings) This specific issue was recently reported in this thread by new member @ED_Sln I believe the real reason behind this bug is the one mentioned here: https://forum.palemoon.org/viewtopic.php?f=61&t=19273 Mozilla on AMO have switched to providing extension update manifests exclusively in JSON format, killing the XML format used in Basilik55; the MC team mitigated this change in the UXP repo (hence Serpent 52.9.0); owing to a similar root cause, current Bk55 (as offered by Roy) can't update other extensions not installed from AMO, but whose update manifests also come in the form of .json; one such example I am aware of is the GitHub hosted beta/RC versions of gorhill's uBlock Origin : https://github.com/gorhill/uBlock/releases whose update manifest URI is: https://raw.githubusercontent.com/gorhill/uBlock/master/dist/firefox/updates.json E.g. on Serpent 52.9.0, 1.16.11rc1 will update to 1.16.11rc2, but NOT on Basilisk 55.0.0 (has to be installed manually from Github). To fix this bug on Bk55, you'll have to back port code from the UXP repo! EME and Widevine CDM support on Vista OS This was already brought up by me here previously, sadly those posts have permanently vanished due to site's server crash/database corruption TL;DR: Yes, your Bk55 builds are compiled with the --enable-eme=widevine flag and while widevine on Windows XP is a lost cause (again, there was discussion/explanation in this thread that is now lost), on Vista the plugin does appear as loaded and enabled (v1.4.8.903) inside AOM (about:addons); FWIW, extensive tests by yours truly have shown that Serpent55+WV works as expected in WinOSes >=7, but not on Vista Explanation: Actually, neither MC team nor you are to blame for this! Widevine is a closed source plugin; from my many tests and online searching I have concluded that WV on a Mozilla type browser only searches for h264/aac decoders among the system codecs and implies a working WMF implementation in the browser; BK55 doesn't support Vista's WMF+WV, because that support was already removed by Mozilla in the source (53.0a1?) MC originally forked; MC didn't plan on their test bed browser working on Vista, so never bothered to reinstate Vista's broken WMF support (not the story with Basilisk52: in that case, Vista WMF+WV support was present in the forked source, MC team selectively removed it and you (Roy) reinstated it ; hence, Serpent 52.9.0 + WV works OK in Vista! ). Visiting https://bitmovin.com/demos/drm with Basilisk-55.0.0-roytam1-git-20180623-g0249f58.en-US.win32[buildID=20180623000710] on Vista I get: avc1 (h264) decoding support is achieved via your patched ffvpx lib, not by WMF; thus widevine (and other EME) are not supported! Similar results are produced when one visits https://demo.castlabs.com/ @roytam1 you'd have to install a Vista VM (fully updated with all Service Packs and Platform Update Supplements!) to reproduce; if your kind heart wishes to fix this, you'd have to bring back WMF on Vista; you can start by looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1324183 https://bugzilla.mozilla.org/show_bug.cgi?id=1329547 and possibly others... Non-working userstyles I have an eye condition and I can't stand bright colours for long, plus I tend to be on-line more during the night (yes, bad for my sleep patterns ); as such, on all of my browsers I install Stylish (or similar) and a group of "dark" userstyles to have a darker web experience! When I updated my previous Bk55 installation (Basilisk-55.0.0-roytam1-git-20180616-gde24cec.en-US.win32[buildID=20180616141358]) to the latest compile (Basilisk-55.0.0-roytam1-git-20180623-g0249f58.en-US.win32[buildID=20180623000710]), I was unpleasantly surprised to find that more than half of my installed userstyles quit working (while the rest remained functional!); my Stylish version is 2.1.1, the last (hybrid-)XUL version that still has access to the browser GUI (as I also use a number of userstyles to accommodate the GUI to my liking!). A brief list of userstyles that stopped working after the latest update is Addons Mozilla Firefox 2017 Dark Theme bing nightly Bitbucket Org Dark Dark style for (ftp|archive).mozilla.org Darker Facebook Darker IMDb DarkSearch for Google DuckDuckGo DeepDark GitHub Dark Userstyles DeepDark Website: cleaner - Mozillazine.org Forums YouTube DeepDark Material YouTube DeepDark Classic Findbar on Top Right (modifies Browser GUI) Some of them can be found on-line, others I have picked-up from various sources I now have no recollection of; it is noteworthy that while all but one are "dark" styles affecting the look of webpages, I have at least one that modifies the browser GUI itself (Findbar on Top Right) which is now broken... For the record, I have one "dark" userstyle, "Wikipedia - Dark, blue, simple", that is not broken and still works! To make matters worse, it looks as though the style hosting site https://userstyles.org is broken; when I visit, e.g. https://userstyles.org/styles/118959/darksearch-for-google and have that style installed, there's no indication on the site the style is indeed installed (or am I confusing this with greasyfork.org? ); in any case, don't hit that deceptive button "Install with Stylish"; you'll end up with the latest webextension version of Stylish that will mess things up for you... The relevant changelog is https://github.com/roytam1/basilisk55/compare/de24cec...0249f58 I hope something responsible for the userstyle breakage stands out for you... This new bug is a deal-breaker for me and I have switched back to Serpent 55.0.0 (2018-06-16) I hope you'll appreciate the detailed bug-report, my gratitude for your hard work remains unscathed regardless Best wishes to Hong Kong

I don't really spend time "wondering" about anything Microsoft does these days....it is just one continuous nightmare.... bookie32

Wise words jaclaz

Well, considering that: Windows Embedded Standard 2009, Extended Support will end on Jan. 8, 2019. Windows Embedded POSReady 2009, Extended support will end on Apr. 9, 2019. ...it does make sense. That's not to say we'll give up on XP so soon, of course!

Aye, their presence can indeed be rather vexatious, especially if it has been repetitive and you've got a lot of work to finish up. I certainly don't blame you for ditching the debug DLL. Admittedly, I too have done so in the past. At the same time, I'm really grateful that we have BigMuscle around to continue working on AeroGlass. And I'm confident he'll release version 1.5.9 soon enough :-)

I think the confusion was because the pop-up boxes are to gather info that is helpful to the developer. You still need to manually copy and paste the details (if asked for when dealing with a particular issue). None of the pop-ups nor Aeroglass in general will forward any information behind your back.

Firefox has been updated to 52.9.0 ESR release as of June 25, 2018. Security and stability fixes should be in release notes tomorrow.

Probably a good idea....;) Your maths is right.... We are leaving the floor until I get the main joist and roof on.....no point at the moment.... The main cottage will have a small kitchen, bedroom and main living area...with a small loft above the kitchen and bedroom..... So...we keep on track with this thread I will send you a link when more pics are on onedrive....Just coming up to my 62nd birthday in July...didn't expect to be building a cottage....we bought a "kolonistuga" last year and it had so much wrong with it we had to take it down.....so my partners idea of us having somewhere to grow veg and relax will have to wait a couple of years.....There is a glimpse of a second smaller cottage still in place as a storage hut at the moment and then with some of the original cottage build a smaller 10m2 one that will be the toilet shower and storage area for garden tools... Not many new cottages are built....from scratch so all our neighbours are keen to see what happens....;) bookie32

Here's the patch that can be applied on top of latest revision of Rufus source code to restore Windows Vista support and the executable (version 3.1.1321). I experienced strange bug where the code that is supposed to prevent DLL sideloading causes UI elements to lose Aero look and reverts to classic, so the patch removes that. The mitigation doesn't have much value IMO, if you're worried that the program will load malicious DLL from its folder, then you've already lost by getting such DLL in the first place. Still, the relation between UI look and the DLL search directory is odd. At first I thought older version of comctl32.dll was getting loaded, that's not the case though. Calling SetDefaultDllDirectories does it. It's one of those functions that were added with an update and the issue appears to be exclusive to Vista. Unless there's a separate update addressing that.