Hello

I want to know whether Fossil Version 2.18 [44f4d624f1 ] 2021-12-29 not support WinXP OS any more?

When use below error comes- Fossil.exe is not a valid win32 application

I am able to run Fossil Version 2.17 [1e5dc324ef ] 2021-09-13 win the same WinXP OS machine.

I want to use latest version 2.18.0.0 to overcome the issue of *** time skew *** as version 2.17.0.0 not support command "--ignore-clock-skew"

Fossil.exe is not a valid win32 application

Are you perhaps trying to run a 64-bit executable on a 32-bit machine?

No,Its 32-bit I run

I also, tried 64-bit and result same message like 32-bit

Fossil 2.18 can be built to run on Windows XP, but it looks like the current snapshot version available for download doesn't.

To build Fossil with MSVC for Windows XP, the variable definition "FOSSIL_ENABLE_WINXP=1" needs to be passed to NMAKE. To do this with Fossil's own "win/buildmsvc.bat" script, the environment variable "USE_V110SDK71A=1" can be set before calling the script, for example.

This step mostly ensures the OS and subsystem versions written to the PE (exe) file header allow the program to run on Windows XP -- Fossil itself doesn't rely on any functionality not available in Windows XP.

To make things work with OpenSSL, the "_WIN32_WINNT=0x501" definition has to be passed to the C compiler, so OpenSSL won't rely on functionality missing in Windows XP, such as SRW locks, or linkage to BCRYPT.DLL. The OpenSSL configuration script is somewhat annoying in this regard, as it doesn't allow certain combinations of CFLAGS and LDFLAGS, and passing the variables on-the-fly doesn't work because the OpenSSL makefile is heavily recursive and discards the entire build environment right from the start. But adding "/D_WIN32_WINNT=0x501" to SSLCONFIG in "win/Makefile.msc" might work, if no additional linker flags are specifed.

Thanks Can I get the new build file for download which Enable for WinXP.

It's drh who maintains the downloads available on the Fossil website, and I'm not sure if he has the resources to provide Windows XP compatible versions.

If you apply something similar to the following (quick and probably not too clever) patch:

Index: win/Makefile.msc
==================================================================
--- win/Makefile.msc
+++ win/Makefile.msc
@@ -144,10 +144,13 @@
 !else
 SSLCONFIG = $(SSLCONFIG) no-shared
 !endif
 !endif
 !endif
+!if $(FOSSIL_ENABLE_WINXP)!=0
+SSLCONFIG = $(SSLCONFIG) "/D_WIN32_WINNT=0x501"
+!endif

 !if $(FOSSIL_ENABLE_TCL)!=0
 TCLDIR    = $(B)\compat\tcl-8.6
 TCLSRCDIR = $(TCLDIR)
 TCLINCDIR = $(TCLSRCDIR)\generic

And then run the following command from the win subdirectory in the Fossil source tree (with the MSVC build environment initialized):

nmake /nologo /f Makefile.msc FOSSIL_DYNAMIC_BUILD=0 FOSSIL_ENABLE_WINXP=1 FOSSIL_BUILD_SSL=1 FOSSIL_ENABLE_SSL=1 SSLDIR=..\compat\openssl-3.0.1

You get the latest version of Fossil to run on Windows XP. Just verified with:

• Fossil [f8681a9c06]
• OpenSSL 3.0.1
• MSVC 19.30.30706
• Windows SDK 10.0.22000.0

(Sorry for the delayed answer, building OpenSSL on my laptop takes ages ...)

(Edit: mentioned the Windows SDK version.)

Please try the just-uploaded Win32 snapshot build on the Download page.

I am not able to reproduce your problem. I dug a circa-2008 laptop out of the closet and powered it up. It has Win7, and it works fine with the prior build. Nevertheless, I added the /D_WIN32_WINNT=0x501 option to the OpenSSL build (as suggested by Florian) for Win32 and rebuilt everything. The new builds work fine on all my systems. But I have no way of knowing if they work on a WinXP system.

I still own an old notebook (always offline from internet) with Windows XP on it.

When trying to run this newest 32 bit version on it in a CMD shell then I get the response that

fossil.exe is not a valid Win32 application in a popup box and in the shell is logged access rejected.

Unfortunately the same as the OP experienced - it does not work. But now let's wait also for the feedback from the OP.

The shell header says Windows XP [Version 5.1.2600] and it is from about 2006 to 2011.

I experience the same issue

I own another old notebook with Windows XP and I tried 3 different exe versions on it. The shell window starts also with [Version 5.1.2600]

version 2.17 [f48180f2ff] 2021-10-09 14:43:10 UTC is running well

the other two are failing with the same error as just posted. (translated into english language the shell log should be "access denied".)

These other two versions are:

version 2.18 [44f4d624f1] 2021-12-29 16:02:38 UTC

and the newest one:

version 2.18 [a36cddb453] 2022-01-05 13:09:53 UTC

But the newest one is running very well in shell [Windows 10.0.19042.1415]. I can confirm that my 3 files were all windows-32 images.

I hope this feedback helps a little bit

I also have same experience with these 3 version

Hello Richard

Thanks for your support. But Unfortunately, It still not works in WinXP environment with same popup along with access denied message in cmd shell.

I think the steps in the "Windows 32-bit using MSVC" section of the "Release Build How-To" wiki page don't pass the "FOSSIL_ENABLE_WINXP=1" option to Makefile.msc.

This option ensures the operating system version and subsystem version fields in the PE (exe) header (as output by link /dump /headers or dumpbin /headers) are set to 5.01, the highest number allowed for Windows XP x86-32.

"Modern" MSVC build tools (i.e. for Windows Vista an later) set these version numbers to 6.0 by default, so the Windows XP 32-bit image loader refuses to load them, even if all dependencies could be resolved.

Also, the CRT DLLs (vcruntime*.dll and ucrtbase.dll) of the most recent MSVC build tools don't work on Windows XP any more, that's why "FOSSIL_DYNAMIC_BUILD=0" may also be necessary, to statically link the minimal and backwards-compatible subset of the CRT used by Fossil. (Just noticed this defaults to "FOSSIL_DYNAMIC_BUILD=0", anyway.)

So changing the line:

nmake /f Makefile.msc FOSSIL_ENABLE_SSL=1 OPTIMIZATIONS=4 clean fossil.exe

To:

nmake /f Makefile.msc FOSSIL_ENABLE_SSL=1 FOSSIL_ENABLE_WINXP=1 FOSSIL_DYNAMIC_BUILD=0 OPTIMIZATIONS=4 clean fossil.exe

Should work to produce binaries that run on Windows XP.

(This may break one day with the most recent MSVC Windows 11 build tools, when the CRT starts using functions not available in Windows XP, but we may be able to import the minimal set of CRT functions used by Fossil directly from ntdll.dll, then. Run link /dump /exports "%WINDIR%\System32\ntdll.dll" and be amazed, because this DLL is loaded into every single NT process, for any subsystem. ☺)

---

Attaching my summary about OpenSSL configuration (for Windows), in case somebody wants or needs to deal with it. The recordings date from 2021-07-04 and apply to OpenSSL versions 1.1.1k and 3.0.0-beta1, but are still valid for OpenSSL versions 1.1.1m and 3.0.1.

1. OpenSSL configuration script:

   1. Accepts individual compiler flags, and appends them to the defaults (good).
   2. Accepts individual linker flags, and appends them to the defaults, but without removing the -L prefix, so can't be used with the MSVC linker (bad).
   3. Accepts entire CFLAGS="..." and LDFLAGS="..." command-line variables containing multiple compiler and linker flags, but they overwrite the defaults instead of being appended (bad).
   4. Accepts entire CFLAGS and LDFLAGS environment variables containing multiple compiler and linker flags, but they overwrite the defaults instead of being appended (bad).
   5. Disallows combinations of methods 1+2 with 3, i.e. no longer accepts individual compiler and linker flags as soon as an entire CFLAGS or LDFLAGS variable is passed (bad).

2. OpenSSL makefile:

   1. Discards additional make variables specified on the command-line, because they're not forwarded to recursive make invocations (bad).
   2. Discards environment variables intended to override make variables, because the -e option is omitted for recursive make invocations (bad).

So the only reasonable thing is to use option 1.1 for compiler flags, combined with option 1.4 for linker flags, with the restriction that the OpenSSL default linker flags are overridden.

That's probably why I've come across so many jokes that OpenSSL has to be configured using sed or awk while reading about the topic.

BTW, to save you some time with the rebuild with the added "FOSSIL_ENABLE_WINXP=1" option, you can just take the current Windows 32-bit snapshot build (that you already compiled with "/D_WIN32_WINNT=0x501") and run the following command:

link /EDIT /OSVERSION:5.01 /SUBSYSTEM:CONSOLE,5.01

The modified fossil.exe works on Windows XP, zip, reupload, done.

Edit: Correcting a silly copy-paste error. The command-line should be:

link /EDIT /OSVERSION:5.01 /SUBSYSTEM:CONSOLE,5.01 fossil.exe

I uploaded a new snapshot build for Win32. Please try it out on a WinXP system and let me know whether or not it works.

I just downloaded 5 min ago the 32 bit Windows version from following public available download place: Snapshot as of 2022-01-05 (history graph) (subsequent changes) but what I get is only the same file from yesterday (2022-01-05), which did not work as described above.

Where do you provide the new snapshot for download to us?

The new fossil-w32-20220105.zip file overwrote the old. Perhaps you ran into a stale-cache problem?

Thanks for that hint.

After trying again with another browser -and an empty cache- all looked very similar but now fossil.exe is running again on Windows XP, same two old notebooks as I used yesterday.

>fossil.exe version
>This is fossil version 2.18 [a36cddb453] 2022-01-05 13:09:53 UTC

Thank you very much to all who helped to solve this issue.

Now let's see if my experience will also the the one from the OP.

Yes, It works in my case too..

Hello Richard,

Thanks for your quick support and updates. It works now in WinXP system.

Thanks

Distilled the comments from this thread into a branch to fix Windows XP builds with OpenSSL using MSVC.

I'd like to test this with a few more MSVC versions over the next days before merging.

Could this cause problems for someone? Or does anyone see a more robust solution, and would like to take over the branch?

Also note that the steps in the Release Build How-To are not affected by this branch, I've just made a minor edit to use the canonical form for /D_WIN32_WINNT=0x0501, the way is was already used in the MSVC makefile, to simplify searching across the project.

And I need to figure out how to preserve the trailing backslashes when back-porting to tools/makemake.tcl, maybe using \x5C?