• New components and objects - The ALP run-time library now contains all the AXPack1 family components:

  •  AXPack1 core - (newobjectspack1.dll) is now extended with several new objects: COMScriptThread, COMSleeper, Event, Mutex, Semaphore - a set of objects allowing you to run scripts as background threads (running long tasks behind the scene). StringUtilities - powerful string formatting set of functions compatible with the C library's printf but supporting many extended features (especially useful for SQL statements generation).
    Improvements in some of the existing objects were implemented:
    Composite objects now initialize while created and can be easily used as ASP enabled objects (objects with OnStartPage/OnEndPage that receive internal access to the ASP objects when created).
    Various minor additions have been made in some of the other objects.

  • NetStreams - (netstreams.dll) a new member of the family. It contains several objects that allow the application to implement TCP/IP and IRDA functionality at any level. The objects from NetStreams library supply the connection - once established a SFStream object can be attached to it and you can drive it as like it is a file.

  • SQLite COM - (SQLITECOMUTF8.dll) a new member of the family. Fully functional zero-configuration SQL database engine and interface to it in a single DLL. It can be used on the fly without need of ANY permanent configuration or installation and it is perfect for autorun scenarios and applications that want database independent of ADO, Jet and OLEDB. Absolutely no system updates are needed!

• ALP core now incorporates all the standard processing modules (Content Generators) - ASP, CGI and the others in the core's DLL (iewebsrv.dll). Therefore the number of the DLL-s has been lowered and customizing redistribution packages is a bit easier. Having the modules in the same DLL also removes the need of data marshaling and the speed is increased 10-30% depending on the page specifics. The cgstandard.dll and alpaspcontext.dll are now obsolete and no longer needed (these were the DLL that contained the standard CG modules before). Yet the support for external modules is intact and custom processors can be built like before.

• New features in ALP. While the most interesting new features are in the ALP run-time libraries, ALP itself now includes some new features.

  • Security features. ALP now incorporates several security oriented features that help the developers build applications secured against any possible hacker attack.

    • Security URL - (see directory settings in ALP settings shell extension). The directory settings now support an entry that instructs ALP to serve the content from the affected directories as like it comes from the URL specified. This allows the developers to synch the security zones of their online and ALP content with two major benefits:
      - No problems with Windows XP SP2 info bar. The content impersonates the specified URL and is allowed to run client side scripts.
      - Safe cross frame scripting between online and ALP content. If you have 2 or more frames that show mixed content - some ALP pages, others page from an online WEB site you can permit cross-frame scripting by setting the SecurityURL for the corresponding ALP application directory(ies) to match the URL of the online WEB application.

    • Unattended Code Execution Protection (UCEP). This is a simple directory setting that allows the developer secure the application against hacker attacks. When set the application must be entered through one of the default documents - otherwise an error is shown (Safe entrance required). This is a simple measure but it is enough to discourage the hackers from using your application as system penetration tool. It ensures that no online WEB page will be able to execute pages from your application with parameters that will cause it to perform a harmful operation. The developer just needs to consider which part of the application may pose such a danger and set this setting for it. Even if there is no risk at all it is most often safe to set this option while most applications are constructed in manner that makes entering them from a default document preferred.
      A new pseudo header is supported: ALPHeader-ResetSafeEntrance - you can use:
      Response.AddHeader "ALPHeader-ResetSafeEntrance", ""
      to rest the application state and require the next reference to your application to come through one of its default documents. This is useful when it is clear that the task for which the user has entered your application is complete and you want to guarantee that even if the user leaves the window open no hacker attack will be possible.  

    • Browser requirements. This is a feature with dual meaning - security and compatibility. Through these settings (see ALP application - Security settings) your application can be configured to require ALPFrame browser in order to run. It is even possible to require ALPFrame browser with a specific configuration (APPID) recognized by the APPID setting put in the alpframe.cfg. Thus you may disallow your application to be executed in IE or in ALPFrame configured inappropriately. The benefits are: 1) Your applicatio will prevented from running in IE or ALPFrame configured in non-suitable way which will guarantee that the users will always run your application from the right shortcut or CD even if they tend to dig into their hard disks and do things they do not understand. 2) Your application will be guaranteed that it will benefit from the restrictions ALPFrame can give (see below) which may be important in order to give the users ultimate protection from attacks and other threats.

    • ALPFrame browsing restrictions. ALPFrame now supports a set of browsing restriction features that allow the developer configure special instances of the browser (as many as needed - on the same machine different presets can be configured and exposed to the user through different shortcuts). This includes ability to deny browsing to certain URL-s or protocols, configure warning messages shown once per profile or every time the user navigates in a direction considered potentially unsafe and so on. The restrictions may vary from restriction to the application(s) you ship with ALPFrame only (most restricted) through limited WEB browsing to full browsing allowed with some warnings or without them.
      While this may be considered as paranoia it can be very helpful for corporations where protection against future problems is desired.

• Behavior adjustments
  • A new IIS compatibilitylevel has been added - 3. See ALP Settings shell extension - ALP Application settings - settings about files processed as ASP. If set: 1) Session and Application will extract values from any objects passed to them (no longer needed to use recordset("Field").Value). 2) The returned values list from Request("FieldName") when the field/parameter does not exist will act as Empty instead of empty string. Note! The default setting for IIS compatibility is 1 and is retained because it is needed in order to keep ALP compatible with the existing applications. To make use of this feature you need to create/edit the settings for all the file types processed by the ASP module in the ALP application settings for the folder containing your application. 
• Problems fixed
  • Previously it was required to have both Application_OnStart and Session_OnStart defined in global.asa if you intend to use one of them (i.e. none or both were required) - otherwise the sessions were lost. Now this is fixed and only the routine actually used is required in global.asa. 
  • A problem in ALPFrame has been fixed. Previously it was impossible to use certain keyboard combinations as accelerators, now all the supported combinations work correctly. Now the ALPFrame menus are with higher priority and whatever you configure comes first. This allows handling Ctrl-C/Ctrl-V for instance and thus creating copy/paste functionality in your pages (ALPFrame forbids copy/paste by default - you need to implement menus and handlers for them in order to allow it. This allows the application permit these operations only where the developers wants them).

Version 1.1

• Global.asa support
• OBJECT RUNAT=SERVER and SCRIPT RUNAT=SERVER tags support (in both global.asa and normal ASP pages)
• Mixed script languages in ASP pages
• Upload (multipart/form-data encoded forms) support
• Miscellaneous additions in ALPFrame and ALPInstall
• ALP Settings shell extension (edit ALP site/application/directory settings)
• Support for ASP objects
• Bundled with newObjects ActiveX Pack1 and NetProbe (beta - requires Win2k/XP or later)
  • OLE compound files access
  • FS access binary and text mode
  • Record based access to files and streams
  • Protocol independent connectivity (beta - requires Win2k/XP or later)
  • and many other features included (all compatible with IIS as well)

Version 1.0.5.8

• Response.Write method now accepts values non-convertable to string.
• newObjects collections in the ALP package are updated with the latest version. These components are used in the Request, Session and Application implementations.

Version 1.0.5 

• This version includes the fix described on the ALP site - problem parsing HTML comments.
• Several mistakes in the documentation are corrected
• UtilStingList collection is extended and corresponding behavior of the Request collections is corrected to be compatible with ASP see Request Collections comments for more details.
• Support for a few new options was added to the ALPInstall. See ALPInstall configuration for details.
• Redirect method was added to the Response object and dummy implementation for Response.Flush for compatibility reason.
• Support for the Microsoft Script Encoder was added - see "How to use encoded scripts" for details. 
• Prebuild redistribution package - containing only the ALP engine (without documentation and samples) is available for the registered customers.
• Examples showing how to use encoded scripts were included.