Jump to content

ClassicNick

Member
  • Posts

    129
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Canada

Everything posted by ClassicNick

  1. @roytam1 Now I have the perfect excuse to request you upload a copy of Firefox 1.5.0.12 (Mozilla 1.8.0.12) source code. Personally I prefer Firefox 1.5 over 2.0 because it is more lightweight, and it should ironically be easier to fork than 2.0. I still want Gecko 1.9.x building with Visual C++ 6.0 SP5 (really Visual C++ 5.0 SP3), but this is a great start. I tried using Visual C++ 5.0 SP3 on my RetroZilla fork, but it crashes while trying to display pictures. https://codeberg.org/Nicholas_McAnespy/FxVC5Mods
  2. I just relied on the comment from Mozilla in xpcom/base/nscore.h. After some further testing, I found out Visual C++ 5.0 SP3 does not produce internal compiler errors because it doesn't support HAVE_CPP_ACCESS_CHANGING_USING, but because it can't use an undefined T (my non expert observation). Mozilla's default definition of T for compilers it allows HAVE_CPP_ACCESS_CHANGING_USING on (every compiler that isn't Visual C++ 5.0) is located in xpcom/base/nsISupportsBase.h. What I did was gave problematic files (there were 2) access to nsISupportsUtils.h, which includes nsISupportsImpl.h, and nsISupportsBase.h. Doing that allowed me to produce a working build of Mozilla 1.6 using Visual C++ 5.0 SP3 (I did use ac_add_options --disable-crypto though).
  3. @roytam1 On May 1st if I remember correctly, I asked you if you could build Classilla or Mozilla 1.2 using Visual C++ 5.0 SP3 so you can try reproducing hanging and/or crashing on startup. I did a build of Mozilla 1.6 using Visual C++ 6.0 SP5, but undefined HAVE_CPP_ACCESS_CHANGING_USING, and I discovered that was causing hanging on startup. Trying to use HAVE_CPP_ACCESS_CHANGING_USING on Visual C++ 5.0 SP3 comes with the side effect of producing internal compiler errors... The first of which is while trying to compile netwerk/base/src/nsInputStreamChannel.cpp.
  4. I'm okay with that for now, although I'm also sitting on a local build of Firefox 38.8.0esr that works on Visual C++ 2010, but is much more reliable than New Moon 27.9.6-20190223. Stable as far as I remember might be a stretch to say, but it does work. Officially, Firefox 35.0.1 is the last one that works properly, although with changing delete operators to MOZ_DELETE, 37.0.2 will work, but without unified sources.
  5. - return ( - (FStar_UInt128_uint128){ - .low = a.low + b.low, - .high = a.high + b.high + FStar_UInt128_carry(a.low + b.low, b.low) }); + FStar_UInt128_uint128 c; + c.low = a.low + b.low; + c.high = a.high + b.high + FStar_UInt128_carry(a.low + b.low, b.low); + return c; What may need to be done in this example is change return c to return c.low, c.high.
  6. If you get any crashes in freebl, security/nss/lib/freebl/verified/FStar.c is probably the reason why.
  7. @roytam1 I should admit the reason why I want an Arctic-Fox fork to work with Windows 2000 is because your builds work with Windows XP SP2 and later. That means users will request a browser that works on "Windows XP". Since I don't like the idea of restricting service pack compatibility, if someone wants a browser that works on Windows XP, and they get it from me, they'll get something that works on the original version of Windows XP. Since Windows 2000 and XP require the same versions of Visual C++ to be used (2008 or earlier), I just as well try Windows 2000 support too. If for some reason you are no longer able to publish your browser builds, it would be nice to offer this community something newer than a fork of Pale Moon 26.5.0. Also, Firefox 31+ and Arctic Fox is much faster at compilation than Pale/New Moon 26.5.0, and UXP browsers (for now).
  8. The first thing I thought of when I read CMOVcc was i686 compatible, lacking that will probably mean i586 CPU support, and if I need an OS target for an i586 CPU, I'll go for Windows 95...
  9. As I understand it, CMOVcc is a conditional move instruction set supported on Pentium MMX and newer CPUs with some exceptions. Why do you not want CMOVcc? I don't personally care either way, so I'm just curious why you don't want it.
  10. To go from Visual C++ 2010 to 2008 compatibility, UniquePtr references need to be changed or removed. Auto as a type specifier needs to be replaced, along with move/forwarding semantics. Then support will need to be added for the Windows Vista and Server 2008 SDKs, which I expect will result in some code being deleted.
  11. Another goal of mine is to fork Arctic-Fox, and make it Visual C++ 2005/2008, and Windows 2000 compatible. Presently, Arctic-Fox requires Visual C++ 2013, and Windows XP SP2. There exists a Pale Moon 27.x fork by @roytam1 that includes Arctic-Fox commits, that is in the process of becoming Visual C++ 2010/2012 compatible by roytam1 and I.
  12. I used VC 2012 at that time. However, your post came at a great time because I just built it using VC 2010, but using the Windows 8.1 SDK. Next up... Removing UniquePtr references, and move semantics from xpcom/glue/nsCOMPtr.h. In October 2023, I failed to make UniquePtr.h compile cleanly using VC++ 2008, so I think it will be easier to just do away with it completely.
  13. @roytam1 I just finished the New Moon 27.9.6 build... The browser loads and seems to work, but I can't test if it can handle encrypted websites (I messed around a lot in the security directory). I also disabled webgl because I didn't want to solve the 18 "unresolved externals" I got while trying to link LibGLESv2.dll.
  14. Do you have any way to stay cool? Edit: Do you mean your internal body temperature is 37 Celsius at all times? So the air temperature is appropriate for you to regulate your body temperature?
  15. Unless the outside temperature is not within the range of -20 Celsius, and +10 Celsius, I'm a happy guy. On the other hand, in the interest of not getting banned, I shouldn't say how I really feel about the temperature @NotHereToPlayGames is subjected to. @roytam1 It fails early on in the compilation, so you can try it yourself if you get any free time (it certainly wouldn't work with Visual C++ 2010, so I'll just do what I've been doing so far). Also, my HP Pavilion g6 2218nr now has broken hinges, and something else causing nothing except a bright black screen to be displayed instead of normal OS booting. I'm presently using an HP Compaq DC5850 that is not connected to the internet. That means even if I make NSS 3.41 work with Visual C++ 2012 or earlier, I can't test that it actually connects to encrypted websites.
  16. Off topic: 2 degrees Celsius where I live in Nova Scotia. Partially on topic: @roytam1 In the past, you have said getting TLS 1.3 support working in older versions of Visual C++ will be difficult due to C keywords/types being used that do not work in older Visual C++ versions (forgive me I still don't know much about C/C++). I'm presently half way to making a New Moon 27.9.6 2019-02-23 source code snapshot compile using Visual C++ 2012. Should I be worried about tough to solve errors when I reach the security directory? Also, I replaced the modules/zlib directory with the one from PM27-pm27_eol because I couldn't figure out how to remove use of the align keyword without causing runtime execution failure.
  17. If you use the January 27th build, does the "Alt+CharCode text input" work? Do you have an example (web page presumably) that I can use to test it myself?
  18. 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.
  19. 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.
  20. 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.
  21. 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".
  22. 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.
  23. 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.
×
×
  • Create New...