Migration or Porting?
Changing code to make it compile and run on different (Windows) platforms. Call it migration, call it porting, when it comes to 64-bit it might be more a question of to be or not to be (part of the imminent future of computing).
Over the last years I had this discussion over and over again. Making an application work on the 64-bit Windows platform, massaging existing source code (Code clean) to make it compile and run on another platform than it was initially designed and developed for. Afterwards starting the performance and tuning exercise (after testing and debugging) for each of the newly supported platform(s).
Would you call it migration or would you call it porting?
Being not a native speaker of the English language (which you can tell from my blog. “Sprechen Sie Deutsch?”), I always preferred migration.
“Migration occurs when living things move from one biome to another. In most cases organisms migrate to avoid local shortages of food, usually caused by winter. Animals may also migrate to a certain location to breed, as is the case with some fish.”
“In computer science, porting is the adaptation of a piece of software so that it will function in a different computing environment to that for which it was originally written.
Porting is usually required because of differences in the central processing unit, operating system interfaces, different hardware, or because of subtle incompatibilities in—or even complete absence of—the programming language used on the target environment.”
Now, what do you say? Migration clearly has something to do with living things while porting is about “a piece of software”. Here we go. At least from this source porting has to do with software.
But wait, there’s more. The porting piece does not mention that this software will run on both, the old and the new, platforms. The migration article clearly states a shortage of some sort as one of the main reasons for migration. In that respect, applications are living things that may suffer from shortage of compute power, too little addressable memory or even worse, combinations of both. To me there is clearly an analogy between the winter in world of the living and the lack of resources in the world of 32-bit applications.
We all agree, work is required when applications are meant to support different CPUs or subtle incompatibilities. But calling it an application port, nahh. It is more like a migration. The biome (read: application) has evolved over time. Instead of going down the cliff (like lemmings), we help application discover new territory, a new infrastructure, a new environment with new possibilities and a way to survive in the ever hot struggle for life (read: new customer and markets).
Be it as it may – and I am very interested in hearing your opinion on migration vs. porting – porting vs. migration.
If you want to be compatible with the entire Windows world, you certainly consider to take your code to the next level and provide a version based on the .Net Framework; perhaps managed C++ for starters. The benefits are tremendous. Feel free to call this undertaking migration or porting, I don’t care. The Framework supports all platforms (including Itanium and soon x64) and there’s no biome (read: set of applications) you cannot develop and grow in this universal ecosystem.