|
|
||||
|
|
Deeper with Dlods |
|||
Exporting classes is one of the dlod technology's main interest. roughly, it consists in storing methods and class-related datas (such as vtbl or class name & class id) in a dlod and send this dlod through a package to another program. Therefore, each class (and each dlod) will provide an init function. This function is called by the system each time it embeds the dlod into a new program. Similary, the dlod might provide an uninit function (this won't be very useful unless your dlod registers resources). The uninit function is called when the dlod is unloaded (quite seldom), or when the host program ends.
A class-dlod should also provide other standard features like the getClassInfo() function or create(). create() is used to build new instances of the class, and getClassInfo() will return miscellaneous informations according to an info-request it is given. (such as the dlod package where the class comes from, its superclass, etc) Each object build with create() should start with a pointer to the class itself. Here is a probable overview of a class-dlod structure.
| (1) dlod header with dlod id, init(), uninit() and description of the regions in the dlod |
| (2) class datas including vtbl, references to superclass(es?) |
| (3) methods Here comes the code for init,uninit, create... plus the code for the methods provided by instances of the class |
| (4) dlod trailer This is the "reloc section" of the dlod. |
Note that zones "1" and "4" are common to all dlods. Zones 2 and 3 are specific by their content. By the by, they are "usual" data and code regions. When importing such a dlod, only one link is defined (which should be the name of the class). This link will be set to the start of zone 2 (i.e. the "class infos" structure), and from there, any other link may be defined. Therefore, external dlods or host program will need to access methods through the method table, while the dlod itself can use direct accesses (i.e. absolute addresses). In order to let any program use the dlod, the structure of "class infos" should be standardized (at least the head of that structure)
An alternative to exporting class and then creating objects is to let the server create the object and then export it. This scheme may be quite useful if building the object requires a huge amount of information (that the client should not see). Here, the client will immediately get an object (i.e. a piece of data) and the main link will be a pointer to this object. Note that the object will need a "class pointer" (cf. supra), which is supposed to point to its class. This might be troublesome, because the class is still on server-side...
The first solution is to insert the class methods and structures in the object-dlod (this is called explicit class-link). The dlod is then self-sufficient, but this might lead to memory wastes if many objects of that class must be imported by the same host. An alternative is to use a dlod-reference to code the class-pointer. This mean, instead of having a direct pointer, you'll use the dlod-mechanism and tell "at this position should come main address of dlod XXX". This isn't hard to do because that dlod is made by that class! (which is supposed to know its own name). This scheme allows each object-dlod to reuse the same class-dlod (which will be embedded automatically with the first object). It also improve the "thru-passing" of object-dlods from one program to another, because there's only one region to "pack".
Note that, if many programs just pass object-dlods without using them, the second solution might not be fair, because each of them will need to import the class (this is done by default by the system), which might be quite time-consuming (because of possible related links).
