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
||AXPack1 by DLL
and Files - File system, OLE files, core API for
abstract streams and storages, binary data tools.
- TCP/IP (v4/v6) networking and IRDA support.
- Advanced COM tools and misc. helpers
objects - Set of objects to enable development of
custom COM objects in script.
Script hosting - Running and using (another
scripts) from your applications.
see also Composite
Databases - Fully functional SQL database
COM, SQLite3 COM,
Cryptography - Hash/HMAC, symmetric and
Data management - various objects for data
management in-memory and over various medias. Dictionary
objects, configuration and platform independent data
Advanced string techniques - string formatting etc.
Synchronization - Access to the system's
synchronization objects. Needed for complex multithreaded
projects and other scenarios where synchronization between
concurrent tasks is a must.
Objects: Event, Mutex,
Classification by data management technique
Streams - The objects that must/can be used
through the Stream driver (SFStream)
SFStreamCrypt, see also
SFMain for the
internal support for Memory Streams and OLE File
Structured data consumers/suppliers - objects
that use VarDictionary
trees to pack their outputs or
expect data packed in VarDictionary trees.
Objects: ConfigFile, Composite objects,
COM, SQLite3 COM,
(error info only). Products
outside AXPack1 - ALP, ASPC,
and many others.
(ver: 184.108.40.206) - the core DLL. You need to re-distribute it always - all
the other components use it.
Depends on: newObjectsPack1.dll
Depends on: newObjectsPack1.dll
Depends on: newObjectsPack1.dll
Depends on: newObjectsPack1.dll
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.
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").
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).
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:
- 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.
- On desktops: nwMicroHost.exe should be installed in the
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
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.
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.
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
- 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)
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