Installer support of Win Setup API - replacing blocked files after reboot

Hi René,

From the MSDN link that you gave, I read that this API should not be used anymore:

Setup API should no longer be used for installing applications. Instead, use the Windows Installer for developing application installers. Setup API continues to be used for installing device drivers.

I guess that indeed you need to complement the existing tags as you suggested.

You can manipulate the uninstaller (see how the registry listeners work).

I have one further question: how would your change work on other systems than Windows? I guess such files are somehow OS-specific, but sometimes they may not. What do you think?

Cheers

Hi Julien,
I'd like to declare the your questions as shortly as possible:

"Setup API" and "Windows Installer" are some completely different worlds.
Setup API handles single files in so called file queues. If target files are to be overwritten and if they are blocked at install time, they are written automatically by Setup API into a temporary location and overwritten after reboot automatically, too. There is no other way to do so in Windows at all. Otherwise, if I file is blocked there is no other way to get it overwritten than unblock it by shutting down the application which blocks it. In several situations such applications are needed in a running state during installation time. That's the use case when Setup API makes sense. The Setup API specification is very stable over several versions of Windows all time, as many functions of the Windows API.
Windows Installer is partly some complex alternative to IzPack for Windows, it's about doing complex installation transactions based on registered applications. It's on another abstraction level. And it would break the platform independence in a worse manner. Windows Installer might use Setup API internally, maybe. Furthermore, using Windows Installer makes an installer application depending on a preinstalled Windows Installer, which is on quite different feature level compare between the Windows "distributions". Native installers for Windows might use the Windows Installer itself, but IzPack should not, at least not yet.
Maybe one time Java for Windows will make it easier to copy blocked files in Windows, but at the moment there no such feature.
I haven't tested Setup API on Windows Vista and 2008, but on Windows XP and 2003 Server it works fine, for example.

What I do not want is to confuse existing IzPack tags too much.
This should be well specified and is to be discussed somewhere.

Some "brainstorming":

• Setup API is Windows-specific and would be simply ignored on other systems. Blocked files do not exist on UNIX systems in that way as far as I know.
• Copying a file or a bunch of files by Setup API should be declared explicitely in install.xml, on the other hand without this declarations all files should be copied in the classic way.
• Attributes for limit tasks to specific target OS are automatically implied to "windows" on wanting copy a file using Setup API.
• The JNI DLL used here takes about 55 KBytes of space in the installer, as other DLLs, too.

My favorite question at the moment:
Should this be made in a branch or how could this be handled within this project? In trunk?

And at least I have to get the permission of my company to offer code here that I made for them.

If this discussion would lead to an "yes" for introducing this feature I can propose the interface changes in install.xml and discuss it with you and all who are interested in to make the best possible solution of it. I have already patched 4.2.1 on my private computer with the sources I already have ready

Ok I see.

1. This should be made on your side (as I won't give you access to the SVN repository at the moment)
2. You may use Git if you like, I maintain a repo at http://github.com/jponge/izpack/tree/master
3. Once you have the feature working and documented, you can attach the patch (as a diff!) to the issue, and we wil review.
4. Hopefuly it gets merged into the project, but I cannot make any promise at this stage

Cheers

Thank you. For now, I will work in a SVN copy of izpack-src/branches/4.2 and provide a patch as soon as there is a pre-tested result.

This is my patch for it. Would be nice if you had a look at it.

TODO:

• translations (only eng, deu, cze at the moment)
• compilation of the JNI DLLs in VC 32+64bit (Borland BCC 5.5 32 bit at the moment)

Maybe there are some formatting errors, I use the AnyEdit Eclipse plugin to remove trailing spaces at the end of lines, for example.

Thanks,
René

More TODOs:

• Check automatically for Windows at install time, don't even try using file queues otherwise (will add it next week).
• Put a warning at compile time if blockable files are not explicitely limited to Windows in install.xml

This is a more complete patch:

• Enhanced documentation, more detailed specification and added a special section to "Advanced features" describing it more detailed with an example. The feature is now well-documented for anyone, I guess.
• Added a compiler warning if the 'blockable' attribute is used on multiplatform installations (this is legal, but the user should be informed anyway, IMHO)
• Added ignoring 'blockable' on non-Windows platforms
• Removed invalid line break in translations for message box

Handling blockable files in an uninstaller is still not implemented, but prepared in the base classes, no new JNI DLLs will be needed.

The feature is pre-tested on Windows XP and OpenSUSE 11.1 (for compatibility on non-Windows systems).

Small typo fix in examples with some GUI text

My latest patch.

If you haven't already applied it for review:
This latest patch contains only a cleanup - removed some obsolete code from some previous implementations: Win API shutdown functions not used at all here.
There is no functional change, only the piece of code gets a bit smaller

Forgot to say even for the previous patches:
The patch applies against the current SVN trunk - should work fine with r2769

Note:
The WinSetupAPI.DLL and WinSetupAPI_64.DLL must be copied manually to
izpack-src/trunk/src/native/SetupAPI/
Or even better someone rebuilds them with Visual C++ in real 32 and 64 bit mode. At the moment both are 32bit compiled with Borland BCC 5.5, I don't have any other compiler and a 64bit system here at the moment. Hopefully the WinSetupAPI_64.DLL runs in 32-bit compatibility mode on 64-bit systems.

Thanks, we'll put that under review soon.

Ok thanks.

As you will see, the affected components are not limited to the installer, only, as originally chosen on creating this issue. The following components are affected (I can't change this any more):

• Build
• Compiler
• Documentation
• Installer
• Translations
• Uninstaller (not yet, but hopefully soon)

Could this feature also be used to remove locked files after the uninstall? I have the problem that some files of the bundled JRE are locked while the uninstaller JAR is running. These files should be deleted after the uninstall JAR and the java.exe of the bundled JRE have completed. A reboot would not be necessary.

Hi Christian, this might work, see
http://msdn.microsoft.com/en-us/library/aa377425(VS.85).aspx
But rather than using it for deleting I would use the File.deleteOnExit() method in that case, instead, which should delete them afterwards. Of course, deleteOnExit() might be a problem for deleting files and directories recursively.
Personally I haven't tested the SetupQueueDelete API function much often, thus, I cannot guarantee that it will fit the your need in all points. Anyway, it is defined in the JNI interface brought by this patch and could be immediately used for testing.

But even here you can get into trouble on removing files recursively, since it removes only one or more single files, but not the directories in which blocked files are located.

The idea behind this feature is to mark files potentially blocked by running processes, so integrating it also in the uninstaller is a functionality which is should be also there in each case later, but isn't yet implemented in the current patch. I will put it there as soon as possible, at least for using it in IzPack in my local copy of the trunk.

René, thanks for your reply.

File.deleteOnExit() will probably not work to delete the files of the running JRE, because a process cannot delete it's own EXE and DLL files while it is running.

Just wondering: Anything new here in common, any opinion or progress? Thank you

Assigned to me, I will make reviews soon

I'm very sorry for only getting back to you now....

I tried to apply the patch and some hunks fail. I have attached a log file.

Would it be possible for you to update the patch?

Thanks a lot.

Hi Julien,
this is a common patch for both issues, 295 and 405.

Those issues are absolutely independent concerning the implementation. There are only some particular files affected by both and I'm not able to separate them now so quickly, because I enqueued those changes over half a year in trunk. I hope this will not be a big deal.

A a hint, I give you a list of classes:

Issue 405:
com.izforge.izpack.installer.Installer
com.izforge.izpack.installer.PanelConsole
... and all classes implementing PanelConsole.java:
com.izforge.izpack.panels.FinishPanelConsoleHelper

com.izforge.izpack.panels.HelloPanelConsoleHelper

com.izforge.izpack.panels.HTMLLicencePanelConsoleHelper

com.izforge.izpack.panels.InstallPanelConsoleHelper

com.izforge.izpack.panels.JDKPathPanelConsoleHelper

com.izforge.izpack.panels.LicencePanelConsoleHelper

com.izforge.izpack.panels.TargetPanelConsoleHelper

com.izforge.izpack.panels.UserInputPanelConsoleHelper

Issue 295 + 405:
src/doc-reST/advanced-features.txt
#405: Section "Unattended installations" (merged with previous issues)
#295: the rest
com.izforge.izpack.installer.ConsoleInstaller
#295: method checkedReboot(),
#405: the rest

Issue 295:
All other files and the DLLs (not in the patch) to build and copy.

Just ask if you get into trouble with this.

BTW: There are many formatting issues due to trailing white spaces in the source code. I would appreciate to use an automatic tool for eliminating them for better patches and formatting, such as the AnyEdit plugin for Eclipse.

Thanks, René

... the precompiled DLL files you can take from take from the previous patch GZ, to be copied to
bin/native/IzPack

Note: The _64 DLL isn't really a 64 bit one, but only a renamed 32 bit DLL. I don't have a 64 bit Windows environment available at this time.

Great job I must say!

Thanks René!

Thanks also to my company, which gave me the time and possibility to integrate this here. Of course they use the result, also

This issue can still be enhanced:

• put this also to the uninstaller to delete blocked files after reboot (I'm not sure whether this works in all Windows versions)

... and especially a call for help with:

• translations (only english, czech and german at the moment)
• compiling the DLLs for 32 and (real) 64 bit in a VC environment (instead of Borland compiler)
• testing (especially with Vista and 64 bit)

Thanks for your work René.

> put this also to the uninstaller to delete blocked files after reboot

And: Delete blocked files after the Java VM running the uninstaller has terminated (when a Windows reboot is not necessary).