David Miller wrote:
I would be interested in knowing more about the goals of this project. Don't consider me officially working on such a thing just yet. I have no real perl experience, but would like to learn. First I'd like to know more about what I'm up against.
I'm not sure what project you're talking about, but I can make a few wild guesses...
- Is there a specific set of dll's and exe's we want included in the
database or does it need to scan and gather a list of all dll and exe files? That would suggest a clean OS install is necessary.
Sure, a clean OS install is probably good. Many of the APIs exposed by even the clean OS install may not be needed if no application calls them, but it's hard to know that in advance.
We might want to also scan applications to see what APIs they actually use, but that's real hard.
- What information should be in the database? (OS ver, name of dll or
exe, name of imported dll, APIs and whether they are imported or exported, etc.)
Maybe use the same format as we use in the souce tree? e.g. scanning advapi32.dll should produce something that looks very much like http://cvs.winehq.com/cvsweb/wine/dlls/advapi32/advapi32.spec?rev=1.32
- Will a single MySQL table do or does it need to be a relational
database with multiple tables?
IMHO no SQL is needed. The database should be plain text files checked into CVS.
- Anything else you can tell me about this task?
Compare with other standards which provide lists of API's, for example: http://www.linuxbase.org/spec/ http://www.unix.org/ http://www.ecma.ch/ecma1/STAND/ECMA-234.HTM to get some ideas. Of course, these are formatted all fancily, and cover different operating systems, but the goal is similar: to provide an authoritative list of APIs. Ideally, the result could be part of a submission to a standards body. (See also http://www.kegel.com/remedy/remedy2.html#fix.info ) - Dan