Hi, we've been discussing in bug 13462 howto fix that bug, but in short i think we lack knowledge of how this should properly be fixed, and Erich suggested to take this to wine-devel.
I did some testing and this is a major bug, preventing the following apps from working: CDBurner XP, XML Notepad2007, Nasa WorldWind, FX_Composer(nvidia), Ninja Trader and probably a lot more .net applications.
I fixed up a patch here http://bugs.winehq.org/attachment.cgi?id=15775, that lets the applications start fine, but i haven't got a clue if it's correct, and Erich said it probably isn't correct, so my question is: Does anyone of the developers (on ole32) have suggestions how to fix this bug properly? More info at http://bugs.winehq.org/show_bug.cgi?id=13462
2008/9/14 Louis. Lenders xerox_xerox2000@yahoo.co.uk:
Hi, we've been discussing in bug 13462 howto fix that bug, but in short i think we lack knowledge of how this should properly be fixed, and Erich suggested to take this to wine-devel.
I did some testing and this is a major bug, preventing the following apps from working: CDBurner XP, XML Notepad2007, Nasa WorldWind, FX_Composer(nvidia), Ninja Trader and probably a lot more .net applications.
I fixed up a patch here http://bugs.winehq.org/attachment.cgi?id=15775, that lets the applications start fine, but i haven't got a clue if it's correct, and Erich said it probably isn't correct, so my question is: Does anyone of the developers (on ole32) have suggestions how to fix this bug properly? More info at http://bugs.winehq.org/show_bug.cgi?id=13462
I suggest you write a test case that replicates what the application does and either send it to wine-patches with appropriate todo_wine's or attach it to the bug.
It might help you understand what needs to be done or it will help someone else implement the functionality that is causing the application to fail.
Rob Shearman <robertshearman <at> gmail.com> writes:
I suggest you write a test case that replicates what the application does and either send it to wine-patches with appropriate todo_wine's or attach it to the bug.
Well, it looks like the app is only checking if the uuid of the interface is defined using Context_QueryInterface, and that's about it. It doesn't really seem to try to use anything from it, as Erich's initial hack is already enough to get the apps running as well (this one:http://bugs.winehq.org/attachment.cgi?id=13379)
It might help you understand what needs to be done or it will help someone else implement the functionality that is causing the application to fail.
So as far as i can tell, the functionality doesn't need to be implemented at all, it's just enough to fake as if it would exist, by returning S_OK, when Context_QueryInterface is called for this specific uuid.
So what now?
2008/9/15 Louis Lenders xerox_xerox2000@yahoo.co.uk:
Rob Shearman <robertshearman <at> gmail.com> writes:
I suggest you write a test case that replicates what the application does and either send it to wine-patches with appropriate todo_wine's or attach it to the bug.
Well, it looks like the app is only checking if the uuid of the interface is defined using Context_QueryInterface, and that's about it. It doesn't really seem to try to use anything from it, as Erich's initial hack is already enough to get the apps running as well (this one:http://bugs.winehq.org/attachment.cgi?id=13379)
That's fine. You can still add a test that does the same as what the app does.
It might help you understand what needs to be done or it will help someone else implement the functionality that is causing the application to fail.
So as far as i can tell, the functionality doesn't need to be implemented at all, it's just enough to fake as if it would exist, by returning S_OK, when Context_QueryInterface is called for this specific uuid.
That's not acceptable as that change will cause applications that do use the returned interface to either crash on a NULL pointer (if you set *ppv to NULL and return S_OK) or stack corruption (if you return a pointer to the wrong interface). You will be turning a known unimplemented feature into a buggy feature which will be harder to fix later.
So what now?
If running the tests on Windows show that the interface in question is implemented for the Context object then add that interface to the object with stubbed functions.
Rob Shearman <robertshearman <at> gmail.com> writes:
That's not acceptable as that change will cause applications that do use the returned interface to either crash on a NULL pointer (if you set *ppv to NULL and return S_OK) or stack corruption (if you return a pointer to the wrong interface). You will be turning a known unimplemented feature into a buggy feature which will be harder to fix later.
So what now?
If running the tests on Windows show that the interface in question is implemented for the Context object then add that interface to the object with stubbed functions.
Hi Rob, thanks for the reply. I'll add your comments to the bug report. As for fixing the bug + the tests myself, i guess i have to learn a lot more about this stuff, but maybe someone (with more knowledge on this matter) can use your hints to get the bug fixed. Regards
-
Louis Lenders -
Louis. Lenders
-
Rob Shearman