[larsivi]

It turns out that the COFFLoader use the same magic string as my ArLoader (.a) to identify the filetype, namely "!<arch>\n". So much for your 8 bytes of identification Anyway, it seems like the format is similar, but not entirely the same. Since my ELFArchive is coded quite differently from COFFLibrary, I can't see the immediate differences.

I've used the specs linked to below when parsing the .a-files. Could Eric or AgentOrange look at or point me to the COFFSpec? Maybe the archive loader should be common, with a possibility to hold several types of objects? At least we need to think some more about where to differentiate. Currently my elfloading works because the ArLoader is checked first

http://docs.hp.com/en/B9106-90011/ar.4.html

and

http://ou800doc.caldera.com/en/man/html.4/ar.4.html

[pragma]

Yikes, I was afraid this might happen. I'll look into it.

In the meantime, one can always use Bless and force the type to either "COFFLIB" or whatever signature you're using for .a files. At least that way, the resulting .ddl is "signed" with the correct type to load.
_________________
-- !Eric.t.Anderton at gmail

[pragma]

Its amazing how close these two file formats are. Is the .ar type technically a COFF format? Lars, take a look at the PECOFF spec, section 7. As far as I can tell, they're identical.

http://svn.dsource.org/projects/ddl/trunk/doc/pecoff.doc.

I think the COFFLIB loader could be revised to not assume the format of the internal .obj files, and feed the loading of the .obj back into the LoaderRegistry as to properly detect the type. Take a look at the DDLLoader for an example of how that could work.
_________________
-- !Eric.t.Anderton at gmail

[larsivi]

[pragma]

I was hoping that you'd say that MS used the unix ar format, as that certainly helps us out. This is very good news.

We're on the same page, especially with the architecture bit (although you left out the OMF and DDL loaders, but I get your point). Are you suggesting that the registry handle module and library loading as two separate tasks?

[larsivi]

So, what extension should getFileExtension return for ArLoader? Maybe char [][] getFileExtensions() would be more appropriate in any case?

[pragma]

[larsivi]

[pragma]

[larsivi]

So who the f*** gave MS the monopoly? When using the Ar format for PECOFF, they also broke it. Not that it is an big problem, but these small things annoy me. The Ar spec clearly say:

If the archive contains a symbol table, the file is named "/ ". If the archive contains a table of long names, the file is named "// ". Now those great guys in Redmond decided to do the same, only that they put a file at the beginning, also named "/ " and deprecated it. Now this misfeature can be used to identify the lib, but as it isn't needed for anything, it is just cruft...

[kris]

[larsivi]

[kris]

[larsivi]

Ok, I got much of this stuff collected now, but I wonder somewhat over how to organize the classes.

So far, the ArLoader creates a class called Archive that holds the logic for loading a file with the "!<arch>\n" magic string. But ArLoader wants to return a DynamicLibrary, so Archive is now a subclass of that, but the export stuff isn't implemented yet so currently my test bombs.

Anyway, currently the registry and DDLFile isn't optimally ready for taking a chunk of data from memory.

What i do, is read the data, and do this:

<code>
DDLFile ddlfile;
ddlfile.filename = fName;
ddlfile.buffer = cast(ubyte[])memberData;
DynamicLibrary dl = this.registry.load(ddlfile);
this.modules ~= dl.getModules();
</code>

A couple of things here:
* DDLFile could/should possibly have a load([]buffer),
* The registry.load call seems a bit kludgy as long as the return library really is a DynamicModule
* The above code don't currently grab the exports, but that isn't a problem, just mentioning it

Other things to consider:
* I should probably call the class ArchiveLibrary or ArLibrary...
* As long as the archive contains a symboltable, we should use this for optimization. At least I think it might help us locate only the files in the library that is of relevance. It's just about finding a good algorithm. The problem as I see it (related to your lazy loading schemes), is that we then DON'T want to parse all of the lib now, just the symbol table (if the symbol table ain't present, which is quite possible with Ar the whole archive must be processed), and then parse the objects pointed to by the symbol table. As it is, I think we should think a bit on how we want this, just do the all encompassing loading for now (as it is more or less already there), then when we get some good use cases to test, we can start with some additional profiling/lazying/etc.

[pragma]