Leaderboard

alright I could create a crash here, but the code that crash occur is not changed for long time, I may need more time to debug.

Admittedly, I have been remiss in revisiting this thread, but to the extent it concerns my personal usage, I don't consider Vista's native Windows Defender an urgent matter (as explained previously, I'm only running it and try to keep it updated for "legacy"/sentimental reasons ) ... In any case, Microsoft have been really hopeless in their - still advertised - NT 6.0 support for the off-line WD standalone updater (file mpas-fe.exe); "Previously on Dynasty", I had reported that series 1.323.xxxx.0 of installers became Vista incompatible, because it introduced engine file mpengine.dll of version 1.1.17400.5, not NT6.0-compatible; that series ended with version 1.323.2309.0, digitally signed (SHA2) Oct 1st 2020. During the course of the 1.323.xxxx.0 series, Vista users could update manually their WD by 1. Manually downloading mpas-fe.exe from 32-bit: http://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe 64-bit: http://definitionupdates.microsoft.com/download/DefinitionUpdates/amd64/mpas-fe.exe 2. Extracting from it (with 7-zip) the two *.vdm files (the actual definitions; the smaller-sized is a binary diff one) 3. In Windows Explorer, navigating to the Updates folder of their WD default installation, e.g. for Vista 32-bit it's in: "C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Updates" 4. Dropping inside that directory the extracted *.vdm files (overwriting files, if present); in a matter of ~ 20 seconds, the newer defs will be auto-installed! NB: Step 4 implies a Vista compatible engine file (e.g. v1.1.17300.4 from the previous 1.321.xxxx.0 series) is still in place in "C:\ProgramData\Microsoft\Windows Defender\Definition Updates\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}" (the alphanumeric string changes into a new random value with each update) Then, in the docs.microsoft.com URL provided by @Vistapocalypse, there was a link to a newer engine file, v1.1.17400.7, digitally signed Sept 3rd 2020, which was indeed NT 6.0 compatible; sadly, that file was only circulated "internally", while on-going series 1.323.xxxx.0 was still shipping to end users incompatible engine 1.1.17400.5 ... FWIW, the very few Vista users with access to "fixed" mpengine.dll v1.1.17400.7 could finally upgrade past v1.1.17300.4 by placing it, as with the *vdm files, inside: "C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Updates" On Oct 2nd 2020, series 1.325.xxxx.0 was released (with 1.325.10.0) and it introduced new engine mpengine.dll v1.1.17500.4 that reinstated NT 6.0 compatibility; Vista users could, once again, update their WD app by simply running file mpas-fe.exe It would appear all was hunky-dory for Vista users, but, once again in a very short while, Microsoft people goofed up big time On Oct 22nd 2020, while series 1.325.xxxx.0 was still on-going, Microsoft released mpas-fe.exe v1.325.1199.0; the file still contained the compatible engine v1.1.17500.4, but trying to run said file under Vista you get: Probing the file itself with specialised tools revealed that it as well as the inner file MpSigStub.exe, though both remained NT 6.0 compatible functions-wise, had been compiled with a Subsystem 6.1 PE header, thus they couldn't be run under Vista in their default state ... Of course, trying to mess with the PE headers (and I had no clue how to modify the internal .exe's one ) would invalidate Microsoft's SHA2 code/file signatures, "bricking" the mpas-fe.exe for updating purposes... Series 1.325.xxxx.0 ended on Oct 29th 2020, with v1.325.1653.0 (the breakage still not fixed); if Vista users wanted to update their WD past v1.325.1177.0 (issued on Oct 21st), could follow the procedure outlined above (by selectively extracting *.vdm files, etc). On Oct 30th 2020, series 1.327.xxxx.0 was released (with 1.327.7.0), introducing new engine mpengine.dll v1.1.17600.5; I am happy to report that a. The new engine remains NT 6.0 compatible b. Files mpas-fe.exe & MpSigStub.exe both have their Subsystem PE headers "fixed" to 6.0 IOW, business as usual (file mpas-fe.exe launches and updates WD's definitions as expected!) Given MS's previous record on this , I'd say the next f**k-up is imminent...

On Facebook, people do not delete or remove messages, they "unsend" them now. This is English, not Newspeak. Or is it?

UXP (Unified XUL Platform) is the name of the platform on which several upstream and downstream (forks) projects are built... Organisation: Moonchild Productions (MCP) UXP applications: Pale Moon 28 (+29), Basilisk (52.9.*) Organisation: Hyperbola (unofficial abbreviation: HBL) UXP applications: Iceape-UXP+Icedove-UXP Organisation: Binary Outcast (offical abbreviation: BinOC, unofficial abbreviation: BOC) UXP applications: Borealis Navigator+Interlink Mail & News Thus, Basilisk/UXP -> Serpent 52.9.0 Basilisk/Moebius -> Serpent 55.0.0 (*) Pale Moon 27/Tycho -> New Moon 27.9.x (*) Pale Moon 28[/29]/UXP -> New Moon 28.10.x Borealis Navigator/UXP -> BNavigator Interlink Mail & News/UXP -> MailNews The Hyperbola forks are meant to run only on said Linux distro, but roytam1 has forked them to compile and run on WinXP+... (*): The Tycho and Moebius official platforms have long been deprecated (and also purged completely from official repositories ) , roytam1's forks currently use code from other projects to get updated...

To prevent user confusion, I strongly recommend disregarding the tutorials and contacting me directly instead about the extended kernel. The original post was removed as it was continuing to confuse users. There will be further discussion about the evolution of the extended kernel in the coming pages.

So basically my main pc with ryzen 5 1600 and rtx 2060 is running on Windows 8.1. Microsoft for some idiotic reason only ported d3d12 libraries on windows 7, but I dont see anything preventing these libraries running under Windows 8.1 yet even compatibility mode does absolutely nothing and games using these libraries simply wont start. (My test game is COD WARZONE). Is there any hope of getting these games to run on windows 8.1?

Nah, WindowBlinds is just too buggy to my taste. You can tell that WB is just a software running on top of your Windows 10. Unlike Glass8 which feels native part of the O.S.

Interesting. Should I feel glad or sad that it doesn't crash for me? I kinda feel left out But with Roytam mentioning that area of code hasn't been touched in a while, that kind of bugs me. Because it tells us that a "new patch" at one address DOES effect code in a totally different address.

Hi Yes, the problem exists on the Edith Piaf video, but also on youtube constantly and randomly with newmoon 27.9.7 2020/10/31 . (no add-on and new profile, win x86 xp2) No problem with the previous version 27.9.7 2020/10/24

you may try the command line: cd <patch path> for %1 in (*.exe) do %1 -q The -q switch is just an example normally meaning quiet installation; you may find other switches by typing "<patch.exe> /?"

In order to make teamviewer work within LAN, the server and client should both in same version. So you should install 14.2.56676 on Win10 too, and disable auto-update (I tested on Win7). Google says: Remote Desktop client works with Windows XP Home edition, and there's method to make rdp server works too, though seems a bit complicated.

I agree, nobody knows how to make a website anymore. Everybody uses a template and the end product looks awful. I use mainly HTML + CSS3 and my policy is no JS unless absolutely necessary. Mainly advanced dropdowns and necessary logic. Most of my pages don't have any site JS. Thus, my website loads quickly and is accessible. Also, I code every line myself. All the PHP, all the CSS, and most of the JS... (sometimes, I do use a small library for a specific task, b/c I hate JS).

It's not working for me either! I'm not aware of any other hosts though ntext is actually not an MS file and one I compiled myself so if I can find an alternative link I'll post it here. Here it is. Just ntext and nothing more. https://drive.google.com/file/d/1OvxwDWdI2yz3f6MTrz9T34PGESYuOE6p/view

The only reason Microsoft would do this is because it allows them to collect more user data.

@VistaLover Thank you very much for the clarification! Thanks for testing! Could you please also test YT, i.e. Édith Piaf - Non, Je ne regrette rien. The problem is, you didn't test under the same conditions - XP x64 instead of XPSP3 POSReady. And which version of NM27 have been tested with? So the value of your result is at least questionable. And if it isn't available there for any reason, you can also get it from my page (soggi.org - tools) @greenhillmaniac. kind regards soggi

Hi There is a problem with palemoon 27.9.7 2020/10/30 without add-on and new profile with the German website

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rthost.win/basilisk/basilisk52-g4.7.win32-git-20201031-ffb32e0-uxp-6a4c3caa8-xpmod.7z Win64 https://o.rthost.win/basilisk/basilisk52-g4.7.win64-git-20201031-ffb32e0-uxp-6a4c3caa8-xpmod.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/custom IA32 Win32 https://o.rthost.win/basilisk/basilisk52-g4.7.win32-git-20201031-ffb32e0-uxp-6a4c3caa8-xpmod-ia32.7z source code that is comparable to my current working tree is available here: https://github.com/roytam1/UXP/commits/ia32 NM28XP build: Win32 https://o.rthost.win/palemoon/palemoon-28.10.2a1.win32-git-20201031-fcd19efc9-uxp-6a4c3caa8-xpmod.7z Win64 https://o.rthost.win/palemoon/palemoon-28.10.2a1.win64-git-20201031-fcd19efc9-uxp-6a4c3caa8-xpmod.7z Official UXP changes since my last build: - [netwerk] Make nsIncrementalStreamLoader's GetNumBytesRead threadsafe. (28119b040) - Bump platform version for added features. (d5e5bef3c) - [layout] Avoid negative availSize.BSizes in paginated table reflow. (2cd89d584) - [layout] Re-order rowgroups if reflowing. (6eba9263c) - Update docs for change of repository host. (1950e886b) - Update docs for change of repository host. (0daf842cf) - Issue #1656 - Nuke the remaining vim lines in UXP (6a4c3caa8) Official Basilisk changes since my last build: - Update submodule location (affb1cb) - Nuke vim configuration lines from the front-end (no code changes) (0a95895) - Update back-end branch pointer (ffb32e0) Official Pale-Moon changes since my last build: - [branding] Use about:blank as default newtab for unofficial. (810a8db8c) - Update submodule location (b82a4e75b) - Update 'README.md' (c269e3d0e) - Update 'README.md' (0bd23b462) - Graft updated protected branding assets. (85f7050a7) - Nuke vim configuration lines from the front-end (no code changes) (fcd19efc9) My changes since last build: - skipped branding related commits

All updates are OK, except the ones that replace MSO.DLL with an incompatible version. IMO the easiest way to make sure you get the latest (and now last) usable versions of all the Office 2010 files is to install all the most recent updates and then simply replace the MSO.DLL file with the one from KB4092483, which contains the last version which works on XP systems. Remember that updates which replace MSO.DLL can replace other files as well, but you only need to replace that one file to get the system working again.