Cross-OS Development Platform and OS Abstractor
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
- Up front cost associated with purchase of various OS and tools in order to validate your product
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? 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.
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.
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: http://mapusoft.com/contact/
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
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: http://www.mapusoft.com/os-changer-porting-kit
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:
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:
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:
Frequently Asked Questions about Ada-C/C++ Changer
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: www.mapusoft.com/downloads 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
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
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:
Q: What simulators are available from Mapusoft?
A: The following simulators are available:
OS Version UpKit
Frequently Asked Questions about OS Version UpKit
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: http://www.mapusoft.com/appcoe
Q: Why should I develop on a host instead of the target platform?
A: Developing on a host will provide you the following benefits:
Q: Why should I use a unified architecture for development?
A: Using a unified architecture will provide you the following benefits:
Q: Why should I use the Eclipse IDE?
A: Using the Eclipse IDE will provide you the following benefits:
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 (http://marketplace.eclipse.org/).
Q: What is required to add target support for my In-house OS to AppCOE? 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.
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:
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.
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.
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:
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: http://www.mapusoft.com/customer
Q: Can I see testimonials of your customers?
A: Yes, testimonials can be viewed on our website here: http://www.mapusoft.com/testimonials
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:
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: http://mapusoft.com/contact
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.
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: http://www.mapusoft.com/techdata
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: http://www.mapusoft.com/techdata
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: http://mapusoft.com/contact
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: http://www.mapusoft.com/techdata
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: http://mapusoft.com/contact
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: http://mapusoft.com/contact
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: http://mapusoft.com/contact
Q: Where can I download an evaluation?
A: A free evaluation of our products is available for download here: http://mapusoft.com/downloads A 30 day advanced evaluation is also available by request. Please contact MapuSoft for an advanced evaluation license by following this link: http://mapusoft.com/contact
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: http://mapusoft.com/services