How do I migrate Ada code from a Sun Solaris 10 to 11 using an APEX compiler

Question

I have zero experience with Ada so please bear with me. We inherited a 20 year old system written in the late 90's. The compiled code is currently running on a Sun Solaris 10 system. No one has touched the code in years. The compiler for Ada is APEX. I am tasked to know if this will run on Solaris 11 and if so what compiler to use. So my question is - does apex even exist anymore? I found an article that references it and the website (www.rational.com) is no longer active - it reroutes you to an IBM site. The 800 number does not work either. So am I to assume this is no longer an option? What do I do now to migrate and recompile all our code on the new system? C C++ Ada etc. Do I need to buy new compilers - will it take coding changes to work? Any help is greatly appreciated.

Answer 1

ApexAda v5.2 added Solaris 11.4 support. You can found out more about the current state of ApexAda from PTC's recent August 2020 webinar https://www.ptc.com/en/resources/plm/webcast/ada-developer-tools-webinar/thank-you

Answer 2

There's a good chance you don't even need to recompile. Oracle guarantees backwards binary compatibility on Solaris:

Oracle Solaris Guarantee Program (valid through 12/31/2021)

Oracle Solaris is designed and tested to protect customer investments in software.

While new functionality may be introduced in new releases, Oracle Solaris is designed with continuity of binary interfaces, so applications developed on earlier releases can continue to run. This enables customers to purchase new systems or upgrade the OS on older systems and continue to run their existing applications.

Customers and Partners who have purchased Oracle Premier Support for Operating Systems can receive assistance in resolving compatibility issues identified when moving a binary application from an earlier OS release.

...

A binary application built on Solaris 2.6 or later that makes use of operating system interfaces as defined in stability.5 run on subsequent releases of Oracle Solaris, including their initial releases and all updates, even if the application has not been recompiled for those latest releases. If an application experiences a compatibility problem when running on your latest supported Oracle Solaris Operating System, support is offered as described below:

For Oracle Solaris 10

Use the integrated "appcert" utility (see the man page for appcert) to check your application. If no errors are reported but problems running the application remain, a Service Request (SR) should be opened to obtain support.

For Oracle Solaris 11 and subsequent releases

The Preflight Application Checker tool is used to verify application compatibility and can be downloaded from: http://www.oracle.com/technetwork/server-storage/solaris11/downloads/index.html. The package includes documentation that describes how to check an application for compatibility with Oracle Solaris.

...

Note that if you have an Oracle Solaris support contract, and your compiled application passes the above compatibility checks (appcheck for Solaris 10, "Preflight Application Checker tool" for Solaris 11), it's Oracle's problem, not yours. Even if the binary was compiled 20+ years ago on Solaris 2.6.

For another 14 months or so, anyway.

In my experience, your binary compiled on Solaris 10 will work just fine on Solaris 11 without being recompiled.

Answer 3

I worked recently re-porting a flight simulator from 1995 era that run on an Silicon Graphics servers, IRIX OS, Apex Ada with low level C code. This interfaced to display hosts that were running C and SL-GMS graphics. Its a bit hopeful to say it will run on the latest OS version when talking about a 20+ year old legacy system. Some issues you will find is legacy systems used 32 bit pointers, which are now almost universally 64 bit pointers. Many of the low level code routines, especially in C were manipulating pointers using "int", they will all needed to be changed to "long" to accommodate 64 bit pointers. If the system interfaces to external equipment, there may be big-endian to little-endian issues on top of the 32-64 bit issue. Ditto if the new host equipment has changed from a processor that used big endian but now uses little endian (say Intel) or vice versa. Any packed formats need to take into account that the pointers will be 64 bit so will require 8 bytes not 4 in any packed structure. That's just pointing out the main issues, there will also most likely be deprecation issues, such as 32 bit libraries, ...