Created attachment 55718 [details]
Validation result from Orca

I make these checks nearly in every minor. And if an error appears, this will be
fixed immediately. So there must not be an error. 
What problem with msi patching do you have? With native180 I integrated the new
msi database creation process, in which the database is created with the help of
an existing database. The old database currently has to be found via path in
openoffice.lst using the key UPDATE_DATABASE (this step will surely be changed
in the near future). From the msi databases prepared in this way I could create
successfully msp patches.  

Here I present some sample warnings and discuss them.

ICE03	WARNING	String overflow (greater than length permitted in column); Table:
File, Column: Component_, Key(s): statusbar5.xml

ICE03	WARNING	String overflow (greater than length permitted in column); Table:
FeatureComponents, Column: Component_, Key(s):
gm_o_jf_Palm_Aportisdoc.g_f_registry_spool_oo_td_palm_filters_xcu__share_registry_modules_o_o_td_filter

ICE03	WARNING	String overflow (greater than length permitted in column); Table:
Registry, Column: Registry, Key(s):
g_r_software_manufacturer_productname_productversion_capabilities_applicationdescription

ICE03	WARNING	String overflow (greater than length permitted in column); Table:
Component, Column: Component, Key(s):
g_f_share_c_sc_uiconfig_zip__share_c_soffice_cfg_modules_schart_statusbar

These are caused by many component names still being too long. Even more radical
abbreviation is needed in get_file_component_name() in
solenv/bin/modules/installe/windows/file.pm. Probably it would make sense to
just use underscore-prefixed MD5 hashes as component names, instead of trying to
use "human readable" component names. I think many installer-builders do that.

ICE33	WARNING	Reg key g_r_bau is used in an unsupported way. ProgId should be
registered via the ProgId table. This entry may overwrite a value created
through that table.

ICE33	WARNING	Reg key g_r_openoffice_calcdocument_1_clsid is used in an
unsupported way. ProgId - CLSID associations should be registered via the ProgId
and Class tables. This entry may overwrite a value created through those tables.

ICE33	WARNING	Reg key g_r_office_extension_curver is used in an unsupported way.
Version Independent ProgId should be registered via the ProgId table. This entry
may overwrite a value created through that table.

ICE33	WARNING	Reg key g_r_office_extension_1_defaulticon is used in an
unsupported way. ProgId - Icon associations should be registered via the ProgId
and Icon tables. This entry may overwrite a value created through those tables.

ICE33	WARNING	Reg key g_r_office_extension_1_shell is used in an unsupported
way. Shell extension verbs info should be registered via the Verb table. This
entry may overwrite a value created through that table.

ICE33	WARNING	Reg key g_r_bau is used in an unsupported way. Extensions should
be registered via the Extension table. This entry may overwrite a value created
through that table.

ICE33	WARNING	Reg key g_r_c_30a2652a_ddf7_45e7_aca6_3eab26fc8a4e_ is used in an
unsupported way. CLSIDs should be registered via the Class table. This entry may
overwrite a value created through that table.

ICE33	WARNING	Reg key g_r_c_30a2652a_ddf7_45e7_aca6_3eab26fc8a4e_defaulticon is
used in an unsupported way. CLSID - Icon associations should be registered via
the Class and Icon tables. This entry may overwrite a value created through
those tables.

ICE33	WARNING	Reg key g_r_c_30a2652a_ddf7_45e7_aca6_3eab26fc8a4e_inprochandler32
is used in an unsupported way. CLSID DefInprocHandler should be registered via
the Class table. This entry may overwrite a value created through that table.

ICE33	WARNING	Reg key g_r_c_087b3ae3_e237_4467_b8db_5a38ab959ac9_inprocserver32
is used in an unsupported way. CLSID contexts should be registered via the Class
table. This entry may overwrite a value created through that table.

ICE33	WARNING	Reg key g_r_c_30a2652a_ddf7_45e7_aca6_3eab26fc8a4e_progid is used
in an unsupported way. CLSID - ProgId associations should be registered via the
Class and ProgId tables. This entry may overwrite a value created through those
tables.

ICE33	WARNING	Reg key g_r_odb_mime_database is used in an unsupported way. MIME
info should be registered via the MIME table. This entry may overwrite a value
created through that table.

These warnings are more or less self-explanatory I think. Presumably the current
way the installer pokes directly into the Registry works fine, but it would be
cleaner to use the higher levels of abstraction offered by the ProgId, Class,
Icon, Verb, Extension and MIME tables.

ICE57	WARNING	Component 'g_f_exe_sbase__program' has both per-user and
per-machine data with an HKCU Registry KeyPath.

ICE57	WARNING	Component 'g_m_root_registry' has a registry entry that can be
either per-user or per-machine and a per-machine KeyPath.

These warnings I don't really understand yet...

ICE60	WARNING	The file soffice.exe is not a Font, and its version is not a
companion file reference. It should have a language specified in the Language
column.

This is a pretty clear message, at first sight. The Language column needs to be
populated.

But... another question is then whether the values in the Language column need
to match the language in the executable's version resource block? Argh, I hate
Windows Installer... this is just so typical, that the same information (Version
and Language) can be duplicated in the File table and in the (executable) file
itself, and it is very unclear whether this is OK (and whether they then must
match exactly or not), or whether it is enough that the executables contain
version resource blocks and it in fact is wrong to then also give them in the
File table...

ICE60	WARNING	The file alignmentbar3.xml is not a Font, and its version is not a
companion file reference. It should have a language specified in the Language
column.

For non-executable files, though, the File table is the only place where the
language can be specified, so it probably should be done. I guess even just a
zero would make the validator satisfied?

ICE61	WARNING	This product should remove only older versions of itself. The
Maximum version is not less than the current product. (36.0.0 2.4.9310)

Hmm, what is that 36.0.0 version in the Upgrade table?

ICE86	WARNING	Property `AdminUser` found in column `LaunchCondition`.`Condition`
in row 'AdminUser'. `Privileged` property is often more appropriate.

Maybe so then. I doubt this is essential?

> What problem with msi patching do you have? 

Some files get patched, others not;) As far as I can see it is completely random
which files msiexec manages to patch, which not. For those that it doesn't
patch, the log file just says for instance: 

The file represented by File table key 'sc680mi.dll' has no eligible binary patches

And it is not only for exectuables for whic this happens, either, also for instance:

The file represented by File table key 'imp680zh_CN.res' has no eligible binary
patches

while for other files it manages to patch them and the log says:

Activating binary patch with sequence 21953 for file key pdffilter680mi.dll

or

Activating binary patch with sequence 23588 for file key web.jar

> With native180 I integrated the new msi database creation process,
> in which the database is created with the help of an existing database.

That sounds interesting! Looking forward to trying out that.

(Forgot to mention, the .msp file *does* contain patches also for those files
for which the msiexec log file says "no eligible binary patches".)

Yes, I know these warnings. And of course, you are right, it would be great to
remove them. 
I fully agree in non-human-readable short component names. This seems to be
quite easy.
For the registry we only use the Registry table. This is a simple conversion
from scp2 to registry.idt. This works fine. But of course the usage of special
tables is better. But I suppose, this is less important.
I cannot see the reason for the language column in the File table for
soffice.exe. But this can be the biggest problem for the patch problems. I also
had problems in my tests, but especially with language specific files like
license.txt and readme.txt, that were not patched using msp files.
The 36.0.0 in upgrade table is caused by a wrong usage of ProductVersion in OOo
2.0 Beta, where I wrote something like 2.8457.x.y, where 8457 was the build id.
This was approximately 34 x 256 (or 255?) and is therefore shifted to the left
number, which is increased by 34. Argh ;-)
And finally changing AdminUser to Privileged? Seems also less important.

When you talk about the log file saying "xyz has no eligible binary patches",
you mean the log file, that is written during installation of msp file? Do you
have additional information from the log file that is written during patch
creation? And of course it would be fantastic, to have a relation between the
Orca warnings and the msp installation problems, but this would probably be too
simple for Windows Installer technique ;-)

> When you talk about the log file saying "xyz has no eligible 
> binary patches", you mean the log file, that is written 
> during installation of msp file?

Yep. I run: msiexec /update foo.msp /l*x foo.log

> Do you have additional information from the log file that
> is written during patch creation? 

That file contains just lines like:

Files differ: 'c:\ooo\msp\2.4.1\10\.\.\.\program\xmlsecurity.dll',
              'c:\ooo\msp\2.4.1\4\.\.\.\program\xmlsecurity.dll'.
Patch file created: FTK=xmlsecurity.dll; temp location=OOo\25000.HDR.

The files that have real changes (and for which the patch then fails with the
mysterious "no eligible binary patches") aren't mentioned in any special way in
the msimsp log file.

The log file does contain a few warnings like this:

WARNING (14): File versions are equal.  Upgraded:
'c:\ooo\msp\2.4.1\10\.\.\.\program\policy.1.1.cli_types.dll' ver=13.0.0.0; 
Target: 'c:\ooo\msp\2.4.1\4\.\.\.\program\policy.1.1.cli_types.dll' ver=13.0.0.0.

but these all refer to files that aren't that relevant... (.NET stuff like the
above, ICU or Mozilla DLLs), they haven't effectively changed, it doesn't matter
whether they are patched or not.

I made some test concerning the files, that are listed with "xyz has no eligible
binary patches" in the patch log file. There seem to be reproducable (in SO and
OOo) three different scenarios:
1. The file is not installed, because it was not selected for installation. If
you deselect "Calc" or "Quickstarter" the corresponding files are listed in the
log file with the "no eligible binary patches" text. I suppose, you deselected
Calc, so that sc680mi.dll was not installed.
2. The files are not installed in the office directory. This is relevant for the
"cli"-files, meaning cli_cppuhelper.dll, policy.1.0.cli_cppuhelper.dll,
cli_cppuhelper.config and the other files, that are installed into the Windows
directory.
3. There are some files, that are included in the patch completely. In the log
file you find the text "modified xyz with full-file update". This includes
version1.ini, version2.ini and 8 files segment_3*.

I found it also interesting to look at the changes the msp file makes in the msi
database (using Orca and shifting msp over msi):
A. The 10 files from point 3 get new higher sequence numbers and are included
into the patch cabinet file, that is included into the msp file. See table
"Patch", that contains files with high sequence numbers and is medium 2 in media
table. 
B. Nearly all files from point 2 are also included into the "Patch" table. Only
the "cli_*.config" files were missing.
C. The files that can be deselected (testtool.exe, quickstarter.exe,scmi.dll,
...) are also included into the "Patch" table. Does it mean, that all
deselectable files are saved in internal cabinet file?

So there seem to be good reasons for the log file text "xyz has no eligible
binary patches". In my tests I could not find one file in the office directory,
that was not patched correctly (cli files not checked).

> three different scenarios:

> 1. The file is not installed, because it was not selected for installation.

That is not the case here, the installation I am trying to patch does have Calc
installed (for instance, in the sc680mi.dll file's case). But good to know
anyway that in this case at least the "no eligible" message is output.

> The files are not installed in the office directory. This is 
> relevant for the "cli"-files, meaning cli_cppuhelper.dll, 

I probably should add all these files to the UpgradedFilesToIgnore table anyway,
as they should never change anyway.

> In the log file you find the text "modified xyz with full-file update".
> This includes version1.ini, version2.ini and 8 files segment_3*.

Actually I don't see any full-file update messages at all, and not those files
either, are they 3.0 specific?

reassigned

version1.ini and version2.ini are new in OOo 3.0. I do not know the segment_3*
files. This are new files included into the zip files probably from extras project.
Strange, that you have different  files with "... has no eligible binary
patches". In my tests StarOffice and OpenOffice both have the same
"problem"-files (English only). Do you have a 68-language installation set? 
Perhaps you can try to reproduce your problem with my msp creation process from
cws native180, that creates installation sets based on informations in older
installation sets (with big similarities to your process of reading File.idt and
Director.idt). This was introduced in ooo300 m2.

Setting target 3.1

Patching works fine in my opinion. Setting target OOo Later.