Jump to content


  • Posts

  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country


Everything posted by ClassicNick

  1. 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?
  2. @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)?
  3. 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
  4. 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?
  5. 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).
  6. 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)?
  7. 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?
  8. 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
  9. 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.
  10. @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:
  11. @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?
  12. 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.
  13. 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.
  14. @shelby Recently, I have been making progress on a Firefox 1.1a2 Visual C++ 5.0 compatible build, but still having some trouble. I managed to get XPCOM compiling and executing successfully replacing nsInterfaceHashtable, nsBaseHashtable, and nsClassHashtable references with nsHashtable references. Necko causes freezing in my build, and the NSS files cause crashing (known issue that I don't know how to resolve, because it fails in Visual C++ 6.0 without the "processor pack", and ml.exe). @roytam1 Shifting gears, I tried compiling your "gecko28a1-vc8-master" browser with Visual C++ 2008 Express SP1, Windows 7 SDK with .Net Framework 4.0, and Mozilla-Build 1.8, and I have problems with an auto generated file named "BluetoothTypes.cpp", which uses the auto C++ keyword. The directory for the file is "obj-i686-pc-mingw32/ipc/ipdl". My mozconfig file consists of ac_add_options --enable-release ac_add_options --enable-application=browser ac_add_options '--enable-optimize=-O2 -GS-' ac_add_options --enable-jemalloc ac_add_options --enable-shared-js ac_add_options --enable-devtools ac_add_options --disable-debug ac_add_options --enable-strip ac_add_options --disable-skia ac_add_options --disable-maintenance-service ac_add_options --disable-crashreporter ac_add_options --disable-updater ac_add_options --disable-tests ac_add_options --disable-mochitests ac_add_options --disable-jsd ac_add_options --disable-webapp-runtime ac_add_options --disable-webgl ac_add_options --disable-angle ac_add_options --disable-gamepad And the first 16 lines of BluetoothTypes.cpp consist of // // Automatically generated by ipdlc. // Edit at your own risk // #include "mozilla/dom/bluetooth/BluetoothTypes.h" //----------------------------------------------------------------------------- // Method definitions for the IPDL type |union BluetoothValue| // namespace mozilla { namespace dom { namespace bluetooth { auto BluetoothValue::MaybeDestroy(Type aNewType) -> bool Do you know of any way to remove usage of the auto C++ keyword so line 16 looks like bool BluetoothValue::MaybeDestroy(Type aNewType) like it does in New Moon 26.5.0 oldvc?
  15. Without cheating by copying "MSVCRT.DLL" from a Visual C++ 5.0 installation/medium while compiling with Visual C++ 6.0 (which does work), that will require Visual C++ 5.0 support for any hope of Windows NT 3.1/3.50 compatibility, which is something I want to try, but I don't know if I'll be able to add the code necessary to support Windows NT 3.1/3.5. For Windows 3.x, on 3.1x, that requires Visual C++ 4.0 (for Win32s), or 1.0 support along with a way to create a 16-bit build. For Windows 3.0, I don't even know the build tools I would need to use in order to achieve support for that. From a practical/realistic standpoint though, Windows 3.x support is impossible to achieve, with NT 3.1/3.50 being theoretically possible, but very difficult to attempt. The earliest Firefox version I can compile is 1.5, and I want to use that so I can try my hand at Visual C++ 5.0 support, but as for Windows NT 3.1/3.5 I don't think I'll be able to support that. BTW. I want to fork Firefox 3.0 for the purpose of having a Visual C++ 6.0 compatible Firefox build, then add back the Windows 95 support code, but I'm feeling discouraged right now by having my Firefox 3.0a5, and Firefox 3.0a6 builds not displaying a context menu when right-clicking on anything, which also means the menu bar doesn't work.
  16. Support for the Optional Chaining, and Nullish Coalescing operators is in UXP in theory (and in my experience does work). I don't think support exists outside of the UXP/Moebius codebase though. If you have New Moon 28.10.6a1, Serpent 55, or Serpent 52.9 (My preference would be to use a build released since mid-2022), you can use Palefill 1.25, which should allow GitHub to work again. https://github.com/martok/palefill/releases/download/v1.25/palefill-1.25.xpi
  17. I'm feeling like it's a 50/50 chance from me... One of my personal projects I have is to get Firefox 3.0 compiling on Visual C++ 6.0 using the "Windows" GFX toolkit. Because it takes a long time to modify the code in a way I feel most comfortable with, which means reverting https://bugzilla.mozilla.org/show_bug.cgi?id=177805 I've been building several Firefox 3.0 alpha and beta versions. I recently tried a modified build of Firefox 3.0a5, but it doesn't display a menu frame when clicking on the menu bar. I might try to add Windows 9x/NT 4.0 support if I can make the menu frame display since I'm on the hook for that anyway. My new topic/thread (which I will use more as I get closer to a Firefox 3.0 Visual C++ 6.0 and Windows 95/NT 4.0 compatible build) is here... My temporary GitHub repository (only used for Firefox 3.0 Visual C++ 6.0 mods) is also here... https://github.com/ClassicNick/Fx3.0a-VC6-mod
  18. This topic is specifically to discuss development of Winternight-Classic (which is an upcoming fork of the Firefox 3.0 codebase, but with support for the deprecated "Windows" GFX toolkit, Visual C++ 6.0, and Windows NT4/9x support included). The purpose of Winternight-Classic is to have a fork of Firefox that is "lightweight", but still supports semi-modern web technologies, and also still supporting Windows NT4/9x and Visual C++ 6.0.
  19. Off-topic post removed. @ClassicNick This thread is specifically about roytam1's browsers only. Please start a new thread for your own projects.
  20. Another Update: I got Firefox 3.0b4 building on Visual C++ 6.0 SP5 with the "Windows" GFX toolkit. The display/rendering bugs are the same as in Firefox 3.0b1, but with text rendering properly this time. I know I want to build Firefox 3.0b5, but I don't know what version I actually want to settle on for a new fork. Since my ability to use GitHub (especially the desktop version) is as great as my ability to use Cygwin, @roytam1 I will eventually need you to upload source code for my browser so I can fork it on the GitHub website. Between Firefox 3.0b2 (Note: Search functionality doesn't seem to work when compiled on Visual C++ 2003 using the Thebes "Cairo-Windows" GFX toolkit, but I like it for being "lightweight" in comparison to the newer versions), Firefox 3.0b5 (I'll probably switch the unit measurement definitions to help with the display issues in that version), or Firefox 3.0.19, which one do you recommend I use for a new Firefox fork? In order to keep a mental note of what I want to do, and in the order I feel it should be done, I created a task list on GitHub. https://github.com/ClassicNick/Fx3.0a-VC6-mod/issues/4
  21. Thank you for the response! I tried to compile Firefox on Visual C++ 5.0 so I could see where the compilation errors are, and I struggle greatly with "xpcom/ds/nsHashPropertyBag.h" and "xpcom/ds/nsHashPropertyBag.cpp". Compiling them as is results in an unresolved external. Trying to use "xpcom/ds/nsHashtable.h", instead of "xpcom/glue/nsInterfaceHashtable.h" results in many errors relating to a conversion error from "class nsHashKey *" to "const class nsAString_internal *" if I remember correctly. Firefox 1.0 and earlier do not have those files, and Mozilla 1.4.4 relies very heavily (exclusively?) on "xpcom/ds/nsHashtable.h", so XPCOM sources will build with very little trouble on Visual C++ 5.0. Surprisingly enough, PDP switches in Makefiles in Firefox do not cause build errors even on Visual C++ 5.0. If you could tell me how to use an object directory in Mozilla 1.4.4 and Firefox 1.0? (similar to "mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-fx95-release in RetroZilla), that would be lovely.
  22. Update 2: I decided to try building Firefox 1.0, and Mozilla 1.4.4, and Phoenix 0.5/Classilla 9.3.3, and I'm still struggling to make it out of the config/mkdepend directory. For reference, I'm building in the source tree using Visual C++ 5.0, Cygwin easy 2007-03-21 https://github.com/whitone/cygwin-easy/releases/tag/2007.03.21
  23. Update 1: I got Firefox 3.0b1 building on Visual C++ 6.0 SP5 using the Windows GFX toolkit, but since I didn't revert the unit measurement definitions in "gfx/public/nsIDeviceContext.h", the menu bar takes up the entire browser window. https://github.com/ClassicNick/Fx3.0a-VC6-mod/releases/tag/Fx3.0b1-Buggy-VC6-Mod
  24. Would doing a "plain" Firefox 28.0/K-Meleon 74.0, or a New Moon 26.5.0 build on Visual C++ 2008 change the CPU requirements due to enforcing MMX/SSE support?

  • Create New...