Leaderboard

I just checked the kernel32 fault and it is not in a section of the file that I modified/added. It's in a subroutine called by ReplaceFileW, CreateDirectoryExW and indirectly by CopyFilesExW. Vista's WEI does indeed max out at 5.9.

the download server is up again, and feel free to mirror thingies on the server.

Not for any changes to 372.70. Only for newer drivers once ntoskrnl is extended.

Since quite a long time now (at least 2016), I am doing MPlayer builds using MinGW, targeting My old Win98SE machine. http://www.mplayerhq.hu/design7/news.html There are a few modifications that are made to the code and then it works just fine. I decided to share those builds now so that everyone can benefit from it. I mostly use WinXP now, and I still prefer to use my own builds for performance reasons and because I enabled automatic CPU detection which is quite helpful when installing on several computers. Here is the links with last stable release (1.4) and last build. MEGA: https://mega.nz/folder/zbJiHIqK#garNgPLQaYp0Tu9bF--MsA GitHub: https://github.com/RamonUnch/MPlayer-Ringo-builds/releases In general I recommend the last build because it is usually stable. I will try to add every few months a new build (whenever I will need it). Note that the stable builds requires at least an i486 The latest build requires at least an i586 because of latest ffmpeg (I may try to fix that in the future). This player is very up to date and you will be able to decode any modern h264/265/opus streams etc. Be sure to check the configuration in mplayer/config (open with notepad or any other text editor) Whenever I start a new build I will always use the latest mplayer/ffmpeg config so that it all stays updated. In the future I hope to build GNU TLS for 9x so that you can read HTTPS streams. I will also need to add CD support someday... Tell me what you think about it. Keep in mind however that I have very little time to bug-fix and do all of this.

Notice: These projects have no affiliation with any upstream community code sources or organizations. Please direct all support or related questions to here. "Serpent", "New Moon", "MailNews" are generic debranded names and they are subject to change in the future. Archive directory names and archive filenames will only be changed once generic debranded names are not used in the future. Latest changelog is available here as well: http://rtfreesoft.blogspot.com/search/label/browser for people who can't register here, there is another place you can create post for asking/help besides in github and blog: https://forum.eclipse.cx/viewforum.php?f=33 Serpent/UXP browser (MCP reforked 52ESR as new base), and NM28XP releases: Binaries are moved to here: (I'm lazy to edit all previous posts) https://o.rthost.win/palemoon/?sort=date&order=desc BOC and hyperbola related binaries: Binary list: https://o.rthost.win/boc-uxp/?sort=date&order=desc ------------------------------------- NewMoon 27 build: ------------------------------------- Serpent/moebius browser (deprecated by MCP, forked by me), and also 26.5 as playground : And NewMoon 26.5 and K-Meleon 74 with Goanna 2.2 (newmoon-26.5) for vanilla Win2000 build: ------------------------------------- K-Meleon browser with Goanna/Tycho engine: It has its own sub-forum in K-Meleon official forum! http://kmeleonbrowser.org/forum/list.php?19 Latest build: ------------------------------------- Firefox ESR 45 with TenFourFox fixes for IA32/SSE-only machines: ------------------------------------- K-Meleon Original cross-post is here: ------------------------------------- ArcticFox XP win32 test build: ----previous post----

New build of Serpent/UXP for XP! Test binary: Win32 https://o.rths.ml/basilisk/basilisk52-g4.6.win32-git-20201003-ef27fbe-uxp-15acac52b-xpmod.7z Win64 https://o.rths.ml/basilisk/basilisk52-g4.6.win64-git-20201003-ef27fbe-uxp-15acac52b-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.rths.ml/basilisk/basilisk52-g4.6.win32-git-20201003-ef27fbe-uxp-15acac52b-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.rths.ml/palemoon/palemoon-28.10.2a1.win32-git-20201003-8afdaa8c9-uxp-15acac52b-xpmod.7z Win64 https://o.rths.ml/palemoon/palemoon-28.10.2a1.win64-git-20201003-8afdaa8c9-uxp-15acac52b-xpmod.7z Official UXP changes since my last build: - Issue #1656 - Fix broken comment from Part 1 (a2ed139a4) - Merge pull request #1660 from g4jc/1656 (4e72f8ed0) - Issue #1643 - Follow up: Add a null check for mOwner in ResizeObserverNotificationHelper::Unregister (fb086631d) - Issue #1643 - Follow-up: Make sure things aren't changed while iterating. (bc531bfbb) - Issue #1647 - Followup: Remove excessive VARIANT_OPACITY statements. (b8c604196) - Merge pull request #1663 from athenian200/opacity_followup (96736fce7) - Update CONTRIBUTING.md (15acac52b) No official Basilisk changes since my last build. Official Pale-Moon changes since my last build: - [downloads] Correct and simplify host handling. (fd30b23a0) - Issue #1842 - Part 1: Establish Beta Branding for Windows and Linux (48188d196) - Issue #1842 - Part 2: Add Mac icons for beta branding & fix unstable (810ccfe4c) - Issue #1842 - Part 3: Add beta channel to ACCEPTED_MAR_CHANNEL_IDS in confvars.sh (207535416) - Back-end branch pointer update (Unstable 2020-10-01) (8afdaa8c9) My changes since last build: - skipped Issue #1842 related commits

Microsoft Visual C++ 2008 Service Pack 1 Redistributable Hopefully you didn't get it from some shady "Fix All Your DLL Problems" site...

I removed it, and the same thing happened, so the crash doesn't seem to be related to the digital signature. Though I'm not exactly sure why the crashes are happening. Could be because of your reason or that the 8.x directx graphics kernel doesn't work well with W7-targeted binaries. DirectX binaries were not digitally signed until Windows 8 came out.

It kinda broke the formatting, but that's easily fixed. Thanks for the solution

Well, that function is not in that copy of ole32. Someone else complained to me about it. The standard extended kernel v3.0e English (not the gameguard version) has this function in ole32 and works good with roytam's browsers. But I remember that the extended kernel installer has many options, some of which have to do with ole32.

CoGetInterceptorFromTypeInfo() calls exist in vanilla Firefox52, so maybe something else is going wrong. EDIT: tested with Win2000 JP with extended kernel 2.8jG and it works here.

Well sometimes Let the Mountain come to me. At this point i see arrogant and rude people from ultra-right wing country who trying push normal people, from around the world, to they wacky understanding of reality. Resist that, don't bend to them! By the way msfn is not the only forum where this moon-people shenanigans are condemned. Google translate it easy. Roytam1 is doing excellent work, i support him - he helped so many people with his calm and intelligent approach.

Lets try and pool together on this.

I found a version block for Windows 8/8.1 in the file, but nothing for Vista. So I think the D3D parts of 368.xx/372.70 are like this: 900 series and below: works on Vista as with old drivers Pascal support added in these new drivers that have no official Vista support, so no workie on Vista Drivers have specific Windows 7 directives, so Pascal probably works when Windows 7 directives are in force. So I think that once I can get the drivers to use the Windows 7 directives, that may be enough to get D3D working as good as Windows 7. Possibly including 12 unless DXGI does not cooperate.

All security and cumulative updates released after January 14, 2020 require an ESU key to install on a classic Windows 7. Except the Licensing Preparation Package and SSUs.

Could you explain what this means? Is this a v28-only build preference Please read below: that's the accessibility libraries, official builds and my old builds used to have --disable-accessibility specified. I lost the build config and then it turns on that on compilation. ... and will go if I remember to do this. As to: I'm not currently using NM27, but do you now (i.e. in latest builds) see extraneous accessibility files inside its main directory? FWIW, one can always consult built-in pages like "about:buildconfig" to read build-time configuration flags...

Moonchild's stance is now "if the mountain won't come to Muhammad, then Muhammad must go to the mountain", as expressed (along with "name calling") below: https://forum.palemoon.org/viewtopic.php?p=200402#p200402 and further down in that thread:

That hack is essentially the same we used on XP: by keeping Engine Version 1.1.15800.1, we were able to continue updating up to the *.vdm v. 1.293.2807.0... then the next *.vdm files required a newer engine version and game over it was. But, from that period just before game over, @heinoganda had cobbled up an automated updater that download the the new definitions, replaced the engine by the last one working and put all files in their proper place, therefore helping more people to keep their MSE up-to-date up to game over, and I bet he sure might be able to modify that tool for the Vista community to enjoy the last leg of their MSE/WD more confortably. In case he doesn't ping this theread soon, do send him a PM. I'm sure he'll be delighted to be of help. Ceterum censeo Decimum delendum esse!

I understand where you're coming from with that, however I certainly don't believe it's too much to ask for them to keep their "unsolicited opinions" to themselves. I don't care if they "disapprove" or "dislike" what we're doing, I know they don't approve and I didn't ask them to agree with it. I only ask that they stop "disparaging" us with it. This is how "diplomacy" works. If they expect us to do something that they demand, then they can show good faith by ceasing their constant attacks. And, I hate to say it, but they have no right whatsoever to insinuate that someone is "stealing" code; that's not how "Open Source" works. If that is their attitude, then they're nothing but a bunch of hypocrites, because they owe their entire existence to Mozilla and Firefox, from which they "stole" code to begin with. If they want the "right" to claim people are "stealing" code, then let them go and start from scratch and build a closed-source copy of what they have now. I would estimate they might be back up and running in five years or so, if they're lucky... That is Mr. Tobin's interpretation of the licensing. That doesn't necessarily make it the correct, or most accepted interpretation. You will recall that I disagreed with him on this previously, and he had no direct response to the points that I made. It would be pretty senseless to be able to obtain source code that could not be "built" - this, to me, is a perfect example of "attempting to limit the user's rights in the Source Code" which the MPL prohibits, as I listed before. Based on previous behavior, which I also provided links to, it seems to me that Mr. Tobin and company prefer to just go around making threats and creating a toxic atmosphere for those whom they don't like building their code, hoping that they can "scare off" or bluff them all into submission, because whoever they're targeting simply doesn't want to deal with their constant attacks. Oh no, I have absolutely no intention of beating that dead horse again. It is dead, and should remain dead. The issues of licensing are wholly independent from the "rebranding" discussion. I knew that, however these "ramifications" (read "threats") or whether they can be enforced or not come down to licensing. I covered that specific aspect in my other post. You did ask for other input...

FWIW, I got all the XP-X64 EXE files and double-checked that no more updates just after/around MS clobbered support. Done in a HyperVM (whatever) on one my other PC's (Srv2k8R2). Maybe an upload to Web Archive is in order?

Good old days I remember Yahoo and Altavista