LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Trimming distribution size

Since I have a considerable number of built LabVIEW applications, and sometimes send new installers out by e-mail, it is very important to keep the sizes small. Still, I would like to provide an installer, and not just the executables.

(Of course I don't built installers containing the runtime engine, but simply request that it be downloaded and installed from NI. This saves considerable volume)

The builder (LabVIEW 7.1) generates 6 installer files:
-- data.cab (variable size)
-- install.msi (1616KB)
-- InstMsi.exe (1460KB)
-- InstMsiW.exe (1470KB)
-- setup.exe (68KB)
-- setup.ini (1KB)

The last two are small, so I don't worry about them. Obviously, I need to include the data.cab. Install.msi is also a changing file, thus must
be included.

This leaves InstMsi and InstMsiW. These seem to be just some version of the windows installer, similar to what can be downloaded from Microsoft.

First, "InstMsi" seems to be for Windows 9x only. Since LabVIEW 7.1 only supports Windows 2000 and higher, it is not clear why it is even there.

"InstMsiW" is the Windows 2000, XP equivalent. On all PCs I tried, the installation works without problem even if this file is not present. Obviously, all these PCs already contain the functionality of it as part of the OS.

For a while now, I've been distributing zip archives of only 4 files (leaving out the instmsi*). The archives are sub-megabyte, instead of 3+ MB with all six files. Nobody ever had an problems installing.

Is it sound to leave these files out? What the worst case scenario if these are not included?
Message 1 of 5
(3,084 Views)
InstMsi.exe and InstMsiW.exe are updates to the Microsoft Installer (MSI) like you mentioned, one for 95/98/ME and one for NT/2000/XP. Setup.exe checks if the correct version of MSI is installed and if so runs install.msi. If not it will run the corresponding InstMsi*.exe, which installs MSI, prompts to reboot the machine then starts the install.msi. Since you are not including the setup.exe the other 2 exes would never be called automatically. If you are installing on a 2000 or XP machine MSI is already installed and probably the right version (1.1). If you are installing on NT and it is a clean install or has very few programs installed, MSI may not be there or version 1.0 may be installed. If it is not there the .msi file won't run (no exe associate
d with it) or it will pop up an error about needing MSI 1.1. But if the NT machine has much of anything installed on it (Office, newer Internet Explorer, even not MS apps), then it will probably have MSI 1.1 or higher on it.

To cover all possible scenarios you should have all 6 files, but the minimum you need is just the .msi and .cab which will take care of the most common and straight forward scenarios.
Message 2 of 5
(3,084 Views)
Thanks for the detailed reply!

(I actually include the setup.exe and setup.ini. They're small so I don't care).

Since I force users to install the runtime first, I would think it is 100% guaranteed that the correct MSI installer is already present, because it hopefully got upgraded (if needed) during the runtime install.

It seems I'll be perfectly fine with a lean "4 file distribution". (OTOH, it is known that people don't read instructions and thus might not install the runtime first ...sigh!).

I am still confused about the presence of the W9x InstMsi since these platforms are no longer supported with LabVIEW 7.1. Is it required to sucessfully start the installation so the user can be told that it won't work because their OS is obsolete?
😉
Message 3 of 5
(3,084 Views)
Oops, I misread, I thought you were not shipping the setup.exe or setup.ini, therefore my comment. People generally expect a setup.exe so it is probably a good thing to ship it. And yes if they have installed the LabVIEW Run-Time Engine first (or any installer that uses MSI) MSI should be installed/up to date, so setup.exe won't have to look for either InstMsi exe.

The reason InstMsi.exe is still being included is to cover one of the corner cases. Setup.exe is very generic and can be used on any Windows OS. 95 & 98 predate MSI, so they don't ship with any version of it (I think ME has it but it might be 1.0). The install.msi actually contains the logic to check for NT/2000/XP. But in order for it to run MSI must be installed. So ther
e is the possibility of someone running setup.exe on a 9x machine without MSI, it looks for InstMsi.exe, if it didn't find it and an error about InstMsi.exe is returned, this isn't useful to the end user. However if InstMsi.exe is there, then MSI is installed, the system asks to be rebooted, it launches install.msi and then is able to pop-up that NT/2000/XP is required. Which is really the message you want your end user to see.

Not a pretty corner case, but one that is still being covered for now. Setup.exe should probably be made smarter, but it seems the standard is to put the OS check in the installer itself.
Message 4 of 5
(3,084 Views)
I'd suggest to use the Innosetup at http://www.innosetup.com. It's free, and creates only one file, setup.exe. It has features such as register ActiveX components and version checks, creates shortcut on desktop, quicklaunch bar and unintall link, etc.

I hope NI can list out all the runtime files so we'll be able to include the files without including the runtime engine. The application builder interface really not that intuitive and easy to use.

-Joe
0 Kudos
Message 5 of 5
(3,084 Views)