unclecaptain5426 changed the title [-]Firefox fork for XP[/-] [+]Firefox fork for XP SP3[/+] on Dec 15, 2025

the-r3dacted

on Dec 15, 2025

I actually didn't know this happened, amazing. Something that surprised me is the presence of wow_helper.exe in the 32 bit release, which I think means 32 bit sandbox, and sandbox in general, working on Vista and maybe even XP? Firefox uses the Chromium sandbox, and that has been a bit of a sticking point for Vista. Vista doesn't really work past sandbox level 7, this fork defaults to 7, r3dfox defaults to 8 (and I'll probably set it up to 9 for 147), but I make it fall back to functionally being the same as sandbox level 7 on Vista so it still works there. Mypal68 completely disables the sandbox for it's XP compatibility.

So I wonder if it would be possible to get this fixed and have 32 bit sandboxing working on Vista.
#83

For major XP support, I think first would be to try to get a similar build system to Mypal68? Patch Rust to work on XP, or perhaps even try using Rust9x as is. Then main compiler maybe LLVM, but idk how it would go. Mypal68 is built with LLVM 9 I think? Modern Firefox might have a lot of C code that could be too new for old LLVM. Might need custom compiler idk. Idk what compiler is used to get Chromium to run on XP. I didn't see any funny dll redirection either, so it looks like full on native support. Maybe that could work?

Something semi-related would be I want to try getting Lun3r to run on Windows 2000, but I'd need to either downgrade to VS 2008 or so (probably impossible) or mingw64, but I have no idea how to get mingw64 to work or if the modern version can target w2k. I barely have the build system working as is.

e3kskoy7wqk

on Dec 15, 2025

Owner

The sandbox of Chromium for windows 7 runs correctly on Windows XP. I believe that if Firefox uses the Chromium sandbox, it is entirely possible to make the sandbox work on 32-bit Vista as well.

Chromium for windows 7 is built using VS2019 and Windows SDK 22621, and it requires defining _USING_V110_SDK71_ in build/config/win/BUILD.gn. Newer versions of Visual Studio and Windows SDK introduce APIs that are unsupported on Windows XP (such as FlsAlloc). While these issues could be resolved using techniques like DLL redirection (as in Supermium), I currently prefer not to adopt such an approach.

Regarding the compilation toolchain, I have not modified the default LLVM and Rust versions used by Chromium. Only some Rust code in third_party/rust-toolchain has been altered, and the modifications follow the same approach as my Firefox fork.

Additionally, to support Windows XP, a particularly challenging issue must be addressed: the Thread-Local Storage (TLS) problem. In short, if a DLL is dynamically loaded by an executable, TLS will not be initialized for that DLL on Windows XP. To resolve this, I intercept LdrLoadDll and manually initialize TLS after it returns. Although this approach is not perfect, since TLS used in DllMain cannot be initialized, it is sufficient to resolve most TLS issues on Windows XP and allows chrome.exe to start successfully. For details, please refer to my implementation: https://github.com/e3kskoy7wqk/Chromium-for-windows-7-REWORK/blob/main/chromium-140.0.7339.264/da667f7e960637d2531cf0306fbc2137633e1773.diff

As for porting Firefox to Windows XP, I believe it is technically entirely feasible. However, since I am not familiar with HTML, CSS, and JavaScript, and I do not know how to build older versions of Firefox, the challenges of porting Firefox to Windows XP might be significantly greater than those encountered with Chromium.

the-r3dacted

on Dec 15, 2025

The sandbox of Chromium for windows 7 runs correctly on Windows XP. I believe that if Firefox uses the Chromium sandbox, it is entirely possible to make the sandbox work on 32-bit Vista as well.

Chromium for windows 7 is built using VS2019 and Windows SDK 22621, and it requires defining USING_V110_SDK71 in build/config/win/BUILD.gn. Newer versions of Visual Studio and Windows SDK introduce APIs that are unsupported on Windows XP (such as FlsAlloc). While these issues could be resolved using techniques like DLL redirection (as in Supermium), I currently prefer not to adopt such an approach.

Makes me wonder if FWDK could be used to build modern Firefox lol. Not sure how to make it interface with the modern build system, but this is how I make it work with Mozillabuild 3.2 to build Lun3r.

32 bit

@ECHO OFF SET MOZ_MSVCBITS=32 SET MOZ_MSVCVERSION=14 SET MOZ_MSVCYEAR=2017 SET VCDIR=C:\DEV\MSVC14\ SET TOOLCHAIN=32-bit SET MOZILLABUILD=%~dp0 SET MOZ_TOOLS=%MOZILLABUILD%moztools SET VSINSTALLDIR=C:\DEV\MSVC14 SET VCINSTALLDIR=C:\DEV\MSVC14 SET FrameworkDir32=C:\Windows\Microsoft.NET\Framework\ SET FrameworkVersion32=v4.0.30319 SET Framework40Version=v4.0.30319 SET UCRTVersion=10.0.19041.0 SET WindowsSDKLibVersion=10.0.19041.0\ SET INCLUDE=C:\Dev\MSVC14\include;C:\Dev\MSVC14\atlmfc\include;C:\Dev\Windows Kits\10\include\shared;C:\Dev\Windows Kits\10\include\10.0.19041.0\um;C:\Dev\Windows Kits\10\include\10.0.19041.0\winrt;C:\Dev\Windows Kits\10\include\10.0.19041.0\ucrt; SET LIB=C:\Dev\MSVC14\lib\x86;C:\Dev\MSVC14\atlmfc\lib\x86;C:\Dev\Windows Kits\10\lib\10.0.19041.0\um\x86;C:\Dev\Windows Kits\10\lib\10.0.19041.0\ucrt\x86; SET LIBPATH=C:\Dev\MSVC14\lib\x86;C:\Dev\MSVC14\atlmfc\lib\x86;C:\Dev\Windows Kits\10\lib\10.0.19041.0\ucrt\x86; SET PATH=C:\Dev\MSVC14\bin\Hostx64\x86;C:\Dev\MSVC14\bin\Hostx64\x64;C:\Dev\Windows Kits\10\bin\10.0.19041.0\x86;%PATH% SET SDKDIR=C:\Dev\Windows Kits\10\ SET WINDOWSSDKDIR=C:\Dev\Windows Kits\10\ set "UCRTContentRoot=%WDKContentRoot%" set "UniversalCRTSdkDir=%WDKContentRoot%" START %MOZILLABUILD%msys\bin\mintty -e %MOZILLABUILD%msys\bin\console %MOZILLABUILD%msys\bin\bash --login

64 bit

@ECHO OFF SET MOZ_MSVCBITS=64 SET MOZ_MSVCVERSION=14 SET MOZ_MSVCYEAR=2017 SET VCDIR=C:\DEV\MSVC14\ SET TOOLCHAIN=64-bit SET MOZILLABUILD=%~dp0 SET MOZ_TOOLS=%MOZILLABUILD%moztools SET VSINSTALLDIR=C:\DEV\MSVC14 SET VCINSTALLDIR=C:\DEV\MSVC14 SET FrameworkDir32=C:\Windows\Microsoft.NET\Framework\ SET FrameworkVersion32=v4.0.30319 SET Framework40Version=v4.0.30319 SET UCRTVersion=10.0.19041.0 SET WindowsSDKLibVersion=10.0.19041.0\ SET INCLUDE=C:\Dev\MSVC14\include;C:\Dev\MSVC14\atlmfc\include;C:\Dev\Windows Kits\10\include\shared;C:\Dev\Windows Kits\10\include\10.0.19041.0\um;C:\Dev\Windows Kits\10\include\10.0.19041.0\winrt;C:\Dev\Windows Kits\10\include\10.0.19041.0\ucrt; SET LIB=C:\Dev\MSVC14\lib\x64;C:\Dev\MSVC14\atlmfc\lib\x64;C:\Dev\Windows Kits\10\lib\10.0.19041.0\um\x64;C:\Dev\Windows Kits\10\lib\10.0.19041.0\ucrt\x64; SET LIBPATH=C:\Dev\MSVC14\lib\x64;C:\Dev\MSVC14\atlmfc\lib\x64;C:\Dev\Windows Kits\10\lib\10.0.19041.0\ucrt\x64; SET PATH=C:\Dev\MSVC14\bin\Hostx64\x64;C:\Dev\MSVC14\bin\Hostx64\x64;C:\Dev\Windows Kits\10\bin\10.0.19041.0\x64;%PATH% SET SDKDIR=C:\Dev\Windows Kits\10\ SET WINDOWSSDKDIR=C:\Dev\Windows Kits\10\ set "UCRTContentRoot=%WDKContentRoot%" set "UniversalCRTSdkDir=%WDKContentRoot%" START %MOZILLABUILD%msys\bin\mintty -e %MOZILLABUILD%msys\bin\console %MOZILLABUILD%msys\bin\bash --login

and in mozconfig

# x86 build ac_add_options --host=i686-pc-mingw32 ac_add_options --target=i686-pc-mingw32 WIN32_REDIST_DIR=$VCINSTALLDIR/Redist/MSVC/14.16.27012/x86 WIN_UCRT_REDIST_DIR=$WINDOWSSDKDIR/Redist/10.0.19041.0/ucrt/DLLs/r86

# x64 build ac_add_options --host=x86_64-pc-mingw32 ac_add_options --target=x86_64-pc-mingw32 WIN32_REDIST_DIR=$VCINSTALLDIR/Redist/MSVC/14.16.27012/x64 WIN_UCRT_REDIST_DIR=$WINDOWSSDKDIR/Redist/10.0.19041.0/ucrt/DLLs/r64

Not sure where mingw32 comes from, I don't have it installed afaik, but it works.

As for porting Firefox to Windows XP, I believe it is technically entirely feasible. However, since I am not familiar with HTML, CSS, and JavaScript, and I do not know how to build older versions of Firefox, the challenges of porting Firefox to Windows XP might be significantly greater than those encountered with Chromium.

I don't know that you really need to know HTML, CSS, or Javascript. I don't really know how to code like at all yet I have been able to make r3dfox. It's mostly just C and Rust that needs to be figured out.

the-r3dacted

on Jan 19

In the event we try XP, this might be an issue.
Eclipse-Community/r3dfox@7e570d8

I don't think a XP compatible version of msvcp140_atomic_wait.dll exists.

Although we would probably need to downgrade compiler anyways so idk if real issue. For r3dfox though I guess I'll switch it to use Vista compatible VC++ dlls instead of the older XP compatible set I've used so far.

unclecaptain5426

on Feb 25

Author

What about it is also possible to backport it to Vista RTM along with r3dfox?
(Edit: Since I tested this firefox fork and r3dfox on Vista build 5840.16384 by having the kernel function changed from GetTimeZoneInformationForYear to GetTimeZoneInformation and using files from KB971644 (such as dwrite.dll and others) and launched to get it to work but crashed after seconds a while ago)

e3kskoy7wqk

on Feb 25

Owner

@unclecaptain5426

What about it is also possible to backport it to Vista RTM along with r3dfox?

Perhaps it will be feasible in the future, but I prefer not to do it for now. The call to GetTimeZoneInformationForYear is located in third_party/rust/chrono/src/offset/local/windows.rs, and so far, I have not found an elegant way to eliminate this call (apologies, I'm still new to Rust).

Since I tested this firefox fork and r3dfox on Vista build 5840.16384 by having the kernel function changed from GetTimeZoneInformationForYear to GetTimeZoneInformation and using files from KB971644 (such as dwrite.dll and others) and launched to get it to work but crashed after seconds a while ago

I'm not sure what method you used for this modification. As far as I know, GetTimeZoneInformationForYear and GetTimeZoneInformation differ in both the size and number of parameters they accept. This means that after redirecting from GetTimeZoneInformationForYear to GetTimeZoneInformation, you must ensure stack balance is properly maintained (for example, by replacing some push ... instructions with nop). Otherwise, the program will inevitably crash.

e3kskoy7wqk

on Feb 25

Owner

@the-r3dacted Sir, I'm afraid I won't be able to reach XP after all. At this point, I'm even struggling to maintain compatibility with Windows 7.

This isn't the first time I've encountered such a situation this year (2026).

the-r3dacted

on Mar 1

@the-r3dacted Sir, I'm afraid I won't be able to reach XP after all. At this point, I'm even struggling to maintain compatibility with Windows 7.

I feel like XP support would require a different compiler, and I'm not sure how we will do that. This though is in my opinion a minor cosmetic issue, which actually wouldn't occur on XP as far as I know.

This was an issue I had left to sit in the r3dfox issues because I didn't have the time or will or to be honest any idea how to fix. So the caption buttons being covered by theme was just an issue until you fixed it in your fork. I wouldn't sweat something like this too hard.

It might be easier to figure out why WebRender has the bug where caption button masks don't work with hardware acceleration, and fix it. Or somehow bring back layers and use that since that would also fix DWrite dependency and allow the browser to work on Vista RTM.

e3kskoy7wqk

on Mar 2

Owner

I'm not sure, but it seems increasingly difficult to maintain the Windows 7 UI elements (such as the transparent title bar, native menus, etc.). If that really is the case, I will abandon these Windows 7 UI features and stop reverting UI related commits.

This is what the title bar looks like when default system - auto light theme is enabled, it is expected to be transparent:

unclecaptain5426

on Mar 2

Author

I think bring back layers and fix the DWrite dependency and allow the browser to work on Vista RTM

ZepopaOwleMukasa

on Mar 2

@e3kskoy7wqk

Probably better to just leave the UI alone at this point, barring any actual functional issues with it. It seems way to much of a hassle and is really not all that important in the grand scheme of things. If it simplifies and frees up development time for more important issues than thats definitely prefereable.

the-r3dacted

on Mar 3

I'm not sure, but it seems increasingly difficult to maintain the Windows 7 UI elements (such as the transparent title bar, native menus, etc.). If that really is the case, I will abandon these Windows 7 UI features and stop reverting UI related commits.

I mean in normal use with stock light or dark if it works then I consider it good enough. I did not bother fixing the default system or custom themes before your fork. The UI elements are very important, and if it's just issues with an inherently flawed theming system I don't mind if they're kinda broken.

the-r3dacted

on Mar 29

Another case for replacing WebRender with the old layers compositor.

Something about the r3dfox logo svg lags the shit out of WebRender while classic layers handles it completely fine.

unclecaptain5426

2 days ago

Author

I wish the nightly browser could run on Windows XP SP3 without one core API.

Same, and also Windows XP before Service Pack 2 with kernelxp.dll wrappers by roytam1 and Windows 2000 DLL wrappers by Eazy Black.

SleakaJ commented 18 hours ago

SleakaJ

18 hours ago

I wonder how difficult it is to port the latest firefox browser to 32-bit Windows XP SP3.

So far, nobody has been able to do it. It's difficult.

The author of Supermium announced his Firefox port called Superfox a couple of years ago, but he never got it to successfully run on XP. He ended up abandoning it last year.

e3kskoy7wqk

yesterday

Owner

So far, nobody has been able to do it. It's difficult.

Although I have not yet tried to port Firefox to Windows XP, just thinking about it makes it clear how difficult the task is. I started quietly working on porting Chromium to Windows XP in May of last year, and the work was not finally completed until January of this year. My original goal in porting Chromium to Windows XP was to let an old Windows XP computer in my home, one that my father bought when he was young and that has been in our house for at least 20 years, run a modern browser. However, in the end I did not achieve the intended result, because the browser runs far too slowly. You can see the computer's specifications and a video of the browser running at https://www.bilibili.com/video/BV1Vyf4B5E4X. I think modern browsers and modern web pages are simply too large for hardware that is decades old. I do not believe Firefox could perform significantly better than Chromium on my computer running Windows XP, so I have decided not to port Firefox to Windows XP, as the effort would not be proportional to the reward. However, if anyone is interested in porting Firefox to Windows XP, I can help them.