About us

Mapusoft Technologies is the leading provider of porting and abstraction solutions that increase the
level of code re-use to protect software investment.

Copyright © 2017 MapuSoft Techologies, Inc. All rights reserved.

– Transitioning an application from one software development kit (SDK) to another SDK
– Moving from one hardware platform to another
– Making a software driver work with a new device
- Making the startup code and initialization routines work on another processor
- Moving your
application from one language to another language
- Transitioning to a new operating system.

And that was just in 15 seconds. I came up with those as fast as I could type them. You could probably add between 10 – 15 variations yourself.

Generally, the word ‘porting’ conveys the transitioning of code from one system to another. The system can be defined as hardware or software. The code can be a driver, an init file, or an entire application. But the difference between those options is huge. Why? The actual work involved is completely different.

In the porting world, there is an important distinction between specific modifications and work that can be automated. You, as a programmer, want to deal with the specific coding/re-writing and automate as much as you can. That just makes sense. Why would you add extra work for yourself?

When you introduce the word porting into the conversation, it doesn’t convey a differentiation between the two types of work. You could be talking about automating the transition of your application and it gets lost in the conversation to the engineers who are dealing with the startup code. And vice-versa. When you discuss moving your initialization code to a new hardware platform, talking about automating the porting process gets confusing.

You see, when you change hardware, you are required to make certain code changes. It’s understood. It’s a given. There are memory addresses, interrupt structures, registers locations, and bit patterns that are all specific to the new hardware. So you must make some changes to your software at the hardware level.

But that’s not necessarily the case as you move up the software stack. As you move higher up the software layers, it gets easier to automate the changes. So moving to a new operating system or even a new language is drastically different than moving to a new hardware platform, because that
engineering process can be automated for embedded software.

But yet, we continue to use the word porting to describe both of these processes.

As an industry, we need to take charge of the language we use. Besides, we’re all engineers. Aren’t we all smart enough to make the distinction without resorting to some lazy, ineffective, hand-waving use of a single word?

Why we need to change the word ‘Porting’

Have you ever wondered how a word gets into the Webster’s dictionary? I was researching that topic a few weeks ago and ran across this factoid. According to the Merriam-Webster website, a word is updated when it is widely used and has a clear and accurate meaning. As soon as I read this, I had a shocking revelation about the embedded industry…

In the embedded software industry, we need a clear definition for the word ‘porting.’

I’m going to make my case to you now.

Inside the embedded software industry, the word porting is used to describe a larger phrase - embedded software porting. In this context, the word porting is the most slippery, amorphous, and utterly useless word we use as engineers. The meaning of the word has to be determined from the context of the conversation. The meaning can actually take on multiple definitions in the same conversation. It’s crazy.

Here’s what I mean. I jotted down just a few meanings that I could come up with to describe embedded software porting:

Check out our LinkedIn Group

Contact Us