Cross-OS Development Platform and OS Abstractor


Click here for FAQ´s

Frequently Asked Questions about Cross-OS Development Platform and OS Abstractor

Q: What is OS Abstractor and Cross OS Development Platform
A: Cross-OS Development Platform™ is a C/C++ source-level virtualization technology that provides a robust and industry standard OS interface architecture for flexible real-time application development, while allowing theuser to protect the software from being locked to one OS. OS ABSTRACTOR is a component of Cross-OS Development Platform™ along with POSIX and uITRON Interface that provides user to develop portable applications using Industry standard generic API's

Q: What value does Cross-OS Development Platform provide?
A: By using Cross-OS Development Platform, your embedded application can run on many real time (RTOS) and non-real time operating systems to negate any porting issues in the future when your platform changes. OS Abstractor Interface from Mapusoft provides you a robust and standard OS interface architecture for flexible application development while eliminating the risks associated with selecting an OS and dependency on a single vendor. OS Abstractor Interface makes your application adapt to multiple operating system platforms with a standard OS interface, thereby reducing cost associated with code maintenance and learning multiple operating systems. POSIX Interface enhances the OS Abstractor Interface architecture with the addition of optimized non-proprietary and industry standard POSIX Application Programming Interface (API) to facilitate using open source POSIX/Linux in your design.

Q: Can I start developing my application with the OS Abstractor APIs without a RTOS?
A: Yes, the OS Abstractor APIs are available in AppCOE to enable the development of applications on a host x86 platform.

Q:How does the OS changer abstraction layer works? Is it VM? Does HW support needed?
A: The implementation is not dependent on any hardware. The code is 100% written in ‘C’. Our abstraction is based on source-level virtualization. OS Abstractor features compete with the native implementation in many situations to offer better performance.

Q: Why not use an in-house abstraction?
A: Developing in-house OS abstraction requires considerable

  • Time, resources and money
  • Planning to support multiple OS
  • Detailed knowledge of low level OS functions and interfaces
  • Development
  • Testing
  • Maintenance
  • Up front cost associated with purchase of various OS and tools in order to validate your product
OS Abstractor is an effective and economical alternative.

Q: Why develop portable code?
A: Developing portable code will Protect software investment by enabling efficient software re-use across multiple platforms Eliminate manual updates to applications when upgrading to newer versions of OS Allow you to easily switch your OS platform for more cost effective development

Q: Why use a standardized OS interface?
A: Using a standardized OS interface architecture will

  • Reduce the learning curve associated with adopting a new OS by using intuitive, flexible and standard APIs across multiple operating systems
  • Protect software investment by enabling efficient software re-use across multiple platforms
  • Eliminate manual updates to applications when upgrading to newer versions of OS

Q: Why support multiple operating systems?
A: Developing software to run on multiple operating systems will

  • Expand your market share and opportunities
  • Provide flexibility to your customer to use your software on their preferred OS platform
  • Protect your software investment from OS platform changes in the future
  • Allow you to easily switch your OS platform for more cost effective development

Q: Why should I leverage open source code in my platform?
A: Leveraging open source code will give you the following benefits:

  • Efficiently add feature rich services in a cost effective manner regardless of the underlying OS
  • Get to market faster with compelling open-source applications and content in your design
  • Tap into the large talent pool of available engineers with POSIX/Linux experience
  • POSIX Interface enhances the OS Abstractor OS Interface architecture with the addition of optimized non-proprietary and industry standard POSIX Application Programming Interface (API) to facilitate using open source POSIX/Linux in your design.

Q: Why should I use OS Abstractor with my proprietary OS?
A: Using OS Abstractor with your proprietary OS will give you the following benefits:

  • Leverage re-usable open source POSIX/Linux code to efficiently add feature rich services in a cost effective to your proprietary OS
  • Make your application more compelling and valuable to your end users and customers
  • Make your proprietary OS more adaptable for your customers

Q: Are the Cross-OS Development Platform APIs CPU dependent?
A: Cross-OS Development Platform APIs are not CPU dependent, since there is not any target specific code and OS Abstractor is 100% C code. We have customers using Cross-OS Development Platform APIs on many different CPU platforms. While, there should be no problems across platforms, MapuSoft does offer validation services if requested.

Q: Which POSIX Standard is your product conformant to?
A: We are not conformant in terms of supporting required POSIX functionalities in POSIX profile 51, 52, 53, and 54. For some of the POSIX features (such as, run-time libraries, math libraries, and so on) we are dependent on the underlying OS, but we plan to provide all of this directly from MapuSoft in the future. For example, OS Abstractor APIs for VxWorks is pretty close to profile 53. OS Abstractor APIs for LynxOS would be close to profile 54. However, the listed APIs in the POSIX Interface API list comes from MapuSoft libraries.

Q: How do you support Process Model?
A:We support process models for all the supported target OS (around 25 of them). If the target OS offers hardware protection & true process, then we will use that model, when it does not, we offer software process model where each process is independent with software protection features.

Q: Could you give one example of target OS which gives hardware protection & true process and which does not provide?
A:] Linux (also VxWorks 6.x and higher) provides hardware protection and full process. ThreadX (also MQX, etc.) does NOT provide full hardware protection and process support.

Q: Could you give any key difference between software process model and hardware assisted model as supported by OS abstraction layer? Please also give details of any key difference vs Linux process model
A:] The software process model uses private memory area that is dedicated to each process for local memory. It creates all resources (eg timers) by default private (however the scope can be changed to “system” if the resource needs to be shared across process) and provides the handle . The memory is divided in case if it is single kernel memory OS like ThreadX, otherwise true process feature provided by the OS is used. As far as the Linux process and OS Abstractor, they are identical. I suggest you read the system configuration manual documentation for further information (this system manual is available within AppCOE (help menu->help_contents-> AppCOE). You can download the software from our website via the download link. We also offer ability for processes to specifically create resources with public scope (which means another process will be able to use it, but cannot delete it, e.g. timers)

Q: How do you support Memory Management - VM, Shared Library, demand paging etc? If yes, is it "arm-linux-eabi" complaint?
A:] Mapusoft support ansi memory, dynamic pool memory, partitioned memory, tiered pool memory (dynamic memory build using layers of partitions like a wedding cake) and then shared tiered pool memory and also general shared memory area. Memory is fully managed by us, however we take advantage of the MMU feature offered by OS if available. Application basically gets configured for so much memory usage, which we guaranty and also ensure application will not go beyond its allocated memory and start impacting other applications. We do not use EABI features.

Q: Could you give more details of support levels for "Shared Library" & "demand paging" in the OS Abstraction layer?
A:] Under NDA we can provide the reference manuals for our shared memory support. You can use the native Linux shared memory ‘as is’ in addition to what OS Abstractor offers. We do not do any demand paging. Also, the virtual address differences in shared memory access across process will also not be a problem when using OS Abstractor.

Q: How do you support Linux Extensions like - SysV IPC/cgroups/inotiy/futext/readahead/udev etc?
A:] Our level of support is posix 1003.1, 1003.1b and 1003.1c . In addition, the POSIX that we provide will automatically be able to take advantage of many of the real-time features from the specific OS Abstractor component for a target OS. OS Abstractor module provide the universal OS interfaces and OS features for many OS.

Q: Is it possible for Mapusoft to check feasibility to implement these features at the OS Abstraction layer? A:] Currently our OS Abstractor runs on over 25 different target OS and their versions. We need to know the additional levels of support and also on what needed target OS to be supported then we can work this under a NRE and support this.

Q: Do you support extensions to include TCP/IP stack which may not be provided as part of underlying RTOS?
A:] Yes. But for selected OS, we offer BSD compliance implemented using the net stack from the appropriate vendors offering. For example, we offer BSD complaint interface for Nucleus NET stack.

Q: Do you support necessary WiFI, BT kernel Interfaces, so that native OS Connectivity frameworks can be re used? Ex: BlueZ, Connman etc.
A:] As far as the device drivers itself, we do not offer our own across every OS. What we offer is a unix device driver I/O system framework to connect to many target OS so that the application code can be portable.

Q: How do you schedule process in multi-process application? Does this depend on target OS?
A:] We do not schedule process. All OS Abstractor processes are created equal and each thread within a process competes directly with the threads from the other. Also, we do not have a concept of parent/child/grandchild, etc. when it comes to processes. All the processes stand in a single level. To answer your second question, it does not depend on target OS. Note that uITRON and T-Kernel scheduler is First Come First Serve and preemptive. I am not sure of other OS scheduling policies. Most of them must be roundrobin. We provide support for all the scheduling (refer to OS_Create_Task API) as defined when you create a task using OS Abstractor API. If an underlying target OS does not support, we find a way to support the required scheduling.

Q: Are there possible software modes where function or performance would be anomalous? If so, how does the software enter such modes?
A:] OS Abstractor does not enter into any anomalous modes (though the target OS may do so, which is beyond OS Abstractor’s control). OS Abstractor returns failure codes if a function fails. For serious problems (e.g. exceed max configured resources) it will generate an error (in this case, based on user configuration, OS Abstractor will ignore or stop on error and can also print the error message string).

Q: How would you classify the OS Abstractor version of Linux? For example, do these versions have significant code reuse when compared to previous versions? Or, can they be considered child or rehosted versions of a mature product?
A:] OS Abstractor releases have significant code re-use when we add support to new OS. Once the product is validated for a specific OS (not specific OS versions), the code base is fully separated for each target OS. Bug fixes and enhancements that are generic will be carried out to all code bases for each supported target OS and goes through independent validation. Keeping the code base separate provides us the ability implement further target OS specific optimizations and also ensures that the new code changes do not impact solutions supported on the other OS platforms. We also have an automated test framework containing over 100 test suites that exercise OS Abstractor usage across various target operating systems and versions. Adding a new OS support is pretty much a cookie-cutter type of operation for us. We start off with a stable and suitable code base and make the target specific optimizations and then perform the validation. This effort is normally anywhere from 2 to 4 weeks for us on a stable new OS platform.

Q: Do you have safety data that you can provide us with? Examples include but are not limited to: Traceability matrix, Code review records, Functional Testing Results, Stress Testing Results, Stability Testing Results, Condition/Decision Coverage
A:] Yes. Please let us know what information that you would specifically need. Here are some examples of what we usually do:

  • Test logs: We run the test suite and capture the log results under specific target environment. Release is made only when all the functional & regression level tests have passed repeatedly for a period of time.
  • Test cases: We are constantly adding new test suites as new test cases arise.
  • Test Configuration: Test can be run light (few resources) or heavy (more resources and large data sizes). Can also configure test loop count, duration between test runs, print results in summary or verbose, run only selected tests or all tests, etc.
We have innumerable records (mostly in email format) of code review meetings and findings. Sometimes the code review continues many weeks for major feature additions or when we add a new OS support.

Q: I generated source code for Windows XP as the target in AppCOE, compiled, and executed the program in VC++. Are the resultant tasks scheduled by the Windows scheduler?
A: OS Abstractor does not do scheduling on any port. We use the OS scheduler. However, we configure the threads to be real-time priority (e.g. on Windows we use the threads priorities that are normally not used by MFC app).

Q: If I select uITRON as a target OS, who schedules the task? Do the AppCOE libraries call uITRON dispatcher?
A: uITRON scheduler will schedule the thread.

Q: What is the default maximum stack size for QNX in the main thread?
A: The stack size defined under OS Abstractor for QNX is as follows: #define OS_MIN_STACK_SIZE 16384 #define OS_MAX_STACK_SIZE 0xffffffff The above defines are in cross_os_def.h. It is recommended that you always use the default OS_MIN_STACK_SIZE which is defined across various target OS. For example, under Linux, this is directly mapped to pthread_stack_min define.

Q: If three same priority processes, A, B and C are created, which process starts execution first? When will it switch to another process?
A: OS Abstractor processes do not compete with each other, but only the threads within them. The process will be started First In First Out (FIFO).

Q: If a task is created with priority 100, and it is changed to priority 50, then will the created task start executing? Is it not possible to set higher priority than the parent process?
A: You can set any priority when creating tasks. If you want it to run immediately, you pass along the flag parameter START, it will resume, irrespective of the priority.

Q: There are three processes, A, B and C, created of the same priority and are in ready state. If process A create new task D, with a priority higher than other three processes, then will Process D start first? If priority D is lower, then will process A keep executing? If priority D is equal to other processes, will the application execution be in this series: A -> B -> C -> D -> A,,,, ?
A: OS Abstractor Processes do not compete.

Q: OS Abstractor document says that we can use target OS native IO functions if I set MAP_OS_ANSI_IO to OS_FALSE. Does this mean that I can also call other target OS APIs from application program?
A: You should be able to use any native APIs directly from the target OS (as long as the API names are not the same).

Q: If target OS is uITRON, can I call set_tim (set system time API)?
A: You should be able to set_tim native uITRON API, however, that line of code will not be portable. It is recommended to use the clock routines provided by either the OS Abstractor APIs or the POSIX APIs.

Q: How about sig_sem (signal semaphore)?
A: You should be able to use sig_sem native API. But it is recommended to use the signal APIs from OS Abstractor APIs to ensure that your code be portable.

Q: If target OS is uITRON and it has Windows compatible file system and TCP/IP which support BSD Socket, then can the developer use open, close, read, write functions for file related operation?
A: The developer has the options to use OS_open, OS_close, etc (OR) they can set MAP_ANSI to TRUE and have open(), close() calls map to OS Abstractor APIs. The developer also has the option to use both APIs OS_open and open() by setting the MAP_ANSI to false.

Q: If target OS is uITRON and it has Windows compatible file system and TCP/IP which support BSD Socket, can the developer use socket functions such as socket, accept, listen., etc by calling native OS system call?
A: OS Abstractor API’s does not provide socket APIs, so the target OS needs to supply them. We have developed a BSD compliance wrapper for many netstacks on a custom solution basis if needed.

Q: What do I do if I get OS_ERR_RESOURCE error code when creating the OS Abstractor resources?
A: This error code indicates that the application is exceeding the max-allowed resources (see section Resource Configuration) and there are no free resource control blocks. To prevent this error from occurring, adjust max-allowed resource configuration for the appropriate resource, which is causing the error.

Q: What do I do if I get OS_ERR_NOT_OWNER error code when using any OS Abstractor resources?
A: This error code indicates that the resource was created with a Process scope and only the process, which created this resource, can use it. If you need the resource to be shared across processes, then use OS_SCOPE_SYSTEM option during creation of system resources.

Q: I see some functions inside the OS Abstractor library that starts with “INT_”. Can we also use these functions in our applications?
A: The functions starting with “INT_” are functions internal to the OS Abstractor, In order to keep the application portable, application should not use those functions (use only the functions that are exposed in the OS Abstractor manual).

Q: Is all access to a memory pool serialized among all threads (tasks)? Does each thread lock the memory pool when allocating or deallocating from that memory pool?
A: The memory allocation is FIFO based across all OS. There are two types of memory allocation to be discussed: Fixed Memory Allocation: OS Abstractor does NOT synchronize the alloc/de-alloc request. Neither does it searches memory to find a free block. Even in other types of resource creation/deletion we do NOT sequential. That being said, we have proprietary mechanism in place to ensure that everything will work concurrently under a multi thread/process environment with better performance. Dynamic or Variable Memory Allocation: OS Abstractor normally depends on the OS to do the allocation and de-allocation. It is expected that the OS may lock a thread momentarily during the period acquiring a free block, but this should not be viewed as sequential operation (it's only for data protection under multithreaded environment). Under Linux, in order to utilize the MMU defrag feature, OS Abstractor does allocation of memory only during the allocation time and not the pool creation time.

Q: What happens if a memory pool is deleted while there are still open handles to that memory pool? Or what happens to the memory behind the pointers that are still held?
A: All the resources including memory allocation gets automatically freed up when the process gets deleted. Also, all memory gets freed up when the pool goes away. If applications still use the memory pointers then we will have unpredictable results (seg faults are typical). Since OS Abstractor actually tracks the amount of memory allocated and available, it is easy to check its control block for memory leaks in application prior to actually deleting these pools.

Q: Does the application have direct access to OS Abstractor control blocks?
A: Applications will not have direct access to the control blocks if the option OS_INCLUDE_PROCESS is set to true. However, the application could corrupt the control block if the underlying OS/hardware does not have support for MMU.

Q: Does OS Abstractor dynamically allocate memory at run-time?
Answer: OS Abstractor library allocates memory for all the control blocks, application memory pools and such either statically or during initialization. This is done to ensure that OS Abstractor provides a stable environment for the application. The run time allocations that occur are only to cater to applications needs for queue buffers, stacks, pools and such). But this will be automatically come from the specific process pool, unless you are creating shared memory partitions and such. Applications can also create additional memory fixed/dynamic memory pools locally using the appropriate OS_Create APIs to bypass the use of process memory pool as an added flexibility. There may be few dynamic allocations that may take place (please refer to section on Internal run-time memory allocations by OS Abstractor and Interface)

Q: Can I set up a memory pool at a specific physical address and share it across multiple process and processors?
A: Contact MapuSoft for appropriate advice for your target environment.

Q: Why do the POSIX function names in OS Abstractor starts with “PX_” first?
A: This is intentionally done so that there would be no conflict at link time with the POSIX functions provided by the OS itself and the ones by the OS Abstractor. Please refer to the POSIX Interface section in the reference manual for more information.

Q: What are the important design goals of OS Abstractor?
A: Portability and Performance are key factors, which go hand in hand. Next is the API simplicity and development flexibility. The APIs are designed in such a way that they can be extended easily with new features and still preserve backward compatibility of the API interface. Each OS Abstractor API is developed as an independent building block (such as lego blocks) so that any complex functionality could be built using them.

Q: Can OS Abstractor and Interface libraries be built as shared libraries? What about as DLLs?
A: OS Abstractor and Interface libraries can be built as shared libraries. This would be the recommended option if you develop multi-process applications. As far as DLL, the current release does not support this feature. However, MapuSoft can provide custom help for your specific target environments.

Q: Does OS Abstractor support DLL calls?
A: Yes, under certain target OS that normally does not provide DLL support. DLL support is not packaged with the OS Abstractor release. If you need specific DLL support for your target environment, please contact MapuSoft.

Q: How can I use the process feature within a single or multiple executable images?
A: If it is a single image, then you can use OS_Create_Process() function to create new processes and this way you can break down your single application to run as many individual processes. In case of multiple images, OS Abstractor automatically creates a process for every application main ().

Q: How can I pass parameters (such as void *, Char *, etc.) to task functions?
A: OS Abstractor task accepts a parameter type UNSIGNED. If you need to pass any pointer, you can assign the pointer value to a variable of type UNSIGNED and pass that to the task routine. You will then retrieve the value within the task function and initialize the value to a local pointer of the appropriate type and then can use the pointer.

Q: How is memory defragmentation handled in the OS Abstractor product on Linux and VxWorks?
A: OS Abstractor always prefers to use the OS defrag methods for pools created using OS_Create_Memory_Pool API. Under VxWorks, the pool management and defrag is handled by the OS itself. Under Linux, we have two options: Option 1: This is a preferred option if the pool is big and varied size allocation. OS Abstractor does partial memory management but relies on the MMU assisted defrag and block allocation mechanism offered by the OS. Memory is not pre-allocated during pool creation but instead allocated at the time of request. OS Abstractor ensures that the applications do not over allocate system memory beyond what they are allowed (via OS_Application_Init API init call) for when they are created. As such failure of a memory request is unlikely even though allocations are done at request time. The disadvantage is that, there may be a non-OS Abstractor based application running along with OS Abstractor based applications eating up all the memory suddenly, which then could impact the OS Abstractor applications. Option 2: This is an option offered by MapuSoft for a smaller size pool in lieu of the above. Here the memory allocation is based on first fit. Automatic and limited defrag happens during each time the memory is freed. With every memory free request, the block adjacent to the freed block is checked and if free, then it gets combined into one bigger block. This defrag mechanism is no way close to how things are done via Option 1 (this is a custom request from MapuSoft).

Q: Since I do not have a source code for OS Abstractor, it is difficult to understand your products. Is it possible to send me the full source code?
A: Yes, you can generate source code for all the Mapusoft products if you have the required License. For more information on our OS Abstractor manual and/or for an overview of our licensing please contact MapuSoft for more information by following this link:

Q: Are the Cross-OS Development Platform APIs CPU dependent?
A: Cross-OS Development Platform APIs are not CPU dependent, since there is not any target specific code as it is 100% ‘C’ code. We have customers using Cross-OS Development Platform APIs on many different CPU platforms. While, there should be no problems across platforms, MapuSoft does offer validation services if requested. AppCOE also provides feature called App/Platform Profiler that allows the application to collect performance data. By default, this feature is disabled, however when it is enabled, there is small architecture specific code that retrieves CPU clock frequency. Right now, we only support x86 architectures for this feature and we will add support for other architectures in subsequent releases.

Q: Which latest Linux kernel version do you support?
A:] We basically support every version and distribution out there for Linux

Q: Linux comes with varity of scheduling policy. Do you support any of them? These may not be supported in underlying RTOS
A:] We support, priority, time slice, combination and then run-to-completion scheduling at the OS Abstractor level. In addition we offer support for various scheduling done by OS like VxWorks, POSIX, etc.. We do not require the underlying OS to support all these scheduling as we contral the scheduling (except for the save/restore task context).

Q: Do you provide any NAND flash based file systems?
A:] We provide ANSI interface to various file systems offered by the RTOS vendors

Q: What kind of security abstraction features are supported in the OS Abstraction layer ? Ex: SMACK, SELinux, DAC etc
A:] We do not have any encryption support. Access to objects contained in shared memory are restricted only when they are accessed using our APIs.

OS Changer Porting Kit


Click here for FAQ´s

Frequently Asked Questions about OS Changer

Q: What value does OS Changer provide?
A: The OS Changer family of products gives users the freedom to switch operating systems while leveraging on their existing embedded code and knowledge base to protect their software investment and avoid costly porting issues. OS Changer also allows developers to write code using a familiar application programming interface (API) and run the application on a wide variety of supported target OS platforms. More information can be found here:

Q: Why not do a port myself?
A: It’s not easy to make existing software adapt to a new OS without incurring high cost and time to market. It’s an error prone, tedious and time-consuming task and it requires expensive and skillful resources that take away the focus on building your product.

Q: Why don’t I use my new OS vendor’s porting kit?
A: OS vendor’s solutions are restricted and tied to a specific OS. Comparatively, MapuSoft provides solutions that port to many different operating systems. OS vendor’s solutions are usually unsupported because they are more focused on building and maintaining their operating system; many of them are partners with MapuSoft and would rather rely on us to help you move your code to their OS.

Q: Why don’t I throw out my code and start anew?
A: There are many reasons to leverage your legacy code. Here are a few:

  • Leverage existing software and knowledge base when migrating to next generation platforms
  • Achieve your time to market goals
  • Don’t throw away your software investment

Q: Why would I need to change my OS?
A: There are many reasons you would need to change your operating system. Here are a few:

  • OS becomes unsupported or obsolete
  • New chip architecture has different OS availability
  • Customer demands for different OS
  • Need to adhere to industry standards
  • Change in your technical requirements
  • Change in your commercial business model
  • Need to use a better development environment
  • Need to move to a widely used OS and target platform that offers a wide range of driver, protocol and middleware support

Q: Which operating systems can I port my legacy code from?
A: OS Changer supports porting from VxWorks, pSOS, Nucleus, and Windows to different operating systems. Additional OS component support is also available:

  • VxWorks ANSI File and VxWorks BSD Network API compliance for other target RTOS’s
  • pSOS Classic OS Changer allows developers to re-use their pSOS 4.1 rev. 3/10/1986 code on different operating systems
  • Nucleus NET OS Changer allows developers to re-use their Nucleus NET code on a Linux netstack

Ada-C/C++ Changer


Click here for FAQ´s

Frequently Asked Questions about Ada-C/C++ Changer

Q: Could you please explain about Ada-C/C++ Changer Tool Tuning?

A: Every time that we use the tool to complete a project, we make adaptations to it based on the language constructs used in the source system and the desired target output (including desired coding standards, architecture, language, target language features, etc.). This adaptability is actually one of the features of the tool—it is quickly and efficiently customized to a particular customer’s desired output, rather than being a “one size fits all” tool that probably disappoints most customers.

When the code in scope is run through the tool the first time, the tool identifies the language features for which there is adaptation required. These are displayed in some indices of the initial documentation it generates. This is one of the reasons for an initial onsite visit of a couple days—we can run the code through, make some minor initial adaptations, and generate code that is transformed with 95% or greater automation. We would also gather some information from you about the desired target architecture, and use that information to select which rules are used, and make changes to existing transformation rules as needed.

Typically, the next steps on the project are to decide upon desired target outputs and tune the toolset to address any parse errors remaining or other transformation rules to the target language. Since the tool uses rules applied to a model of the original source system, we can adjust and adapt the rules being used and rapidly regenerate the system (even many dozens of times, fairly rapidly) to iteratively regenerate the target until it meets the project requirements.

Q: Which programs or projects Mapusoft has worked on for the DoD in the past?

A: The engine powering Mapusoft's Ada-C/C++ Changer 2.0 Engine has been used on DoD project since the early 2000s. These projects include:

  • - The Navy Multi-band Terminal (NMT), a SATCOM terminal, which the tools transformed from Ada to C++
  • - The Advanced Field Artillery Tactical Data System, a 5.1 million line Army system written in Ada, which the tools transformed from Ada to Java
  • - The COBRA DANE Radar Calibration System (SCRS), part of the Ballistic Missile Early Warning System (BMEWS), transformed from 380,000 lines of Ada to C++
  • - The US Army Variable Message Format Test Tool (VTT), transformed from Ada to C++
  • - The P-3C Orion aircraft Acoustic Signal Processor System (ASP), transformed from Ada to C++
  • - The Joint Mission Planning System (JMPS), a multi-branch system used by the Army, Navy, and Air Force, transformed from Ada to C#
  • - The Weapons Control System (WCS), a weapons launch system for the Naval Undersea Warfare Center (NUWC), transformed from Ada to C++
The tool has also been used on many more Ada modernization efforts within the DoD, US government, and around the world. The same technology, in fact, has been used to transform systems in many other languages as well.

Q: What specifications or requirements does our Ada code need to meet to be used by Ada-C/C++ Changer?

A: It must be self-contained and compilable by an Ada 95 or Ada 83 compiler. If you use third-party libraries which are not part of the Ada standard library, you will need to at least include the Ada source code for the package specs for such a library. If you want a translation of the third-party libraries as well, you will need to include the Ada source code for the package bodies of the library as well.

Q: Our Ada Software is far from modular. We would have a difficult time converting code pieces of the project for trial testing. How do you suggest we go evualuating Ada-C/C++ Changer to make sure it meets our needs? For example, if we just grabbed 5 random .adb files, would ADA-C/C++ Changer handle the conversion and just tell us what was undefined? Or would it fail completely?

A: AdaChanger is like a compiler. It requires the "specs" for any package that is "with"ed. It requires the bodies for any generic that is instantiated. It can work on a piece of a program, but that piece must at least include all of the package "spec"s referenced by "with" clauses, directly or indirectly. If you want to "build" an executable, then you will need a self-contained test program, including both specs and bodies for all code. If you simply want to compile the generated C code and/or do a manual review of the generated C code as part of your evaluation, you can get by with just the package specs.

Q: During our transition from Ada to C++, we will likely have developers working in Ada. How does Ada-C/C++ Changer handle development versions? For example, we take a snapshot of our Ada code today for conversion. While we are converting our Ada code and testing our new C++ code, our developers will be making improvements to the Ada. During the conversion, the developers make changes comparable to 3000 SLOC dispersed throughout the Ada project. Will the tool process just the 3000 SLOC changes when we go to make our final snapshot or will we need to convert the entire 150,000 SLOC again, resulting in the need for a license with more SLOC conversions?

A: The license is based on the maximum number of lines of code in the code base. There is no extra charge to re-translate the same lines again, nor to translate modified lines. If there are additional lines of code, then the total in the code base must remain below the license level.

Q: We have both a unclassified repository and a classified repository. The delta of our repositories is about 10,000 SLOCS. If we know the files which are different, can Ada-C/C++ Changer tool convert just those files without requiring a license that would re-count the other 100k lines that are the same?

A: You would only need to convert the package bodies in the shared code once. The package specs would be needed for both translations.

Q: Can I evaluate Ada-C/C++ Changer?
A: Yes, you can download an evaluation here:

Q: What is the difference between Ada-C/C++ Changer and an Ada to C language syntax converter?
A: Ada-C/C++ Changer is not an Ada to C language syntax converter, which is very inefficient. Ada-C/C++ Changer technology is actually an Ada compiler along with a few command line switches that are used to perform Ada to C conversion. Since the conversion is performed via a compiler engine, the resultant code is optimized and guaranteed to execute. ‘C’ compiler can then be used on the resultant C code, which provides double optimization, therefore, the performance of the resultant C code is not compromised but optimized.

Q: What does the Ada-C/C++ changer tool consist of?
A: This tool uses the same Ada 95 font end that is used by Green Hills, Aonix, Analog Devices and Raytheon for their validated Ada 95 compilers. The C-generating “emitter” is used on daily basis both in-house and at customer sites, compiling millions of lines of Ada 95 code.

Q: What are the components of Ada-C/C++ Changer?
A: There are six components of Ada-C/C++ Changer:

  • AdaCgen - Ada compiler which automatically compiles all user-registered Ada source and generates interim optimized C files, then the compiler will go through the optimized C files and convert them to readable/maintainable C source.
  • AdaBgen - Ada builder/linker generates final executables by first automatically compiling required files (using AdaCgen) and then linking all the compiled modules to generate the executables
  • Adareg - helper utility that will allow users to register all the Ada source for conversion
  • Lister - helper utility that will generate cross-reference listings
  • Adaopts - helper utility to set the Ada compiler/linker configuration options
  • RTL - ‘C’ run-time modules that provides I/O, tasking, exception handling, and memory management modules which are normally required by Ada language for the ‘C’ converted code base


Q: How do you migrate the Ada tasking model to C/C++?
A: If the original code uses Ada tasking, the translated code makes calls on the routines that implement the Ada tasking model. As mentioned above, these are in turn implemented by a layered Ada run-time system that can be hosted on top of most modern RTOS’s.

Q: How does Ada-C/C++ Changer handle run-time errors?
A: Ada language, by default, automatically handles various run-time errors that are not handled by the application. It is recommended that the Ada code be first inspected manually or using Ada Inspector tool to ensure there is enough error handling code in place before performing the ‘C’ conversion. More information can be found here:

Q: How is my application’s safety certification maintained or re-asserted after converting to C?
A: Probably the best analogy is recompiling the system with a new compiler. Clearly you would have to rerun all your tests, but presuming you translate any Ada unit tests/drivers as well, you should be able to achieve the same level of MC/DC coverage achieved before the translation. Fault analysis, etc. should be identical. All of the comments in the code are preserved, and the code component names remain essentially the same, meaning that documentation should not need to be altered in any significant way. Given the ability to translate the tests/drivers, achieving adequate MC/DC coverage should not need redoing. Ada-C/C++ Changer is very mature. The Ada 95 front end used to drive the translation has been in active use for over 10 years, in many safety-critical systems, because of its use as part of the Aonix and Green Hills compilers.

Q: Conversion tools like AdaMagic only cover 70% - 80%. Do you have any data about the percentage of your coverage of Ada-C/C++ Changer?
A: We convert 100% of the Ada source into C, with no human intervention required whatsoever. Our tool is based on a fully validated Ada compiler, which handles the full Ada 95 language. It produces efficient and readable C that exactly matches the semantics of the original Ada program. Other tools with which the customer may be familiar operate more at the “syntax” level rather than the “semantics” level, and as such generally only handle a subset of the language, and even then often only produce an approximate equivalence to the Ada semantics in the generated C program. Because of the deep semantic analysis performed by our Ada-C/C++ Changer technology, we can precisely reproduce the Ada semantics in C, while still producing C code that is both readable and efficient.

Q: Apart from the I/O packages for each instantiation, what is the rate of lines of code increase when converting Ada->C? Also, are there any options in Ada-C/C++ Changer to reduce this increase?
A: It varies from 1.5 to 1 to 3 to 1, depending on the complexity of the Ada source code. Heavy use of string concatenation and dynamic aggregates produces more C code, since C doesn’t really have any equivalent to these.

Q: While evaluating Ada-C/C++ Changer, C code generated is around 5 times more than ADA code. Why is this?
A: The amount of C code will depend on the complexity of the Ada constructs being used in the Ada source code.

Q: A lot of types were not converted and carried over to the ‘C’ files. There were no errors issued by the compiler. Why?
A: All of these types should be carried over into the generated code, unless there was a compilation error. Note that many of these may have ended up in the “.h” file rather than the “.c” file. Be sure to check both.

Q: The interface of functions with Ada String parameters is changed and we had trouble understanding the body of the operation Procedure Printf(Msg: String) was converted to extern void Printf(const Character * const Msg, int32 const * Msg__dope). Explain.
A: In Ada, every unconstrained array also carries information on its array bounds. This is traditionally called the array “dope.” So when an array is passed, we also need to pass information on the low and high bound of the array, which is represented as a 2-word array of integers in the generated C code. Note that you can gain some control over this by using pragma Export or pragma Convention in the original Ada code. For example, by specifying the Convention is “C”, it will only pass the address of the first element of the array, and presume the called routine has some other way of knowing the high bound (e.g. a null terminator or a separate parameter).

Q: We don’t understand some of the ADA custom type conversions Type Reset_Data_Type is (One, Two, Three, Four) was converted to Const Integer Reset_data_type_enum_integer_table[4]={3,6,11,15};Const Character Test_data_type_enum_image_table[11]= {“ONETWOTHREEFOUR”}
A: Ada provides ‘Image’ and ‘Value’ functions for every enumeration type, and so the compiler needs to build up a table of information that allows an internal enumeration value to be turned into a string, and vice-versa. The enum_integer_table and the enum_image_table are used for that purpose. If you want to suppress the generation of such a table, you can use Ada’s “Discard_Names” pragma. Having done that, then Ada code that uses ‘Image or ‘Value will no longer work as expected, and instead will use numeric literals for input and output.

Q: The .h and .c files were created, but all it contained were the comments. No errors were reported in the command console. Why were these files not converted?
A: This normally means there was some compile-time error, or it might be that the file produces no code. This might happen for a generic package or generic subprogram, which produce code only when instantiated. We would need a test case to be sure either way.

Q: Why are .h and .c files created for each Ada file? I expected the Foo.1.ada file to be converted to Foo.h and the Foo.2.ada to be converted as Foo.c. Instead, I get a pair of .h and .c files for the Foo.1.ada and Foo.2.ada files.
A: A single Ada source file can have any kind of code within it, though some compilers are more restrictive than that and use specific naming conventions (such as Rational’s .1.ada and .2.ada, or AdaCore’s .ads and .adb). Ada-C/C++ Changer is designed to handle any organization of code within source files. Furthermore, even though a source file might contain only a package spec, it might still have code that needs to be executed when the package is “elaborated.” This code will be placed in the “.c” file for the package spec. Similarly, even though a file might contain only a package body, it might have “subunits” or “inlined” subprograms that need access to its local declarations, and so those are placed in a “.h” file for the body.

Q: I have several warnings about installation when executing my batch file. Is it a problem?
A: See joined files “batch.txt + batch.bat”. We will need to provide you with a “SITE/config” file and a “rtl/src/system.spc” that matches your current compiler’s configuration. We ship by default with a configuration that matches a typical 32-bit Intel x 86 compilers. You are using 64-bit integers, so that will require a different package System and a SITE/config file that supports 64-bit integers.

Q: What I expect from you is a syntax translator. In this particular case, what prevents you from translating it as a C “long long” type?
A: It will be the job of the C compiler that I will choose independently from Ada-C/C++ Changer, to verify if the long long is implemented on my HW platform. The location where I translate may not be the location where I compile.

Q: Is the code generated from Ada-C/C++ Changer compiler portable and real-time?
A: Ada-C/C++ Changer is very portable because the Ada-C/C++ Changer RTS relies mostly on the standard C run-time. However, it isn’t truly “real time” because it uses C “setjmp/longjmp” to accomplish multi-threading, which is not very flexible. By adapting the Ada-C/C++ Changer RTS to use the OS Abstractor APIs, we can use “true” multithreading, and still be very portable to multiple OS and RTOS, thanks to the many targets on which MapuSoft’s OS Abstractor runs.

Q: The result of your ADA check seems to be a condition to accept translation. In particular, you find an “error” because 1 line of _comment _is more than 210 characters long. This case is not in the supplied trace. Please translate!
A: The Ada standard identifies 200 characters as the line length that an implementation must support (see Ada RM 2.2(15)). We can alter this if you choose to order the product, but for evaluation purposes you may want to break the long line into two lines no more than 200 characters each.

Q: I am an eval customer. Does your management library control the limitation of the number of lines to translate, but performs cross files checks (for “with” dependencies)?
A: Because the translation to C is done at the “semantic” level rather than at the simple “syntax” level, we need to be able to “compile” the source that we are going to translate. So that means that we require the source code for all “with”ed package specs be made available to the translator


Q: In SITE directory, the content of rts_path is wrong. The path is false! Is it a problem?
A: Yes, this needs to be edited, as explained in the Ada_Magic_Install.txt file, so that it refers to the “rtl” subdirectory of the installation directory.

Q: I have manually modified the rts_path file, but ADA.LIB generated file is still wrong. The tool behavior does not change. So, in my Files_C directory, the content of ADA.LIB is wrong. The (same) path is false! Is it a problem?
A: Yes, this is copied from the rts_path file. So you will need to delete the ADA.LIB and rerun after fixing the rts_path file.

Q: Is OS Abstractor & Ada-C/C++ Changer an independently Safety Certified Product? (Approved agencies include, but not limited to, DoD safety boards, National Security Agency, or Federal Aviation Administration)?
A: They are not independently certified. It has been in use with various applications that require certifications. We will assist our customers with the certification process of the application combined/integrated with MapuSoft code if necessary.

Q: Does Ada-C/C++ Changer accept Ada83 code or is conversion to Ada95 required?
A: Ada-C/C++ Changer accepts Ada83 code as is and does not require the code to be converted to Ada95

Q: Have any customers moved from Rational APEX with MapuSoft tools?
A: We generally don't know what compilers the customers were using. The key thing is that you will need to have full access to all of the Ada source code, including that supplied by the compiler vendor, unless it is part of the "standard" Ada library.

Q: Are there any Ada-C/C++ Changer options specifically available for Ada code developed under Rational APEX?
A: Not really. The "config" file may need to be adjusted to match the target computer, for example if the target has a 64-bit address, or uses a big-endian (as opposed to a little-endian) word representation, etc.

Q: Does the Ada-Changer handle the Ada elaboration aspect correctly?
A: Yes. Think of Ada-C/C++ Changer just like a validated Ada95 compiler. It handles the full language, and generated C/C++ code that does precisely what the Ada program did.

Q: I understand Ada-C/C++ Changer includes a C/C++ debugger. Does it also include an Ada source level debugger?
A: Limited Ada source level debugging is supported and it is roughly similar to what is supported by "yacc," where we can associate the Ada source code and the Ada line numbers with particular locations in the C/C++ source code, using "#line" directives. However, this can be confusing, because the programmer still has to live with the fact that in Ada upper/lower case doesn't matter in Ada debugging, while in "gdb" it does matter, and with the fact that Ada has overloading, but in the generated code we append unique numeric indices to names, such as "Ada::Text_io::Put_line__2" for what in Ada was "Ada.Text_IO.Put_Line." Because of this, we generally recommend that developers debug at the C/C++ source code level. The names are usually easy to connect back to the Ada source code level, and they are displayed in the C/C++ source code with the correct upper/lower case

Q: Do you have support for 64 bit when using Ada changer?
A: Ada-C/C++ Changer does support 64-bit target environment when you do code generation. It is just a question of updating the "config" file. We use it ourselves on a daily basis on a 64-bit Intel target ("X64").

Q: Does Ada-C/C++ Changer automatically convert Ada generics to C/C++ templates?
A: Automatic conversion is not supported. However, manual conversion is possible by engineers with strong C++ background and if they are able to read Ada generics. If required, MapuSoft could provide a consultant who can do this either remotely or at customer site for extra charges.

Q: How is MapuSoft’s Ada-C/C++ Changer compare to simpler tools like Ada2CC?
A: Ada-C/C++ Changer includes a front-end Ada compiler and provides 100% automated conversion of Ada code to C/C++ there by eliminating the risk associated with the transition. In addition, it is integrated with Cross-OS development platform to support wide range of OS platforms and tools. Ada2CC only does a syntax-level conversion from Ada to C/C++ and there is no guarantee that the result will compile, much less do the same thing if you do get it to compile. Because of this, great amount of manual porting and testing work is eliminated.

Q: Why cant I see any active code in the translated files? All I can see is the comments after the conversion.
A: Translation/Conversion could have failed due to the lack of 64-bit integers in the package “System” and in the “config” file that we ship by default.

Q:When trying to run the Ada-C/C++ Changer on some Ada code that uses #IF/#END IF the # is flagged as an illegal character. Is there a way to get the Changer to recognize the preprocessor directives?

A: Preprocessor directives are not a standard part of the Ada language. Some Ada vendors support them, but they don't all support them the same way.
In some cases you can use the standard C preprocessor with the Ada sources, using the "-E" flag to gcc, for example, to have it process only the preprocessor directives and produce an expanded version of the source. You will have to temporarily rename your Ada source to end in ".c" if you want "gcc -E" to expand the C preprocessor directives, then you can redirect the output, delete any remaining lines starting with "#", and rename it back to end in ".ad?".
Alternatively, you might be able to use the original Ada compiler you used to develop the Ada code, and give it a flag requesting an expansion of any preprocessor directives.

Q: Are Ada enums directly translated to C enums or defines?

A: Ada enums are translated to C enums

Q:. How are the tick operators handled and translated on enums, such as ('first, 'last, 'count, 'range, 'succ, 'image) i.e. does 'succ and 'pred become ++ and -- does 'image become an sprintf

A: 'First, 'Last, etc. are translated to references to the appropriate C enumeration literals. 'Succ and 'Pred do not become "++" and "--" but rather "+1" and "-1". 'Image becomes a call on a run-time routine rts_enumeration_image which we provide. This relies on a table of enumeration-literal images which is generated by the translator and included in the C source code.

Q: How are Ada rep-specs translated directly to C-field specs? (i.e. Ada LSB is nominally C-language MSB)

A:: Appropriate C bit-field specifications are include in the C struct definitions. There is a "config" file which can be used to tailor the translator to unusual characteristics of the target C compiler, though the default "config" file works in most cases.

Q: Is the boundary for this translation integer only (32bit). Is there any provision for 16bit

A: The translator can generate appropriate C pragmas and bit-field specifications to control packing down to the bit level.

Q: How are fixed and scaled integer/floats handled (i.e. Ada delta).

A:Ada fixed-point types are translated to C integer types, with run-time routines used for special operations such as fixed-fixed multiply and divide where the built-in C operators don't do the right thing.

Q: If we have this mapped to a variable-member in a record/rep-spec can we simply assign to it
or do we have to do additional mathematics to get the delta of the LSB's to be correct.


A: The generated C has exactly the same semantics as the original Ada source code. You don't have to do any manual fixups.


Q: How are Ada packed arrays handled? Are they converted to strings? and if so, do you add 1 extra byte for the null?

A: Packed arrays are referenced as byte-arrays in C, with appropriate shifting and masking to handle cases where the elements are less than 8-bits/element. We don't generally add an extra byte. Ada strings are converted to C char-arrays, and C string literals end up with an extra null byte.

Q: How are Ada arrays with enumerated indices handled? (i.e. Ada allows array indices to start with non-zero, even non-numeric values) How is this mapped to C which must always starts at zero?

A:Enumerated indices are not generally a special case, as enumeration values may be used as indices in C. However, if the Ada enumeration type has an enumeration rep clause which leaves holes in the enumeration sequence, then a table is used to translate the Ada enumeration values to a contiguous sequence of values starting at zero, as needed for indexing. In the general case, the low bound of an Ada array is subtracted out to produce a zero-based array for C indexing.

Q: Is there a concern while using of computations with 'pred, 'last, 'first and expressions using them giving the correct answer

A: A table is used to ensure that 'pred, 'last, etc. produce the right answer, even for enumerations with holes in the representation.

Q: Ada isn't case sensitive and there may be some variables of correct name which have incorrect case. How is this handled with case sensitive C? Does the capitalization of the declaration take precedence?

A: Ada C/C++ Changer has several different options. The default is to canonicalize the spelling so the first letter is capitalized and the others are lower case in the generated C source code. Ada C/C++ Changer can also use the spelling from the declaration in all cases. It can all use all lower case in the generated C.

Q: . How are Ada rep-spec 'use at or 'size clauses translated? (iow. how does a record (or variable) get mapped to an address with correct size).

A: Appropriate padding or packing is specified to ensure the generated C struct matches the specified 'size. For "use at" (i.e. for X'Address use ...) a pointer is used in the C code, with the pointer initialized to the specified address.

Q: How are Ada Classes translated/implemented in C++

A: They become "struct"s in the generated C++, with separate tables of function pointers used to implement Ada's dispatching operations.

Q: . How are "for" loops and "while" loops handled in Ada C/C++ Changer? Will this implement jump statements?.

A: Both "for" loops and "while" loops in Ada become while loops in C. We don't use "jump" statements in the generated C unless the original Ada had a "goto."

Q: How are task priorities handled?

A: When a task is created, a run-time routine is called, with the specified task priority as a parameter. If you are using the OS Abstractor, these priorities are passed through to the underlying RTOS. If you are not using the OS abstractor, the priorities are used by a simple task switcher implemented using setjmp/longjmp.

Q: How is preemption handled in Ada C/C++ Changer ?

A:If you are using the OS Abstractor, then all task scheduling is handled by the underlying RTOS. If you are using the setjmp/longjmp task switcher, preemption is handled through C signal handling.

Q: How are task delays, waits, scheduling handled?

A: Again, the answer depends on whether you are using OS Abstractor. If using OS abstractor, all of these things are translated into corresponding operations of the underlying RTOS. If using the setjmp/longjmp task switcher, delays are implemented using "alarms," waits and scheduling are implemented using priority queues.

Q: With the OS Abstractor we were informed that an OS dependent library call is made for tasks.

A: The OS Abstractor provides a standard interface that resembles Posix threads. Internally it turns calls on its interfaces into calls on the underlying RTOS.

Q: How is the Ada bit representation for record types converted?

A: There is a fairly direct translation, with Ada records becoming C/C++ structs, and Ada components becoming C fields, with C/C++ bitfield specifications generated as appropriate.

Q:) How is hardware/memory addressing converted – an Ada “use at” statement?

A: The C struct is referenced through a pointer, which is initialized to the specified address.

Q: How are Ada exceptions converted?

A: If you are generating C++ rather than C, Ada exceptions are translated into C++ exceptions.

Q: How are calls to Ada library packages converted (wind32, calendar, text_io)

A: When generating C++, each Ada package becomes a separate C++ namespace. For bindings like Win32, the generated C/C++ code has direct calls on the corresponding C interface, using export "C" {}.

Q: How is memory allocation/deallocation converted?

A: The standard C library malloc and free routines are called. If using OS Abstractor, these are generally converted into calls on the RTOS malloc/free calls.

Q: How are AdHow are Ada generic packages converted?

A: Instances of Ada generic packages are expanded at compile-time into non-generic code C/C++. Generic packages themselves do not translate into anything in the C/C++ code. We can provide assistance in a semi-manual procedure for generating C++ templates from Ada generics, but this is not a fully automated process.

Q: How are Ada record types converted? What do they look like if they have bit representations?

A:Ada C/C++ Changer use C/C++ bit field specifications as necessary to provide an identical "struct" representation as described in above answers.

Q: For the Ada compiler, what target hardware is supported?

A: As far as the target support it basically depends on the C/C++ compiler that would be used by the customers. Ada-C/C++ Changer has Ada compiling front-end and uses a C/C++ compiler back-end. Many of our customers use GNU compiler which basically support a wide variety of target platforms.

Q: Can Ada-C/C++ Changer tool be used outside of AppCOE IDE?

A: Yes. There is no need for everyone to use AppCOE to do Ada to C/C++ conversion, if you wish, the tool can be used outside of the AppCOE with our standalone tools for Ada compile/conversion. Even if you choose to use the AppCOE tool initially, you can always extract the full source code along with required projects and such via code generation.
MapuSoft’s product line is focused on providing developers a way to move their code to different platforms. In addition to our Ada convertor, we also offer the Cross-OS Development Platform. This tool can be integrated with Ada-C/C++ Changer to easily port your code from various operating system platforms without you having to do the porting work.

Q: Why an automated conversion tool should first compile the Ada code?

For any automated conversion method you will require that the Ada source code be compilable by the tool. Unless you can compile Ada source code, there is really no way to know what it is doing. For example, in Ada, something as simple as "F(X)" can mean about five different things, such as calling a function called F, indexing into an array called F, converting to the type called F, calling a function called F which returns a pointer to an array, and then indexing into that, or selecting the "X"th dimension of a multi-dimensional array F. So unless you can compile the code, there is no way to properly translate "F(X)" into C or C++, because without compiling, the tool won't know what is the exact meaning of "F" nor the exact meaning of "X," both of which can affect what is the proper translation for "F(X)". Therefore, our tool first compiles the code before it will start the translation so that you know the outputted code will compile and run.
Assuming that Ada libraries are available in source code format, Ada-C/C++ Changer can be easily configured to support various Ada compiler code generation formats. We also provide GNAT compatibility to assist in moving from GNAT compiler. Our tool supports variety of host platforms and also handles various re-hosting scenarios.

Q: How does Ada-C/C++ Changer compare to Ada2cc?

The following paragraph has appeared on the Ada2cc product description for many years:

“How ‘good’ is the translation?

We estimate that the current version of the translator converts 90-95% of the code without hand modification. However 5% is still a lot and we are constantly making improvements. Most of the changes required are of the following nature:

Promoting nested functions.
Adding non-default constructors.
Adjusting template parameters.
Inserting system specific function calls to support real-time functions."

This exact same set of "changes required" has been true for many years, while they have claimed for many years they are "constantly making improvements," but apparently they aren't really doing so.

In addition, these are very basic limitations, so this looks like a very simple-minded syntax-based translation tool, with no real semantic information used, and no guarantee that it preserves Ada semantics at all.

Q: What is the purpose of Label___dope appearing in my converted code?  And more generally anything “dope”?

In Ada, the bounds of an array (the 'First and 'Last) are generally passed as a separate argument.  This argument is traditionally called the array "dope" or array "dope vector" (e.g. see
Q: What is “rts_ss_mark” and “rts_ss_release” functions appearing in my converted code?  I’m not sure I’m following what’s going on there…

Ada uses a "secondary stack" to hold locally declared objects and temporaries whose size is not known at compile time.  This secondary stack is managed using a "mark/release" discipline (for background, see "mark-and-release" in  "rts_ss_mark" does a "mark" on the secondary stack, "rts_ss_release" releases everything on the secondary stack back to the specified mark.  In the above example, a "mark" is saved into pointer_1 at the beginning of a series of operations, and then a "release" is performed at appropriate points to recover the storage that had been allocated on the secondary stack, by operations such as "rts_ss_char_concat" which concatenates two strings into a temporary result on the secondary stack.

Cross-OS Hypervisor


Click here for FAQ´s

Frequently Asked Questions about Cross-OS Hypervisor

Q: How is MapuSoft’s Cross-OS Hypervisor performance better than other hypervisor Solutions ?
A: With other hypervisor solutions, the application has to go through double OS layers & device I/O and also two instruction-set layers. With the Cross-OS Hypervisor solution the application is connected effectively at the source code level to the host platform, allowing the platform to be a standard PC with immediate availability of rich set of device drivers and off the shelf devices

OS Simulator


Click here for FAQ´s

Frequently Asked Questions about OS Simulator

Q : How is MapuSoft’s OS Simulator different from that of that of an OS Vendor Solution?
A: MapuSoft’s OS Simulator is designed to give the best simulation environment. OS Simulator consists of AppCOE – A powerful eclipse based IDE as its base with OS Abstractor & other interfaces. While other advantages are as follows:

  • Most OS Vendor solution are not provided in full source format like MapuSoft's solution and offers no customization
  • OS Vendor’s solutions will work for testing simple applications only as a single process. If one block (module) breaks, then all stops
  • OS Vendor’s solution will prevent you from directly utilizing native middleware/stack/tools/drivers
  • OS Simulator allows application to use OS Abstractor APIs or allow access to native OS APIs
  • Takes full advantage of the OS kernel to provide enhanced performance
  • OS Simulator puts the focus on testing the application and not the OS components
  • OS Vendor’s solution will lock your test platform to one OS/vendor and prevents you from testing any other types of applications (POSIX, VxWorks, Windows, uITRON, etc.)
  • OS Vendors provide little support for their kernels as they compete with the real product sales. Further, they only support certain host configuration
  • With Mapusoft solution, you can generate performance metrics for both application and platform to analyze performance

Q: What simulators are available from Mapusoft?
A: The following simulators are available:

  • VxWorks Simulator
  • pSOS Simulator
  • Nucleus Simulator
  • micro-ITRON Simulator
  • Linux/UNIX Simulator
  • Windows Simulator
  • ThreadX Simulator
  • OS Simulator (using OS Abstractor Interface)
  • OS Version UpKit


    Click here for FAQ´s

    Frequently Asked Questions about OS Version UpKit

    Coming Soon!



    Click here for FAQ´s

    Frequently Asked Questions about AppCOE

    Q: What value does AppCOE provide?
    A: With Application Common Operating Environment(AppCOE ) you can easily port, abstract and optimize your code on a host machine and run the application on different target platforms. AppCOE leverages the existing OS Changer and OS Abstractor technologies while adding advanced code optimization capacities on multiple OS environments. AppCOE provides users an easy-to-use graphical user interface that is integrated with the Eclipse® based CDT environment. More information can be found here:

    Q: Why should I develop on a host instead of the target platform?
    A: Developing on a host will provide you the following benefits:

    • Don’t be constrained by a limited availability of your target hardware
    • Begin developing the application before the hardware is available to improve your time to market
    • Simulate your application on a host for easy testing, verification and presentation

    Q: Why should I use a unified architecture for development?
    A: Using a unified architecture will provide you the following benefits:

    • Reduce the learning curve by using a standard IDE across multiple operating systems
    • Re-use same code base across multiple OS to reduce time consuming maintenance
    • Eliminate manual updates to applications when upgrading to newer versions of OS

    Q: Why should I use the Eclipse IDE?
    A: Using the Eclipse IDE will provide you the following benefits:

    • Offers state-of-the-art CDT for productive development
    • It’s the industry de facto standard
    • Offers open source plug-ins for economical development

    Q: How should I choose between the standalone (full-package) or code optimizer solutions?
    A: The standalone version is now called the Full Library Package option and can be generated from AppCOE. You can also generate Optimized Code (using Code Optimizer) or Standalone binaries. Both options are provided with full source code without obfuscation. Here are a few technical points about the choices:

    The standalone (or Full Library package) library includes the standalone products with all the features. Integration to an Eclipse-based IDE for host development is possible by purchasing the standalone solutions for the host platform. Using this option requires the necessary integration with your tools. The package is provided with a standard one-size-fits-all source code library and is manually configured via usr.h file. Standalone solutions are used as a library and code size and performance optimizations are done by the compiler tools. Some integration is required to tie one or more libraries to the applications. Sample demos are provided showing target OS specific initializations (excluding the board level initializations) and sample project files are supplied for some tools.

    The Code Optimizer includes access to the AppCOE IDE which allows development, porting and debugging of applications on Linux & Windows host platforms using Eclipse framework without a need for the target hardware. Porting legacy applications under a host environment is much easier than porting on the actual target. This option allows for graphically configuring & integrating multiple OS Abstractor & OS Changer solutions. The source code generated is based on the level of API usage by the application for a more custom solution and to increase the application performance. Also available is the option to select individual APIs for execution speed optimization in addition to other compiler optimizations. The generated interface code can either be made part of the application or can be a standalone library. This option provides automatic generation of target OS specific initialization code (excluding board level initializations) and automatic generation of project files (make/visual C++/eclipse/etc.).

    Q: What source code plug-ins are available for the Mapusoft Eclipse based IDE?
    A: AppCOE is based on eclipse framework and as such there are innumerable plug-ins available which can be readily used or easily integrated with AppCOE if needed (

    Q: What is required to add target support for my In-house OS to AppCOE?
    A: Adding support for an in-house OS can be easily done by our India development team for a nominal fee. Validation can also be done by MapuSoft or yourself. In order to estimate the work, we need know more about the OS functions in your In-house OS, such as:

    • Do you support priority based scheduling?
    • Is there a way to change thread priority of a running task?
    • Is there a way to manually suspend/resume a thread?
    • Is there a way to manually relinquish thread control?
    • Is there a way to get the current thread id?
    • Do you have a basis semaphore support?
    • Do you have a basic message queues support?

    We also need to know the OS Interfaces that you need supported (e.g. POSIX, uITRON, VxWorks, etc.) on top of your target In-house OS so that you can either migrate code to your In-house OS or develop new code using those Interfaces. For example, if your In-house OS needs to run Linux code, you would need POSIX/Linux Interface support for your target In-house OS.

    To support the AppCOE Profiler feature, two APIs (related to higg resolution) need to be ported to run on your target In-house OS. These APIs need access to the hardware hi-res clock on your board. This is something you can easily do yourself or ask us to do it for you, if you wish.

    Linux OK


    Click here for FAQ´s

    Frequently Asked Questions about Linux OK

    Q: Why use POSIX Interface on a POSIX based OS?
    A: Benefits only provided by POSIX Interface from Cross-OS:

    • Includes OS Abstractor APIs - Allows development of highly portable applications
    • True Portability - Code written for an older version of POSIX will run on a newer version - Code written for one POSIX type such as UNIX or Linux will run on all POSIX types
    • Development Flexibility - OS features beyond the POSIX standard provide more development features which are missing in POSIX
    • Adds Performance, OS Hardening and Reliability - Maximizes use of compile-time translations - Maximizes use of low-level OS functions - Zero data copy of messages - OS Abstractor APIs - Static allocation of control blocks - Scalability at component & feature levels - Real-time enhancements and other safety critical OS features are added to your OS - Protect resources or optionally share them with other applications and processes - Unique process features enables independent development of complex and multiple applications - Dynamic application reconfiguration and restart - Provides Task Pooling feature to reuse task envelopes - Every POSIX distribution offers different features, our APIs will fill in the missing pieces to give you the “best of the best”

    About MapuSoft


    Click here for FAQ´s

    Frequently Asked Questions About MapuSoft

    Q: What value does MapuSoft provide?
    A: MapuSoft Technologies (MT) is the number one provider of embedded software re-usability solutions and services that are designed to protect software investment by providing customers a greater level of flexibility and control with product development. MT offers porting, integration, support and training services to help developers easily migrate from legacy platforms to the next generation. We believe that our advanced software and vision will revolutionize the embedded software industry. We are working hard to provide software that is practical, familiar, financially reasonable, and easily operable. We provide full source code with no royalty fees. Our licensing strategy makes it extremely affordable for you to incorporate our products into your embedded applications. In addition, our attention to engineering detail provides you with robust software and requires minimal technical maintenance.

    Q: Why don’t I hire a consulting company to make a porting kit or abstraction layer?
    A: Consulting solutions are very expensive and take time since they don’t have off the shelf products. MapuSoft is unique in offering ready-made off-the-shelf porting and abstraction products and therefore can offer you solutions quicker and at a lower cost.

    Q: Why don’t I use an open source porting kit or abstraction layer?
    A: Open-source solutions are limited, unsupported and risky. MapuSoft provides you fully supported porting and abstraction solutions that are more reliable since they were developed working with the OS vendors themselves.

    Q: Who are your customers?
    A: We have many success stories from our customers. A list of some of our customers can be found here:

    Q: Can I see testimonials of your customers?
    A: Yes, testimonials can be viewed on our website here:

    Q: Which industries have your products been used in?
    A: MapuSoft products are widely used in many industries. Refer to the pages under the Industry item on the menu bar for more info.

    Q: What types of products have used MapuSoft’s tools?
    A: Our product list includes:

    • Air & Missile Defense
    • Blade Servers
    • Centrifuge
    • Digital Multi-Media Application
    • Embedded Training Products
    • Fire Alarm System
    • HVAC Controller/Web Server
    • Industrial Control
    • Instrumentation
    • T1/Tel Interface Card
    • Navigation Console
    • Navy Training Applications
    • Network Communications
    • Network Control Center
    • Optical Network Platform
    • Patient Monitor
    • Peripheral Device
    • Power Meter
    • Router
    • Security Appliance
    • Set-top box
    • SoSCOE Platform – FCS
    • Telematics
    • Telephone Application
    • Test & Measurement
    • Test Fixture
    • VoIP Phone
    • Windmill Control
    • X-Ray Machine
    Q: If a customer purchases MapuSoft's tools, what kind of software and documents are provided? Does the software include source code?
    A: Source code is always provided, except when you run on AppCOE host platform.

    Q: Are your products royalty free?
    A: Yes, all of MapuSoft’s products are royalty free, there are only downstream costs when your customer is not the end user and will continue development of the application.

    Q: What is the pricing and licensing of your products?
    A: You can contact us request information about our pricing and licensing here:

    Q: What is your Capability Maturity Model Integration (CMMI) certification level?
    A: We have not rated ourselves independently or internally with CMMI at the present time. We have refined processes and also utilized tools aiming towards providing value and 100% product & service satisfaction to our customers.

    MapuSoft Services


    Click here for FAQ´s

    Frequently Asked Questions about MapuSoft Services

    Q: Where can I find the latest release notes?
    A: A document detailing release notes for our latest releases can be found here:

    Q: What operating systems do you support?
    A: For a list of supported operating systems please refer to the latest release notes on this page:

    Q: You don’t appear to support my operating system. Can you still help me?
    A: Yes, MapuSoft often adds support for operating systems as requested by customers. To send a request for MapuSoft to add an operating system please click this link:

    Q: What API’s do you support?
    A: For a list of the latest APIs supported, please refer to the latest release notes on this page:

    Q: You don’t support every API used by my application. Can you still help me?
    A: Cross-OS Development Platform is designed to even out the OS landscape. If a feature is missing in the underlying target OS, then the platform will automatically provide that feature. The goal for Cross-OS Development Platform is to provide portability without compromising performance. For example, Cross-OS Development Platform process feature is still available on single memory based OS. However, if there is no mmu support, then we may not be able to provide hardware protection. While there may be few APIs not supported in the current release, which would result in printing run-time errors, we are constantly extending support for additional APIs and feature sets for each release. Please contact MapuSoft if you would like to request the addition of certain APIs:

    Q: What impact do your products have on my code size and speed?
    A: MapuSoft’s products are designed to have very little impact on your code size and speed. Our products have been tried and tested in many performance critical areas such as medical and mil/aero. The exact size of the footprint of our products varies by target operating system. In some target operating systems it can be as little as 2k. In some cases, using our products will enhance the speed of your application due to our advanced development features. For more technical information about this, please click this link to contact MapuSoft with your question:

    Q: How can I get a reference manual?
    A: Our product reference manuals provide more technical information than can be found on this website. Product reference manuals can be accessed in the AppCOE program by those with eval or product license keys. To send a request for a product reference manual, please click this link:

    Q: Where can I download an evaluation?
    A: A free evaluation of our products is available for download here: A 30 day advanced evaluation is also available by request. Please contact MapuSoft for an advanced evaluation license by following this link:

    Q: I want to evaluate your products on my hardware. Is this possible?
    A: Our evaluations are only available on Windows, Linux and soon Solaris. Q: What does a support contract include? A: A support contract includes access to support by phone or e-mail, bug-fixes and upgrades for the products you have purchased, all at no extra costs. Only customers with current support contracts will have access to support.

    Q: What services do you provide?
    A: In addition to off-the-shelf products, MapuSoft also offers porting, integration, support and training services to help developers easily migrate from legacy platforms to the next generation. A list of our services includes adding proprietary OS support, customization and full service porting. More information can be found here: