Nicholas McAnespy
Content Type
Profiles
Forums
Events
Everything posted by Nicholas McAnespy
-
@roytam1 I downloaded your "palemoon27-pm27100-vc2010" source code, and tried removing C++ 11 move/forwarding references. I now get a crash in mozjs.dll. Also, I can't do a debug build due to a "program database manager mismatch" error. If you can upload the source code so I can see my changes on GitHub, that would be great. Note: I removed the delete constructors in js/src/jsobj.h lines 544-545. I also used Visual C++ 2010 to compile this, so I assume my modifications are incomplete. https://codeberg.org/Nicholas_McAnespy/palemoon27/releases/tag/2796-MoveRef-Busted
-
@K4sum1 Thank you for doing public releases of lun3r and Hydra. I prefer to use a browser based on Pale Moon, and I build browsers based on Arctic-Fox/Pale Moon 27, so it's nice to have a browser that I can leave running, while testing my own browsers that share the Pale Moon profile.
-
@roytam1 I have been getting some errors related to "NodeInfo is not a member of mozilla::dom::mozilla" while trying to compile New Moon 27.9.7 using Visual C++ 2008. My way of solving those errors means de-unifying the C++ sources.
-
Update: Visual C++ 2008 doesn't like using <intrin.h> in nsprpub/pr/pratom.h, and prbit.h.
-
With further testing, I noticed the older K-Meleon 76 Goanna builds (76.1.1) lack GetLogicalProcessorInformation in xul.dll, but have it in the gmp* files, libavcodec files, and MSVCR120.dll. I believe Firefox, Arctic-Fox, and Pale Moon have some sort of hack to allow execution on Windows XP SP2, even though Visual C++ 2010 and later do not naturally support it, which is probably why K-Meleon 76 Goanna doesn't work with Windows XP SP2. Since MSVCR90.dll is the last version to not call GetLogicalProcessorInformation, I hope this problem fixes itself if/when we get Tycho/Goanna3 compiling using Visual C++ 2005 and/or 2008.
-
While you're doing that, I tried compiling the New Moon 27.9.7 VC2010 mod using Visual C++ 2008, and hit a roadblock due to compiler errors caused by C linkage where it's not appropriate for it to be specified. I do not know where the C linkage is though... If you can find where "GetLogicalProcessorInformation" is defined, that would be great, but could be difficult because it is called from xul.dll in K-Meleon 76 Goanna, but no such call exists in xul.dll from New Moon 27. Admittedly, I haven't tested whether xul.dll in K-Meleon 76 Gecko calls GetLogicalProcessorInformation, and thus, fails to execute in Windows XP SP2.
-
The Source code containing git information is uploaded to https://github.com/ClassicNick/palemoon27/releases/tag/27.9.7-VC2010
-
@roytam1 I didn't bother cherry picking d918e4f. The last commit I cherry picked was 2d9c22e, which reverted e186cc7, which caused the browser to crash when opening a new tab. I'm also sitting on a local build of New Moon 27.9.7, so when I upload it, do you want the git information along with the source code, or do you just want the source code?
-
@roytam1 Now that I'm cherry picking commits from our palemoon27 repositories that are dated ~September 2019, I notice commit partial hash d918e4f (9/17/2019) apparently contains e10s code that you didn't like at the time (Accusation caused by f25cb74, which was dated 9/20/2019). Should I try cherry picking d918e4f, or should I move on without it? Also, I decided to read some comments on your 1st browser builds thread, and you said the Ryzen 7 3700X with your SSD caused build times to be 1/3 of what they were with your previous hardware. What were the specs of the previous computer you did your browser builds on?
-
My Git commands presently are "mkdir palemoon27-27100-VC2010-WIP" "cd /F/palemoon27-27100-VC2010-WIP" "git clone "https://github.com/ClassicNick/palemoon27.git" and Ex. "git cherry-pick 593d1c0". Basically, my method is cherry picking all commits from newer branches. That way, I don't need to worry as much about git conflicts. As for SSH, I don't know how to add an SSH key. Now that I can cherry-pick commits, after how many changes should I upload the source code?
-
After a day of trying out some git commands, I realized Git 2.10.0 does not support Codeberg due to a problem with the SSL certificate. I finally logged back in to my GitHub account, and also realized I can download whatever I want from Git 2.10.0, but I can't upload anything from there because password authentication is no longer supported on GitHub. What git command do you recommend using to port palemoon27-classic, and eventually palemoon27-master commits to palemoon27-pm27100-vc2010?
-
@roytam1 Before I do any more work on Visual C++ 2008 SP1 compatibility, should I use the pm2796-vc2012 branch, or the 27100-vc2010 branch? If it's possible to use Git 2.10.0 in Windows XP SP3, and if you have an excessive amount of patience, I would like it if you could help me use it.
-
In js/src/gc/Heap.h, #include "mozilla/TypedEnum.h", and then check if you can get away with using MOZ_BEGIN_ENUM_CLASS(AllocKind, uint8_t) in place of enum class AllocKind : uint8_t {. Also, replace } with MOZ_END_ENUM_CLASS(AllocKind). I do not guarantee that will work, but it typically will. If it doesn't, you'll need to use enum : uint8_t {. What error message are you getting with bug 1139552?
-
I was hoping I would get the broken source code with bug 1134425 already applied, so I could see what removing the characters = CanGC from template <typename T, AllowGC allowGC = CanGC> would do.
-
If you haven't fixed it yet, do you want to upload a zip file containing the source code you are/were working on?
-
I know that doing work of that nature properly can take a long time, so I hope there is still enough time have a special New Moon 27.10.0.9794 (should probably have a 27.11.0 version number, and at that time, specifically 27.11.0.9794) build that is based on Arctic-Fox 41 (which is effectively based on Firefox/Gecko 45/46) that works with Visual C++ 2010, and Windows XP if you can use your kernel wrapper for it. I say this because having a Gecko 45 compatible New Moon 27.10.0.9794 build running on Windows XP (RTM if I must specify it this way) on the 25th anniversary of it's retail launch (October 25th 2026) is very interesting if not amusing to me. Also, since I'm using Windows XP SP3 right now, I can't test whether pm2796-vc2012 compiles using Visual C++ 2013 still. If it does, and if the changes are breaking the builds in every merge, is that because the later Arctic-Fox commits have Visual C++ 2010/2012 incompatible code, but will work fine using Visual C++ 2013, or is it because our Visual C++ 2010/2012 compatibility changes interfere with changes already present in the newer branches, meaning if Visual C++ 2013 still works with pm2796-vc2012, it will no longer work with a pm2797-vc2010-WIP, or pm27100-vc2010-WIP branch due to the breaking changes?
-
If you're worried about too many breaking changes between February 2019, and February 2021, then let's split it down the middle. Create a public PM2797-VC2010-WIP 2020-02-XX branch, then merge our existing changes from pm2796-VC2012 if GitHub allows that. Then, I can have fun making the newer build work with Visual C++ 2010 without applying all the previous changes manually. Confession: I struggle with keeping priorities straight, so I don't know if I should try Visual C++ 2008 compatibility first, or make the newer Arctic-Fox/New Moon builds compile with Visual C++ 2010 first.
-
I will admit that I finally tested our New Moon 27.9.6 build from May 24th 2024, and I got 1 crash in XUL.DLL during my ~1 hour of testing. I hope me requesting the changes from pm2796-vc2012 be ported to a pm27100-vc2010-WIP branch (2021-02-26) is not too much to ask... Also, I think I finally produced a working build of Firefox 33.1.1 without UniquePtr references in the source code. However, I messed around in the js directory because I got errors when switching to Visual C++ 2008 "no rule to make target js-config.h", so I'll soon try a Firefox 35.0.1 build without UniquePtr references. Congratulations with your Firefox 38 and New Moon 27.9.6 builds!
-
As I understand it, if my order is a tall order, it means I gave you a difficult or impossible task. If so, is it difficult because GitHub won't allow you to force merge commits/pull requests ("conflicting files/commits"), or because our Visual C++ 2010/2012 compatibility changes relevant to New Moon 27.9.6 2019-02-23 will still fall short of proper Visual C++ 2010/2012 compatibility in a New Moon 27.10.0 2021-02-26 build? I ask because I fear the first scenario much more than I do the 2nd one. That's why I can't rely on Codeberg to help me with my Firefox 3.0 Windows GFX/Windows 95 mods, so I have to apply all the changes manually.
-
@roytam1 Would it be possible for you to create a New/Pale Moon 27.10.0 branch on your GitHub repository (2021-02-26 I believe), and then transfer our pm2796-vc2012 changes to that branch?
-
I thought I could get away with partially reverting bug 371434 by simply changing nsLayoutUtils::DrawImage(&aRenderingContext, parameter 1, parameter 2, parameter 3) to aRenderingContext.DrawImage(parameter 1, parameter 2, parameter 3). It turns out I needed to fully revert bug 371434 in order to fix the picture rendering problem I have been having. After making the full set of changes to layout/generic/nsImageFrame.cpp (and nsImageFrame.h), pictures now display as intended. https://bugzilla.mozilla.org/show_bug.cgi?id=371434
-
RetroZilla Community Edition
Nicholas McAnespy replied to Wunderbar98's topic in Windows 9x Member Projects
I assume you mean when the firefox38-vc2010 repository has ~500 more commits than it does now, it will be functionally equivalent to New Moon 27.9.6? I wonder if it's possible that if I revert 500 of Mozilla's commits between Firefox 3.0a2, and Firefox 3.0a3, JPEG files will display properly in my Firefox 3.0a4 build? My next task is to build a Thebes/Cairo-Windows GFX version of my Firefox 3.0a4 mod. -
If anybody wants to test my Firefox 3.0a4 mod, here it is: https://codeberg.org/Nicholas_McAnespy/Fx3.0a-VC6-mod/releases/tag/Fx3.0a4-Win95
-
Update: Bug 377947 was the rewrite of Mozilla's system font handling. That means I did remember the bug number correctly.
-
1. I don't know how to apply/revert commits (at least well enough to make it worth it), so all the commits I reverted, I did locally and manually by getting the text file, then going through every line of code and reverting the changes. If I could reliably revert bug 177805 using an automated process, then applying all commits afterward on top of it, I would. 2. As far as jumping too far ahead, last year, when I was trying to figure out why a Windows GFX build of Firefox 3.0a6 was not displaying context menus, and why the text in the entire UI was ~1 pixel in size, I eventually found out it was because of bugs 377539, and 377947 if I remember correctly. It took me a build of a May 10th 2007 Firefox 3.0a5 snapshot to be led to a change (bug 377539) in dom/base/src/nsScreen.cpp. Also, my latest (local) Firefox 3.0b5 build has "374 unresolved externals" while trying to link gklayout.dll. Note to self: In Firefox 3.0, define MOZ_ENABLE_CAIRO_GFX in config/autoconf.mk.in, or else #ifdef MOZ_CAIRO_GFX will not work.