This document discusses the challenges of porting applications to new platforms and using abstraction to develop reusable software. It notes that applications are often locked to the original development platform, and porting can involve costly code changes due to variations between platforms. Reasons for platforms changing include technical requirements, economics, and obsolescence. Both porting and abstraction aim to reuse existing code investments when platforms change. Porting transfers code to a new platform while abstraction allows developing on multiple platforms from the start. The document outlines differences between operating system APIs, models, and functionalities that complicate porting and must be addressed through abstraction. It presents components of an effective abstraction model including portability, performance, stability, and development flexibility.
2. Getting Locked-In
Applications are developed with a particular platform in mind
The software is locked to the current platform
If a component of that platform changes, the application will no
longer run without costly changes to the code due to variances
in platforms
Reasons platforms change
Changes in technical requirements
Switching to more economical platforms
Platform becomes obsolete
Market & industry demands
3. Advantages of Software Reuse
Lots of time and money go into developing an application
This investment must be protected when platforms change
Developers need to leverage their existing software to
re-coup the time and money
Software reuse can be accomplished two ways:
Porting existing code to a new platform
Using an abstraction platform for new code
development
Challenges are brought about by variances in platforms
4. Variations in OS Platforms
OS Model & Type Variations
Single address (Kernel model)
Virtual memory (Process model)
Single vs. multi-processor
32/64 bit architecture
SMP/UP processor model
Real-time or non real-time
Safety critical certifications (Do178B, ARINC653, etc.)
Security certifications
OS emulations on host platforms
5. Variations in OS Platforms
OS Process API Variations
Real-time vs. non real-time
Process creation (spawn, exec, fork, etc.)
Inter-process communication (signals, messaging, pipes, etc.)
Shared memory (data protection)
OS Task API Variations
Scheduling models (priority based, time-slice, etc.)
Priority levels & ranges
Task stack variations
Critical region protection
6. Variations in OS Platforms
OS Messaging API Variations
Fixed/Variable message queues
Sending message (fixed vs. unlimited)
OS Mutex API Variations
Shared vs. use within a process
Deadlock prevention (priority in-heritance, ceiling, etc.)
Performance impact
7. Variations in OS Platforms
OS I/O System API Variations
Proprietary vs. UNIX/ANSI model
Offers levels of I/O control functions (ioctl)
Device driver model variations (Linux vs. Windows drivers)
OS Semaphore API Variations
Binary vs. counting semaphores
Usage within & across processes
Dispatch order (FIFO, LIFO, Priority)
Suspension (Polling vs. true)
8. Variations in OS Platforms
OS Memory API Variations
Fixed vs. variable allocation
Virtual, physical or shared
Defrag algorithm
Alignment issues(architecture dependency)
OS Clock & Timer API Variations
Hardware Clock (timer interrupts per second)
System Tick (interrupts per tick)
• Timer resolution
• Sleep & other application waits
9. What is Porting?
Porting is the ability to reuse software from one environment to
another by making minimal changes to the existing code
Porting can turn into a major code-rewrite if the underlying OS
platforms are very different
This is a tedious and error prone task
10. Importance of Porting
Porting is usually quicker and cheaper than performing a full code
rewrite
Existing code already works and has been perfected in the field
Throwing it away and starting from scratch
because of a change in environments is
not sensible
A porting tool can greatly decrease the amount
of manual work involved
11. Challenges in Porting
Differences in OS APIs
Missing OS functionalities
Obsolete APIs
Managing multiple code bases across different
OS versions
Misleading POSIX portability
12. What is Abstraction?
Abstraction provides the ability to develop software that can be re-
used across multiple environments without changing the code
A good abstraction protects software investment
Keeps it from being locked-to a particular platform
from day one
13. Importance of Abstraction
Negates future porting issues and protects the code
Avoids shifting the focus from the organization’s core
competencies
Ensures that the fundamental OS resources behave the same
across all platforms
Reduces potential learning curve and makes
the concept of code reuse easier to adopt
14. Importance of Abstraction
Allows for development of host based proof-of-concept application
quickly
Product development knowledge is not locked
to a specific vendor’s tools, IDE or platform
Hardware changes won’t impact applications
Application development team can keep
developing without worrying about
changes to the hardware or underlying
platform
15. Challenges in Abstraction
Has to support a variety of operating systems and account for new
versions in the future
Should not impact the application’s performance
Should not fully rely on the underlying OS
16. Abstraction Model Components
Portability
Support for a wide variety of OS, able to account for variances
Able to support a new OS quickly
API compliance at behavior level, not just interface level
Performance
Resource pooling
API profiling & optimization
Just-In-Time Virtualization of OS Models
17. Abstraction Model Components
Stability & Robustness
Mission critical features
OS hardening
Development Flexibility
Simple, intuitive and thread-safe APIs
Multiple API use within a single application
Scalability within a component
API usage across process, user-mode or
kernel-mode