This page lists several ALP application deployment samples. The application
role is assigned to simple pages in order to make the samples more simple and
easy to understand. Only a few of the samples contain important ASP code (see DB
on th 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 to the
update (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. To build your own setup get the closest
example(s) and change its configuration and content. Download the ZIP files
if you want to use the sample and the SFX (Self extract archives) if you
want smaller and fast preview only. The SFX packages are created with WinRAR
and can be unpacked without starting them by using the WinRAR archiver. The SFX
packages are configured to start the installer or the ALPFrame and will not
allow you to extract the files manually.
SFX EXE (480k)
||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 other setup)
installation. This package contains the ALP engine and the application and
||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
||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 188.8.131.52 (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 with ability to remove
the copied files from the Add/Remove applet.
** The SFX and the ZIP contain the same files the considerable difference in the
size is caused only by the fact that WinRAR is much better archiver.
Adopting 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 or 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)
- Review, delete add options in the MAIN section (such as RunOnce,
- If localization is needed (or you need 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
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 CD.
Catalogues, Presentations, References etc.
- installed autorun - the application is installed on the PC but
the major part of the data (data base, other resources) are still on the
CD. E.g. the installation process is short and simple but the CD is
required in order to run the application. Encyclopedias, Business
applications, Recurring catalogues, other complex systems and hybrid
applications (such as WEB/ALP hibrids)
Pure autoruns are not always possible depending on the components
the application will use. For example an application that uses many COM
objects from different vendors will need to install them first - so installing
the application also will not make the install process much longer, nor more
complicated. Thus pure autorun limits the technologies allowed to the ALP
standard components (ALP objects, ActiveX pack1), 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 mode.
See 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 (Note that alpframe.cfg is standard for
the non-autorun sample - it is not recommended to change it).
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 will
receive support). 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 ALP
What causes the limitations of the pure autorun applications? These are
programs that shall run on any desktop Windows system beginning from Windows
95. 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 - contrary you can 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 - 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 this site), or other
components implementing IDispatch in registry independent fashion.
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 Pack 1 includes components for record based access to
files and streams and if you want to go that way it is possible and even
easier to do in ASP.
If you have questions please contact