|This page is intended to inform you for the ALP
modules, configuration files and applications structure. It points to the parts of this
help file containing the appropriate reference information.
In two words:
ALP allows the ALP applications to be moved by just copying their directory tree. All
configurations allow relative paths and applications can be easily built independent of
their location. Most ALP applications equal to the Virtual ALP site they
occupy and moving the directory tree that begins in the directory
containing the alp.site file will move the entire application.
Core components are installed automatically but this page provides
additional information that allows you to make changes and add additional ALP components
when obtained for example from the resources WEB page. Also the page describes some of the
details you should know when building redistributions.
ALP core modules
ALP core components consist of several DLL files and 3 global configuration files. The
count of the DLL files required for its functions depends on the features required on the
iewebsrv.dll - implements the ALP Engine and is always required. Its
location is important because ALP loads its default/global configuration files from the
directory containing the file. This behavior helps to avoid need of registry settings and
thus makes ALP easy moveable.
iewebsrv.dll implements Asynchronous Pluggable Protocol name space handler. It is
assumed that it will be loaded mostly by the Internet Explorer WEB browser. The ALP
installation registers the components found in the module and also registers the main
component as alp and alpdump namespace handler. Using the special tool (ALPFrame) from the
resource site ALP can be used without the registration as a temporary namespace handler
(read the ALPFrame documentation carefully if you are going to use it).
Core dll loads the global configuration files on request: alp.site,
alp.application and alp.directory.
These files are expected to be in the same folder and is strongly recommended to avoid
changing them on the end-customer systems. Some of the applications written by other
vendors may depend on the default "factory" settings thus changing them may
change the behavior of the entire system. During the development process changing the
configurations can help sometimes but redistributing global configurations adapted to a
specific environments will lead to the same effect as changing the core system settings in
the Windows registry and redistributing the OS in this form. All application requirements
can be reached through creation of a local configurations.
There is one exception - native applications. They are registered system wide and thus
they must be registered in the global alp.site file (see LIBRARIES
in alp.site). Redistribution should contain all the required content generators - the
installation will take care about the versions. Thus this part of the configuration is
intended to add but not remove the features to the system. With the new versions of the
ALP and some of the content generators recommended global settings will change we will
provide updated global files applicable for the redistributions. Installation will mix
them with the currently available files on the system.
There are two types of DLL that ALP uses - Jacked-Objects modules and COM modules.
- Jacked-Objects modules are registered with the ALP core in the LIBRARIES section in the global alp.site file. ALP
maintains a root class library and all Jacked-Objects objects use its services to create
the required objects. This allows some of the classes to be replaced with new or custom
versions in some applications.
- COM modules are used by the classes defined in the precious paragraph indirectly. They
are registered as a typical COM modules.
Some of the DLLs contain both Jacked-Objects and COM objects thus they need the both
From ALP 1.2 the standard ALP modules (ASP, CGI and so on) are
implemented in the core ALP DLL iewebsrv.dll. The remaining binary files
are from the ALP Run-time library and the oither ALP components.
newobjectspack1.dll - ALP
Run-time library core DLL. ALP uses newObjects
ActiveX Pack1 family as run-time library.
netstreams.dll - part of the ALP
Run-time library. Implements the networking components - see NetStreams.
sqlitecomutf8.dll - part of the ALP
Run-time library. Implements the embedded database engine. See SQLite
NetProbe.dll - (Supplied without guarantee and support). A
protocol independent network and pseudo-network communications. See NetProbe.
ALPFrame.exe - The ALPFrame
VarioMenu.dll - used by ALPFrame to support the dynamic
menus in ALPFrame.
ALPShellExt.dll - ALP Shell
extensions invocation facility.
About the default settings
As noted above redistributions of the ALP with your applications should avoid changing
the global settings. Here are some summary notes about the files:
alp.directory global file should be never changed because access
restrictions expected by the applications will change. We recommend all the applications
to redefine the required features in their local files but it is still possible that some
of the applications will not do this. Default documents are also registered in this file -
changing the set of these documents can be comfortable for a particular user but will not
be a good practice for the redistributions.
alp.site global file must be changed by the redistributions in
difference with the other files. Registration of the modules is in this file thus changes
are permitted but redistributions should not unregister modules found in the system
(installation does this - but if because of some reason you want to build your own
installation it should take care of this). The FIXUP keys changes depend on their meaning
and currently there is no key that causes the redistributions directly. You should never
set your VendorID in the global alp.site - it will be ignored. Its place is in the local
alp.site - in the application directory.
alp.application is a very complex file and describes how the ALP
"drives" the applications. You should never make changes that may change the
expected behavior. For example adding an association of the .gif files with some native
application in the global file will cause all GIF pictures in all ALP applications on the
machine. If you need such change do it in the local file in your application. Prebuilt
file provided by us contains a small count of file extensions in order to prevent
collisions but still provide some default behavior. Associations entered by us are the
wide known ones and the specific ones. Long file extensions are used for the specific
cases - such as js-script, vb-script and html-tml. CGIs are registered only for the EXE
extension and unwanted execution of an EXE file dedicated for download should be prevented
by setting the Execute to 0 in the alp.directory file in the application. There are many
popular CGI extensions but their processors are not available on every machine thus
redistributions using such tools (perl and PHP for example) should contain the processors
as well. In that case global registration of the extension is still not recommended (for
example .pl with perl processor) unless the tool installed has an appropriate version
checking and good compatibility with the previous versions.
Installing on the network. ALP will run from network share but it
requires checking of many files and this will slow the performance if the network is too
slow. ALP targets local use for the networks WEB server will be the right choice. With the
WEB share application for the ALP that we plan to publish later this year ALP applications
will be able to become automatically WEB sites. We think that such tool will be very
useful in small offices that have no resources for a WEB server administration.