Jump to content

ClassicNick

Member
 View Profile  See their activity

  • Posts

    95

  • Joined

  • Last visited

  • Donations

    0.00 USD 

  • Country

    Canada

 Content Type 

Everything posted by ClassicNick

  1. ClassicNick
    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).
  2. ClassicNick
    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)?
  3. ClassicNick
    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?
  4. ClassicNick
    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
  5. ClassicNick
    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.
  6. ClassicNick
    @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:
  7. ClassicNick
    No, not presently...
  8. ClassicNick
    @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?
  9. ClassicNick
    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.
  10. ClassicNick
    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.
  11. ClassicNick
    @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?
  12. ClassicNick
    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.
  13. ClassicNick
    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
  14. ClassicNick
    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
  15. ClassicNick
    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.
  16. ClassicNick
    Off-topic post removed. @ClassicNick This thread is specifically about roytam1's browsers only. Please start a new thread for your own projects.
  17. ClassicNick
    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
  18. ClassicNick
    Thank you for the response! I tried to compile Firefox 1.5.0.12 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 1.5.0.12 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.
  19. ClassicNick
    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
  20. ClassicNick
    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
  21. ClassicNick
    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?
  22. ClassicNick
    I love that you're having success building Firefox 27 and 28 on Visual C++ 2005, and that you are able to target Windows 2000/XP with them.
  23. ClassicNick
    That's nice to know, although I still need to know how to upload a repository in GitHub...
  24. ClassicNick
    Update: I built Firefox 3.0a6 on the "Windows" GFX toolkit, and I now managed to give it the opposite problem I had with my Firefox 3.0a3 build. The text in the Address bar and Menu bar is ~1 pixel, signaling a possible TwipsToPixels conversion error. My plan is to build Firefox 3.0b3 or later, and then fix the bugs. @roytam1 I will probably need your NSS 3.21.4 TLS 1.2 patches soon, and I was wondering what version of Firefox 3.0 you would want to apply your NSS patches to. Firefox 3.0b3, 3.0, or 3.0.19? https://github.com/ClassicNick/Fx3.0a-VC6-mod/releases/tag/Fx3.0a6-Buggy-VC6-Mod
  25. ClassicNick
    @roytam1 I noticed on GitHub you have a repository named "gecko27-vc8". Did you have any success building it yet?


×
×
  • Create New...