The library is made by a set of mostly interrelated parts, each dealing with a specific functionality and each more or less OS-dependent. Here's a list:
- Wrapping code for portability issues: macros for symbol visibility and signed integer number representation;
- Initialization and finalization: initialization and finalization procedures;
- Error handling, assertioning and debugging: error codes, debugging code blocks, assertions against statements and function parameters;
- Memory management: customizable memory handling procedures for each layer (from the first development release) and for different purposes (planned for some future release);
- Thread synchronization: mutexes (from the first development release), atomic CAS (compare and swap) operation, CAS-based spinlocks, semaphores and other more complex locks (planned for some future release);
- Message reporting and logging: routing system for hierarchically organized text messages and status notifications with optional logging;
- Filesystem interaction: generic file handling, directory scanning, file placing and file path retrieving policies;
- Dynamic loading and module handling: dynamic loading and unloading, symbol retrieving;
- Internationalization: integrated support for text translations and localization (planned for some future release).
As you can see the union of such facilities constitutes a lightweight yet powerful basis on which the rest of the framework can be built without directly interfacing to the OS. This means that, apart from external dependencies each higher-level library/application/module can have, every time NASPRO core is ported to a new platform, the whole framework will start working on that platform too without modifications.
Also, because of this separation of competence, improvements and optimizations made in this library will probably be the most effective for the rest of the framework and it is also very likely that refining will require less adapting and adjusting work after a period of API stabilization.
