I thought a few of you might be interested in the current status of this script, so here is an update. I will attach a copy in case anyone wants to test it, or add functionality or fixes. I'd be interested in the results of any tests, especially if you discover any parsing errors.
It is far from complete, but at this stage does the following:
- Scan a given path, locating all dll files - Generate an HTML map of dll imports only (sorted, lowercase, stripped of paths) - dumpbin /import and dumpbin /export on all dll files and save the results in imports.txt and exports.txt respectively - parse imports.txt as follows, and save the results in imported_api.txt:
DLL name imported DLL imported API
- parse exports.txt as follows, and save the results in exported_api.txt:
DLL name exported API
Future plans:
- Create a matrix of data currently in HTML map - Generate HTML cross reference of all imported/exported API - Implement dumping of data into a database (Something queryable, but what?) - Detect and report unimplemented APIs in wine
Havn't had a chance to look at your script yet, but I am two hours' work away from something that parses the original HTML you gave, and outputs the monster in the form Dimi and I suggested. I will attach it later today, and then you can merge the two, if you like.
Shachar
Quoting David Miller compsol@ptd.net:
I thought a few of you might be interested in the current status of this script, so here is an update. I will attach a copy in case anyone wants to test it, or add functionality or fixes. I'd be interested in the results of any tests, especially if you discover any parsing errors.
It is far from complete, but at this stage does the following:
- Scan a given path, locating all dll files
- Generate an HTML map of dll imports only (sorted, lowercase, stripped
of paths)
- dumpbin /import and dumpbin /export on all dll files and save the
results in imports.txt and exports.txt respectively
- parse imports.txt as follows, and save the results in
imported_api.txt:
DLL name imported DLL imported API
- parse exports.txt as follows, and save the results in
exported_api.txt:
DLL name exported APIFuture plans:
- Create a matrix of data currently in HTML map
- Generate HTML cross reference of all imported/exported API
- Implement dumping of data into a database (Something queryable, but
what?)
- Detect and report unimplemented APIs in wine
Attached is a perl prog that taked David's original HTML output with a single necessary preprocessing (replacing each <br> with <br>\n), and issues a list of the DLLs (no deps as of yet) in the order discussed before (i.e. - A depends on B -> A is higher, A has more dependants than B -> A is higher).
I will now work on displaying this in a table. Shouldn't be too difficult (the fact that the table will be 238 coloumns wide nonwithstanding). Could be worse. The table is 1141 lines long.
This does not work with David's new prog yet, but as the both of them are in perl I am sure it will not be too big a deal to merge the two progs into one. This will just simplify the process of getting the initial input (currently parsed from the HTML).
Shachar
Shachar Shemesh wrote:
Havn't had a chance to look at your script yet, but I am two hours' work away from something that parses the original HTML you gave, and outputs the monster in the form Dimi and I suggested. I will attach it later today, and then you can merge the two, if you like.
ShacharQuoting David Miller compsol@ptd.net:
I thought a few of you might be interested in the current status of this script, so here is an update. I will attach a copy in case anyone wants to test it, or add functionality or fixes. I'd be interested in the results of any tests, especially if you discover any parsing errors.
It is far from complete, but at this stage does the following:
- Scan a given path, locating all dll files
- Generate an HTML map of dll imports only (sorted, lowercase, stripped
of paths)
- dumpbin /import and dumpbin /export on all dll files and save the
results in imports.txt and exports.txt respectively
- parse imports.txt as follows, and save the results in
imported_api.txt:
DLL name imported DLL imported API
- parse exports.txt as follows, and save the results in
exported_api.txt:
DLL name exported API
Future plans:
- Create a matrix of data currently in HTML map
- Generate HTML cross reference of all imported/exported API
- Implement dumping of data into a database (Something queryable, but
what?)
- Detect and report unimplemented APIs in wine
Thanks, I will look into merging the two together sometime soon, if no one beats me to it. First I want to make the existing program a little more readable before it becomes unmanageable and even I don't know what it does. :)
The sample HTML I created was done from my laptop, which has all sorts of applications installed. There might be a lot of irrelevant information. It may become a much smaller table once it's run on a clean system.
At 01:11 AM 2/9/2003 +0200, you wrote:
Attached is a perl prog that taked David's original HTML output with a single necessary preprocessing (replacing each <br> with <br>\n), and issues a list of the DLLs (no deps as of yet) in the order discussed before (i.e. - A depends on B -> A is higher, A has more dependants than B -> A is higher).
I will now work on displaying this in a table. Shouldn't be too difficult (the fact that the table will be 238 coloumns wide nonwithstanding). Could be worse. The table is 1141 lines long.
This does not work with David's new prog yet, but as the both of them are in perl I am sure it will not be too big a deal to merge the two progs into one. This will just simplify the process of getting the initial input (currently parsed from the HTML).
ShacharShachar Shemesh wrote:
Havn't had a chance to look at your script yet, but I am two hours' work away from something that parses the original HTML you gave, and outputs the monster in the form Dimi and I suggested. I will attach it later today, and then you can merge the two, if you like.
ShacharQuoting David Miller compsol@ptd.net:
I thought a few of you might be interested in the current status of this script, so here is an update. I will attach a copy in case anyone wants to test it, or add functionality or fixes. I'd be interested in the results of any tests, especially if you discover any parsing errors.
It is far from complete, but at this stage does the following:
- Scan a given path, locating all dll files
- Generate an HTML map of dll imports only (sorted, lowercase, stripped
of paths)
- dumpbin /import and dumpbin /export on all dll files and save the
results in imports.txt and exports.txt respectively
- parse imports.txt as follows, and save the results in
imported_api.txt:
DLL name imported DLL imported API
- parse exports.txt as follows, and save the results in
exported_api.txt:
DLL name exported API
Future plans:
- Create a matrix of data currently in HTML map
- Generate HTML cross reference of all imported/exported API
- Implement dumping of data into a database (Something queryable, but
what?)
- Detect and report unimplemented APIs in wine
-- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
Dave wrote:
Thanks, I will look into merging the two together sometime soon, if no one beats me to it. First I want to make the existing program a little more readable before it becomes unmanageable and even I don't know what it does. :)
The sample HTML I created was done from my laptop, which has all sorts of applications installed. There might be a lot of irrelevant information. It may become a much smaller table once it's run on a clean system.
Please keep the foreend/backend approach, as I have neither tools nor environment to run your original perl prog, and I would still like to get the HTML rendering. I think the best approach is for a backend to dump the raw data into a easy to parse format (and your original format was, as you can see, not too difficult once you add the newlines), and a frontend that formats these into HTML.
As for the unnecessaries - 238 columns is much better than I feered. More worriying than the sheer number is the warning my prog issues when run on your original input (like I said - I don't have any other): DLL fsusd depends on DLL gdiplus, which does not exist DLL photowiz depends on DLL gdiplus, which does not exist DLL shmedia depends on DLL gdiplus, which does not exist DLL webvw depends on DLL gdiplus, which does not exist DLL wiadefui depends on DLL gdiplus, which does not exist DLL wiavideo depends on DLL gdiplus, which does not exist DLL wiavideo depends on DLL gdiplus, which does not exist DLL wiavusd depends on DLL gdiplus, which does not exist
Manually checking that with your output reveals that to be a correct assesment (i.e. - not a bug). there are references to a DLL called "gdiplus", which does not itself show in the output. Care to check your system and find out how that came about?
Shachar
At 01:11 AM 2/9/2003 +0200, you wrote:
Attached is a perl prog that taked David's original HTML output with a single necessary preprocessing (replacing each <br> with <br>\n), and issues a list of the DLLs (no deps as of yet) in the order discussed before (i.e. - A depends on B -> A is higher, A has more dependants than B -> A is higher).
I will now work on displaying this in a table. Shouldn't be too difficult (the fact that the table will be 238 coloumns wide nonwithstanding). Could be worse. The table is 1141 lines long.
This does not work with David's new prog yet, but as the both of them are in perl I am sure it will not be too big a deal to merge the two progs into one. This will just simplify the process of getting the initial input (currently parsed from the HTML).
ShacharShachar Shemesh wrote:
Havn't had a chance to look at your script yet, but I am two hours' work away from something that parses the original HTML you gave, and outputs the monster in the form Dimi and I suggested. I will attach it later today, and then you can merge the two, if you like.
ShacharQuoting David Miller compsol@ptd.net:
I thought a few of you might be interested in the current status of this script, so here is an update. I will attach a copy in case anyone wants to test it, or add functionality or fixes. I'd be interested in the results of any tests, especially if you discover any parsing errors.
It is far from complete, but at this stage does the following:
- Scan a given path, locating all dll files
- Generate an HTML map of dll imports only (sorted, lowercase,
stripped of paths)
- dumpbin /import and dumpbin /export on all dll files and save the
results in imports.txt and exports.txt respectively
- parse imports.txt as follows, and save the results in
imported_api.txt:
DLL name imported DLL imported API
- parse exports.txt as follows, and save the results in
exported_api.txt:
DLL name exported API
Future plans:
- Create a matrix of data currently in HTML map
- Generate HTML cross reference of all imported/exported API
- Implement dumping of data into a database (Something queryable, but
what?)
- Detect and report unimplemented APIs in wine
-- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
I checked my system for gdiplus.dll. It simply is not under c:\windows\system32, which is the path I gave when I made the sample HTML. It is under c:\windows\winsxs.
The new program strips the path and dll extension in the HTML output. Would it be better to reverse that change, and include the path and extension to be compatible with your parser?
At 09:39 AM 2/9/2003 +0200, you wrote:
Dave wrote:
Thanks, I will look into merging the two together sometime soon, if no one beats me to it. First I want to make the existing program a little more readable before it becomes unmanageable and even I don't know what it does. :)
The sample HTML I created was done from my laptop, which has all sorts of applications installed. There might be a lot of irrelevant information. It may become a much smaller table once it's run on a clean system.
Please keep the foreend/backend approach, as I have neither tools nor environment to run your original perl prog, and I would still like to get the HTML rendering. I think the best approach is for a backend to dump the raw data into a easy to parse format (and your original format was, as you can see, not too difficult once you add the newlines), and a frontend that formats these into HTML.
As for the unnecessaries - 238 columns is much better than I feered. More worriying than the sheer number is the warning my prog issues when run on your original input (like I said - I don't have any other): DLL fsusd depends on DLL gdiplus, which does not exist DLL photowiz depends on DLL gdiplus, which does not exist DLL shmedia depends on DLL gdiplus, which does not exist DLL webvw depends on DLL gdiplus, which does not exist DLL wiadefui depends on DLL gdiplus, which does not exist DLL wiavideo depends on DLL gdiplus, which does not exist DLL wiavideo depends on DLL gdiplus, which does not exist DLL wiavusd depends on DLL gdiplus, which does not exist Manually checking that with your output reveals that to be a correct assesment (i.e. - not a bug). there are references to a DLL called "gdiplus", which does not itself show in the output. Care to check your system and find out how that came about?
ShacharAt 01:11 AM 2/9/2003 +0200, you wrote:
Attached is a perl prog that taked David's original HTML output with a single necessary preprocessing (replacing each <br> with <br>\n), and issues a list of the DLLs (no deps as of yet) in the order discussed before (i.e. - A depends on B -> A is higher, A has more dependants than B -> A is higher).
I will now work on displaying this in a table. Shouldn't be too difficult (the fact that the table will be 238 coloumns wide nonwithstanding). Could be worse. The table is 1141 lines long.
This does not work with David's new prog yet, but as the both of them are in perl I am sure it will not be too big a deal to merge the two progs into one. This will just simplify the process of getting the initial input (currently parsed from the HTML).
ShacharShachar Shemesh wrote:
Havn't had a chance to look at your script yet, but I am two hours' work away from something that parses the original HTML you gave, and outputs the monster in the form Dimi and I suggested. I will attach it later today, and then you can merge the two, if you like.
ShacharQuoting David Miller compsol@ptd.net:
I thought a few of you might be interested in the current status of this script, so here is an update. I will attach a copy in case anyone wants to test it, or add functionality or fixes. I'd be interested in the results of any tests, especially if you discover any parsing errors.
It is far from complete, but at this stage does the following:
- Scan a given path, locating all dll files
- Generate an HTML map of dll imports only (sorted, lowercase, stripped
of paths)
- dumpbin /import and dumpbin /export on all dll files and save the
results in imports.txt and exports.txt respectively
- parse imports.txt as follows, and save the results in
imported_api.txt:
DLL name imported DLL imported API
- parse exports.txt as follows, and save the results in
exported_api.txt:
DLL name exported API
Future plans:
- Create a matrix of data currently in HTML map
- Generate HTML cross reference of all imported/exported API
- Implement dumping of data into a database (Something queryable, but
what?)
- Detect and report unimplemented APIs in wine
-- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
-- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
David Miller wrote:
I checked my system for gdiplus.dll. It simply is not under c:\windows\system32, which is the path I gave when I made the sample HTML. It is under c:\windows\winsxs.
The new program strips the path and dll extension in the HTML output. Would it be better to reverse that change, and include the path and extension to be compatible with your parser?
I don't think that would be necessary. Just make sure that in the HTML you add a real NL after each <br> (or otherwise make the interesting parts at most one per line), and that SHOULD work.
My parser removed the path if it's there, and removes the extension if it's .dll. If the files have no path and no extension, that should still work fine (I would love to either have you check that, or give me an up to date HTML for me to check against).
Shachar
Ok, here is new HTML. I used c:\windows as the path so gdiplus would be included.
I'll add the newlines, but haven't yet. So new HTML doesn't have them.
At 12:25 AM 2/10/2003 +0200, you wrote:
David Miller wrote:
I checked my system for gdiplus.dll. It simply is not under c:\windows\system32, which is the path I gave when I made the sample HTML. It is under c:\windows\winsxs.
The new program strips the path and dll extension in the HTML output. Would it be better to reverse that change, and include the path and extension to be compatible with your parser?
I don't think that would be necessary. Just make sure that in the HTML you add a real NL after each <br> (or otherwise make the interesting parts at most one per line), and that SHOULD work.
My parser removed the path if it's there, and removes the extension if it's .dll. If the files have no path and no extension, that should still work fine (I would love to either have you check that, or give me an up to date HTML for me to check against).
Shachar-- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
In our continous effort to to avoid understanding what the other one is writing by sending our own stuff, here is a version of my parser that does the actual generation of a HTML table.
Also attached is this program's output when run against Dave's original HTML. The HTML is compressed with bzip, as when compressed with gzip it was over this list's quota (44Kb). Be warned that the file size after uncompress is 2.7MB(!!!), and it poses quite a problem for Mozilla to display (though it manages to, eventually).
Also not that the resulting display is as ugly as an airport. This was, in fact, on purpose. If you view the source of the HTML, you will find that it was meant to be styled with a CSS, and thus contain no formating directives, but do contain "class" directives. Unfortunetly, my web design skills are close to nada, and so I do not consider myself up to the task of creating such a style sheet. If anyone else present would like to generate CSS for this table, please keep in mind that Table Data cells of class "CyclicDepend" are cells that, if marked, indicate that the DLL has a cyclic dependancy. It is therefor probably a good idea to give them a different background.
Last, this program still has a bug, though I don't know how serious. When run it issues lots of warnings about use of uninitialized var. I believe this has the potential of indicating a real bug in the program, but the DLLs I have sample checked against the original input proved to be ok.
Share and enjoy.
Shachar
Dave wrote:
Ok, here is new HTML. I used c:\windows as the path so gdiplus would be included.
I'll add the newlines, but haven't yet. So new HTML doesn't have them.
At 12:25 AM 2/10/2003 +0200, you wrote:
David Miller wrote:
I checked my system for gdiplus.dll. It simply is not under c:\windows\system32, which is the path I gave when I made the sample HTML. It is under c:\windows\winsxs.
The new program strips the path and dll extension in the HTML output. Would it be better to reverse that change, and include the path and extension to be compatible with your parser?
I don't think that would be necessary. Just make sure that in the HTML you add a real NL after each <br> (or otherwise make the interesting parts at most one per line), and that SHOULD work.
My parser removed the path if it's there, and removes the extension if it's .dll. If the files have no path and no extension, that should still work fine (I would love to either have you check that, or give me an up to date HTML for me to check against).
Shachar-- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
-
Dave -
David Miller -
Shachar Shemesh -
Shachar Shemesh