The Omni framework can be compiled for many platforms including many Unix and Linux derivations and the Windows and Apple lines of OS. The framework makes use of many OS specific API as well as standards conforming API's (like those in the C++ standard library or in the POSIX.1c specification).

Omni on Windows makes use of the WinAPI. For Unix and Linux variants, most API's used are POSIX.1c compliant and some are OS specific. For Apple platforms the POSIX.1c specification is used, as well as Unix specific API's and depending on the framework function, Apple specific C/C++ library functions will be used. For more information on which API's are called throughout the framework, visit the API's page.

Part of the goal of the Omni framework is to not have to guess what the function or class will do on different systems (i.e. we want to ensure predictable and deterministic behaviour regardless of platform). As the framework has morphed into what it is today, there have been caveats and impasses down the road of cross platform compatibility. These issues affect certain design decisions and Omni must make use of certain system level capabilities depending on what is being used or called to ensure proper determinism. For instance, the omni::mutex makes use of of the CRITICAL_SECTION type on Windows and the pthread_mutex_t type on other platforms. The mutex object (specifically the CRITICAL_SECTION) on a Windows platform is a recursive lock by design whereas the POSIX code for the mutex object has to explicitly define if the mutex is to be recursive, that is, code on POSIX systems will call pthread_mutex_create passing a pthread_mutexattr_t type with the PTHREAD_MUTEX_RECURSIVE defined so the underlying system mutex will be a recursive mutex. There are even certain portions of code that have to be explicitly enabled (via compile time flags) due to their non-portable nature; omni::system::path() is an example of non-portable code. Any source specific items worth bringing to attention (the omni::mutex, for instance) will be documented and explained in the corresponding help and source documentation.

The current version has been tested and works with the following platforms:

• Windows (Windows 2000 and above)
• Apple OS X (kernel 10.4 and up)
• Sun Solaris (10+)
• Linux and Unix/BSD kernel bases:
  Ubuntu 10.04, Fedora core 17, RHEL/CentOS 6.3, Linux Mint 13, openSUSE 12.3, Slackware 14, Debian 6.0.7, NetBSD 5.1.2, FreeBSD 9.1, OpenBSD 5.1, PC-BSD 10, RoboLinux, QNX 6.4.0, TurboLinux, ArchLinux, CoreOS, Gentoo, PCLinuxOS, PuppyLinux, Mageia, Manjaro, ElementaryOS, Zorin

This list is not an exhaustive list of compatible platforms, it's merely a list of platforms we have tested against due to their reasonable popularity as a distribution and due to time considerations (testing the compatibility of every fork of a specific Linux/Unix kernel is no longer feasible in today's cornucopia of distributions). If you do not see your specific distribution in this list (or have an older version), there's still a very likely chance the framework will compile and run as expected on your platform; as with any 3rd party library or source, you should always verify the tools being used against your needs.

Please be aware if you are compiling for Windows in MinGW/MSYS or Cygwin your code will be treated and compiled as a POSIX platform and not as a Windows platform. It should be noted that the Windows pthread libraries are wrappers for the appropriate WinAPI calls and certain code will output as if it were compiled for a Windows platform.
top

Platform Testing
To test a specific platform, a unit test was written utilizing the Omni framework and it passed if 3 conditions were met:

1. The unit test compiled successfully with the Omni source and needed libraries (-pthread or -rt for instance).
2. The functionality of the unit test succeeds; the outcome of the test was as expected and without error.
3. The functionality of the unit test did not change the expected results on the platform being tested.

The 3rd item being the most important in determination of final test status. If a test was written and it compiled on all platforms and each platform successfully completed the test as per the functional requirements (i.e. a mutex lock call should only return if it gets the lock), the test is considered platform safe, meaning that the specific function can be compiled and used on that specific system. If the test changes in any unexpected ways on a specific platform, research is done to determine if that specific platform might need a tweak to the code (as can be the case with certain Linux and Unix derivations). If a small tweak to the code can give the support needed and all tests have passed then the code is considered cross platform compatible. If the tests still fail or more than a small tweak is needed (like extra functions) for a specific platform, that portion of code is relegated to the non-portable section and annotated.

Non-portable code does not necessarily mean that it won't work on your platform, it merely means that the output cannot be determined to be the same across all platforms tested.
top

Embedded support
For Microsoft this is the WindowsCE and Windows Embedded line of OS, for Linux this includes any embedded Linux/Unix derivation.

Embedded support cannot be guaranteed as not all system libraries are available among the many embedded environments. However that does not preclude one from using Omni in an embedded environment. For a Microsoft build, the basic WinAPI set need be available and a POSIX compliant environment for a Linux/Unix based build. If your environment does not support exception handling (some Android platforms for example), you can specify the OMNI_NO_THROW preprocessor flag.

For other preprocessor flags that might be useful for your platform (embedded or not), visit the options page.
For system API calls that might affect your decision for using Omni in an embedded environment, see the API's page.

Please note that the Omni framework is an object oriented framework; one of its priorities is to ensure as small a footprint as feasible. That being said the Omni framework can still be heavy in certain classes simply due to object composition and inheritance. To this affect, there is the OMNI_LITE preprocessor define (among others) that can help slim down the framework considerably, albeit at the cost of reduced functionality in certain areas. Depending on your needs, reduced functionality may not actually inhibit your ability to take full advantage of the Omni framework; visiting the specific help page from the classes portal will give more information and other considerations to be taken.
top

Future support
When Omni was started, the C++11 standard had not be fully defined. The omni::smart_ptr is similar in function to the C++11 std::unique_ptr and the omni::sync::thread object could also make use of the std::thread, but because not all compilers and platforms support the new extensions, Omni can be compiled with C++11 support by specifying the OMNI_ENABLE_CXX11 preprocessor flag. This flag enables certain language extensions to be used in the Omni framework instead of system specific API calls as well it changes certain portions of code to handle the new extensions (like the = delete function modifier).

The C++14 specification is not fully defined but will further extend/amend the C++11 standard; as such Omni aims to be a statically fluid framework by allowing users to take advantage of the new C++XX features if their compilers support it via compile time flags. We chose to have a user specifically enable C++XX future support because everyone's need is different and sometimes upgrade your compiler/library isn't always an answer; we want Omni to work for the developer, not the developer to work for Omni.

For specifics on the classes and examples on how to utilize the framework, you can check out the individual class sections as well as the examples section.

If you have questions, comments or concerns about the framework or would like a further breakdown of a specific aspect please feel free to contact the Omni Q&A email
top