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.
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.
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.)
3. Will a single MySQL table do or does it need to be a relational database with multiple tables?
4. Anything else you can tell me about this task?
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
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 Cc: wine-devel@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...
- 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
-- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
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 Cc: wine-devel@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...
- 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
-- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045