Jump to content

Winternight-Classic development

ClassicNick
 Share

Recommended Posts

ClassicNick

ClassicNick

Posted
Posted

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.

1
Link to comment
Share on other sites

  • 3 months later...
ClassicNick

ClassicNick

Posted
  • Author
Posted

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:

604500139_2023-03-3102_09_57.jpg.8b6f18eedbc3008352065f78948f3638.jpg

My Firefox 3.0b5 Visual C++ 6.0 mod:

2136501714_2023-03-3102_11_56.jpg.9b17cf99b765c10665f27558b1c88d83.jpg

 

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)?

1
Link to comment
Share on other sites
roytam1

roytam1

Posted
Posted (edited)
On 3/31/2023 at 3:23 PM, ClassicNick said:

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:

604500139_2023-03-3102_09_57.jpg.8b6f18eedbc3008352065f78948f3638.jpg

My Firefox 3.0b5 Visual C++ 6.0 mod:

2136501714_2023-03-3102_11_56.jpg.9b17cf99b765c10665f27558b1c88d83.jpg

 

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)?

WinMerge

 

and by the way there is way too much changes between every firefox3 alpha/beta versions, it is better to check CVS changes for details: https://github.com/roytam1/mozilla-cvs-history-subtree

Edited by roytam1
1
Link to comment
Share on other sites
  • 8 months later...
  • 2 weeks later...
ClassicNick

ClassicNick

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
  • 1 month later...
ClassicNick

ClassicNick

Posted
  • Author
Posted

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.

Link to comment
Share on other sites
  • 3 months later...
ClassicNick

ClassicNick

Posted
  • Author
Posted

@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.

Link to comment
Share on other sites
ClassicNick

ClassicNick

Posted
  • Author
Posted
2 hours ago, ClassicNick said:

@roytam1

 

 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.

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). 

Link to comment
Share on other sites
ClassicNick

ClassicNick

Posted
  • Author
Posted
20 minutes ago, ClassicNick said:

Fx1.5VC5Screenshot.jpg.617859a8213558d7c1e8b6a53d10162a.jpg

@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

Link to comment
Share on other sites
ClassicNick

ClassicNick

Posted
  • Author
Posted (edited)
On 5/5/2024 at 2:37 PM, ClassicNick said:

@roytam1 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

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.

Edited by ClassicNick
Link to comment
Share on other sites
roytam1

roytam1

Posted
Posted
23 hours ago, ClassicNick said:

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.

I think you may need to revert and fixups manually.

and for me, codeberg is a very slow (if case of network speed) site so I can't do anything with it.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...