Jacobus Erasmus <jacobus(a)kewlconcepts.co.za> wrote:
Is it possible to workout or read the API's that a specific Windows application use ?
The theory is that it would be possible to estimate the amount of work needed to get a Windows app to work on Wine by calculating the number of API's that is not working or only half working and estimating the time it would take to correct these API's.
This would be a very rough estimation. Some APIs are simple to implement and some are not. The ones not yet in Wine are often of the second class but that is not a general rule.
By running wine-debug it is possible to get the API's used by an application. I'm hoping that there is some simpler way (although I'm not holding my breath) to read the API's used by an application directly from the .exe or .dll.
It really depends. You could walk the import table of the executable both the standard and delayed imports and get quite far. dumpbin or whatever it is called can do that. However this will not account for dynamically imported APIs some applications do, to work for instance around API differences between different Windows version. Or another reason might be that a certain API is optional and the app should keep running eventhough that API is not available on the target system. I think to catch those APIs as well only API profiling would help. But it may not be the main issue here as the dynamic runtime linking is most often done to prevent the application from not starting up when the underlyiing API is not present. Rolf Kalbermatter
On May 18, 2004 07:19 am, Rolf Kalbermatter wrote:
Jacobus Erasmus <jacobus(a)kewlconcepts.co.za> wrote:
Is it possible to workout or read the API's that a specific Windows application use ?
The theory is that it would be possible to estimate the amount of work needed to get a Windows app to work on Wine by calculating the number of API's that is not working or only half working and estimating the time it would take to correct these API's.
This would be a very rough estimation. Some APIs are simple to implement and some are not. The ones not yet in Wine are often of the second class but that is not a general rule.
By running wine-debug it is possible to get the API's used by an application. I'm hoping that there is some simpler way (although I'm not holding my breath) to read the API's used by an application directly from the .exe or .dll.
It really depends. You could walk the import table of the executable both the standard and delayed imports and get quite far. dumpbin or whatever it is called can do that. However this will not account for dynamically imported APIs some applications do, to work for instance around API differences between different Windows version. Or another reason might be that a certain API is optional and the app should keep running eventhough that API is not available on the target system.
And then there is the functionality it accesses via COM
I think to catch those APIs as well only API profiling would help. But it may not be the main issue here as the dynamic runtime linking is most often done to prevent the application from not starting up when the underlyiing API is not present.
Rolf Kalbermatter
-- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed
On Tue, 2004-05-18 at 16:19, Rolf Kalbermatter wrote:
Jacobus Erasmus <jacobus(a)kewlconcepts.co.za> wrote:
Is it possible to workout or read the API's that a specific Windows application use ?
The theory is that it would be possible to estimate the amount of work needed to get a Windows app to work on Wine by calculating the number of API's that is not working or only half working and estimating the time it would take to correct these API's.
This would be a very rough estimation. Some APIs are simple to implement and some are not. The ones not yet in Wine are often of the second class but that is not a general rule.
Yep except if you get the estimate from a developer. Compare with his previous estimates and accuracy of those estimate and then incorporate it into the model. But yes I agree a very rough estimate basically multiply by 2 then multiply by 1.5 and then tell you're boss it will take twice as long. Hopefully we can get some estimation on the complexities of implementing certain API's and work this into the model. CU jacobus(a)kewlconcepts.co.za
participants (3)
-
Bill Medland -
Jacobus Erasmus -
Rolf Kalbermatter