Cross-OS Development Platform

Section description:

What is OS Abstractor and Cross OS Development Platform?
What value does Cross-OS Development Platform provide?
How does the OS changer abstraction layer works? Is it VM? Does HW support needed?
Why not use an in-house abstraction?
Why develop portable code?
Why use a standardized OS interface?
Why support multiple operating systems?
Why should I leverage open source code in my platform?
Are the Cross-OS Development Platform APIs CPU dependent?
Which POSIX Standard is your product conformant to?
How do you support Process Model?
Could you give one example of target OS which gives hardware protection & true process and which does not provide?
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
How do you support Memory Management - VM, Shared Library, demand paging etc? If yes, is it "arm-linux-eabi" complaint?
Could you give more details of support levels for "Shared Library" & "demand paging" in the OS Abstraction Layer?
How do you support Linux Extensions like - SysV IPC/cgroups/inotiy/futext/readahead/udev etc?
Is it possible for Mapusoft to check feasibility to implement these features at the OS Abstraction Layer?
Do you support extensions to include TCP/IP stack which may not be provided as part of underlying RTOS?
Do you support necessary WiFI, BT kernel Interfaces, so that native OS Connectivity frameworks can be re used? Ex: BlueZ, Connman etc.
How do you schedule process in multi-process application? Does this depend on target OS?
Are there possible software modes where function or performance would be anomalous? If so, how does the software enter such modes?
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
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?
If I select µITRON as a target OS, who schedules the task? Do the AppCOE libraries call µITRON dispatcher?
What is the default maximum stack size for QNX in the main thread?
If three same priority processes, A, B and C are created, which process starts execution first? When will it switch to another process?
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?
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?
If target OS is uITRON, can I call set_tim (set system time API)?
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?
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?
Why do the POSIX function names in OS Abstractor starts with “PX_” first?
Can OS Abstractor and Interface libraries be built as shared libraries? What about as DLLs?
How is memory defragmentation handled in the OS Abstractor product on Linux and VxWorks?
Which latest Linux kernel version do you support?
Linux comes with varity of scheduling policy. Do you support any of them? These may not be supported in underlying RTOS
Do you provide any NAND flash based file systems?
What kind of security abstraction features are supported in the OS Abstraction layer? Ex: SMACK, SELinux, DAC etc

Find quick answers to your questions about Cross-OS Development Platform

What is OS Abstractor and Cross OS Development Platform?

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,...
What value does Cross-OS Development Platform provide?

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 cha...
How does the OS changer abstraction layer works? Is it VM? Does HW support needed?

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 implementa...
Why not use an in-house abstraction?

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 Maint...
Why develop portable code?

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 O...
Why use a standardized OS interface?

Using a standardized OS interface architecture will...
Why support multiple operating systems?

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 Protec...
Why should I leverage open source code in my platform?

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 ...
Are the Cross-OS Development Platform APIs CPU dependent?

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 differe...
Which POSIX Standard is your product conformant to?

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)...