Leaderboard

semi-OT: finally got my firefox55norust creating working build, by specifying `--disable-sandbox' switch in .mozconfig. maybe finally I can revert all XP+ only commits and creating a working XP 56-ish build.

Sorry for the delay; it's been a busy week. I can understand MCP removing Primetime support, since the Windows versions they support have WMF and thus don't need it the way XP users do. I can confirm that under Win 7, Primetime works on Serpent 52.9.2019.11.15 (with media.ffvpx.enabled & media.wmf.enabled both set to false) just as it does under Win XP. And Widevine is visible, although I still have v1.4.8.903 for some reason. (See attached thumbnail.) Unsure why it never updated to v1.4.9. Not sure it matters now, since one needs 1.4.10 now and AIUI 1.4.10 isn't yet compatible with Serpent/Basilisk. I'll recheck with 52.9.2019.11.22 tonight, but I expect you're right: Primetime and Widevine will still be visible but Primetime won't work. IIRC @dencorso originally installed Primetime because the built-in support (media.ffvpx.enabled) produced distorted audio on some sites. I asked about this issue not long ago, but Serpent users were getting around it by just setting the Firefox compatibility settings in about:config (apparently some web sites use an audio codec Serpent/Firefox can't handle if they don't see Gecko/Firefox in the UA). BTW, thanks for the "FT-DeepDark" theme link! Only problem I see is that the "Tab Tally" drop-down menu has very low contrast with it. Know of a way to fix that annoyance?

Hello and welcome to the MSFN forums May I ask where did you retrieve an UNSIGNED version of the Kill Sticky firefox extension? This is of the Web Extension (WE) format and, as such, it can't be found inside the CAA addon, while ALL versions of it currently hosted on AMO are SIGNED BTW, the latest version there is 1.6, not 1.4; both claim to be Fx 52 compatible (but we've known from past examples that this is not written in stone, Mozilla may be - and have been - wrong, I'm convinced no-one of their staff manually tests released WEs with older - unsupported - Firefox versions ). Now, although Serpent 52.9.0 has retained whatever limited WE support was originally present in the UXP platform (contrary to official Basilisk 52 which has ditched WE support altogether ), Serpent 52 is NOT ON PAR with Firefox ESR 52.9.0 when it comes to WE support; several WE APIs were removed upstream (by MCP) from Serpent, so telling us that a certain WE addon works in Fx52 but doesn't in St52 isn't something conclusive... I decided to investigate myself, and Kill Sticky v1.4 is an id-less extension, a type of WEs that is not supported in Serpent 52.9.0/UXP out-of-the-box; if you've made the common mistake of transplanting an existing dirty Firefox 52 profile onto Serpent 52/UXP, then it's no surprise the extension got disabled... When changing browsers, always start with a new, clean profile! Trying to install Kill Sticky v1.4 in a Serpent 52 new profile, you'll be met by failure: As already mentioned, this is because it's an id-less WE; but you can patch the XPI file yourself to add the missing id, e.g. edit its manifest.json file like below: { "manifest_version": 2, "name": "Kill Sticky", "version": "1.4", "description": "Kill off the annoying floating things blocking the website you're trying to see", "icons": { "32": "icons/32t.png", "48": "icons/48t.png" }, "background": { "scripts": [ "background.js" ] }, "permissions": [ "activeTab" ], "optional_permissions": ["tabs"], "browser_action": { "default_icon": "icons/32t.png", "default_title": "Kill Sticky" }, "applications": { "gecko": { "id": "kill_sticky@mozilla.org" } } } Of course, that way you'll invalidate the extension's signature, so you can also remove directory META-INF! Have you reached so far yourself? Is this what you mean by an "unsigned" version of KS 1.4? I have no trouble installing my patched version of kill_sticky-1.4-an+fx.xpi in a clean profile of latest Serpent 52.9.0 (2019-12-06); its button shows up in the address bar, the addon is listed as ENABLED in the AOM, and it doesn't get disabled after several browser restarts : Slightly OT, but if you want an extension that can remove "web page overlays", then the legacy extension Behind The Overlay v0.1.6 (via CAA) works nicely in my St52 profile... I personally believe this is not "extension blocklist" related, but deleting a blocklist would only offer a temporary remedy, as the browser will automatically re-download it and place it within its profile... Best regards EDIT: Apparently, boolean user pref extensions.blocklist.enabled (defaults to true) controls the blocklist implementation; there exist several other extensions.blocklist.* prefs, one of which is extensions.blocklist.url; I guess by modifying its current value (string) to an invalid URI, you can stop the browser from fetching it... But I stress I don't believe myself the OP's issue is blocklist related... (but I could be wrong, once more... )

It is with sadness I have to report my favourite Bit Torrent client of close to 6 years now, qBittorrent, has dropped Vista (and probably XP) support! I was running the portable PAF version and just found out the hard way, after accepting a prompt to upgrade to the recently released new version 4.2.0: Inspection of the main x86 executable with Dependency Walker reveals further missing function calls in Vista's system files: in SHELL32.DLL Shell_NotifyIconGetRect in MFPLAT.DLL MFCreateMFByteStreamOnStream in USER32.DLL ChangeWindowMessageFilterEx CloseTouchInputHandle GetTouchInputInfo IsTouchWindow RegisterTouchWindow UnregisterTouchWindow The application is compiled with the Qt Framework, last version of which to be compatible with Vista+XP is 5.6.x (I think 5.6.3 was the last release of the 5.6 branch); the app's code is open-source, published on GitHub: https://github.com/qbittorrent/qBittorrent Browsing that repo, it becomes evident that the team of devs willingly moved past NT6.0 support, e.g. https://github.com/qbittorrent/qBittorrent/commit/5d0d8a0b7b032ed6f850325921eddc2f7303d9a8 https://github.com/qbittorrent/qBittorrent/commit/a4b9a4d9da9c9479eb1e63c8b8157aa4209c627c https://github.com/qbittorrent/qBittorrent/commit/7276a79cefe00f3e82fec8760ec876aa8a276df0 https://github.com/qbittorrent/qBittorrent/commit/2f0ae7a7d8c53d8c1d1bee08d61e5dcb28cfd61b https://github.com/qbittorrent/qBittorrent/commit/3ab2fe907f9519a9a90e072576ba6cfbbd52857d https://github.com/qbittorrent/qBittorrent/commit/74fc86e2ab2896bff9e90ab710b722027f2b9678 where the last commit dates from March 17th (!) 2019 and contains the changelog lines: - WINDOWS: Drop support for < Windows 7 (snip) - OTHER: Raise minimum Qt version to 5.9.0 (sledgehammer999) Another reason I did not see that coming was the fact the pre-release alpha builds, v4.2.0alpha, had been available only in the x64 architecture (on their site: "For Windows, only the 64-bit build is available for the alpha release."), so I couldn't test them prior to the official 4.2.0 x86 release... Had I been more cautious, I could have 1. spotted, between the lengthy release notes of 4.2.0, and in the downloads page itself So, I guess I'm stuck at the last version of qbittorrent that's Vista SP2 compatible, which is v4.1.9.1 https://www.fosshub.com/qBittorrent-old.html?dwl=qbittorrent_4.1.9.1_setup.exe https://sourceforge.net/projects/qbittorrent/files/qbittorrent-win32/qbittorrent-4.1.9.1/ Portable version, in PAF format: https://portableapps.com/downloading/?a=qBittorrentPortable&n=qBittorrent Portable&s=s&p=&d=pa&f=qBittorrentPortable_4.1.9.1.paf.exe Many years ago, I'd be using Shareaza (remember that?) as my P2P client, for both ed2k and bittorrent shares, but when emule went out of fashion, I switched to μTorrent for the BT network... But when that turned into a horrible adware , I gladly switched to qbt, which offers pretty much the same GUI (minus the adds...); plus, its Python powered search feature is not to be missed... Other BT clients I had also tried in the past, showing a preference to Tixati ; but I stayed with qbt ; I don't want to derail this thread, but should I be considering switching to another BT client for the duration I'm still on Vista SP2? What is your personal experience with the other choices?

you may turn on firefox compat mode to see if problem persists.

Thanks for that informative post Bruninho, you've been around the block with this stuff. As most of my hardware is not SSE2 capable, SeaMonkey stops for me at v2.49.4, even in a recent Linux install. SeaMonkey is a terrific browser, they have been struggling as of late. You can't really blame them for dropping Windows XP support, do any other browsers still actively support it? Forgot i already tried RetroZilla v2.2, but dismissed it too early. This time around installed rn10950's release: https://github.com/rn10950/RetroZilla/releases/tag/2.2 This forum's RetroZilla thread can be found here: https://msfn.org/board/topic/174987-retrozilla-an-updated-version-of-mozilla-for-windows-95-and-nt4-22-released/ It's a similar experience to SeaMonkey v1.1.19 with improvements. TLS v1.2 support is not evident from browser preferences or about:config. To confirm browser capabilities load this (from RetroZilla thread): https://www.ssllabs.com/ssltest/viewMyClient.html Additionally, the last RetroZilla thread post from ClassicNick indicates modifying about:config for improved cipher support. --- ClassicNick: Retrozilla does support AES-GCM cipher suites, but you need to enable them through about:config. search "security.ssl3" then create a new Boolean "security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256" and "security.ssl3.ecdhe_rsa_aes_128_gcm_sha256". Retrozilla works very well, and I'm excited for the next version (especially a 3.0 release). --- No other browsers tested thus far in vanilla Windows 98 pass the TLS v1.2 test. Quite a feat, believe Firefox didn't introduce this until version 20 something. Note the last working version of Opera for vanilla Windows 98 was not tested, just a personal preference. Old Opera versions have been highly praised on this forum many times. From brief RetroZilla usage, obvious improvements were noted. For example, built-in updated certificates, startpage search engine works, some previously inaccessible websites now load (Wikipedia, https://sourceforge.net). All of my SeaMonkey tweaks still work: - Custom search engine engines mentioned on page 4 of this thread (November 6th) - Old SeaMonkey / Mozilla extensions linked on page 11 of this thread (November 28th) Of course, rendering is poor compared to a modern browsing experience, JavaScript engine is dysfunctional and many sites still don't load, take what you can get. Hopefully developers rn10950 and roytam1 will eventually re-visit RetroZilla for further tweaks. To me this drawn out testing experience was worth it. Secure and functional online access remains the primary obstacle from keeping Windows 98 fully viable. IMHO I am now using the best browser for this old system. Thanks for everyone's input, i've always got to learn the hard way, by doing. Now just have to clean up almost half a dozen browsers and a whole bunch of scattered bookmarks.

don't know if that will fix it, I'll try to revert https://github.com/roytam1/UXP/commit/e50e93c too see.

Five updates offered today - Security Update for Microsoft Office 2010 (KB4484193) 32-Bit Edition Security Update for Microsoft Excel 2010 (KB4484196) 32-Bit Edition Security Update for Microsoft Office 2010 (KB4484192) 32-Bit Edition Security Update for Microsoft PowerPoint 2010 (KB4461613) 32-Bit Edition Security Update for Microsoft Word 2010 (KB4475601) 32-Bit Edition Tried Microsoft Update, fearing the worst after last month, and was amazed when they all worked! All seems to be OK, so presumably no MSO.DLL replacement this time. I guess last month's signing problem must have been a one-off glitch, at least I hope so!

The screenshot in that blog is of a prerelease version, and was apparently borrowed from their 2014 blog post pertaining to Windows XP. There has been no prerelease version since 4.10 in 2016. The bad news in that blog is the link to FAQ about Extended Security Updates for Windows 7, where the following question and answer can be found under ESU coverage:

With KernelEx updates by Jumper on Windows 98SE, you can go up to 2.8 with SeaMonkey, theoretically you can try 2.9, but it will crash a lot more often and will not work well. SeaMonkey 2.9 is the last version for vanilla Windows 2000, and SeaMonkey 1.1.19 the last for Windows 98/ME. Both useless for proper HTML. As a test, I try to load my main daily news website; If the blocks are rendered exactly like I see on my macOS, then it's working as expected. If they render in cascade (meaning CSS is not rendering properly or some HTML5 tags aren't being recognized) then it's garbage to me (unless the layout looks sort of a mobile website as a fallback, then it's acceptable). With BlackWingCat's kernel extenders on Windows 2000, I can go to the latest (and I really mean, latest) SeaMonkey: 2.49.5, and they announced that it will be the last version supporting Windows XP and Vista. "How rude". I was becoming a fan of SeaMonkey after that until I learned this news. At least Youtube works, sites are rendered as expected. Probably some super new CSS3 properties aren't, those that are in the draft for the next version of CSS. Hopefully - and I haven't tested yet - CSS Grid & Flexbox are still supported. If KernelEx with updates on Windows 98 is supposed to make possible to run XP-like apps, then why it doesn't work in practice for SeaMonkey? Something must be missing. The most decent browser I could run on Windows 98SE vanilla was probably Retrozilla 2.2. No Youtube, and no proper rendering of my favorite websites, though. And some cipher overlap errors somewhere else. Opera 10.63 probably was a little better. I haven't tried other browsers in a vanilla Windows 98 apart of RetroZilla, SeaMonkey and Opera. I know Firefox 2.x won't render OK.

Hello, since a few days the workaround does not work for me anymore. Mp4 videos can no longer be played on youtube and other sites. Does anyone know a solution to continue to play MP4 videos in Firefox on Windows XP? Example: https://www.youtube.com/watch?v=rx-D-Ssjets Edit: I found the Error. A few days ago I put the 3GB switch on a trial basis in Boot.ini because I had problems with another program. By deleting the 3GB switch everything works again as usual.

WinNTSetup 4.0 Final - Added Dark Theme support - Added multicore appling of WIM - Added wimlib 1.13.1 - Added bottice 1.3.3.2 - Added Disable Reserved Storage tweak - Added WIM Capture option - Added apply mode Wimboot:WIMCOPY - Added Hotfix uninstall option - Added Driver Export/Import option - Added LegacyBootMenu checkbox - Added exclude section to Tools\Win10Builds.ini - fixed wimlib apply alters WimBootCompress.ini - Boot code UEFI will be selected as default in case of EFI system partition - WOF decompression of \Bootmgr, \EFI\boot\boot*.efi, \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI - WOF decompression of \Boot\BCD, \EFI\microsoft\boot\BCD - Does not delete MountedDevices key for non sysprep images - Allow creation of expandable VHD with any size - Non fitting expandable VHDs will stop from auto expanding on boot - Workaround wimgapi "PrepopulateList" bug

They don't even bother to test the drivers provided with the OS. Seriously?