| newObjects Active Local Pages 1.2
||$15 (M) $320 (D)
Application deployment (deployment examples)
We recommend you read this page on the new ALP site: www.activelocalpages.com
This page lists several ALP application deployment samples. The application
role is assigned to simple pages in order to concentrate on the deployment
techniques. Only a few of the samples contain important ASP code (see DB on the
CD for example) and there is one common ASP based tool included in all the
examples that may need it - TESTPC directory with two ASP pages intended to
check the PC for certain common components and provide the user with link(s) to
updates (on the net or on the CD - the samples point to our site but can be
changed to point to a file on the CD).
The deployment scenarios are many and we hope these samples are good
representation of the most popular ones. To build your own setup you can get the
closest example and change its configuration, then replace the dummy application
with yours. Download the ZIP files if you want to use the sample and the SFX
(Self extract archives) if you want small and fast preview only. The SFX
packages are created with WinRAR and can be
unpacked without starting them by using the WinRAR archiving utility. The SFX
packages are configured to start the installer or the ALPFrame after unpacking
and will not allow you to extract the files from them.
The examples list:We are in a process of updating the deployment
samples - the samples that are not available yet will be there after a few days)
||Simple autorun application
based on pure ALP components only. It has no need of ADO therefore the
package does not contain testing code.
||Autrun application with
ADO usage. It needs to check the PC and provide update links if needed.
||ALP redistributable files.
No application is included - this package is intended to be started
almost silently on the PC to install the ALP engine. Recommended if you
use other setup solutions (configure it to start after or before the
installation. This package contains the ALP engine and the application
and installs them.
||Application developed for
autorun deployment that allows the user to copy it to the local hard
drive as an alternative. It is just copy process - no component
registration is done - e.g. the only purpose of such package will be
keeping the CD drive free.
||Autorun and install. This
package contains two applications (or two versions of the same app.) -
one for installation and one for autorun. The both applications are
mixed by simply putting them in different directories.
||Like the previous but this
time all the common files are shared by the autorun application and the
installer. E.g. use the previous if you are in hurry and choose this one
if you want to pack everything most efficiently.
(autorun starts the installation)
||Installs the logical part
of the application to the PC, records in the registry the path to the
data base (in real world it can be also a directory with db, images and
other resources) and then the installed application asks for the CD/path
to the DB if the file is not found where expected (as it was written in
the registry by the setup).
||This sample contains ALP
and PHP 18.104.22.168 (a little stripped down from some unneeded files - but
more can be removed on your decision). It shows how PHP application can
be distributted with ALP. In this case this is an installed version
which puts independent copy of PHP on the target PC and uses it to run
PHP pages. The sample contains a little ASP startup page that allows the
PHP application to be informed during the start-up for the location of
the work data. For example it may use huge database from a CD or also
other resources not packed with the main PHP files in order to save
space on the machine. The PHP engine runs as CGI. Unfortunately it seems
there is a little bug in the Windows distribution of the PHP which
prevents more flexible solutions to be built. For example there is no
way to force PHP to run without creating a simple php.ini file -
obviously this is needed for pure autoruns (where nor ALP nor PHP is
installed on the terget PC)
* The installation is in fact simple copy operation. The uninstall registered
in Add/Remove programs will simply remove the copied files..
** The SFX and the ZIP contain the same files the considerable difference in the
size is caused only by the fact that WinRAR offers better compression than ZIP..
Adapting an example. Download the ZIP archive of the sample and unpack
it in an empty directory. Test it - see how it works where the application
resides and replace the sample application with the actual application which
will be deployed. See if it needs additional components such as components that
are not integral part of ALP (most often components from other vendors) and
include them in the setup.cfg (in case of installation). Review the entire setup
file and pay special attention to these parts:
- Base path of your application - common convention is to select something
- If you have many additional components to include probably one or two more
source aliases will simplify your further work.
- See if it will make sense to allow the user to select the installation
location and add in the ASKDESTIONATION section a dialog definition for the
- Define appropriate links to your application in the LINKS section.
- Select carefully the application signature, log file prefix and uninstall
file name (in MAIN and UNINSTALL sections). You can use the same signature
for all of them - for instance you can devise something from your company
name and the application name.
- Review, delete add options in the MAIN section (such as RunOnce,
- If localization is needed (or you want to change all the texts shown by
the installer) copy the sample entries from the ALP documentation to the
TEXT section (subsection of MAIN) and edit them.
- See if read-me dialogs will be needed - to show license agreement, some
- Configure how the application will be started after completing the setup
See ALPInstall in NDL for full
description of the setup.cfg syntax.
Which samples to download?
If you are going to deploy autorun application
Autorun applications are most likely of two different types:
- pure autorun - nothing is installed, everything runs from the
removable media (CD, DVD, flash memory card/disk). Catalogues, Presentations,
- installed autorun - the application is installed on the PC but
the major part of the data (data base, other resources) are still on the
removable media. E.g. the installation process is short and as simple as
possible but the CD is required because it contains data and resources
used by the application.. Encyclopedias, Business applications,
Recurring catalogues, other complex systems and hybrid applications (such
as WEB/ALP hybrids)
Pure autoruns are not always possible. This depends on the
components the application will use. For example an application that uses many
COM objects from many different vendors will most likely need to install at
least part of them first - so installing the application also will not make
the install process much longer, or complicated. The pure autorun most often
limits the components allowed to the ALP standard components (ALP internal
objects and ALP Run-time library), ADO (features available in 1.5 or later -
MS Access DBs in format compatible with MS Jet 3.5 and later), a few other
standard components always available with IE and Windows OS, COM components
from us or other vendors especially developed to support ALPFrame in autorun
See these samples: ALPAutorunSimple, ALPAutorunDB, AutorunCopy,
Installed autorun is not bound by these limitations and may
contain any possible application. Everything missing can be installed.
See samples: ALPInstallCDDB, ALPWithAppInstall, AutorunInstall,
What you need to know?
See the ALPInstall or/and ALPFrame branches of ALP documentation (installed
with the full ALP package only) and review the sample configurations in the
deployment samples of your interest.
You can use ALPInstall to deploy applications without ALP or even non-ALP
applications (even if we permit everyone to use it only the ALP customers
receive guaranteed support for ALPInstall). Also in case you want to prepare
autorun CD but installation is unavoidable - you can configure the setup to
run once and if the user tries to run it again to start the already installed
application (see the ALPInstall documentation in NDL).
What causes the limitations for the pure autorun applications? When autorun
is considered it is assumed it would work on any desktop Windows system
beginning with Windows 95 or at least Windows 98 if your audience is such. ALP
caries wide range of components developed and tested to support all of them
and there are certain standard components preinstalled on every system. Beyond
that there is no guarantee the component you build (or downloaded) will be
preinstalled on all the Windows PCs - on the contrary you can be sure it is
not there by default. By design the COM components need registration with the
system and without it they are unable to function correctly - so they cannot
run from a CD without at least temporary registration. ALPFrame supports
simulation of this process through its configuration but it can be used only
by COM components written in ATL (using the typeinfoeex.h - see the code
snippets on our site), or other components implementing IDispatch in registry
Although the above limitations may look a bit too strict in fact they are
common for all the pure autorun systems - there are features supported by the
autorun system itself and very limited set of external features that can be
accessed. The standard ALP components include wide range of tools - in fact
there is support for many non-visual features otherwise available only for C++
or VB applications for example. Many of the autorun CD solutions are built as
custom applications that use generic file access to implement data base like
functionality. ActiveX Pack1 family includes components for record based
access to files and streams and even ADO independent SQL database engine.
Generally an ALP application can achieve better platform compatibility with
little efforts and minimal functionality sacrifices compared to many
traditional programming environments.
Today the Windows 9X systems are much less. One can say considering
compatibility with them is a kind of paranoia. ALP gives you various choices
and you can serve any kind of audience with applications built for it. Even if
you consider only Windows 2000 and later systems as targets for your product
the ALP flexibility and minimal dependencies give you interesting
opportunities - the rich run-time library will save you much troubles with
untested external components and specific system configurations.
If you have questions please contact