So for starters, we want something like this? It doesn't look very impressive. :)
http://home.ptd.net/~compsol/imported_dll.txt
However, my system is by no means a clean install of WinXP home so most of thos DLLs probably don't belong to windows.
-----Original Message----- From: Dan Kegel [mailto:dank@kegel.com] Sent: Thursday, January 23, 2003 5:20 PM To: Dave Miller Cc: wine-devel@winehq.com Subject: Re: Windows API database
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@kegel.com
To: "David Miller" compsol@ptd.net
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...
- 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:
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://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
--
Dan Kegel
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Dave Miller wrote:
So for starters, we want something like this? It doesn't look very impressive. :)
Yes, but probably want to convert all filenames to lower (or upper) case, and sort them alphabetically.
Next step is to take that data and turn it into a graph or map of some sort. Perhaps the same sort of map I did to display Usenet connectivity of la.personals years ago... here's the "map": http://www.alumni.caltech.edu/~dank/la.personals/map.html and here's the code: http://www.alumni.caltech.edu/~dank/ftp/map/
However, my system is by no means a clean install of WinXP home so most of thos DLLs probably don't belong to windows.
Yeah, you'll probably want to run this on a clean install sometime. - Dan
-----Original Message----- From: Dan Kegel [mailto:dank@kegel.com]
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.