Merge from 2.0.4 branch.

1 files changed, 189 insertions, 49 deletions

diff --git a/doc/novell-win32-incremental-patch-build.txt b/doc/novell-win32-incremental-patch-build.txt
index 329f7a9ef..a395181e5 100755
--- a/doc/novell-win32-incremental-patch-build.txt
+++ b/doc/novell-win32-incremental-patch-build.txt
@@ -1,11 +1,12 @@
-Procedure to produce incremental patch for the NovellWin32ISO
-installers. This is somewhat hard to automate. This document is very
-much a work in progress, written and updated while working out how
-this actually should be done. Read with a large pinch of salt.
+This document describes the procedure to produce incremental patch for
+the NovellWin32ISO installers. This is somewhat hard to automate. This
+document is very much a work in progress, written and updated while
+working out how this actually should be done. Read with a large pinch
+of salt.
 
 The NovellWin32ISO builds are identified by the full three-part
 PACKAGEVERSION from openoffice.lst (2.0.4, for instance) suffixed by a
-dash and an counter, starting from 1 in the first build. The first
+dash and a counter, starting from 1 in the first build. The first
 distributed NovellWin32ISO build of 2.0.4 is thus 2.0.4-1.
 
 The "PATCHLEVEL" we talk about below is a NovellWin32ISO concept, not
@@ -28,6 +29,8 @@ since the previous build are rebuilt. Thus the files that are included
 in each build's installer are mostly from the original build, only
 those that have actual changes are fresher.
 
+
+
 - Rename build/$tag/instsetoo_native/wntmsci10.pro/OpenOffice to
 OpenOffice-$previous (where $previous is the previous build
 counter). Ditto for OpenOffice_languagepack, although I don't think
@@ -37,15 +40,17 @@ installers for language packs.
 - Add a new marker to ChangeLog indicating at which stage this build
 was done.
 
-- edit novell-win32-vrb-branding.diff, increment the PATCHLEVEL
+- Edit novell-win32-vrb-branding.diff, increment the PATCHLEVEL
 value. This means that DLLs built from now on (once the patch is
 applied) will get a new version number.
 
-- Run make patch.apply
+- Run make patch.apply.
+
+- Run sh doc/AUTOGEN.NovellWin32ISO.sh.
 
-- Run sh doc/AUTOGEN.NovellWin32ISO.sh. Run make and interrupt it when
-it starts the main build with "Building project solenv", i.e. after
-having done the upstream configure script and set_soenv stuff.
+- Run make and interrupt it when it starts the main build with
+"Building project solenv", i.e. after having done the upstream
+configure script and set_soenv stuff.
 
 - Inspect ChangeLog entries since the last marker. Go to build/$tag,
 source winenv.set.sh. In each project directly affected by changes
@@ -62,18 +67,42 @@ sc
 binfilter (but nothing that affected what gets built had changed)
 helpcontent2
 
+For 2.0.4-4 vs. 2.0.4-2, they are:
+
+offapi
+scp2
+scsolver
+fpicker
+basic
+sfx2
+filter (because of the added MOOX xcu fragments)
+sc
+sysui (jimmac's new icons)
+desktop (-"-)
+
 Note carefully what changed/new files get delivered, just for
 double-checking later.
 
-- Remove sfx2/wntmsci10.pro/about.obj and do a build && deliver in
-sfx2, too.
+To find out the correct order to build && deliver, given we know what projects are affected, go to postprocess and run:
+
+build --all --show | grep 'Building project' |grep -E ' (offapi|sfx2|scsolver|sc|scp2|basic|filter|fpicker)$'
+
+(use the relevant list of projects in the grep, of course.)
+
+- Remove sfx2/wntmsci10.pro/slo/about.obj and do a build && deliver in
+sfx2, too, if not already done above.
+
+- Go to postprocess, build & deliver.
 
-- Go to instsetoo_native and do a the build there. Edit
-util/makefile.mk to avoid building language packs.
+- Go to instsetoo_native. Edit util/makefile.mk to avoid building
+language packs. Do a build there.
 
-- do an administrative install of previous build, and of what you just
+- Do an administrative install of previous build(s), and of what you just
 built:
 
+  cd build/OOO_2_0_4/instsetoo_native/OpenOffice-2/msi/install/en-US_ar_cs_blabla
+  msiexec /a openofficeorg20.msi
+
   cd build/OOO_2_0_4/instsetoo_native/OpenOffice-1/msi/install/en-US_ar_cs_blabla
   msiexec /a openofficeorg20.msi
 
@@ -83,7 +112,7 @@ built:
 for instance, for 2.0.4-1 and 2.0.4-2: install into
 c:\tmp\OOo-2.0.4-1-admin and c:\tmp\OOo-2.0.4-2-admin
 
-- make a new folder for the patch installer, for instance
+- Make a new folder for the patch installer, for instance
 c:\tmp\OOo-2.0.4-1-2-patch.
 
 Note that a Windows Installer patch can contain several patch pairs;
@@ -92,31 +121,25 @@ patches 2.0.4-1 to 2.0.4-4, 2.0.4-2 to 2.0.4-4, and 2.0.4-3 to
 2.0.4-4. For simplicity, below I talk just about a patch for one
 update, from 2.0.4-1 to 2.0.4-2.
 
-- create a Patch Creation Properties (.pcp) file, for instance
+- Create a Patch Creation Properties (.pcp) file, for instance
 openofficeorg20.pcp. Copy the
 Samples/SysMgmt/Msi/Patching/TEMPLATE.PCP file from the Platform SDK.
 A dump of the relevant tables in that file for the 2.0.4-1 to 2.0.4-2
-patch is included below. Remember to generate a new GUID for the patch
-in the PatchGUID property in the Properties table.
-
-- run msimsp to find the differences between the two above
-installations, verify that the DLL and EXE files that have changed
-indeed have the updated version in their VRBs.
+and 2.0.4-1 and -2 to 2.0.4-4 patches is included below. Remember to
+generate a new GUID for the patch in the PatchGUID property in the
+Properties table.
 
-  msimsp -s openofficeorg20.pcp -p openofficeorg20.msp -l logfile.log
-
-Read the logfile looking for which files have changed
-
-msimsp will not yet actually produce a good enough .msp file. The
-ProductVersion properties in the two .msi databases are the
-same. Increment the ProductVersion of the .msi file in the "upgraded"
-administrative installation.
+- Add PATCHLEVEL to the last part of the ProductVersion in the
+Properties table of the .msi file in the "upgraded" administrative
+installation.
 
 For instance, for 2.0.4-1, the ProductVersion property is 2.0.9073,
-and for 2.0.4-2 this should be then manually incremented to
-2.0.9074. Some typical MS braindamage here: The ProductVersion
-property is three digits: uchar.uchar.ushort, i.e. the first two <=
-255, the last <= 65535. So we can't use the same kind of version
+and for 2.0.4-2 this was manually changed to 2.0.9074, and for 2.0.4-4
+to 2.0.9076.
+
+Some typical MS braindamage here: The ProductVersion property is
+documented to be three digits: uchar.uchar.ushort, i.e. the first two
+<= 255, the last <= 65535. So we can't use the same kind of version
 number as for the FileVersion column in the File table, which is four
 ushorts, and constructed as
 
@@ -139,27 +162,37 @@ string, so there is nothing in the MSI format that prevents this,
 although it is of course questionable how Windows Installer accepts
 other that three-part ProductVersion properties. Oh well...
 
-- edit the corresponding rows (updated DLLs, EXEs, and nonversioned
-files) in openofficeorg20.msi in the second administrative
-installation, change the final number of the FileVersion rows in the
-File table to the patchlevel in question.
+- Run msimsp to find the differences between the two above
+installations, verify that the DLL and EXE files that have changed
+indeed have the updated version in their VRBs.
+
+  msimsp -s openofficeorg20.pcp -p openofficeorg20.msp -l logfile.log
+
+Read the logfile looking for which files have changed
+
+- This step and the two following don't seem to actually be
+necessary. Windows Installer will patch a file even if its version
+number stays the same. It is also tedious manual work: Edit the
+corresponding rows (updated DLLs, EXEs, and nonversioned files) in
+openofficeorg20.msi in the second administrative installation, change
+the final number of the FileVersion rows in the File table to the
+patchlevel in question.
 
-Actually, I don't know whether this is essential or not. It seems that
-Windows Installer is happy to apply patches to files even if the
-FileVersion doesn't change. For versioned files (DLLs and EXEs) I
-guess it is best if the version of the file recorded in Windows
-Installer is the same as the one in the file's VRB block, though.
+For versioned files (DLLs and EXEs) I guess it is best if the version
+of the file recorded in Windows Installer is the same as the one in
+the file's VRB block, though, but even that doesn't seem to be
+necessary.
 
-- run msimsp again
+- Run msimsp again
 
-- verify that the changed files are indeed exactly those for which you
+- Verify that the changed files are indeed exactly those for which you
 edited the FileVersion, no more, no less.
 
 ================
 
 Exports (.idt files) of the non-empty tables in the Patch Creation
 Properties (.pcp) file used when creating the 2.0.4-1 to 2.0.4-2
-patch:
+patch. I have also added some comments.
 
 ==> ImageFamilies:
 
@@ -168,7 +201,10 @@ s8	S72	I2	I2	S128	S32
 ImageFamilies	Family
 OOo	OOoSrcPropName	100	11000		
 
-==> PatchMedatada:
+The number of files in OOo is under 11000, so we start files
+introduced by patches at 11000.
+
+==> PatchMetadata:
 
 Company	Property	Value
 S72	s72	l0
@@ -182,6 +218,10 @@ PatchMetadata	Company	Property
 	MoreInfoURL	http://www.novell.com
 	TargetProductName	OpenOffice.org 2.0.4
 
+The Description and DisplayName strings don't have any prescribed
+format, that "2.0.4-1/2" is just a convention I invented to indicate a
+patch from 2.0.4-1 to 2.0.4-2.
+
 ==> Properties:
 
 Name	Value
@@ -195,10 +235,12 @@ IncludeWholeFilesOnly	0
 ListOfPatchGUIDsToReplace	
 ListOfTargetProductCodes	*
 MinimumRequiredMsiVersion	300
-PatchGUID	{494B0178-4FA5-4AE6-B58E-5B433DD64A92}
+PatchGUID	{489E4A5F-830E-425D-BFA6-6E1C57D35CF6}
 PatchOutputPath	openofficeorg20.msp
 SEQUENCE_DATA_GENERATION_DISABLED	1
 
+The PatchGUID must be unique for each .msp file.
+
 ==> TargetImages:
 
 Target	MsiPath	SymbolPaths	Upgraded	Order	ProductValidateFlags	IgnoreMissingSrcFiles
@@ -206,9 +248,107 @@ s13	s255	S255	s13	i2	S16	i2
 TargetImages	Target
 2p0p4d1	c:\tmp\OOo-2.0.4-1-admin\openofficeorg20.msi		2p0p4d2	1		0
 
+The Target and Upgraded fields must be alphanumeric, thus I
+transformed periods to "p" and dashes to "d", i.e. 2.0.4-1 became
+2p0p4d1...
+
 ==> UpgradedImages:
 
 Upgraded	MsiPath	PatchMsiPath	SymbolPaths	Family
 s13	s255	S255	S255	s8
 UpgradedImages	Upgraded
 2p0p4d2	c:\tmp\OOo-2.0.4-2-admin\openofficeorg20.msi			OOo
+
+================
+
+Corresponding exports of the non-empty tables in the pcp file used
+when creating the 2.0.4-1 and 2.0.4-2 to 2.0.4-4 patch.
+
+This patch is capable of upgrading either 2.0.4-1 or 2.0.4-2 to
+2.0.4-4. (2.0.4-3 was an intermediate build that I just made the en-US
+-only installer for.
+
+Here we had to add rows to the UpgradedFiles_OptionalData table so
+that the msvcr71.dll and msvcp71.dll files were included in the patch
+as whole files. These files changed when running build in postprocess
+as they were rebased to a different address than in the earlier
+builds.
+
+Of course, the base addess is just one field in the PE header, so
+being able to have a binary patch for them would have been extremely
+nice. But unfortunately, as the versions (in the VRB) of these files
+didn't change, and we don't generate MsiFileHash entries for dll and
+exe files, there is no way Windows Installer can verify that it would
+be patching the right file. Thus we have to include the "new" ones
+(with just the base address change) in toto.
+
+When starting a new base build plus patch chain (OO.o 2.1?)  we should
+begin calculating MsiFileHash values also for versioned files, to
+avoid this issue.
+
+==> ImageFamilies:
+
+Family	MediaSrcPropName	MediaDiskId	FileSequenceStart	DiskPrompt	VolumeLabel
+s8	S72	I2	I2	S128	S32
+ImageFamilies	Family
+OOo	OOoSrcPropName	100	11000		
+
+==> PatchMetadata:
+
+Company	Property	Value
+S72	s72	l0
+PatchMetadata	Company	Property
+	AllowRemoval	1
+	Classification	update
+	CreationTimeUTC	2006-12-14 22:00
+	Description	2.0.4-1+2/4
+	DisplayName	2.0.4-1+2/4
+	ManufacturerName	Novell, Inc.
+	MoreInfoURL	http://www.novell.com
+	TargetProductName	OpenOffice.org 2.0.4
+
+==> Properties:
+
+Name	Value
+s72	L0
+Properties	Name
+AllowProductCodeMismatches	1
+AllowProductVersionMajorMismatches	1
+ApiPatchingSymbolFlags	0x00000000
+DontRemoveTempFolderWhenFinished	1
+IncludeWholeFilesOnly	0
+ListOfPatchGUIDsToReplace	
+ListOfTargetProductCodes	*
+MinimumRequiredMsiVersion	300
+PatchGUID	{D79AFC12-0A1B-4E9D-9C29-4128BBDE0365}
+PatchOutputPath	openofficeorg20.msp
+
+I removed the SEQUENCE_DATA_GENERATION_DISABLED property.
+
+==> TargetImages:
+
+Target	MsiPath	SymbolPaths	Upgraded	Order	ProductValidateFlags	IgnoreMissingSrcFiles
+s13	s255	S255	s13	i2	S16	i2
+TargetImages	Target
+2p0p4d1	c:\tmp\OOo-2.0.4-1-admin\openofficeorg20.msi		2p0p4d4	1		0
+2p0p4d2	c:\tmp\OOo-2.0.4-2-admin\openofficeorg20.msi		2p0p4d4	2		0
+
+I don't know whether the values in the Order columns actually are
+needed or not.
+
+==> UpgradedFiles_OptionalData
+
+Upgraded	FTK	SymbolPaths	AllowIgnoreOnPatchError	IncludeWholeFile
+s13	s255	S255	I2	I2
+UpgradedFiles_OptionalData	Upgraded	FTK
+2p0p4d4	msvcp71.dll			1
+2p0p4d4	msvcr71.dll			1
+
+See above why we need to mention msvcr71.dll and msvcp71.dll here.
+
+==> UpgradedImages:
+
+Upgraded	MsiPath	PatchMsiPath	SymbolPaths	Family
+s13	s255	S255	S255	s8
+UpgradedImages	Upgraded
+2p0p4d4	c:\tmp\OOo-2.0.4-4-admin\openofficeorg20.msi			OOo