Recently I spent some time on this again and would like anyone interested in the database to take a look and email me comments. (What's good, how it can be better, and what features could be there, but aren't) Currently the web interface consists of a few forms which do the following:
1. Compare imports or exports between two windows versions. This will output all APIs imported or exported by a dll you specify along with which version exports that API. Example: you specify wine and windows95 as windows versions. Each API will say it is exported by wine only, win95 only, or both. It is color coded in the hope of making it slightly more readable.
2. Perform general queries. This just does SQL queries based on the criteria you specify. You can query by any or all fields.
3. Find unimplemented APIs for a given program. This locates all APIs imported by a specified application and outputs the ones which are unimplemented or stubs in wine. This is broken down by dll which the app tries to import from. Red APIs are not in wine spec files while blue APIs are listed as stubs in the spec files. There are only a couple of apps listed right now. Leave the application field empty for a complete list. I intend to make the output hyperlinks which will query for all apps importing that specific API. Maybe that will help find test cases when tracking down a bug.
The forms are currently at http://24.229.94.2 Unfortunately I can't keep this as a permanent location. The PC is just too slow and the scripts really hog CPU. They do lots of SQL queries. :)
- Find unimplemented APIs for a given program.
I typed some apps name (mirc, dreamweaver...) but i just got 'The following applications were found:'. Did i miss something ?
The forms are currently at http://24.229.94.2 Unfortunately I can't keep this as a permanent location. The PC is just too slow and the scripts really hog CPU. They do lots of SQL queries. :)
SQL queries are already optimized ? Do you use a CGI or PHP script tp make your queries ?
Stephan
If it says "The following applications where found:" but does not list any applications it simply did not find any matches. There are only a couple of apps there at the moment, to test the script. If you want to see how it works just leave the application field empty and it will return all apps in the database.
All of the scripts are written in perl. SQL queries are done using perl DBI. My only perl experience is this project so I would guess overall they are not very well optimized. I did index the api field in the database and that helped a lot.
BiGgUn fbiggun@hotmail.com said:
- Find unimplemented APIs for a given program.
I typed some apps name (mirc, dreamweaver...) but i just got 'The
following applications were found:'. Did i miss something ?
The forms are currently at http://24.229.94.2 Unfortunately I can't keep
this as a permanent location. The PC is just too slow
and the scripts really hog CPU. They do lots of SQL queries. :)
SQL queries are already optimized ? Do you use a CGI or PHP script tp make
your queries ?
Stephan
On August 3, 2003 03:38 am, David Miller wrote:
Recently I spent some time on this again and would like anyone interested in the database to take a look and email me comments.
When comparing 'exports' for example, I get this kind of output: ... IID_IAVIStream is exported by win98-4.10.1998 and wine IID_IGetFrame is exported by win98-4.10.1998 and wine BitReverseBuf is exported by win98-4.10.1998 only FaxCodecChange is exported by win98-4.10.1998 only ...
which is fine, but I will drop the similarities:
IID_IAVIStream is exported by win98-4.10.1998 and wine IID_IGetFrame is exported by win98-4.10.1998 and wine
just output the differences, there are too many anyway. Or have a checkbox to ask the user if they want to see only the differences.
Le lun 04/08/2003 à 10:39, Dimitrie O. Paun a écrit :
On August 3, 2003 03:38 am, David Miller wrote:
Recently I spent some time on this again and would like anyone interested in the database to take a look and email me comments.
When comparing 'exports' for example, I get this kind of output: ... IID_IAVIStream is exported by win98-4.10.1998 and wine IID_IGetFrame is exported by win98-4.10.1998 and wine BitReverseBuf is exported by win98-4.10.1998 only FaxCodecChange is exported by win98-4.10.1998 only ...
which is fine, but I will drop the similarities:
IID_IAVIStream is exported by win98-4.10.1998 and wine IID_IGetFrame is exported by win98-4.10.1998 and wine
just output the differences, there are too many anyway. Or have a checkbox to ask the user if they want to see only the differences.
I checked the unimplemented APIs for vcdeasy, and there are two things: - Cygwin's dlls (cygz, cygjpeg6b, cygxml2-2, cygwin1) are listed, when they're not part of a Windows installation. You should try to separate what's part of Windows (any version), and what can be found elsewhere (from an application, a toolkit, etc.). - Also, in gdi32, BitBlt and StretchBlt are marked as stubs. I have a hard time believing that. What's your method to identify stubs?
Vincent
On August 4, 2003 02:56 pm, Vincent Béron wrote:
I checked the unimplemented APIs for vcdeasy, and there are two things:
- Cygwin's dlls (cygz, cygjpeg6b, cygxml2-2, cygwin1) are listed, when
they're not part of a Windows installation. You should try to separate what's part of Windows (any version), and what can be found elsewhere (from an application, a toolkit, etc.).
- Also, in gdi32, BitBlt and StretchBlt are marked as stubs. I have a
hard time believing that. What's your method to identify stubs?
Cool. Another idea:
The output should be organized on a per-DLL basis. In fact, I think the best way would be to output a list of lists:
<ul> <li> <a name="USER32.DLL"></a><strong>USER32.DLL</strong> <ul> <li> first difference <li> second difference <li> ... </ul> <li> <a name="ANOTHER.DLL"></a><strong>ANOTHER.DLL</strong> ... ... </ul>
This works very well when no DLL is selected (so all DLLs are compared), as well as when one DLL is selected, because it makes it explicit what's going on. Same idea can be applied to apps.
Also, would be very nice to get a "menu" at the top of the page will all the DLL/apps listed within, so one can click on one and jump directly to it. This menu can be as simple as: <a href="#USER32.DLL">USER32.DLL</a> <a href="#ANOTHER.DLL">ANOTHER.DLL</a> ... That is, just let the browser lay them out. (You may want to strip the .DLL, I'm not sure).
Great idea having the option to display only differences between versions or the entire output. That should make things much more readable. Good ideas. I will add a checkbox and a menu list of dlls to my to-do list. :)
Dimitrie O. Paun wrote:
On August 4, 2003 02:56 pm, Vincent Béron wrote:
I checked the unimplemented APIs for vcdeasy, and there are two things:
- Cygwin's dlls (cygz, cygjpeg6b, cygxml2-2, cygwin1) are listed, when
they're not part of a Windows installation. You should try to separate what's part of Windows (any version), and what can be found elsewhere (from an application, a toolkit, etc.).
- Also, in gdi32, BitBlt and StretchBlt are marked as stubs. I have a
hard time believing that. What's your method to identify stubs?
Cool. Another idea:
The output should be organized on a per-DLL basis. In fact, I think the best way would be to output a list of lists:
<ul> <li> <a name="USER32.DLL"></a><strong>USER32.DLL</strong> <ul> <li> first difference <li> second difference <li> ... </ul> <li> <a name="ANOTHER.DLL"></a><strong>ANOTHER.DLL</strong> ... ... </ul>
This works very well when no DLL is selected (so all DLLs are compared), as well as when one DLL is selected, because it makes it explicit what's going on. Same idea can be applied to apps.
Also, would be very nice to get a "menu" at the top of the page will all the DLL/apps listed within, so one can click on one and jump directly to it. This menu can be as simple as: <a href="#USER32.DLL">USER32.DLL</a> <a href="#ANOTHER.DLL">ANOTHER.DLL</a> ... That is, just let the browser lay them out. (You may want to strip the .DLL, I'm not sure).
I'm afraid you are correct. My method of identifying stubs is broken. :( Basically I just select where version = wine and api = $api. If no rows are returned it is unimplemented. That part seems fine. Problem is when I check status to see if it is "stub". It seems there are multiple entries in the wine spec files. BitBlt is listed as a stub in 'display' but it's also cdecl in x11drv, pascal16 is gdi, and stdcall in gdi32. Perhaps I should be limiting my query to the dll which the app is trying to import from. Would that always be correct?
I agree completely. Non-windows dlls don't belong in the output since those API are not provided by windows and will never be implemented in wine. I think it's best if they're removed from the database completely rather than having the script ignore them but I'm afraid when many apps are added it could become a maintenance nightmare.
Vincent Béron wrote:
Le lun 04/08/2003 à 10:39, Dimitrie O. Paun a écrit :
On August 3, 2003 03:38 am, David Miller wrote:
Recently I spent some time on this again and would like anyone interested in the database to take a look and email me comments.
When comparing 'exports' for example, I get this kind of output: ... IID_IAVIStream is exported by win98-4.10.1998 and wine IID_IGetFrame is exported by win98-4.10.1998 and wine BitReverseBuf is exported by win98-4.10.1998 only FaxCodecChange is exported by win98-4.10.1998 only ...
which is fine, but I will drop the similarities:
IID_IAVIStream is exported by win98-4.10.1998 and wine IID_IGetFrame is exported by win98-4.10.1998 and wine
just output the differences, there are too many anyway. Or have a checkbox to ask the user if they want to see only the differences.
I checked the unimplemented APIs for vcdeasy, and there are two things:
- Cygwin's dlls (cygz, cygjpeg6b, cygxml2-2, cygwin1) are listed, when
they're not part of a Windows installation. You should try to separate what's part of Windows (any version), and what can be found elsewhere (from an application, a toolkit, etc.).
- Also, in gdi32, BitBlt and StretchBlt are marked as stubs. I have a
hard time believing that. What's your method to identify stubs?
Vincent
I agree completely. Non-windows dlls don't belong in the output since those API are not provided by windows and will never be implemented in wine. I think it's best if they're removed from the database completely rather than having the script ignore them but I'm afraid when many apps are added it could become a maintenance nightmare.
Maybe it's enough if you maintain a list of unwanted dlls. If a new app is added which needs the same dll then you don't have to delete it again, it will already be ignored. That way the database might get bigger. Or the ignore could be already done on scanning.
bye Fabi
On August 5, 2003 02:42 am, Fabian Cenedese wrote:
Maybe it's enough if you maintain a list of unwanted dlls. If a new app is added which needs the same dll then you don't have to delete it again, it will already be ignored. That way the database might get bigger. Or the ignore could be already done on scanning.
Or simply ignore all the DLLs that are *not* listed as one of the DLLs in any of the Windows versions (including Wine) that we have in the database.
-
BiGgUn -
Dave Miller -
David Miller
-
Dimitrie O. Paun -
dmiller＠ptdprolog.net -
Fabian Cenedese -
Vincent Béron