newObjects ActiveX Pack 1 family is a set of components designed to use each other and thus offer wide range of functionality in many areas. The core element of the family is newObjects ActiveX Pack1 which can be used alone, without any of the other members of the family. The other members of the family use certain features provided by the core DLL and sometimes (optionally) features from other DLL-s of the family.

The area covered by AXPack1 family is huge - file access, utility routines and objects, script hosting, thread management (including running scripts in threads), composite objects (writing COM classes in script), Networking TCP/IP, IRDA, Bluetooth, SQL Database engine and interface to it and so on. And except part of the cryptography functions AXPack1 family is freeware! 

The AXPack1 comes also with a minimal scripting host application (newObjects Micro Script Host) which is simpler than Windows Scripting Host but in contrast is available for all the Windows platforms and provides exactly the same functionality on each of them (Desktop, Pocket PC, Smartphone and every other display based Windows CE device).

AXPack1 family version: 2.5.0
The particular DLL versions in this version of the AXPack1 Family are listed in the table below.
Note: The AXPack1 family version characterizes the family edition and is also the version of the core DLL. The versions of the other DLL are maintained on their own. The list below shows the version for each DLL included in the documented release.

Where to start

These are links to the different areas of the AXPack1 family documentation. To help you find the part you need the same links are provided in two different layouts - by category and by dll. Note that the same link may appear in more than one category because the related object/set of objects may fall in more than one category..

Supported platforms

AXPack1 family supports:
- Windows 95/98/ME, Windows NT4/2k/XP/2003/Vista and later. 
- Windows CE 3.0 and later (incl. CE.NET 4,5 and later).
- Pocket PC (any version), Windows Smartphone 2003 and any later version.

Till now a compatibility problem with new Windows versions never occurred and it is very unlikely that such will ever occur. All the features in AXPack1 are implemented over trusted parts of the Windows API, when a feature requires an API that seems to not be available on all the Windows versions we implement it on our own to guarantee it will work the same way everywhere. There are a few exceptions which are marked in their documentation:  INIFile and SFShellLink objects, a few members in Storages and Files. The case with INIFile is such that it is supported only to cover for an older component of ours - it will not be developed further - use ConfigFile instead. SFShellLink suffers from the differences of the different UI-s in the different Windows versions and while we plan to make an effort to make it available everywhere this will concern only part of its functionality (unfortunately what it does concerns the Windows shell and there is no way one "can do it on his own").

Redistribution considerations

It is not very likely any particular application to use all the AXPack1 features. Therefore when you re-distribute an application that uses the pack you can scrap the unneeded DLL-s. Still you always need to include the core DLL - newObjectsPack1.DLL because it is used by the others. There is one possible exception - HashCryptStreams.DLL. It provides the Hash/HMAC and Symmetric cryptography functions in two forms - one independent of the AXPack1 core and one that uses the stream features of that core. If you are not using the stream cryptography objects (SFStreamCrypt and SFStreamDigest) you can scrap the newObjectsPack1.DLL if you are not using something from it explicitly. 

All the DLL are self-registering COM DLL. Whatever setup solution you are using for your application it should be able to register them - check its documentation to see how this is configured with it. If you are looking for a setup solution (for desktop PC) we provide a simple setup solution (see ALPInstall), which is good for small and middle sized applications. For Windows CE Microsoft provides a fully featured built-in basic lave setup solution - CAB files which can be used directly or extended with 3-d party components - of course, it supports COM DLL registration (See MSDN for more info).

Recommendations about the install locations:

If you are using a setup solution which installs your application and part or all of the AXPack1 it is recommended to:

1. For desktops: Put and register all the DLL files in Program files\Common Files\newObjects\ActiveX. Also if this needs to be specified explicitly in your setup solution, they all should be registered as shared DLL.
   For Windows CE devices there is no particular location that can be called typical. You can install them in the internal memory or on a memory card - as preferred.  
2. On desktops: nwMicroHost.exe should be installed in the Windows\System32 directory.
   On Windows CE: It is recommended to install nwMicroHost.exe in the same directory where the DLL-s are copied.
   The nwMicroHost.exe does not need registration or other processing - only copying (and creating a shortcut if desired).

None of the above is a requirement, these are recommendations only and if there is a consideration that makes another location preferable there is no problem to choose it.

If the size of the setup package is not a problem it is a good idea to include the entire pack - even the parts you do not use. This can be potentially useful in environments where many applications use AXPack1. Installing the micro host alongside the DLL-s may prove useful if you are also involved in direct support of the machines/devices on which your application(s) work - for example you can use it to write some admin or test scripts when needed.

Versioning

The AXPack1 Family version is bound to the version of its core DLL - newObjectsPack1.DLL. The versions of the other DLL are different and follow their own evolution. Sometimes they even represent something more, like in the case of SQLite where the first 3 parts of the version are the same as the SQLite engine version compiled in them. Thus, to identify the version of a particular DLL in the current edition of the family you need to look into the table above. Usually you do not need care about the versions - all the setup solutions support version checking and if a newer version of a particular DLL is already installed they leave it intact. All the AXPack1 is carefully developed to keep backward compatibility with earlier versions of its DLL. This is maximum priority for us and is considered even more important than correcting some inconveniencies. For example we can find out that the default configuration of a certain object can be made more convenient - if we do that the applications counting on its default behavior will fail with new versions of AXPack1, so we do not change what is already in use - never! If the change is too appealing we provide it as alternative implementation - a new member with similar name a fake object that actually creates the other but initialized in a different manner and so on. Thus the compatibility of the AXPack1 with its older versions is guaranteed.

Future extensions

AXPack1 family will continue to grow providing more complete coverage of the OS features, various abstract techniques and other technologies. Still, AXPack1 is by design a pack of non-visual ActiveX. It will never include any visual ActiveX controls that can be put on a form for example (see out other products for such components). This is not limitation - AXPack1 is designed to offer its features to all kinds of applications - visual or non-visual, hence it can play a role of a common run-time library for any COM based or COM enabled project you may want to develop. The availability for all the actual Windows OS versions guarantees that you can count on its features wherever you need them.

The next new components that will be included in the following months are:
  - BTongue - independent language processor of VBScript like language.
  - COM port streams
  - Additional cryptography algorithms and built-in support for some PKCS standards.
(These are planned for the next 2 updates after version 2.5)

Licensing

All the AXPack1 family is freeware unless otherwise specified for a particular DLL. Currently there are no such (non-free parts), however some of the new algorithms in the next version of HashCryptStreams.DLL will require license. However, what is free now will remain free, the non-free parts will be new additions which will return errors if the license is not present, while the rest of the DLL will continue to work without license as before.

How is it possible to maintain this all free? It is possible because the family is included as run-time library in our products and some of them are commercial. This allows us to spend time on the family and also allow free usage without support when the family is used without any of our commercial products and offer support for any customer who has licenses for one of the commercial products that include it. Of course this means that we are extremely interested in keeping the family in good order and bug free - thus we always try to answer interesting questions even if they come from users that use it as freeware. Anyone is allowed to include part or the entire family (as needed) in his/her product and redistribute it - no matter if the product is commercial or not. It is recommended, of course, to have some license or special contract that will provide you with support if the product that uses the family is commercial, but this is not required. For products based on our development tools that use this library - such as Active Local Pages the support comes automatically with the development license for the product that includes the AXPack1 family.