Issue 4729

Hi Falko,
that's a good idea.

Could GNU Gzip/Wiz/Infozip be used for this? See: 

http://whiteboard.openoffice.org/servlets/ReadMsg?
msgId=385448&listName=mirrors

I suppose, that the best thing for Windows should be to use .msi :)
(Microsoft installer :) ).

to me, and I expect the majority of Windows users installing OOo, it
seems completely ludicrous that rather than one executable file which
is obviously run to install the program (the norm for 99% of software
for Windows), OOo comes packaged in a .zip file which it has to be
extracted from and then there are not one, but 414 files. the user has
to scroll down to the bottom of a long list to find the setup.exe file.

this completely breaks the thinking that many people installing
software on Windows will have learned and it seems even more ludicrous
that this is happening for their most fundamental sofwtare application
of all - the office suite - people I've seen have trouble with this
have expected that the care would have been taken with such a
pervasive application to make it as easy as possible to install for
them; and thus gives them a negative impression from the outset

Sorry guys, but this business of the OO eople.
StarOffice does come as an .EXE

closed

> Sorry guys, but this business of the OO eople.
> StarOffice does come as an .EXE

Am I wrong, or is this the OOo issuezilla?

Please don't close an issue because it works in Staroffice!

It's completely fair when you say it's not your duty, and you assign
it back to issues, but not to close it.

Sorry, you are right.
I should not have closed it.
Re-assigned to submitter.

May I suggest we use this issue for discussing what to do with 2.0: How do we
create self-running .exe or .msi downloads for Windows users?

Adjusted summary and Target milestone accordingly.

Created attachment 22843 [details]
Script for a silent self-extracting .exe installer for 2.0

The attached NSIS script will silently extract the install files and run setup.exe. 

The .exe installer also passes any command line option such as -a to OOo's
setup.exe. Furthermore, I have added the -x option to extract the install files
to a directory.

I think this works very much like the installer for SO 8 beta.

In order to make these self-extracting installers based on the attached script
NSIS needs to be installed on the build system. 

NSIS can be downloaded from here: http://nsis.sourceforge.net/
License: http://nsis.sourceforge.net/features/license/

Please let me know if I can do more to make this happen.

Created attachment 22844 [details]
Icon used in script

This appears to be a duplicate of IZ 33117.

Hi Justin,

Issue 33117 is for OOo 1.x and there really is a difference between OOo 1.x and
OOo 2.0. OOo 2.0 is based on MSI and the install files are CAB archives - not
ZIP. That means that there really isn't a lot to gain in compression. But
usability is still an issue.

LZWA compression could be turned on if it is possible to create noncompressed
CAB archives during the build process.

I should probably add that the attached script is global meaning there are no
need for localisation what so ever.

Søren

I am taking this one. Let's see how far I get...

Build requirements:
http://tools.openoffice.org/dev_docs/build_windows_tcsh.html

Native installer description:
http://installation.openoffice.org/how_to_create_native_installer.html

File extensions definition:
http://development.openoffice.org/releases/filenames.html

After exploring the CVS I found out that NSIS related functions have already
been added to these build scripts:
http://tools.openoffice.org/source/browse/tools/solenv/bin/modules/installer/globals.pm
http://tools.openoffice.org/source/browse/tools/solenv/bin/modules/installer/download.pm

I assume this is for the StarOffice wrapper introduced with SO8 Beta.

The SO8 beta wrapper introduces an additional "extract to what directory" dialog
while the script I attached to this issue is silent and thus doesn't need
additional translation.

Before I go any further I would like Sun to comment on what approach should be
taken:
1) SO and OOo should have different NSIS wrappers
2) SO and OOo should align the NSIS wrappers
a) - and it should be the wrapper introduced in SO8 beta
b) - and it should be the silent wrapper
c) - and lets talk about it

Reassigning to mh for a comment.

I begin alignment of SO/OOo Nsis installer in cws mh1990. you're welcome to join
this effort.

Can I help without setting up a build environment and cws system? What are your
plans for the NSIS wrapper?

As far as I understand you should be able to create a single MSI file that knows
how to install itself, containing the CAB files.

creation of download sets committed now to cws mh1990.

we still need to find final bitmaps and compression strategy within CAB and NSIS.

the msi thing should not discussed within this issue now, I suggest to discuss
this on dev@installation first and then may file this as an request for enhancement.

Yes, you can make single MSI files, but I don't know how. Maybe it is hidden
somewhere in this documentation:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/windows_installer_development_tools.asp

To include the cab files into the msi database is already prepared. You only
have to set 

$include_cab_in_msi = 1;

instead of 

$include_cab_in_msi = 0;

in solenv/bin/modules/installer/globals.pm and you will get a 90 MB  msi
database next to other files in the installation set.

Nice. Why don't we just distribute the single MSI file then instead of applying
a NSIS wrapper and thus additional build requirements?

MySQL installer is now a .msi file. Firefox / Thunderbird 1.1 will also be
available in .msi : https://bugzilla.mozilla.org/show_bug.cgi?id=231062

Søren

Our installation sets contain some files that cannot be included into the
database. There is a setup.exe with its setup.ini, there are instmsi files and
there are readme and license files.
 

For the READMEs they are usable within the package anyway and presumably could
be made available from the same download location.
It seems like setup.exe and setup.ini are just used to launch the msi
installation anyway. Is there any other critical functionality / reasons why
they are needed?

The setup.exe looks for an installed Windows Installer service and checks its
version. If the service is not found or if it is too old, the setup.exe installs
the instmsi* files that are also located in the installation set. Only then the
service can be started with the database  and the required transformation (in
multilingual installation sets).
For multilingual installation sets the setup.exe additionally determines the
language, in which the setup is started.
In my opinion we cannot create installation sets without setup.exe, setup.ini,
instmsi*.

I think the point is not that the setup.exe is not needed for some people (with
old Windows Installer versions etc).
The point is that some people know they have Windows Installer installed, and it
would be simpler to give those people a single msi rather than requiring them to
download a zipfile, unzip it, and then run the installer.

I'm also pretty sure that WISE and InstallShield allow you to include the
instmsi files in a single executable with the msi bundled into it, so presumably
this could be possible here as well (using NSIS or suchlike).

From what I recall the setup.exe reads the Windows locale to decide which
language to launch the installer in. Is that correct? Is there no native Windows
Installer support for determining the correct language?

make as verified, although
* bitmaps for installer are not final
* not all discussions are finished about how exactly all parameters are set.

will go into master as a new, but not yet completed feature, to enable all
participants to do further work and discussion on this.

The purpose of this issue is to increase the usability of installation on
Windows. Therefore, I suggest we do not add unneccessary UI steps (and thus
localisation needs).

AFAIK Martins checkin asks the user where he/she wants to unpack the
installation files. My attached NSIS script silently, unpacks the installation
files to s subdirectory in the $TEMP directory and launches setup.exe.

The utility that opens and handles MSI files is Windows Installer. Windows
Installer is bundled in Windows XP and Windows 2000. The latest version (2.0) is
already bundled in Windows XP but can be downloaded for Windows 95, 98, ME, NT4
and 2000.

This means that any XP or 2000 user can doubleclick a single MSI file and it
will launch the installer without the need for setup.exe etc. Windows 9x users
may already have the Windows Installer installed without knowing.

I am favoring moving to a single MSI file or alternatively using a silent NSIS
wrapper.

close issue.