I am an intern who has inherited a problem with a testing program at the place where I am working. After searching around on a little bit I can across a person with my exact same problem. After asking around a little bit here, i found out that the guy who posted this does actually still work here, and I am getting his help with this too, but I think he explains the problem a little more sussinctly than I do.
Here is the jist of it for those of you who don't want to read all that garbage. We have a GUI that runs on the client side and makes remote calls to a test application written in Ada that runs on a SPARC Unix machine. When everyone in the building used Unix machines to do everything, the test app and gui worked just fine, but recently everyone got newer faster linux x86 machines.
Anyone who got the upgrade isn't able to run the test app because of the Big / Little Endian incompatibility between the test app and the GUI.
Now, it's my job to figure out how to fix it. Now, I know there is going to be kind of a big app rewrite here, and I'll probably have to redefine how the GUI and the test app talk to each other, but how can I do this without completely disassembling the program?
A few of the options I came up with myself are as follows: Java RMI XML/RPC SOAP Data Baking?
Keep in mind, I'm a total noob to network programming and even though these "solutions" may look valid to me, I may be completely off base. Please help!
You don't need to rewrite anything. Just make sure you use network order (big endian, the way you naturally express numbers) on both sides. x86 uses little endian, so you have to look at the source code of any application failing on x86.
Then, call htonl/htons/ntohl/ntohs (see man 3 htonl) or a similar function to convert every number you send/receive to the correct encoding in the portions of code that send/receive data. Java always uses network order, so you don't have to worry about native Java code.
Back to the drawing board I guess - NoName 2009-06-16 19:50
You are looking at a really heavy solution. (FYI: Another similarly heavy solution is ASN.1).
All you really need to do is add code on one side (probably the test app) to perform byte swapping on the incomming data.
The tricky part of course is that you can't (generally) just swap bytes. You have to know what the data is, because two 2-byte integers need to get swapped differently than a single 4-byte integer at the same address would be. Character data doesn't get swapped at all.
Possible Easy Solution: If you are using Gnat as your Ada compiler, one option would be to rewrite the data transmission code to use streams (if it isn't done that way already), and write some Ada code on the Linux end to read it using streams. Then fix your compilers to use the XDR version of Ada streams (explained in more detail here and here. The XDR version of Gnat's streams handle byte-swapping automaticly.
