Windows API (What I have so far)

[Shachar Shemesh]

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/
>>
>>
>>
>
>


-- 
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse.pl
Type: application/x-perl
Size: 4608 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20030210/a9a90de3/parse.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winxp_dll_map.html.bz
Type: application/octet-stream
Size: 20008 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20030210/a9a90de3/winxp_dll_map.html.obj