This is an automated email from the ASF dual-hosted git repository.

leginee pushed a commit to branch win10-msvc-trunk
in repository https://gitbox.apache.org/repos/asf/openoffice.git

commit d9f8ab406186ab8b1b160390b8c2ca9230144f1c
Author: Peter Kovacs <[email protected]>
AuthorDate: Tue Aug 25 18:55:39 2026 +0200

    scp2: do not ship the 32 bit gdiplus.dll in a 64 bit install
    
    external/gdiplus/gdiplus.dll is 32 bit, and scp2 copied it into every 
Windows install
    set under a bare #ifdef WNT.  A 64 bit office therefore carried 1.7 MB it 
could not
    have loaded even if it wanted to.
    
    It never wanted to.  GDI+ has been a side-by-side assembly since XP SP1
    (Microsoft.Windows.GdiPlus), and SxS resolution runs ahead of the ordinary 
DLL search
    path, so the private copy beside soffice.bin is never the one that gets 
used.
    Confirmed on a running 64 bit office, which resolves it to
    
        C:\WINDOWS\WinSxS\amd64_microsoft.windows.gdiplus_6595b64144ccf1df_
            1.1.26100.9168_none_...\gdiplus.dll
    
    That is also why nobody noticed the architecture was wrong: under ordinary 
search
    order a 32 bit DLL sitting in the application directory would have stopped
    soffice.bin from starting on the first run.
    
    Worth noting the contrast with the file picker bug fixed in 56e9585c8c.  
Both
    dependencies resolve through WinSxS.  Common-Controls was named in the 
application
    manifest with processorArchitecture hardcoded to x86, so SxS dutifully 
handed a 32
    bit COMCTL32 to a 64 bit process and fps.dll failed to load.  GDI+ is not 
named
    anywhere, so SxS defaults to the process architecture and gets it right.  
Not pinning
    it turned out to be the safer choice.
    
    The 32 bit build keeps the file.  The same argument says it is equally 
unused there,
    but that is the shipping configuration and removing it -- along with the
    configure.ac check that demands it -- is a separate decision.
    
    Verified by deleting both file_library_ooo.par and rebuilding scp2 for each:
    
        x64  gdiplus entries: 0
        x86  gdiplus entries: 1
    
    Co-Authored-By: Claude Opus 5 <[email protected]>
    Claude-Session: https://claude.ai/code/session_01VrM7EMKgiuyVcCUe9nSbZR
---
 main/scp2/source/ooo/file_library_ooo.scp | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/main/scp2/source/ooo/file_library_ooo.scp 
b/main/scp2/source/ooo/file_library_ooo.scp
index 10790227ac..bae968b757 100644
--- a/main/scp2/source/ooo/file_library_ooo.scp
+++ b/main/scp2/source/ooo/file_library_ooo.scp
@@ -665,7 +665,20 @@ STD_LIB_FILE( gid_File_Lib_Fwl , fwl)
 
 STD_LIB_FILE( gid_File_Lib_Fwm , fwm)
 
-#ifdef WNT
+// This is the legacy GDI+ redistributable, needed back when Windows 2000 and 
the
+// original XP had no GDI+ of their own.  Since XP SP1 it is a side-by-side 
assembly
+// (Microsoft.Windows.GdiPlus), and SxS resolution runs ahead of the ordinary 
DLL
+// search path -- so this private copy is never the one that gets loaded.  
Verified on
+// a running 64 bit office, which loads
+//   
C:\WINDOWS\WinSxS\amd64_microsoft.windows.gdiplus_..._1.1.26100.9168_...\gdiplus.dll
+//
+// The file external/gdiplus/gdiplus.dll is 32 bit, so in a 64 bit install it 
is 1.7 MB
+// that could not be loaded even if something tried.  It went unnoticed 
precisely
+// because SxS means nothing ever does.  Do not ship it there.
+//
+// The 32 bit build keeps it: same reasoning says it is equally unused, but 
that is the
+// shipping configuration and dropping it is a separate decision.
+#if defined(WNT) && !defined(BUILD_WIN64)
 File gid_File_Lib_Gdiplus
     BIN_FILE_BODY;
     Styles = (PACKED);

Reply via email to