The article is devoted to the issue of estimating complexity and cost of migration of applications to 64-bit platforms. Such aspects as availability of various components of an application, libraries and development tools are considered. An example of using PVS-Studio program tool for estimating migration is given. Although the mentioned PVS-Studio product is oriented on C and C++ applications in Windows system, Unix-developers (and developers working in other systems) will find the article useful too.
With the phrase "near at hand is the day when all the developers will have to release 64-bit versions of their applications" I begin many articles since 2006, although now, when I am writing this article, 2009 is coming to end. Life has shown that I was wrong. That day is not so close. So many companies have not yet released 64-bit versions of their products. Partly it is due to the policy of Microsoft company that makes money equally well at selling 32-bit versions of Windows and 64-bit ones. And partly it is because far not all applications actually need the 64-bit versions.
But thanks to my experience of communicating with people responsible for decisions of developing applications' 64-bit versions, I understood that the main constraint is very simple. Many people simply do not know how to estimate time and value of the process of migrating an application to a 64-bit architecture. So, this ignorance makes them postpone the process of porting code as far as possible.
In this article I am going to tell you about one of the methods to estimate this process before migration. For it is possible to exactly tell how much time migration of a particular application takes only when this migration is over.
The article is based on the experience of OOO "Program Verification Systems" company's workers, both in porting various applications to 64-bit systems and using PVS-Studio code analyzer.
This article is devoted to estimate of the migration process, but not the migration process itself. That's why I would refer those who want to examine the issue in detail to the article "Seven steps of migrating a program to a 64-bit system" . Nevertheless, I will use some theses from that article here. Before we estimate the peculiarities of migration, we must have clear answers to the following questions:
If you answer "yes" to all these questions you face the main question put in the title of the article.
So, you have some (or some tens of) MBs of source code ready for migration. There is no configuration for building 64-bit code, and consequently no module compiled in 64-bit mode. But after reading the article "20 issues of porting C++ code on the 64-bit platform"  you understand that the process of searching all the hidden errors in the code will be difficult.
To understand how difficult the search of all the errors will be you can use static code analysis. There are various code analyzers (comparison of code analyzers, ) that you may use when searching problems in 64-bit code, but in this article I will stick to PVS-Studio code analyzer for it is this tool our company develops.
So, in PVS-Studio 3.30, you have a new ability of detecting problems relating to 64-bit code even in 32-bit projects. It is this ability that allows you to estimate complexity of migration BEFORE the step of creating the 64-bit configuration of the project. Earlier, PVS-Studio analyzer allowed testing projects only in the 64-bit configuration.
I would like to pay your attention to the mechanism of code testing in 32-bit mode. First of all, you should understand that of course this testing cannot be considered full, and correction of even all the detected problems cannot guarantee code's operability in 64-bit mode. For in the code of any serious application there will be fragments like this:
#ifdef WIN64 ... #endif
Of course, when testing the code in 32-bit mode, a fragment like this will be skipped. Or, more exactly: at the moment when there is no 64-bit configuration, there can be no fragment similar to this in the code. And when it does appear, the analyzer will "forget" to test it.
Another important point is that depending on the project's configuration data types are naturally different. That's why testing in 32-bit and 64-bit modes will nearly always give different results.
But how much will these results differ? Proceeding from the results of the experiments undertaken by our company, we give you the following data. The lists of diagnostic warnings generated by PVS-Studio code analyzer coincide 95-97% when testing projects both in 32-bit and 64-bit modes! This means that not more than 5% of diagnostic warnings differ. These results have been received in this way: we took the codes of real projects, tested them in 32-bit mode and saved the list of the problems detected. Then we tested the codes of the same projects in 64-bit mode and saved the list of the problems detected. After that we compared the two lists and estimated how many per cents of diagnostic warnings had coincided. For the whole procedure was performed in automated mode, the number of the projects tested was rather large (more than 20 projects, each several MBs in size). So, you can trust these results.
Of course you should not hurry to correct the detected potential errors in the 32-bit configuration - you should wait for the 64-bit configuration. But you can estimate how much time it will take to look through the code analyzer's warnings.
To get a time estimate I recommend that you do the following:
Of course there is a weak point in this algorithm of estimating the migration process - the programmer who will look through the warnings during a day. That's why I recommend that you take it seriously when choosing a person responsible for the estimate.
Here you are some recommendations on choosing such a programmer:
Following these recommendations will allow you to get an adequate estimate of value and time of 64-bit migration of applications.
To better understand this article you should consider some points:
I wish you successful estimate of 64-bit migration of code and hope that PVS-Studio tool will help you in it.
Date: Mar 09 2023
Author: Andrey Karpov
Date: Oct 15 2019
Author: Sergey Khrenov
Date: Apr 19 2017
Author: Andrey Karpov
Date: Mar 22 2016
Author: Andrey Karpov
Date: Dec 08 2015
Author: Andrey Karpov