When moving to Linux, recompiling code for Unix apps not written in Java, Perl, tcl or ksh is a fact of life, says...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Alfredo Mendoza, one of the co-authors of Unix to Linux Porting. Although there may be no shortcuts for porting your apps, there are utilities that can make the transition smoother by handling platform differences.
Take a page from this IT pro as he explains the issues you face in porting apps from older Unix platforms and gives recommendations on how to tackle ANSI, ISO and POSIX industry standards.
Can IT shops take shortcuts so that they won't have to recompile all of their code when porting apps?
Alfredo Mendoza: Unfortunately, all software applications written in programming languages other than Java or scripting languages like Perl, tcl or ksh, need to be recompiled to run on Linux. Having said that, the only way to be sure that these applications work on Linux is to test them out thoroughly. After a thorough testing, programmers may find that they still need to modify some parts of the application, either to point to the right directory paths, to increase performance or simply to customize it for the Linux environment.
What programs can be provided to developers to overcome platform differences?
Mendoza: Fortunately, Linux now adheres more closely to accepted industry standards like ANSI, ISO and POSIX. The platform differences that developers will most likely encounter will come from the application using non-industry standards and non-portable APIs [application programming interfaces] provided by different Unix vendors. The only thing that can be done with this is to find equivalent APIs that can do similar things on Linux. My coauthors and I wrote our book solely to provide programmers with a quick reference that would help them find equivalent APIs on Linux.
How do you recommend handling complications that result from ANSI/ISO specifications for older, less compliant code?
Mendoza: Applications that uses older and less compliant code will, no doubt, require more porting effort. This type of scenario happens when the application to be ported has never been ported to other operating platforms. When this occurs, the porting personnel should give an adjusted assessment back to the project manager so that it can be reflected in the porting schedule. Both porting personnel and project manager should have regular checkpoints to adjust schedules and identify risks before and during the whole porting life cycle.
What can users do about platform issues that result from different vendor interpretations of the ANSI/ISO C++ specifications?
Mendoza: The variations in compilers from different vendors may or may not be a factor at all, depending on what features of the C++ language the application to be ported uses. Differences in vendor implementations of C++ compilers originating from different interpretations of ANSI/ISO C++ specifications can result in varying degrees of difficulty in the porting effort.
Also, it is safe to say that there are more commonalities than differences between vendor compilers when it comes to interpreting the standard. Some vendors even offer compatibility flags to overcome differences in standards interpretation. The overall porting effort will be affected in terms of schedule and risks.
How can you minimize complications involved with accessing databases from C++ apps?
Mendoza: Because most applications that we've ported use APIs that are provided by database products, we expect the same products to provide the same APIs on Linux. We rarely, if ever, encounter complications when dealing with database access from C++ applications.
What can developers do to overcome the challenges present when transitioning an application designed for 32-bit processing to a 64-bit platform?
Mendoza: First off, we consider transitioning from 32-bit to 64-bit a separate activity from the port itself. We strongly suggest that if a 32-bit application were to be ported and converted to a 64-bit application when migrating to Linux, do the port first and plan to transition to a 64-bit architecture after the port is complete.
The biggest challenge, however, is finding the parts of the code that need to be changed in order for the application not to fail when it is run as a 64-bit application. We present some of these problems in our book as well as how to correct them. Compilers give out warnings if they think there might be a problem with parts of the code when compiled to produce 64-bit objects. Some of these compilers may also have special switches to perform 64-bit compile checks and flag issues that they encounter.
What methods can be used for avoiding memory management problems that may arise from porting apps that rely heavily upon dynamic memory?
Mendoza: In our book, we mention several tools that find memory-related problems that are freely available on Linux. These tools can be used against the ported application on Linux. After you find and correct the problem on Linux, you need to check the original source of the application to see if it has the same problem.