Jump to content

Nicholas McAnespy

Member
 View Profile  See their activity

  • Posts

    199

  • Joined

  • Last visited

  • Donations

    0.00 USD 

  • Country

    Canada

 Content Type 

Everything posted by Nicholas McAnespy

  1. Nicholas McAnespy
    If you haven't fixed it yet, do you want to upload a zip file containing the source code you are/were working on?
  2. Nicholas McAnespy
    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?
  3. Nicholas McAnespy
    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.
  4. Nicholas McAnespy
    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!
  5. Nicholas McAnespy
    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.
  6. Nicholas McAnespy
    @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?
  7. Nicholas McAnespy
    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
  8. Nicholas McAnespy
    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.
  9. Nicholas McAnespy
    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
  10. Nicholas McAnespy
    Update: Bug 377947 was the rewrite of Mozilla's system font handling. That means I did remember the bug number correctly.
  11. Nicholas McAnespy
    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.
  12. Nicholas McAnespy
    I do have a build of Firefox 3.0b5 I do work on occasionally. My initial plan was to build Firefox 3.0b5 for Windows GFX toolkit compatibility, then transfer the changes to Firefox 3.0, and optionally 3.0.19. My build from last year crashes on startup, and I think part of my problem is I tried to use old code from the view, widget, and gfx directories, instead of reverting incompatible commits individually. Now I'm redoing the build, but with how long it takes, very slowly. I also suck at programming and debugging. Congratulations on your r3dfox project!
  13. Nicholas McAnespy
    What is the last version of Firefox to support legacy Java applets? Firefox 3.5.19 will be easier for me to work with than Firefox 3.6.28. As I have mentioned, I have a working Firefox 3.0a7 Windows GFX build, but it doesn't work properly on Windows 98 for a reason I haven't figured out yet.@K4sum1 I have tested every alpha version of Firefox 3.0, and of them, my favourite versions are alpha 2, alpha 4, and alpha 6. I haven't tested Firefox 3.0a5 other than producing a Windows GFX compatible build of it. The more I think about my predicament, the more I realize I may have to build every alpha and beta version of Firefox 3.0 so Windows GFX, and 95 support don't break too much on me. My picture display problems happen between Firefox 3.0a2, and Firefox 3.0a3. Should I fix the picture display problems first, or should I continue on with Firefox 3.0 builds, and then try to fix it? @roytam1 On my GitHub account, I have a build of Firefox 3.0a4 that works with Windows 98, but not 95 (os_win.c in sqlite3 if I remember the file name correctly?), and I'm sure colours don't display properly with it (bug 361154). As a confession, I believe you are in a much better position to support Windows NT4 with it than I am. Do you want me to upload my Windows 95 compatible Firefox 3.0a4 mod, and you can try your hand at Windows NT4 (preferably Windows NT 3.51) compatibility, or do you want to wait for me to get something closer to Firefox 3.0 working with Windows 95 first?
  14. Nicholas McAnespy
    @roytam1 Has a fork of Firefox 3.6.28, and it works with Windows NT4, but not on Windows 9x (silent runtime execution failure). I did get Firefox 3.0a7 to load in Windows 98, but the address and search bars are unusable. I did succeed at getting Firefox 3.0a4 working though. I think I may want to try getting Firefox 3.0a6 to work to my liking (Windows 95, and Visual C++ 5.0 SP3 support. Windows NT4 will unfortunately be unsupported by me due to silent runtime execution failures), and then gradually upgrade Gecko. I also am in the process of trying to fix picture display and scaling issues I'm having.
  15. Nicholas McAnespy
    1. I'm still using 4GB RAM (that computer is offline though, so I typically use 1-1.5 GB of it). 2. As far as development tools go, I use what allows me to support the operating systems I want, and what uses the least system resources to get the job done. That means I'll use Visual C++ 2010 or older to compile Firefox 38.8.0esr, and New Moon 27.9.6, and Visual C++ 6.0 or older with Firefox 1.5 - 3.0. I managed to compile Firefox 3.0a7, and make it execute on Windows 98, but I can't search for anything using either the address bar or the search bar. It is a Windows 98 specific problem though. Either I did not reinstate Windows 98 support correctly, or some other code broke the compatibility, and was added to the Mozilla/Gecko codebase between Firefox 3.0a4, and Firefox 3.0a7. Then after feeling discouraged, I tried @roytam1 's Firefox 3.6.28, which supports Windows NT4. Using xpcom/glue/nsINIParser.cpp (and nsINIParser.h) from RetroZilla causes Firefox 3.6.28 to fail silently on Windows 98. My present goal is to make Firefox 3.0a6 work with the Windows GFX toolkit, and Windows 95 as cleanly as possible.
  16. Nicholas McAnespy
    In your profile you advertise your OS as Windows 10. If you have access to Windows 10, what are the specs of the computer you are running it on?
  17. Nicholas McAnespy
    Roytam1's UXP browsers (Serpent 52, New Moon 28, Borealis Navigator and a few others) are currently compiled using Visual C++ 2017 (update 9 if I remember the terminology correctly).
  18. Nicholas McAnespy
    I would like my username changed to Nicholas McAnespy to reflect my real name.
  19. Nicholas McAnespy
    @roytam1 In the process of editing my duplicate posts, I accidentally quoted myself instead of editing, so I may as well just use this post to congratulate you on apparently making the rendering engine of your Firefox 38.8.0esr mod compatible with the rendering engine in Pale Moon 27.0.0. Does it still compile using Visual C++ 2010?
  20. Nicholas McAnespy
    That's a fair thing to say. I should also ask: What was so funny in your previous post on this thread?
  21. Nicholas McAnespy
    @roytam1 I think I'll need to stick to Gecko 1.8.x to ensure Windows NT4 support. I still want to see how far I can push Visual C++ 5.0 SP3 though, so I just compiled a snapshot of Mozilla/Gecko 1.9.0a1 source code from April 3rd 2006, which was the final day Firefox 3.0a1 was able to be compiled to run on Windows 9x without modifying the source code.
  22. Nicholas McAnespy
    I believe you should be allowed to have your original account reinstated, even if you really are Tobin. Also, I'm not sure who the moderators on this forum are, but I would like to have my username changed to Nicholas McAnespy to reflect my real name.
  23. Nicholas McAnespy
    Please remember to create a separate branch for your NM27 changes (Arctic-Fox commits?) just in case you add more UniquePtr references to the codebase. I should add the beauty of creating a fork is that you don't need to take all the changes the upstream developers made to their project. In my case, I'm in the process of adding code from Mozilla bug 258080 to my Gecko 1.8.0 fork.
  24. Nicholas McAnespy
    That's great news for me because if someone asks either of us for a "Windows XP" compatible web browser, you can now say "Try my custom Firefox 38.8.0esr build. INSERT LINK HERE" Also, I just tested Firefox 1.5 using Visual C++ 6.0 SP5, and got a compilation time of 1152 seconds using MOZ_MAKE_FLAGS="-j3".
  25. Nicholas McAnespy
    Tip for RetroZilla: Gecko 1.8.0b3 and later support building with MSYS, so that means Mozilla-Build will work with them. rn10950 used Mozilla-Build 1.2 to compile RetroZilla. If you want a native Windows command prompt window instead of rxvt like Mozilla-Build 1.2 uses, Mozilla-Build 1.3 is also suitable to build RetroZilla. Is it possible you are using mk_add_options MOZ_MAKE_FLAGS="-j1" simply because it's the default setting? What I notice with older Mozilla code (pre 2012) is you need a graphics adapter/card to take advantage of a powerful CPU. Wait... What version of Windows are you using to compile RetroZilla? In my experience, Windows 2000 and XP are the best choices for RetroZilla compilation.
×
×
  • Create New...