June 2010 - Wine-Devel - list.winehq.org

Re: (Resent) Documentation - Reference to MSDN?

by Max TenEyck Woodbury

Juan Lang: <grin> Of course one of the reasons to add documentation is precisely because the information on MSDN is less than perfect. Having a good interface definition makes things easier. I'm still in the process of learning how to submit patches. These would be low risk but useful changes so they make good test material. Juan Lang, André Hentschel, Owen Rudge: So, from what Owen said, having a URL can be helpful, but should not be the total documentation. A date as part of the reference probably would be enough warning that things change. Alexandre: Would you mind getting documentation update patches during the code freeze?

June 30, 2010

Re: Please review: Patch for non-Linux serial set_baud_rate()

by Ken Thomases

On Jun 30, 2010, at 11:47 AM, Ken Thomases wrote: > I happened to stumble across some code which didn't look quite right in dlls/ntdll/serial.c. However, I have no expertise in serial comms or termios. Also, I have no means to test the change I propose. On the other hand, the change seems clearly right and conforms to what I learn from man pages, etc. On re-reading, I realize I didn't say what the nature of the problem and change are: set_baud_rate() needs to poke at a termios structure and enter the desired baud rate into its fields. However, the baud rate is represented differently on Linux than on other platforms. This is detected with an "#ifdef CBAUD" test. On Linux, the baud rate goes into the c_cflag field; elsewhere, it goes into dedicated c_ospeed and c_ispeed fields. At some point, somebody extended the non-Linux branch to support higher baud rates, to match capability that the Linux branch had. However, they seem to have just copied the Linux-appropriate code and pasted it into the non-Linux branch. So, the code is stuffing the baud rate into the c_cflag field and not the c_ospeed field. In the non-Linux branch, the high baud rate cases of the switch statement don't match the lower baud rate cases. My proposed change sets the baud rate via the c_ospeed field for all cases on the non-Linux branch. Cheers, Ken

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Erich Hoover

On Wed, Jun 30, 2010 at 11:44 AM, Juan Lang <juan.lang(a)gmail.com> wrote: > > ... > A more general response: I'm not sure that a lot of documentation > patches will be accepted. MSDN has to be considered the definitive > resource for the Windows API. It's often incorrect, of course, and > our regression tests aim to ameliorate the inaccuracy, but we probably > have enough work implementing the Windows API without taking on the > task of documenting it too. > --Juan I was looking into this a while ago and you can add documentation to the "Wine API" by properly formatting it in your patches, for example: http://source.winehq.org/WineAPI/CreateIcon.html is generated from the code here: http://source.winehq.org/source/dlls/user32/cursoricon.c#L1473 Personally, I think that it would be really good to do a better job of documenting the API functions (particularly edge cases). I'm currently very busy with work, but if Alexandre is ok with documentation-only patches then this is something I'm tempted to jump on (in the areas where I have sufficient familiarity) when I have some more free time. Erich Hoover ehoover(a)mines.edu

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Owen Rudge

> No. MSDN is in the habit of changing its URLs all too frequently. For what it's worth, while MSDN seems to like changing its URLs a lot, it does seem to be quite good at maintaining forwarders for the old URLs - most API documentation URLs I've randomly found from 5 years ago still work, for instance. But I agree that it's probably not worth including them in Wine's documentation. -- Owen Rudge http://www.owenrudge.net/

June 30, 2010

Re: add russian translation for winerrs messages [try2]

by Vitaly Lipatov

В сообщении от Среда 30 июня 2010 Вы написали: > Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: ... > Also it doesn't make much sense to send a half completed translation. You are welcome :) I have no time for translate stupid, obsoleted, unexisted errors. Later, as next step, I will do review again and update translation. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by André Hentschel

Am 30.06.2010 19:25, schrieb Max TenEyck Woodbury: > I've been reading the Wine code and noticed that some of the external > interfaces are practically undocumented. I did a web search on some of > the names and found descriptions in MSDN. > > I realize that copying the information from MSDN directly into the code > is a poor idea (like copyright violation) so I have a couple of > questions: > > 1) Would including the URL of the MSDN article be useful/a good idea? Might be a bad idea as such URL may be dead in 12 Month or so, but it is not forbidden. > 2) Would enumerating coded values and flags be allowed? That is the best solution i think. -- Best Regards, André Hentschel

June 30, 2010

Re: (Resent) Documentation - Reference to MSDN?

by Juan Lang

Hi Max, > 1) Would including the URL of the MSDN article be useful/a good idea? No. MSDN is in the habit of changing its URLs all too frequently. A more general response: I'm not sure that a lot of documentation patches will be accepted. MSDN has to be considered the definitive resource for the Windows API. It's often incorrect, of course, and our regression tests aim to ameliorate the inaccuracy, but we probably have enough work implementing the Windows API without taking on the task of documenting it too. --Juan

June 30, 2010

(Resent) Documentation - Reference to MSDN?

by Max TenEyck Woodbury

I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? 2) Would enumerating coded values and flags be allowed? 3) Where should data structures be documented?

June 30, 2010

Please review: Patch for non-Linux serial set_baud_rate()

by Ken Thomases

Hi, I happened to stumble across some code which didn't look quite right in dlls/ntdll/serial.c. However, I have no expertise in serial comms or termios. Also, I have no means to test the change I propose. On the other hand, the change seems clearly right and conforms to what I learn from man pages, etc. So, I'm hoping somebody who is more familiar with this functionality can review the attached patch before I formally submit it. Another approach that seems better from my reading of the man pages is to switch to using cfsetspeed() [or cfsetospeed() and cfsetispeed()] instead of having separate branches based on defined(CBAUD). But maybe that has portability problems worse than the current approach. Thanks, Ken

June 30, 2010

Creating tests with additional binary modules

by Mariusz Pluciński

Hi, wine-devel I'm working on implementation of Windows Game Explorer interfaces for Wine. The work is in advanced stage now, but I have problem with implementation of conformance tests. Thing I want to test is loading and parsing so-called Game Definition Files. GDF are not separate files, but stored as resources in binary modules (usually in game's main executable). Using GE interfaces, programmer only needs to pass path to binary, and GE automatically loads and process embedded GDF(s). Checking results of routines execution is not problem for me. But thing I test is parser, so I need to pass various GDF files to routine. And, as GDFs are stored in binaries, I will need to create many binaries. They should be created in compile time and available for test's executable while running it. The problem is that I don't know how to do this using wine's mechanisms. How should Makefile.in file look to build additional executable files properly (they should be probably always native win32 executables, even if parameter "crosstest" wasn't specified)? How should I guarantee that these additional executables will be copied into winetest directory (to make them accessible while executing tests)? Thanks in advance Mariusz Pluciński

June 30, 2010