Hi all, I studied the wine developer's guide and went a bit through the code. I would like a suggestion, a bug to start understanding better the structure of wine and familiarize myself with it in order to be able to contribute more in the future. thank you
I studied the wine developer's guide and went a bit through the code. I would like a suggestion, a bug to start understanding better the structure of wine and familiarize myself with it in order to be able to contribute more in the future.
Often, picking an application that you yourself run is the best way to work through the code, as it'll keep you motivated to understand. Another suggestion is to look through bugzilla for bugs that have the patch keyword. Trying to understand what the patch does, and why it hasn't yet been applied, may give you the insight you're looking for. Good luck, --Juan
Alexandros Dermenakis wrote:
Hi all,
I studied the wine developer's guide and went a bit through the code. I would like a suggestion, a bug to start understanding better the structure of wine and familiarize myself with it in order to be able to contribute more in the future.
thank you
Hi Alexandros, When I began working on Wine, I found that the easiest way for me was to implement parts of Wine that have no implementation yet. Implementing new functions means you don't have to worry about breaking old tests or re-arranging and understanding someone else's code. It also gives you the opportunity to write new tests from the ground up, so you get used to exactly what the unit tests are for and how they work. Look around in Wine for functions that are labeled with FIXMEs indicating that they are stubs, or look in the .spec files for functions declared as stubs. Find a function that has an easy to understand purpose: a very clear input and output. Then, write unit tests in that DLL's test suite that prove all of the important features of that function. Run your tests on an actual Windows OS (look into "crosstests") and verify that they are correct. Finally, implement that function in Wine to make it also pass your tests. If you want a suggestion for where to look for small stubs, take a look at gdi32 and gdiplus. I know they still have some smallish, unimplemented or half-implemented functions. If graphics don't interest you, there are plenty of stubs elsewhere. Once you've got the hang of how the unit tests work (I mean it, the test cases are the most important part of getting patches into Wine), try looking into bugs on WineHQ until you find one you think you might be able to handle. Then gear up for the most fun you'll ever have reading pages and pages debug logs :) No matter where you begin your work, remember that Wine is a difficult project to work on. Because even very subtle changes can cause breakages in seemingly unrelated parts of Wine, the standard for patches is very high. You will need to prove that your patch is correct using the test suites. No provable tests means it's not getting in. Good luck and thanks for your interest, Andrew
Thanks to both of you Andrew and Juan. I think though I'll with Andrew's suggestion. ;-) On Thu, Aug 20, 2009 at 11:58 PM, Andrew Eikum <andrew(a)brightnightgames.com>wrote:
Alexandros Dermenakis wrote:
Hi all,
I studied the wine developer's guide and went a bit through the code. I would like a suggestion, a bug to start understanding better the structure of wine and familiarize myself with it in order to be able to contribute more in the future.
thank you
Hi Alexandros,
When I began working on Wine, I found that the easiest way for me was to implement parts of Wine that have no implementation yet. Implementing new functions means you don't have to worry about breaking old tests or re-arranging and understanding someone else's code. It also gives you the opportunity to write new tests from the ground up, so you get used to exactly what the unit tests are for and how they work.
Look around in Wine for functions that are labeled with FIXMEs indicating that they are stubs, or look in the .spec files for functions declared as stubs. Find a function that has an easy to understand purpose: a very clear input and output. Then, write unit tests in that DLL's test suite that prove all of the important features of that function. Run your tests on an actual Windows OS (look into "crosstests") and verify that they are correct. Finally, implement that function in Wine to make it also pass your tests.
If you want a suggestion for where to look for small stubs, take a look at gdi32 and gdiplus. I know they still have some smallish, unimplemented or half-implemented functions. If graphics don't interest you, there are plenty of stubs elsewhere.
Once you've got the hang of how the unit tests work (I mean it, the test cases are the most important part of getting patches into Wine), try looking into bugs on WineHQ until you find one you think you might be able to handle. Then gear up for the most fun you'll ever have reading pages and pages debug logs :)
No matter where you begin your work, remember that Wine is a difficult project to work on. Because even very subtle changes can cause breakages in seemingly unrelated parts of Wine, the standard for patches is very high. You will need to prove that your patch is correct using the test suites. No provable tests means it's not getting in.
Good luck and thanks for your interest, Andrew
On Fri, Aug 21, 2009 at 12:58 AM, Andrew Eikum <andrew(a)brightnightgames.com>wrote:
Alexandros Dermenakis wrote:
Hi all,
I studied the wine developer's guide and went a bit through the code. I would like a suggestion, a bug to start understanding better the structure of wine and familiarize myself with it in order to be able to contribute more in the future.
thank you
Hi Alexandros,
When I began working on Wine, I found that the easiest way for me was to implement parts of Wine that have no implementation yet. Implementing new functions means you don't have to worry about breaking old tests or re-arranging and understanding someone else's code. It also gives you the opportunity to write new tests from the ground up, so you get used to exactly what the unit tests are for and how they work.
Look around in Wine for functions that are labeled with FIXMEs indicating that they are stubs, or look in the .spec files for functions declared as stubs. Find a function that has an easy to understand purpose: a very clear input and output. Then, write unit tests in that DLL's test suite that prove all of the important features of that function. Run your tests on an actual Windows OS (look into "crosstests") and verify that they are correct. Finally, implement that function in Wine to make it also pass your tests.
If you want a suggestion for where to look for small stubs, take a look at gdi32 and gdiplus. I know they still have some smallish, unimplemented or half-implemented functions. If graphics don't interest you, there are plenty of stubs elsewhere.
Once you've got the hang of how the unit tests work (I mean it, the test cases are the most important part of getting patches into Wine), try looking into bugs on WineHQ until you find one you think you might be able to handle. Then gear up for the most fun you'll ever have reading pages and pages debug logs :)
No matter where you begin your work, remember that Wine is a difficult project to work on. Because even very subtle changes can cause breakages in seemingly unrelated parts of Wine, the standard for patches is very high. You will need to prove that your patch is correct using the test suites. No provable tests means it's not getting in.
Good luck and thanks for your interest, Andrew
As I understand from Wine's policies, functions should only be implemented if an application requires them. If that's correct, a random search for stubs isn't a good idea, because the follow up question would be "which application requires this function?". --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
As I understand from Wine's policies, functions should only be implemented if an application requires them. If that's correct, a random search for stubs isn't a good idea, because the follow up question would be "which application requires this function?".
We certainly prioritize functions that an application needs, but we don't prohibit code that doesn't identify an application that needs it. It's true that we often ask on this mailing list which application needs a function, but I think that's generally when a patch looks strange for some other reason. One of the usual reasons is that it's lacking a test. So, going back to the original advice: if you can write good test cases for a function, then there's a decent chance you can implement it, and both tests and the implementation can find their way into Wine. If you can't write good test cases, you'll have a much harder time getting your code into Wine. --Juan
On Fri, Aug 21, 2009 at 12:25 PM, Juan Lang <juan.lang(a)gmail.com> wrote:
As I understand from Wine's policies, functions should only be implemented if an application requires them. If that's correct, a random search for stubs isn't a good idea, because the follow up question would be "which application requires this function?".
We certainly prioritize functions that an application needs, but we don't prohibit code that doesn't identify an application that needs it. It's true that we often ask on this mailing list which application needs a function, but I think that's generally when a patch looks strange for some other reason. One of the usual reasons is that it's lacking a test.
So, going back to the original advice: if you can write good test cases for a function, then there's a decent chance you can implement it, and both tests and the implementation can find their way into Wine. If you can't write good test cases, you'll have a much harder time getting your code into Wine. --Juan
Thanks for the clarification. --Stephen programmer, n: A red eyed, mumbling mammal capable of conversing with inanimate monsters.
participants (5)
-
Alex Dermenakis -
Alexandros Dermenakis
-
Andrew Eikum -
Juan Lang -
Stephen Eilert