Especially the code that is responded to as , I know it's a mess to look at, but I didn't write it.
Can you give us examples?
Mostly Wine attempts to follow how Windows works, so MSDN provides a lot of the documentation. This is becoming increasingly true, with kernel32 being implemented on top of ntdll.
There are bits that are hard to understand, certainly, and some areas could use some comments. Unfortunately sometimes the lack of comments demonstrates a lack of understanding, but the code works for someone, somewhere, so we're mostly afraid to touch it until some brave soul comes along.
For example, SHFileOperation was a complete mess until James fixed it up.
Another example is user32. It's impossible to document (in English) what it's supposed to be doing. For this, and many other cases, a good regression test suite is the best documentation: it tells you what's expected, so if you go mucking around you have checks against introducing regressions.
I know you've been working with msi lately. The fact that you've figured out where the problem is indicates to me that it's adequately commented, even if the learning curve is still a bit steep.
Patches to add API comments for the Wine API guide (http://source.winehq.org/WineAPI/ ) are always welcome. Patches to document dodgy bits of code may or may not be accepted, but regression tests to justify dodgy bits of code are happily accepted too. http://source.winehq.org/WineAPI/
--Juan
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I'm just nitpicky I guess. If I use K & R style, or not enough white space, or don't align things perfectly at work my boss will kindly print off a copy of the companies acceptable coding standards policy and bring it over. I guess I'm just used to having things that way, and the shifting coding style and lack of comments in places in wine makes the learning curve steeper than it needs to be for beginning wine developers.
Just my 2 cents as a beginning wine developer.
From: Juan Lang juan_lang@yahoo.com To: EA Durbin ead1234@hotmail.com CC: wine-devel@winehq.org Subject: Re: How are we doing? Date: Fri, 2 Jun 2006 10:56:15 -0700 (PDT)
Especially the code that is responded to as , I know it's a mess to look at, but I didn't write it.
Can you give us examples?
Mostly Wine attempts to follow how Windows works, so MSDN provides a lot of the documentation. This is becoming increasingly true, with kernel32 being implemented on top of ntdll.
There are bits that are hard to understand, certainly, and some areas could use some comments. Unfortunately sometimes the lack of comments demonstrates a lack of understanding, but the code works for someone, somewhere, so we're mostly afraid to touch it until some brave soul comes along.
For example, SHFileOperation was a complete mess until James fixed it up.
Another example is user32. It's impossible to document (in English) what it's supposed to be doing. For this, and many other cases, a good regression test suite is the best documentation: it tells you what's expected, so if you go mucking around you have checks against introducing regressions.
I know you've been working with msi lately. The fact that you've figured out where the problem is indicates to me that it's adequately commented, even if the learning curve is still a bit steep.
Patches to add API comments for the Wine API guide (http://source.winehq.org/WineAPI/ ) are always welcome. Patches to document dodgy bits of code may or may not be accepted, but regression tests to justify dodgy bits of code are happily accepted too. http://source.winehq.org/WineAPI/
--Juan
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
--- EA Durbin ead1234@hotmail.com wrote:
If I use K & R style, or not enough white space, or don't align things perfectly at work my boss will kindly print off a copy of the companies acceptable coding standards policy and bring it over.
Ah, so it's the lack of a defined style guideline that's the problem? That got me too back in the beginning.
The Official Wine Code Style is something like this:
1. New file: whatever the author wants 2. Existing file: whatever others did
This takes some getting used to, and since 2. isn't strictly enforced, we sometimes end up with colliding styles. Only one time that I remember did we manage to sneak in a bunch of formatting changes (into shell32, which was a real mess of conflicting styles.)
I guess that could be documented better, though a quick google turns up statements to that effect: http://www.kerneltraffic.org/wine/wn20010305_85.html#4 http://www.winehq.org/pipermail/wine-devel/2004-July/028483.html
It's also in the developer guide, though a bit buried: http://winehq.org/site/docs/winedev-guide/style-notes The fact that I couldn't find the darn thing quickly is a problem ;)
--Juan
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Friday, June 2, 2006, 12:20:58 PM, EA Durbin wrote:
From: Juan Lang juan_lang@yahoo.com To: EA Durbin ead1234@hotmail.com CC: wine-devel@winehq.org Subject: Re: How are we doing? Date: Fri, 2 Jun 2006 10:56:15 -0700 (PDT)
Especially the code that is responded to as , I know it's a mess to look at, but I didn't write it.
Can you give us examples?
Mostly Wine attempts to follow how Windows works, so MSDN provides a lot of the documentation. This is becoming increasingly true, with kernel32 being implemented on top of ntdll.
There are bits that are hard to understand, certainly, and some areas could use some comments. Unfortunately sometimes the lack of comments demonstrates a lack of understanding, but the code works for someone, somewhere, so we're mostly afraid to touch it until some brave soul comes along.
For example, SHFileOperation was a complete mess until James fixed it up.
Another example is user32. It's impossible to document (in English) what it's supposed to be doing. For this, and many other cases, a good regression test suite is the best documentation: it tells you what's expected, so if you go mucking around you have checks against introducing regressions.
I know you've been working with msi lately. The fact that you've figured out where the problem is indicates to me that it's adequately commented, even if the learning curve is still a bit steep.
Patches to add API comments for the Wine API guide (http://source.winehq.org/WineAPI/ ) are always welcome. Patches to document dodgy bits of code may or may not be accepted, but regression tests to justify dodgy bits of code are happily accepted too. http://source.winehq.org/WineAPI/
--Juan
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I'm just nitpicky I guess. If I use K & R style, or not enough white space, or don't align things perfectly at work my boss will kindly print off a copy of the companies acceptable coding standards policy and bring it over. I guess I'm just used to having things that way, and the shifting coding style and lack of comments in places in wine makes the learning curve steeper than it needs to be for beginning wine developers.
Just my 2 cents as a beginning wine developer.
Oh yeah I see your pain right here... Even hard to respond in the well accepted format, not in a business ignorant style - "My comments more important so I'll put then on top."
Vitaliy
-
EA Durbin -
Juan Lang -
Vitaliy Margolen