Libraries and components (for developers)

Skip to main content (skip navigation menu)

Libraries and components (for developers)

icon for minIni minIni: a minimal INI file parser
Open source 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.
icon EGI 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,
icon AniSprite 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.
icon Panodome Panodome - Panorama viewer
Panodome is a viewer for cylindrical panoramas; it allows you to build immersive environments from these panoramas.
icon Rosette Rosette - internationalize applications
Rosette helps with the creation and maintenance of applications that must be presented in multiple languages.
icon for DOS products 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.
icon other products WaveMix - real-time sound mixing
Freeware 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.