Windows API database

[Dan Kegel]

Oh, ok.  Cross-referencing DLL imports and exports.
Yeah, that sounds like a job for a simple perl script.
All you need to output is DLL name and what DLLs it imports from.
Just generate a flat text file for starters, then
later postprocess that into an ascii tree or graph.

It's going to be a messy little graph, I bet.
- Dan

Dave Miller wrote:
> The project I am considering is mentioned on the contributing page here:
> http://fgouget.free.fr/wine/contributing-en.shtml.  (Build a database of
> Windows APIs and dependencies)  It sounds like less work to simply create
> text files containing the imports and exports, although I think the point is
> partially for the results to be easily cross referenced by developers.
> Hence the suggestion of a database of some kind.  I've considered scanning
> applications as well.  If I have any success with the Windows APIs I may try
> tackling that at some point as well.
> 
> ----- Original Message -----
> From: "Dan Kegel" <dank at kegel.com>
> To: "David Miller" <compsol at ptd.net>
> Cc: <wine-devel at winehq.com>
> Sent: Thursday, January 23, 2003 3:38 PM
> Subject: Re: Windows API database
> 
> 
> 
>>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...
>>
>>
>>>1.  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.
>>
>>
>>>2.  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
> 
>>>3.  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.
>>
>>
>>>4.  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
>>
>>--
>>Dan Kegel
>>http://www.kegel.com
>>http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
>>
>>
>>
> 
> 
> 
> 


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045