Libraries and components (for developers)

minIni: a minimal INI file parser: minIni is a programmer's library to read and write "INI" files in embedded systems. minIni takes little resources and can be configured for various kinds of file I/O libraries. minIni provides functionality for reading, writing and deleting keys from an INI file, all in a tiny and easy to port library.
EGI - advanced frame animation: EGI is a development tool and component to create so-called frame animations, and to embed these animations in your application. EGI is very flexible and it allows for scriptable animations that interact with an application. The file format is an extension of the well known FLIC file format,
AniSprite - advanced sprite animation: AniSprite allows you to add screen effects, layers and simple animation to your program or game. AniSprite has been used in games, in simulation software and in desktop applications alike.
Panodome - Panorama viewer: Panodome is a viewer for cylindrical panoramas; it allows you to build immersive environments from these panoramas.
Rosette - internationalize applications: Rosette helps with the creation and maintenance of applications that must be presented in multiple languages.
Daemon server, DLLs for DOS: Daemon server is resident server program, running under DOS, that allows you to build code libraries that are dynamically loaded and unloaded. Similar to DLLs (OS/2, Windows) or loadable modules (Unix, Linux), that is, but now for DOS. Useful in embedded applications and when maintaining old DOS applications.
WaveMix - real-time sound mixing: Multiple digitized sound clips are mixed and output to the sound card in (near) real-time. WaveMix was developed by Microsoft Corporation; the current release is adapted and maintained by CompuPhase.

Why DLLs instead of ActiveX?

Most of our "programmer's libraries" are available as DLLs. None of our products is available as a VBX, OCX or "ActiveX" DLL. We have made this decision for three reasons: best performance, best portability and best flexibility.

Performance: When using C/C⁺⁺, the overhead of calling a function through an OCX may be negligible, but when using the IDispatch interface, the overhead is real.

Portability: There are (still) quite a few good programming tools/compilers that do not support ActiveX or OCX (or at least, not easily). By using a DLL interface, our libraries can run with PowerBASIC and with Visual Basic, with Authorware and with EGO, with Visual C/C⁺⁺ and with VectorC,...

Flexibility: While the underlying COM technology is equally flexible as the DLL interface, a typical ActiveX "container" application will impose extra requirements. You cannot add any COM server into a Visual Basic form, for example, the object has to implement a few interfaces to be usable by Visual Basic. One of these required interfaces, subsequently, needs to supply a "window handle", which means that the object must create a window and must be contained in a window. This is a severe and artificial limitation, which does not fit into the design of our libraries.

As a side note, "DLL hell" (mismatches between the DLL version and the version that the calling application expects, usually because the DLL was replaced by a different version) is not unique to DLLs. Any shared file may give version problems (even something as mundane as an INI file) and ActiveX/OCX technology has certainly not lived up to its promise to correct these troubles. Most of the version problems can be solved by storing DLLs and other files in the same directory as the program that uses them. This the core idea of the "side-by-side components" technology, by the way.