problems creating binary patch files

[ken rentz]

I'm currently creating a new install for our program, and for some reason it refuses to create binary patch files with an earlier install. While a number of the files have changed, some of them have been static for years, yet when I look in the patch log, every file has an entry stating that "Patch API could not create a small patch; using whole upgraded file". any idea what could be happening, or how I can get additional logging to see what the problem is? If it matters, the older install was created with an earlier version of 6.0, while the new install was created with 6.13. Some web media groups have been changed in addition to new/changed files, but the problem occurs even for files that are in older, unchanged sections.

[Tinus]

This one hit me as well. From the online help section:

Upgrading from InstallAware 6.0

Upgrading setups created in InstallAware 6.0 to InstallAware 6.1 is automatic. Simply open your project in the new IDE as before and continue working normally.

However, the considerations below apply while working with older projects:

If you plan on using InstallAware 6.1 projects back in older versions, you should not use any new/enhanced plug-ins and/or installation commands, as these will not be available in the older versions and your scripts will fail to load.
Due to optimizations made to build directory layouts, you may not create patches for projects built in InstallAware 6.0 or earlier using InstallAware 6.1.
Do not use the Save Feature Selections and Load Feature Selections commands to save/load features on setups built with InstallAware 6.0 or earlier.

[ken rentz]

This one hit me as well. From the online help section:

Upgrading from InstallAware 6.0

Upgrading setups created in InstallAware 6.0 to InstallAware 6.1 is automatic. Simply open your project in the new IDE as before and continue working normally.

However, the considerations below apply while working with older projects:

If you plan on using InstallAware 6.1 projects back in older versions, you should not use any new/enhanced plug-ins and/or installation commands, as these will not be available in the older versions and your scripts will fail to load.
Due to optimizations made to build directory layouts, you may not create patches for projects built in InstallAware 6.0 or earlier using InstallAware 6.1.
Do not use the Save Feature Selections and Load Feature Selections commands to save/load features on setups built with InstallAware 6.0 or earlier.

Ouch!. Any idea what the problem is if I attempt to use 6.1? Breaking compatibility like this in a minor release means that I'll have to go back to 6.0 and stay there for at least the next year, since we need to support all customers on a given version with updates.

[MichaelNesmith]

This is due to optimizations made to build directory layouts, which caused problems when using web media blocks.

[Tinus]

Michael,

is it possible to rebuild the old setup with 6.1 and then create the patch?
Or does this later fail to update an installation based on a 6.0 build?

[MichaelNesmith]

Yes, I'm afraid that would fail updating a 6.0 install.

Web Media Blocks frequently caused exceeding path limits, which was a source of major frustration for users. Unfortunately to fix that, we have had to break backwards compatibility with older web media blocks (and also patches).

[ken rentz]

What's the last version of the program that did not break our existing users ability to patch their programs? It looks to me like I'm going to have to back off the latest version of InstallAware, and not update or upgrade anything until we reach a major revision release (next year at the earliest), as that is the only time that we do not supply patches to our users.

Also, do you make these earlier releases available for purchase? Our SCM group was planning on buying a couple of licenses and taking over some of the nightly and release tasks from our development engineers. If they are unable to make patches for any of our current users, then there is no reason for them to buy their own copies of this installer, since anything they do will be unusable.

[CandiceJones]

We normally do not provide older builds for purchase, but what can be done in this case is actually to provide a newer build, which has optional path generation parameters.

So, a project wide setting, or a command line flag, which sets the old or new path usage method - so your patches will continue to work.

You can take this up with sales - I'm sure they will happily accomodate this request once your purchase has been made.

[ken rentz]

We normally do not provide older builds for purchase, but what can be done in this case is actually to provide a newer build, which has optional path generation parameters.

So, a project wide setting, or a command line flag, which sets the old or new path usage method - so your patches will continue to work.

You can take this up with sales - I'm sure they will happily accommodate this request once your purchase has been made.

Personally, I think the optional configuration is the way to go in any case. We are currently in the process of creating a release and corresponding patch that is among other things, supposed to allow our program to be certifiable under Vista. If we are locked into an earlier release of the program, and changes that you make to your program to fix any last minute Microsoft changes will be unavailable to us. Also, are the scripts created by InstallAware backwards compatible from 6.0 to 6.1.n? If not, having some of us on one version, and some of us on another will mean that any work we do would not be sharable, which is one of the reasons, SCM is going to be taking over a lot of the releases.

[CandiceJones]

Backwards compatibility as far as your setup sources, projects, etc. are concerned is not an issue. You could in fact open up a project created in InstallAware 2.x and it would load and build in 6.14 without any changes. The only thing that changed is the file layout for build media, which is normally not any matter of concern. It only causes a problem when you are doing patching, because this is how the one-click patching establishes links between old and new versions.

[ken rentz]

I was scanning the forum, and it looks like the 6.0 version of the program may have problems with Vista. Is this the case, and if so, what are the problems. One of the reasons for our patch is to fix Vista compatibility problems. If the 6.0 version of InstallAware does not work correctly with Vista, and 6.13 does not allow us to patch installs in the field, then we have a serious problem.

[ken rentz]

Backwards compatibility as far as your setup sources, projects, etc. are concerned is not an issue. You could in fact open up a project created in InstallAware 2.x and it would load and build in 6.14 without any changes. The only thing that changed is the file layout for build media, which is normally not any matter of concern. It only causes a problem when you are doing patching, because this is how the one-click patching establishes links between old and new versions.

This is not the backwards compatibility that we would need. What we would need is the ability to load a 6.1 modified script into a 6.0 version of the program in order to get around the incompatibilities of the patching that we need to support our customers

In order for the script files be fully backwards compatible, an older version of InstallAware would need to be able to recognize functionality that did not exist when it was created, which would be one heck of a trick. The best I could probably hope for was that any new functionality would be flagged and ignored.

[CandiceJones]

The kind of backward compatibility you are talking about does not exist anywhere As you say, its quite impossible.

Backward compatibility typically means that your projects created in old versions will work in new versions. Ex: Microsoft VB.NET is NOT backward compatible. Borland Delphi IS backward compatible.

Taken in this sense, InstallAware is fully backward compatible.