Aonix ObjectAda V8.4 Distribution

There are issues concerning the distribution of applications and DLLs produced by Aonix ObjectAda v8.4

These issues are not described in the release notes and support from Aonix hasn't been very illuminating.

The following is my personal understanding of the situation.

Binaries produced by ObjectAda v7.2.2 were self-contained, that is, they did not require any non-system DLLs to be distributed with them.

ObjectAda v8.2 revealed its Visual C++ heritage by requiring that the Visual C++ runtime library v7.1 accompany it.
Effectively this meant that the file MSVCR71.DLL had to be distributed along with the binary and placed somewhere within the DLL search path, typically either in the same directory as the executable or, more commonly, in the folder %systemroot%\system32

Binaries produced by ObjectAda v8.4 require the C++ runtime library version 8.
If these binaries are executed on systems running Microsoft Windows prior to XP,
for example Win2K, then the file MSVCR80.DLL has to be distributed in a similar manner to MSVCR71.DLL.

However things aren't so simple if the target operating system is Windows XP or later.
In this case the use of the C++ runtime library version 8 or later requires the use of Manifests.

Manifests are Microsoft's answer to "DLL Hell".
Using a Manifest an application or DLL has to declare which DLLs it needs, not only by name but also by version.

If a binary created by ObjectAda v8.4 is executed without a manifest it first complains that the application has failed to start because MSVCR80.DLL is missing.
If this DLL is then provided (by placing it into the DLL search path) the application still fails to start this time displaying the message
"Microsoft Visual C++ Runtime Library
Runtime Error!
R6034 An application has made an attempt to load the C runtime library incorrectly"

ObjectAda v8.4 automatically generates manifests when it builds applications or DLLs.
These are XML documents that can be viewed using any normal editor.
They have the same name as the binary but with the file extension Manifest.

Currently these manifests simply declare that the binary requires Microsoft.VC80.CRT version=8.0.50727.762

If the manifest is present in the same folder as the executable the manifest will be used to locate the correct DLLS.

If it is unable to find suitable DLLs the application will display the message
"This application has failed to start because the application configuration is incorrect" or
"The application failed to initialize properly"

DLLs controlled by manifests are usually stored in the %systemroot%\WinSxS folder
hierarchy. Under XP it is possible to simply copying the appropriate files however this is not recommended and under Vista it is no longer an option because the WinSxS folder has a special protection that allows only registered installers to write there.

Binaries produced by ObjectAda 8.4 require a Visual C++ Runtime that is compatible with version 8.0.50727.762.
This can be installed on the target system using a redistributable package called VCREDIST_X86.exe

There are several versions readily available from Microsoft.
I found version 9 (that is too new) and version 8.0.50.727.42 (that is too old).

Best therefore is to use the redistribution installation that was supplied on the same CD as ObjectAda 8.4 - namely version 8.0.50.727.762

Distributing the manifest in addition to the executable may not always be convenient.
Also a DLL created by ObjectAda 8.4 can be used by many applications and so it may not be
always practicable or even possible to generate a manifest for each and every application that uses the DLL.

Another problem is that DLLs can be loaded at run time using the load library API. In this case a manifest as a separate XML file does not work.

To solve this problem Microsoft have provided a mechanism whereby the manifest can be embedded into an application or DLL.

In the case of an application it means that the separate XML file does not have to be distributed along with the executable and in the case of a DLL that the DLL can be used by any application irrespective of whether it has a manifest or what application's manifest declares.
It also allows DLLs to be dynamically loaded.

To embed a manifest into an application use the command

mt.exe -manifest myprog.exe.manifest -outputresource:myprog.exe;1

To embed a manifest into a DLL use the command

mt.exe -manifest myprog.dll.manifest -outputresource:myprog.dll;2

Although the utility mt.exe is available without cost from Microsoft I had particular
trouble in getting hold of a copy, for example I could only download
it to a machine that had .NET framework version 2 installed.

To make life easier for users of Aonix ObjectAda v8.4 I have placed a copy of
the mt.exe utility (version 5.2.3790.2075) along with a copy of version 8.0.50.727.762 of the C++ runtime redistributable as a download on this site.

Incidentally, in situations where it is inappropriate or inconvenient to install the C++ redistributable, the manifest mechanism can be short circuited by placing a manifest file called Microsoft.VC80.CRT.manifest in the same folder as the executable.

This directs the system to expect the required DLLs to be found in the same folder as the executable. In this case MSVCR80.dll.

I hope that this article has been of help.
Please email any comments and suggestions for improvement to
Ada@White-elephant.ch