Jump to content

Nicholas McAnespy

Member
 View Profile  See their activity

  • Posts

    191

  • Joined

  • Last visited

  • Donations

    0.00 USD 

  • Country

    Canada

 Content Type 

Everything posted by Nicholas McAnespy

  1. Nicholas McAnespy
    If you ever manage to build your preferred browser using a Raspberry Pi 5, remember to use the "ac_add_options --disable-debug-symbols" configure flag in your mozconfig file. I'm finally able to build NM27/Arctic-Fox from mid 2020 on wards, and UXP browsers due to that flag (although NM26 and UXP builds are slow, NM27 is almost tolerable), and I don't seem to have a problem with Visual C++ 2012 and later using too much RAM either. @roytam1 In my testing, all browsers starting with NM26 take ~400-500 MB RAM to link libxul. I would like to know what libxul RAM usage is in your testing (preferably with NM27/ArcticFox) with ac_add_options --disable-debug-symbols. As a bonus, compilation times should be reduced.
  2. Nicholas McAnespy
    Update: After trying a snapshot of Mozilla's source code from May 10th 2007, and still having context menus fail to display, I decided to batch revert code from Firefox 3.0a4, and found out my problem is in the DOM directory (I haven't narrowed it down yet though). Also, I got my custom Firefox 3.0a4 build to work with Windows 95 (replaced db/sqlite3/src/os_win.c with an older version from July 24th 2006), but still no Windows NT 4.0 support yet.
  3. Nicholas McAnespy
    I love this comment because if I have learned anything during the time I have been trying to make Firefox 3.0 compile targeting the Windows GFX toolkit, Visual C++ 6.0, and now, Windows 95, it is that alpha software is typically stable enough for use, and sometimes, works better than the official "stable" release. Due to that, I/we shouldn't mind running software just because it is "alpha" or "beta". Your second point is going to repeat like a broken record, because I work with source code as old as I do because that is all my hardware is compatible with. I did try compiling official UXP on Linux Mint 19.3 in ~September 2020, but it took 6 hours with 2 CPU cores enabled, and 2x that time with 1 CPU core enabled. I can compile roytam1's fork of Pale Moon 26.5.0 in ~3-4 hours with 2 CPU cores enabled, and 6-7 hours with 1 CPU core enabled, along with ~1.2 GiB RAM usage. With 1 CPU core enabled, I can compile RetroZilla in less than 1 hour, while using ~100 MiB RAM with Visual C++ 6.0 SP5. The Mozilla 1.9.0 codebase does not seem to have increased build times than the Mozilla 1.8.1 codebase, although 1.9.1 and 1.9.2 do come with ~15% increased build times, along with ~150-300 MiB RAM usage on Visual C++ 2003, which uses 40% more RAM than Visual C++ 6.0.
  4. Nicholas McAnespy
    I was able to load the site without that error message by setting general.useragent.override.twitter.com to "Mozilla/5.0 (%OS_SLICE% rv:115.0) Gecko/20100101 Firefox/115.0". You can try a different numerical value in the rv: and Firefox section if that is desired. Note: you can reach that setting by typing about:config into the address bar, and searching for general.useragent.override.twitter.com. Also note: I'm not a twitter user, so my testing goes as far as loading the main Twitter page. EDIT: I seem to have a global useragent override set to Firefox 102.0. You should also be able to use "Mozilla/5.0 (%OS_SLICE% rv:102.0) Gecko/20100101 Firefox/102.0".
  5. Nicholas McAnespy
    Locally, I have an unofficial build of Firefox 3.0a1 from June 22 2006 (bug 330276 reverted) working on Windows 95 (my favourite version of Windows preceding 2000), and a build from October 5 2006 that does not work in Windows 95. It fails with an error stating "This program has performed an illegal operation and will be shut down". Apparently Firefox causes an error in kernel32.dll. Between those 2 dates, Mozilla introduced problematic JavaScript code that breaks Windows 95 compatibility in the browser directory (nsSearchService.js, and nsSafeBrowsingApplication.js) in Firefox 2.0. I'm not sure if that is the only thing causing incompatibility with Windows 95 in 3.0a1 though. @roytam1 I can use the Windows Server 2003 R2 SDK if I add the directory paths to "start-l10n.bat". That means I can use the Thebes GFX toolkit using Visual C++ 6.0 SP5, however, it breaks Windows 9x and possibly NT4 support. I haven't tested whether usp10.h and usp10.lib in the October 1999 SDK will work with the Thebes GFX toolkit though (needed for Visual C++ 5.0 and Windows NT 3.1/3.50 support). 2 options are on the table: 1. Create a GetGlyphIndices stub that works in Firefox 3.0a5 and later, or 2. Use the Windows GFX toolkit with Windows 95 and NT4 support ready to go.
  6. Nicholas McAnespy
    I found out that the last version of the Windows SDK that works in Visual C++ 5.0 is the October 1999 SDK. I can get Mozilla-Build working with both Visual C++ 5.0 and the October 1999 SDK, which does alleviate some compatibility issues throughout the codebase. I also learned I can remove the "friend class nsTHashtable<nsBaseHashtableET<KeyClass, DataType> >;" line and related code, which will get around the "6 unresolved externals" error when linking xpcom.dll. Doing this works in Visual C++ 6.0, but does have some minor issues. In Visual C++ 5.0 however, it compiles, but does not display a Window in Windows XP, only a broken title bar. In older versions of Windows (tested on 95), Firefox produces an illegal operation error. So I'm in a position where I can compile a build successfully, but runtime execution will fail. I do not presently know what is causing the problem. I do have similar problems with newer versions of Firefox than 1.1a2 or 1.5.
  7. Nicholas McAnespy
    So far I got Firefox 3.0a4 working on Windows 98 SE, but not 95 or NT 3.51 or 4.0: https://github.com/ClassicNick/Fx3.0a-VC6-mod/releases/tag/Fx3.0a4-Win98
  8. Nicholas McAnespy
    Is it possible to cherry pick commits using the web browser version of GitHub? Partially OT: Test: The Arctic-Fox developer has used Mozilla code changes that switch pointer references (namely nsAutoPtr references) into UniquePtr references. I couldn't get UniquePtr to work in Visual C++ 2008, so want to know if it is possible to revert those commits? I finally found the "Squash and Merge" function on GitHub, which means a lot to me because when I add support for Visual C++ 2008 in "KM75-gecko31-engine", Visual C++ 2010 support in "Arctic-Fox-fix-winbuild", and "palemoon27-classic" it would be easy to add just a couple of files per commit, which could mean in range of 100 commits. There have been many times I have wanted to upload incremental changes to GitHub, but was too scared to because I don't want hundreds of commits when I can have a few dozen larger commits. It would get some use if my dev machine was online... Also, I do not believe I'm leaving GitHub!
  9. Nicholas McAnespy
    That might be enough to fix my problem. 2AM UTC November 3rd is approximately when my 7 day grace period would have expired. With your tip, My GitHub account now sees 2FA as being enabled.
  10. Nicholas McAnespy
    That is the reason why I'm leaving GitHub. I assume that when my 7 day grace period expires, I won't be able to sign in and use GitHub without 2FA?
  11. Nicholas McAnespy
    @roytam1 Presently, I'm trying to compile New Moon 27.9.7 (palemoon27-classic in our GitHub repositories) using Visual C++ 2010 and Windows XP SP3. configure.in in the root "topsrc" directory has WINVER set to 502. In the js/src directory, WINVER is set to 600. Do you know if that version is still able to target Windows XP SP2? Confession: My goal is to make Arctic-Fox target Windows 2000 and XP using Visual C++ 2008 SP1, but I will still use Visual C++ 2010 to save on RAM (~1.3 GiB to link libxul in Firefox 38.8.0esr using Visual C++ 2010).
  12. Nicholas McAnespy
    Correction: roytam1 uses the Visual C++ 2017 toolchain. The last version of Firefox that was able to officially compile on Visual C++ 2010 was 36.0.4, however, I have only managed to compile up to Firefox 35.0.1 on Windows XP SP3. BTW, I have a local build of Firefox 30.0 that I compiled using Visual C++ 2008 SP1, although I did use the --disable-ion configure flag due to a crash in mozjs.dll, which removes jit support. My eventual goal is to get New Moon 27.9.4+ and Arctic-Fox 42.0 targeting Windows 2000 and XP RTM/SP1. In my testing on Windows XP, I get an error stating the program cannot start because the application configuration is incorrect. Apparently Visual C++ 2008 can target Windows 2000, but restricts Windows XP compatibility to SP2. @roytam1 Do I need to use Visual C++ 2005 SP1 for Windows XP and XP SP1 support?
  13. Nicholas McAnespy
    @feodor2 How high does RAM usage usually go when building Mypal 68.13? How much does it consume (linking libxul is traditionally when RAM usage was at its highest)?
  14. Nicholas McAnespy
    Skipping building the ICU files used to be possible until Firefox 48 or 49 by using the "--without-intl-api" configure flag. As a result of the relevant Mozilla bug report below, Mozilla decided to remove the --without-intl-api configure flag, meaning the ICU files must build and be present in the objdir/dist/bin directory in order for the browser to launch. OT: I'm trying to build Firefox 30 using Visual C++ 2008, and I do use the --without-intl-api flag in my mozconfig file. I haven't tested if that means intl.* functions will not work. https://bugzilla.mozilla.org/show_bug.cgi?id=1301882
  15. Nicholas McAnespy
    FYI: The UXP browser builds (New Moon tested) compiled with Visual C++ 2017 still supports Windows XP SP2. @roytam1 Now that you're building UXP applications using Visual C++ 2017 (version 15.9?), will they still compile with Visual C++ 2015 update 2 if JPEG-XL is disabled?
  16. Nicholas McAnespy
    That's why on browsers that allow me to build with both static and shared linking options, I like to do local shared builds, but public static builds. RetroZilla takes ~126 MiB RAM using Windows XP SP3 and Visual C++ 6.0 SP5 to build rzbrowser.exe with static libraries, but only ~83 MiB RAM to link gklayout.dll with shared libraries. Using Visual C++ 2003 bumped the RAM usage of rzbrowser.exe from ~126 MiB to ~178 MiB, but I don't believe I tested that compiler with shared libraries (~117 MiB would be my guess if I did). Building shared libraries of RetroZilla Browser will result in a bin directory size of ~20.5 MiB excluding MSVCRT.DLL. Building static libraries results in a bin directory size of ~18.5 MiB (I don't remember the exact bin size because I more commonly do shared builds instead of static builds, not to mention the differing build configurations I often use that will sway the bin directory size slightly).
  17. Nicholas McAnespy
    Update: I managed to do a modified Firefox 3.0b4, and Firefox 3.0b5 build, but the most notable problem with the builds is the absence of EnsureDeviceContext() in nsDocShell.cpp which is responsible for setting the font size for the menu bar to ~128 pixels. Also, most of the text in the context menus have font sizes ~1-2 pixels in size, which is too small to read, and at the moment, I'm unsure of how to remedy that problem. My Firefox 3.0b4 Visual C++ 6.0 mod: My Firefox 3.0b5 Visual C++ 6.0 mod: My last successful build of Firefox 3.0 was 3.0a4, so I think I want to revert more of the code in suspicious directories (layout/* ?) to what existed in Firefox 3.0a4. @roytam1 I assume you know about comparing changes between files using diff file readers. Can you recommend some diff file viewers that are compatible with Windows 2000 and/or XP (specifically one with support for viewing multiple files)?
  18. Nicholas McAnespy
    If building "shared" libraries comes with the effect of them being split out of xul.dll, resulting in a smaller file size, does RAM usage while linking xul.dll decrease? If so, by how much?
  19. Nicholas McAnespy
    If you read the change logs between roytam1's UXP commit history, and Moonchild/upstream's UXP commit history, you will be able to draw the conclusion that the 2 UXP code bases are nearly identical. Following upstream UXP development, you will know that the defining features of Goanna 6.0 were the implementation of Regular Expression named capture groups, Regular Expression unicode property escapes, and Regular Expression lookaround/lookbehind, and the defining features of Goanna 6.1 were additions to the Shadow DOM v1 implementation (see issue "#2135"), along with a bug fix to make Custom Elements v1 work properly, which allowed "dom.webcomponents.enabled" to be set to "true" by default (see about:config). Also see pages 55, and 61 of this thread to view my favourite change logs of the UXP browser builds and search for issue #1361 on page 55, and #2135 on page 61. https://www.palemoon.org/releasenotes.shtml https://repo.palemoon.org/MoonchildProductions/UXP/commits/branch/master https://github.com/roytam1/UXP/tree/custom https://github.com/roytam1/UXP/blob/custom/config/milestone.txt https://repo.palemoon.org/MoonchildProductions/UXP/src/branch/master/config/milestone.txt
  20. Nicholas McAnespy
    roytam1's UXP browsers already run the Goanna 6.1 rendering engine. I say that because roytam1's UXP repository has most of the additions from upstream with the exception of JPEG-XL support due to roytam1 remaining on Visual C++ 2015 update 3 (thank you @roytam1). The reason why the browsers still report milestone (Goanna) 4.8 is "config/milestone.txt" has not been updated.
  21. Nicholas McAnespy
    @roytam1 Is it possible to display the "privacy" bar in K-Meleon 74/Goanna 2.2 on Windows XP (especially SP3)? I noticed on my Windows XP SP3 installation that it is not possible to display the "privacy" bar, but it is on Windows 2000. Copying macros.dll, privacy.dll, and toolbar.dll from the kplugins directory in K-Meleon 74/Gecko 24 to the kplugins directory in K-Meleon 74/Goanna 2.2 allows the "privacy" bar to display on Windows XP, but not on Windows 2000. K-Meleon 74/Goanna 2.2 on Windows XP: K-Meleon 74/Goanna 2.2 on Windows 2000: Is it possible to fix that issue? K-Meleon 74/Goanna 2.2 with the 3 mentioned kplugins on Windows XP:
  22. Nicholas McAnespy
    No, not presently...
  23. Nicholas McAnespy
    @roytam1Do you think it would be possible to build K-Meleon 75.1 with the Gecko 24 or Goanna 2.2 rendering engines, or does it have to use Gecko 31?
  24. Nicholas McAnespy
    The reason why I'm getting a dependency on the "auto" C++ keyword is because BluetoothTypes.cpp is generated by "ipc/ipdl/ipdl/cxx/cgen.py", and there is code that states to write the auto keyword in place of other more appropriate keywords/declarations/operators if compiled on an MSVC version greater than 8. Since Visual C++ 2008 is major version 9 and doesn't support the "auto" C++ keyword, msvcver > 8 needs to be bumped to msvcver > 9. if md.ret: if md.only_for_definition and msvcver > 9: self.write('auto ') else: md.ret.accept(self) self.println() self.printdent() if md.typeop is not None: self.write('operator ') md.typeop.accept(self) else: self.write(md.name) I have opened a pull request on your GitHub "gecko28a1-vc8-master" repository to bump the msvcver version in cgen.py, and lower.py to > 9.
  25. Nicholas McAnespy
    I think there is a problem with compiler detection in the source code so that the automatically generated BluetoothTypes.cpp (I don't know how it gets generated, or what files cause its creation) uses the auto C++ keyword when compiled on Visual C++ 2008 (VC9, and it errors out because of it), but does not use the auto keyword when compiled with Visual C++ 2005, which causes the file to compile successfully.
×
×
  • Create New...