the x64 version of fossil available for Windows is reporting itself as a 32-bit executable.

That's not what I see:

  % file ~/Downloads/fossil.exe 
  .../fossil.exe: PE32+ executable (console) x86-64, for MS Windows

If you know a way to build the executable to make things clearer to Windows than that, it'd be your itch to scratch.

I think the simplest solution is to change the Manifest file "fossil.exe.manifest" in the "win" subdirectory to leave the processor architecture open:

<assemblyIdentity version="1.0.0.0" processorArchitecture="*" name="fossil" type="win32" />

This should solve the issue, can you test that?

OP here. thanks for the hint. I will play around with the manifest file in that directory. The dependent assembly is what is actually tripping up the executable from running, but both the assemblyIdentity and the dependent assembly will probably have to be updated. See below for the sxstrace parsed output.

=================
Begin Activation Context Generation.
Input Parameter:
	Flags = 0
	ProcessorArchitecture = AMD64
	CultureFallBacks = en-US;en
	ManifestPath = C:\Program Files\fossil-dscm\fossil.exe
	AssemblyDirectory = C:\Program Files\fossil-dscm\
	Application Config File = 
-----------------
INFO: Parsing Manifest File C:\Program Files\fossil-dscm\fossil.exe.
	INFO: Manifest Definition Identity is fossil,processorArchitecture="X86",type="win32",version="1.0.0.0".
	INFO: Reference: Microsoft.Windows.Common-Controls,language="*",processorArchitecture="X86",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0"
INFO: Resolving reference Microsoft.Windows.Common-Controls,language="*",processorArchitecture="X86",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0".
	INFO: Resolving reference for ProcessorArchitecture X86.
		INFO: Resolving reference for culture en-US.
			INFO: Applying Binding Policy.
				INFO: No publisher policy found.
				INFO: No binding policy redirect found.
			INFO: Begin assembly probing.
				INFO: Did not find the assembly in WinSxS.
				INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0_en-US_6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL.
				INFO: Did not find manifest for culture en-US.
			INFO: End assembly probing.
		INFO: Resolving reference for culture en.
			INFO: Applying Binding Policy.
				INFO: No publisher policy found.
				INFO: No binding policy redirect found.
			INFO: Begin assembly probing.
				INFO: Did not find the assembly in WinSxS.
				INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0_en_6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL.
				INFO: Did not find manifest for culture en.
			INFO: End assembly probing.
		INFO: Resolving reference for culture Neutral.
			INFO: Applying Binding Policy.
				INFO: No publisher policy found.
				INFO: No binding policy redirect found.
			INFO: Begin assembly probing.
				INFO: Did not find the assembly in WinSxS.
				INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.Windows.Common-Controls\6.0.0.0__6595b64144ccf1df\Microsoft.Windows.Common-Controls.DLL.
				INFO: Attempt to probe manifest at C:\Program Files\fossil-dscm\Microsoft.Windows.Common-Controls.DLL.
				INFO: Attempt to probe manifest at C:\Program Files\fossil-dscm\Microsoft.Windows.Common-Controls.MANIFEST.
				INFO: Attempt to probe manifest at C:\Program Files\fossil-dscm\Microsoft.Windows.Common-Controls\Microsoft.Windows.Common-Controls.DLL.
				INFO: Attempt to probe manifest at C:\Program Files\fossil-dscm\Microsoft.Windows.Common-Controls\Microsoft.Windows.Common-Controls.MANIFEST.
				INFO: Did not find manifest for culture Neutral.
			INFO: End assembly probing.
	ERROR: Cannot resolve reference Microsoft.Windows.Common-Controls,language="*",processorArchitecture="X86",publicKeyToken="6595b64144ccf1df",type="win32",version="6.0.0.0".
ERROR: Activation Context generation failed.
End Activation Context Generation.

You are right, there is another problem in the manifest file. The dependency for the Microsoft Common Controls library is in my opinion not required. The following lines should also be removed from the manifest file:

  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
                        version="6.0.0.0" processorArchitecture="X86"
                        publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentAssembly>
  </dependency>

Yes, I think it's not required -- but it should also work with processorArchitecture set to *:

  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
                        version="6.0.0.0" processorArchitecture="*"
                        publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentAssembly>
  </dependency>

That should work also -- but Fossil is a command line program and as far as I know, makes no use of the Common-Control library. So why should we create a dependency on them ?

Disclaimer: I'm no expert about this Windows manifest files.

That should work also -- but Fossil is a command line program and as far as I know, makes no use of the Common-Control library. So why should we create a dependency on them ?

A valid point. Fossil already loads a lot of stuff that is not needed for console applications -- mostly due to OpenSSL! But the "comctl32.dll" module is not loaded, whether or not the corresponding <dependentAssembly> entry is in place (just checked with the WinDbg lm command).

The manifest entry just defines which version to load if needed, for example if OpenSSL would display a GUI error message with the MessageBox() function, or similar.

So just patching all processorArchitecture entries to "*" is simpler -- but of course removing the entry would also work, but with the effect that OpenSSL message boxes would have an "older look". Doesn't matter.

BTW no idea why OpenSSL pulls in all that GUI stuff from "user32.dll" -- despite the no-ui configuration option I'm using for my builds.

I have been wondering for a long time why OpenSSL adds so much code to the Fossil binary. But experimentig with OpenSSL is quiet tedious due to the long build time.

You have convinced me. If you do not object, I will put a manifest file with the processorArchitecture patched into a separate branch.

On my system, OpenSSL build time drops by 10 minutes with the trick posted here.

This is handy for experimentation -- however, OpenSSL always forces a full rebuild if configuration options are changed, and this still takes a few minutes.

There's a new tool to analyze Windows PE binaries, and they're also using it to reduce the footprint of the OS itself. It's on my mental low-priority list of interesting things to examine to find out why OpenSSL requires so much space, and in particular the +500 KB leap from version 1.1.1x to version 3x.

My guess is that they're including lookup tables with precomputed certificate fingerprints for the most popular websites in version 3x, so they can take shortcuts when establishing connections ;-) What speaks a bit against this theory is that 500 KB is either way too much or way too little for the most popular websites -- depending whether or not adult websites are included :-(

No objections from me. But I'm already using a patched version, pasted below. It also restores Windows Vista compatibility, and fixes XML namespace declarations.

==== win32-manifest.patch ======================================================

Status.......: ACTIVE
Baseline.....: *
Cherry-pick..:
Required.....:

Simplifications to the application manifest resource:

Use placeholder values for the "processorArchitecture" attributes.

Remove redundant XML namespace selectors, and wrap the settings to disable UAC
virtualization in a more backwards-compatible namespace.

Resources:
[https://docs.microsoft.com/en-us/windows/desktop/sbscs/application-manifests]
[https://msdn.microsoft.com/en-us/library/bb756929.aspx]
[https://blogs.technet.microsoft.com/mrsnrub/2010/08/11/uac-virtualization-allowing-standard-users-to-update-a-system-protected-area/]

Comment on the /MANIFEST linker option:

Disable Win32 application manifest generation and post-processing for MSVC
builds, as fossil.exe.manifest is hand-crafted, and embedded in fossil.exe via
resource script fossil.rc. (The /MANIFEST linker option is only required if
/MANIFESTDEPENDENCY is also present, either in the makefile or by #pragma
directive in Fossil or its libraries SQLite, zlib, or OpenSSL. The use of
/MANIFEST has crept in with MSVC 8.0/2005 and MSVC 9.0/2008, to generate the
dependencies for Microsoft.VCxx.CRT, but is not otherwise required with
hand-made application manifests.) The use of /MANIFEST explains the origin of
the obscure changes reverted by [8be521a2e7].

Comment on the application manifest changes:

Modifications to the Win32 application manifest resource: Use generic
placeholder values for the "processorArchitecture" attributes (valid for any 32-
or 64-bit platforms), and simplify the XML document structure by replacing
namespace-qualified element names with a local default namespace declaration and
unqualified element names. (This is also how the application manifests of
Windows-indigenous executables look like, apart from CR+LF line endings.)

Index: win/fossil.exe.manifest
==================================================================
--- win/fossil.exe.manifest
+++ win/fossil.exe.manifest
@@ -1,14 +1,13 @@
 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
-<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"
-          xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
-  <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="fossil"
+<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
+  <assemblyIdentity version="1.0.0.0" processorArchitecture="*" name="fossil"
                     type="win32" />
   <description>
     Simple, high-reliability, distributed software configuration management system.
   </description>
-  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
+  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
     <security>
       <requestedPrivileges>
         <requestedExecutionLevel level="asInvoker" uiAccess="false" />
       </requestedPrivileges>
     </security>
@@ -25,19 +24,19 @@
       <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
       <!-- Windows Vista -->
       <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
     </application>
   </compatibility>
-  <asmv3:application>
-    <asmv3:windowsSettings
+  <application xmlns="urn:schemas-microsoft-com:asm.v3">
+    <windowsSettings
            xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
       <dpiAware>true</dpiAware>
-    </asmv3:windowsSettings>
-  </asmv3:application>
+    </windowsSettings>
+  </application>
   <dependency>
     <dependentAssembly>
       <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
-                        version="6.0.0.0" processorArchitecture="X86"
+                        version="6.0.0.0" processorArchitecture="*"
                         publicKeyToken="6595b64144ccf1df" language="*" />
     </dependentAssembly>
   </dependency>
 </assembly>

==== Excerpt from wdkbuild-0.patch =============================================

Index: win/Makefile.msc
==================================================================
--- win/Makefile.msc
+++ win/Makefile.msc
@@ -179,11 +179,11 @@

 CFLAGS    = $(CFLAGS) /D_CRT_SECURE_NO_DEPRECATE /D_CRT_SECURE_NO_WARNINGS
 CFLAGS    = $(CFLAGS) /D_CRT_NONSTDC_NO_DEPRECATE /D_CRT_NONSTDC_NO_WARNINGS

 !if $(FOSSIL_DYNAMIC_BUILD)!=0
-LDFLAGS   = $(LDFLAGS) /MANIFEST
+LDFLAGS   = $(LDFLAGS) /MANIFEST:NO
 !else
 LDFLAGS   = $(LDFLAGS) /NODEFAULTLIB:msvcrt /MANIFEST:NO
 !endif

 !if $(FOSSIL_ENABLE_WINXP)!=0
@@ -242,11 +242,11 @@
 !endif

 BCC       = $(CC) $(CFLAGS)
 TCC       = $(CC) /c $(CFLAGS) $(MSCDEF) $(INCL)
 RCC       = $(RC) /D_WIN32 /D_MSC_VER $(MSCDEF) $(INCL)
-MTC       = mt
+MTC       = rem mt
 LIBS      = ws2_32.lib advapi32.lib dnsapi.lib
 LIBDIR    =

 !if $(FOSSIL_DYNAMIC_BUILD)!=0
 TCC       = $(TCC) /DFOSSIL_DYNAMIC_BUILD=1

Thanks for the pointer to the OpenSSL build trick.

The SizeBench tool is interesting if you work with the Microsoft tools. I use most of the time MSYS2/MinGW64 for development on Windows.

What I want to try to reduce the size of OpenSSL is on one hand link time optimization (LTO) and on the other hand the use of separate function and data sections. This should enable the linker to only pull in the stuff that is really needed.

When doing this with MSVC (compiling with /GL and linking with /LTCG), the executable file size is either increased by 16% (from 6.37 MB to 7.44 MB with /O2) or reduced by 1% (from 5.52 MB to 5.48 MB with /O1 /Os) for Fossil [1bf6686e76] and OpenSSL 3.0.2. So it looks like the /O* compiler switches already have most impact -- if passed through to OpenSSL!

Also, my (naive) understanding of "sections" (whether PE image sections, or otherwise) is that "more (separate) sections" means more constraints regarding alignment and extra padding, and possibly more bloat.

Regarding SizeBench: this is quite a beast and requires additional runtime libraries, even on a fresh and up-to-date Windows 11 machine. Otherwise, it's well done, but it's also my impression that a lot of things can already be queried with the CLI tools dumpbin.exe and dbh.exe (the dbghelp shell to walk PDB files, shipped with WinDbg), as well as WinDbg itself -- but SizeBench has a nice graphical display with a better overall view, of course. But as you probably already noticed SizeBench relies on PDB files, and so indeed is unlikely to be useful with GCC (not sure about Clang, which is now shipped and installed by default with Visual Studio).

I compiled Fossil and OpenSSL one time with LTO (-flto) and one time with separate sections (-Wl,--gc-sections -ffunction-sections -fdata-sections) with gcc 11.2 on Windows 7. The results are a little bit frustrating. The space savings where in both cases only a few kilobytes and the link time increased significantly :-(

The growth in size of OpenSSL seems to remain a mystery...

One of my (currently not very active) projects is based on the Scintilla source code editing component. They had to play tricks to make sure the linker would not discard any of the "lexer modules". As fas as I remember, this was due to the Scintilla library interfacing with the host program through the OS's "window messages" API, instead of through direct function calls, so the linker could not trace the calls and would instead see large parts of the library as unreferenced code, and omit it from the final executable.

For OpenSSL 3.0, some refactoring from "engines" to "providers" has happened under the hood, with a more open plugin architecture. Maybe they're using some technique similar to that linked above to make sure no "seemingly unreferenced code" (that is, called via multiple detours through the plugin interface, for example) is discarded? But that's just speculation from my part.

Anyway, I found that /O1 (without the redundant /Os) already helps a lot -- but the flag has to be explicitly passed through to the OpenSSL build process. At least for MSVC, this is not as obvious as it seems, and has to be achieved with the OpenSSL configuration script, see the msvc-openssl-winxp branch. There's no need for the OpenSSL code in my CLI executable to be "super fast", when network operations only run infrequently.

A correction to my post 15:

Clang, which is now shipped and installed by default with Visual Studio

That's incorrect, I was fooled by some *asan* libraries installed by default. It's still necessary to explicitly select Clang in the Visual Studio setup tool.

If you do not object, I will put a manifest file with the processorArchitecture patched into a separate branch.

Although we don't yet have formal confirmation by the original reporter that the proposed fix does indeed work, I've decided to commit it, anyway, so it will be in the next release. The same technique has worked reliably on 32-bit-only systems for years, and is widely used.

While fiddling around, I found that the Windows Setup Environment is a 64-bit only environment, so I was able (by opening the Shift+F10 command prompt during setup) to reproduce the bug and also verify the fix!

Off topic:

During fiddling, I've just discovered Ventoy, a free and open-source tool to install a small boot partition on a USB stick, to boot directly from ISO images copied to the USB stick. No more need to wipe all data off the USB stick when updating, just add/remove/replace ISO images as needed, with other data on the drive untouched.

• https://www.ventoy.net/
• https://github.com/ventoy/Ventoy