Hi all
I've got a load of code that I'm trying to convert into a native amiga program and I've got a question about converting some shared utility function libraries. I've got them as dll and so files on windows and unix. Given the nature of the program, keeping them as shared objects is quite expensive as the program also consists of a load of plugins (as shared objects) and the overhead of reloading the utility libraries as shared objects for each one is too much. The libraries only export functions, no data, so they should be ideal candidates for normal amiga shared libraries.
After playing around with idltool, I'm starting to see how the xml and code fit together but I have a couple of questions.
1. Is the struct interface *self parameter a requirement? My code itself doesn't need it, since it doesn't have any private library specific data, and it would mean that I could just use the same prototypes that are in the library already. Or do I need to create a load of stub routines that include the self parameter that simply call the original prototype. For example, is it enough to have something like
void ConjugateQuaternion (Quaternion * const quaternion_p);
or must I have something
void ConjugateQuaternion (struct EPRIFace *self, Quaternion * const quaternion_p);
2. Looking at idltool it generates the c/h files from an exsiting xml file; for my situation I want to go the other way since I already have the c/h files and would need to generate the xml file. There about a 1000 functions so it could be quite time consuming to generate this interface xml file by hand, so I've started toying with the idea of writing a parser program to scan the header files and produce this xml file. Am I duplicating something that already exists here?
cheers
billy
@billyfish
1. AFAIK, the first parameter in all library functions is always a pointer to the interface structure.
2. I haven't heard of such a tool, so you're probably not going to be duplicating anything. One tricky thing that you will have to bear in mind when implementing this tool is that, unlike with DLLs and shared objects, OS4 library functions are identified by offset not by name. This means that your tool must make sure that functions always end up in the same order every time you run the tool. Otherwise different versions of the library would be incompatible.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
@billyfish
Imho as you will make an real library, you will need soon or later to make an .sfd (or older .fd) file for. And as you will do it one time, then you can generate xml from them with no probs by "fdtrans" (ram:> fdtrans library.sfd -x) , or by fd2pragma if you will make .fd (ram:> fd2pragma library.fd clib proto.h special 140)
Hans and Kasle
Thanks for these. Although I'm aiming the code that I'm porting at being OS4-specific, the automatic library generation tool that I'm thinking about should be able to work with as many OS versions as possible.
Hans, thanks for the info about the ordering, it means this libtool program would also need to be able to read and write an index file of the functions in a given order. Each time the program is ran, it would generate this index file and make sure that all future revisions would keep the same order. If the subsequent library interface was given a new version, can the functions be in a different order to the older versions?
Kasle, good point that the program should be able to generate (s)fd files as well as the xml format that idltool requires.
cheers
billy
@billyfish
If the interface version number changes, then you can completely change the API. However, this new version will also be incompatible with any software that uses a different interface version. Interfaces are not backward compatible with previous versions, which is why trying to obtain version 0 of an interface fails.
You shouldn't increment the interface version number and create a backward-incompatible API unless absolutely necessary.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
Thanks Hans.
Cheers for the info, I think I'm clear on it now.
Just spotted this, thread at amigaworld so it seems you had the same question; I'm 5 years behind you though :-)
So I've started the coding of this and it parses a list of header files and use basic pattern matching to get the requested function prototypes and gets most of the info from the function name, return type and parameters, etc. From there, the generation as xml, fd, sfd files should be relatively easy.
cheers
Billy
@billyfish
By convention, all Amiga libraries are backwards compatible. Aside from interfaces, Amiga libraries should be compaitible because if a function changes or is removed then a program expecting an older version of the library can crash. Perhaps embedding incompatible version numbers in SO names is a Linux normality, but in the Amiga world it is not!
There are some execptions, semaphore handling in Exec, Warp3d IIRC. But it's not a normal thing to do in Amigaland.
The best thing to do is to plan ahead so it will be upwards compatible as well expandable. I know ths is limited as you are porting a third party SO object so you just do the best you can. So you set out the order of the functions. And if you need to add more stick them on the end. If some functions become obsolete or are replaced then you can put dummy functions in their place or rename the old function in a new header and provide a new function.