Jump to content

Nicholas McAnespy

Member
  • Posts

    197
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    Canada

Everything posted by Nicholas McAnespy

  1. As far as I know, Firefox 10 and later run very slowly on Windows 98SE/Me with KernelEx. Do you have a computer with a newer version of Windows to test it on? I think Windows XP SP2 will work with that Firefox 38.8.0esr custom build. @roytam1 Are you using unified C++ sources, or deunified C++ sources.
  2. Fixed that one, but there are still 39 unresolved externals I have no clue how to fix.
  3. nsprpub from RetroZilla is incompatible is incompatible with Mozilla/Gecko 1.8.0, so I just pulled the code manually. I also needed to add various NSS files to security/manager/ssl/src. Presently, I have 40 unresolved externals, one of which is NS_ConsumeStream(nsIInputStream *aSource, PRUint32 aMaxCount, nsACString &a buffer); in xpcom/io, and is referenced by security/manager/SSL/src/nsStreamCipher.cpp.
  4. Since I cannot guarantee the source code compiles properly, I should ask, does it work for you?
  5. https://codeberg.org/Nicholas_McAnespy/FxVC10Mods/releases
  6. Thank you for doing that! I replaced the NSS files from my local Firefox 1.5 build, with your uploaded NSS files, and to my surprise, they did not cause the browser to crash due to me using a different version of Visual C++ than you did. I'm still trying to port NSS 3.42 beta to the Mozilla/Gecko 1.8.0 codebase. When I asked you how difficult it would be, it was because I got an error "plarena.h no such file or directory". Now I'm cherry picking code from RetroZilla's nsprpub directory to solve unresolved externals caused by NSS 3.42 beta. I also noticed you mentioned K-Meleon 0.8 - 1.1. What is your favourite version of K-Meleon?
  7. Nice job getting Classilla 9.3.4 and Phoenix 0.5 working with TLS 1.3 and Windows 95. How difficult would it be to port NSS 3.21.4 and/or NSS 3.42 beta to the Mozilla/Gecko 1.8.0 codebase?
  8. If you are using Visual C++ 6.0 or later, I don't know what could be causing the problem because I can't build Classilla due to reliance on Cygwin. I can't make Classilla compile using either Cygwin or MSYS.
  9. I can't test this presently because my capable (Windows) computers are offline. I can only imagine how amusing it must feel to have TLS 1.3 working with a browser capable of targeting Windows NT 3.51 and 95, and Visual C++ 6.0 SP5. Since I can't build K-Meleon, is it possible to use the RetroZilla codebase to build K-Meleon 1.5.4?
  10. This will derail the thread, but my Dell Inspiron 600M has a broken EIDE adapter, so I can't boot from an internal hard drive. I can theoretically boot from a USB storage device, but the only success I've had with that is configuring a flash drive to work as a bootable startup disk, and installing Windows 95. The problem with that is none of the hardware drivers work with Windows 95, the oldest OS it will work with is Windows 98 (possibly 98 SE). The default operating systems were Windows 2000 or XP. The computer could also run Windows Vista or 7, but I rather not try to do that. For my use case, the best operating system to use is Windows 2000, with XP being a close 2nd. My task presently is getting either Windows 2000 or XP booting from a USB storage device.
  11. And I tried to port Firefox 3.0.19 to Visual C++ 5.0 SP3 with the Windows Server 2003 R2 SDK, and failed because of browser/app/Makefile.in using wmain, which as is, Visual C++ 5.0 SP3 sees as an unresolved external. I also couldn't figure out how to make Visual C++ 5.0 SP3 accept Mozilla's places implementation, so I tried to use Mozilla's browser/bookmarks, and history code without success because it broke most browser functionality, such as typing URLs. More recently, I'm starting to try porting Mozilla bug 317375 to RetroZilla.
  12. 1. @roytam1 I took your fork of the mozilla-cvs-history-subtree repository from Github, and uploaded it to Codeberg, and tried to revert bug 177805 (Fix the use of units in Gecko. Gecko 1.9.0a3 February 7th 2007), but it won't let me due to unresolved conflicts, and server time outs. If you can forcefully revert that bug automatically in GitHub, and preferably 359808 too (Drop support for Windows 9x/NT 4 in xpcom/io if I remember the bug number correctly, also needed for Visual C++ 5.0 SP3 compatibility), that will be great. 2. The crashing I mentioned does not happen due to Visual C++ 5.0 SP3, but because of earlier changes I made in the content directory.
  13. @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
  14. 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).
  15. @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.
  16. 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.
  17. - 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.
  18. If you get any crashes in freebl, security/nss/lib/freebl/verified/FStar.c is probably the reason why.
  19. @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).
  20. 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...
  21. 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.
  22. 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.
  23. 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.
×
×
  • Create New...