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 particular desktop.

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.

Modules

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 registrations.

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.

List:

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 COM.

NetProbe.dll - (Supplied without guarantee and support). A protocol independent network and pseudo-network communications. See NetProbe.

ALPFrame.exe - The ALPFrame browser.

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.

Other notes

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.