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 e18def7a66b028f206d05079d5a2c8c2e855e8c6 Author: Peter Kovacs <[email protected]> AuthorDate: Tue Aug 25 19:42:48 2026 +0200 installer: build a real 64 bit package on a 64 bit build The x64 MSI was marked Intel;1033, so Windows Installer treated it as a 32 bit package: ProgramFilesFolder resolved to "Program Files (x86)" and registry writes were redirected into Wow6432Node. A 64 bit office installing itself into the 32 bit program folder is wrong, and visibly so. Almost none of this is new code. A 64 bit path already exists in the installer perl and has simply never been switched on -- 64BITPRODUCT has four occurrences in the tree and nothing sets it: msiglobal.pm summary Template becomes x64 instead of Intel msiglobal.pm prepare_64bit_database(): RegLocator +16, VersionNT -> VersionNT64 component.pm Component Attributes +256 (msidbComponentAttributes64bit) registry.pm a Reg64 table for entries styled X64 / X64_ONLY and directory.pm already has overwrite_programfilesfolder(), driven by a PROGRAMFILESFOLDERNAME variable that nothing set either. Without that second half a package marked x64 still installs into "Program Files (x86)". Both are set from make_installer.pl rather than openoffice.lst, because the .lst has no architecture dimension -- its Globals and product blocks are shared by every platform, so setting 64BITPRODUCT there would make the Linux and 32 bit Windows builds claim to be 64 bit too. The predicate is $iswin64build, derived in setglobalvariables() from the compiler string that $ENV{OUTPATH} already carries: wntmsci14 is 32 bit, wntmscx14 is 64 bit. download.pm's get_download_architecture() keys off the same thing. An explicit value in the .lst still wins, so this is an override and not a policy. Verified both architectures: x64 Template x64;1033, Director.idt roots at ProgramFiles64Folder, all 975 components carry +256, RegLocat type 18 (2+16) x86 Template Intel;1033 and ProgramFilesFolder, both unchanged Not verified: ICE validation (no darice.cub / msival2.exe on this machine), and the install path itself, which needs an elevated install to confirm. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01VrM7EMKgiuyVcCUe9nSbZR --- main/solenv/bin/make_installer.pl | 30 ++++++++++++++++++++++++++ main/solenv/bin/modules/installer/globals.pm | 1 + main/solenv/bin/modules/installer/parameter.pm | 9 ++++++++ 3 files changed, 40 insertions(+) diff --git a/main/solenv/bin/make_installer.pl b/main/solenv/bin/make_installer.pl index 4ab5d70ea7..2052a15d22 100644 --- a/main/solenv/bin/make_installer.pl +++ b/main/solenv/bin/make_installer.pl @@ -1379,6 +1379,36 @@ my ($allvariableshashref, $installer::globals::ziplistname, $installer::globals::product, $loggingdir); + +# openoffice.lst has no architecture dimension -- its Globals and product blocks are +# shared by every platform -- so a 64 bit Windows build has to say so from here, where +# the output path is known. Setting 64BITPRODUCT in the .lst would make the Linux and +# 32 bit Windows builds claim to be 64 bit too. +# +# This turns on machinery that already exists and has simply never been switched on: +# msiglobal.pm summary Template becomes x64 instead of Intel +# msiglobal.pm prepare_64bit_database(): RegLocator +16, VersionNT -> VersionNT64 +# component.pm Component Attributes +256 (msidbComponentAttributes64bit) +# registry.pm a Reg64 table for entries styled X64 / X64_ONLY +# +# and PROGRAMFILESFOLDERNAME feeds directory.pm's existing +# overwrite_programfilesfolder(), without which a package marked x64 would still +# install into "Program Files (x86)". +# +# An explicit value in the .lst always wins, so this stays an override rather than a +# policy. +if ( $installer::globals::iswin64build ) +{ + if ( ! exists($allvariableshashref->{'64BITPRODUCT'}) ) + { + $allvariableshashref->{'64BITPRODUCT'} = 1; + } + if ( ! exists($allvariableshashref->{'PROGRAMFILESFOLDERNAME'}) ) + { + $allvariableshashref->{'PROGRAMFILESFOLDERNAME'} = "ProgramFiles64Folder"; + } +} + $installer::logger::Lang->printf("variables:\n"); foreach my $key (sort keys %$allvariableshashref) { diff --git a/main/solenv/bin/modules/installer/globals.pm b/main/solenv/bin/modules/installer/globals.pm index d448ea853b..4c0af69214 100644 --- a/main/solenv/bin/modules/installer/globals.pm +++ b/main/solenv/bin/modules/installer/globals.pm @@ -129,6 +129,7 @@ BEGIN $ismacosx = 0; $isos2 = 0; $iswindowsbuild = 0; + $iswin64build = 0; $islinuxbuild = 0; $islinuxrpmbuild = 0; $islinuxdebbuild = 0; diff --git a/main/solenv/bin/modules/installer/parameter.pm b/main/solenv/bin/modules/installer/parameter.pm index 419e5d9156..77da72bd99 100644 --- a/main/solenv/bin/modules/installer/parameter.pm +++ b/main/solenv/bin/modules/installer/parameter.pm @@ -279,6 +279,15 @@ sub setglobalvariables $installer::globals::iswindowsbuild = 1; } + # ... and which of the two Windows architectures. The letter after the compiler + # name is the discriminator that $ENV{OUTPATH} already carries: wntmsci14 is 32 bit, + # wntmscx14 is 64 bit. download.pm's get_download_architecture() keys off the same + # thing. + if ( $installer::globals::compiler =~ /wnt(msc|gcc)x/ ) + { + $installer::globals::iswin64build = 1; + } + if ( $installer::globals::compiler =~ /unxso[lg][siux]/ ) { $installer::globals::issolarisbuild = 1;
