March 2009 - Wine-devel - list.winehq.org

re: The pros and cons of a wiki AppDB
by Dan Kegel 08 Mar '09

08 Mar '09

There's already an example of an appdb wiki, in a way; see http://wiki.winehq.org/AdobeApps I did this because the appdb has ugly URLs for apps, and I was trying to post links far and wide trying to draw people in to helping test photoshop and a few other adobe apps. If the appdb had nice URLs for apps (and this has already been prototyped to some extent, but not deployed), I probably wouldn't have done it. The appdb has a few other issues (e.g. threaded discussion is awkward to use, deleting old comments takes lots of clicking and scrolling, screen real estate is wasted at the top such that users have to scroll to get to the good stuff, the way test results are selected and displayed is really confusing, etc) but in general we *need* a structured way to present the data, because otherwise we'd have chaos. So I like the appdb, even with all those faults, and I'd like to keep it and incrementally improve it rather than pitch it all and go for the chaos of a wiki. - Dan

1 0

Re: [2/6] ws2_32/tests: add tests for Inet_Ntop and inet_ntoa
by James Hawkins 08 Mar '09

08 Mar '09

On Sat, Mar 7, 2009 at 5:56 PM, Jeff Latimer <lats(a)yless4u.com.au> wrote: > Note that Inet_Ntop is only available in Vista and Windows 2008. Hence the > testing of version to avoid breaking the test suite on earlier OS's. > Checking the windows version is not allowed in the tests. -- James Hawkins

2 3

AppDB entries are being delete without contacting maintainer by Rozanne
by Klaus Layer 07 Mar '09

07 Mar '09

Hi all, since several months a user Rozanne is changing AppDB entries without contacting the maintainers. Most of the changes so far were minor changes. But today I was informed that Rozanne just deleted an entry which was maintained by me. According to the email I received, there were duplicated entries for the programm Mapsource. I regard deleting entries from Appdb without giving the maintainer a chance to backup what they maintained a *very* unfriendly act. I would have merged the two entries under one to save the valuable information users added to AppDB. Just deleting entries from AppDB, deletes information the wine community collected to support using wine. Users spent a lot of time and just deleting their work is *not* acceptable. Can someone of the adminstrators of AppDB please make sure that Rozanne stops deleting entries from AppDB without informing the maintainers before. I would expect to be informed about such an action before and that I as a maintainer have the right to discuss was is being delete and what not. Thanks, Klaus

7 10

Re: [1/12] dinput: begin joystick separation into a generic module
by Vitaliy Margolen 07 Mar '09

07 Mar '09

Aric Stewart wrote: > --- Patch set looks good with exception of - few more things can be moved out of joystick_linuxinput.c. But that can be separate patch(es). Vitaliy

2 1

Whither AppDB? (was: Re: AppDB entries are being delete without contacting maintainer by)
by David Gerard 07 Mar '09

07 Mar '09

2009/3/7 Ben Klein <shacklein(a)gmail.com>: > A wiki is likely to be highly unsuccessful for AppDB when the focus is > on test data. I would have thought the focus would be on being useful to users. > Regarding the changelog/history, it'd even be possible to use git to > manage AppDB entries. It's perfectly possible to implement a complete > history without moving to a wiki, but in my opinion only admins should > have access to the history. At present users don't have a reliable go-to place. The present AppDB's failings have been detailed at length on wine-devel. I must confess I am entirely unable to see why history data, or any data in AppDB, should be restricted. - d.

2 1

Test network under wine
by Oliver aka v1k1ng0 07 Mar '09

07 Mar '09

Hello, firstly, I'm sorry for posting in the 3 lists ... I don't know if it is a bug or if some developer can help me. I comment my problem, I've used a game named FML (football manager live) with wine previously, it worked (months ago), I don't remember the version of FML client and wine version :-( I would want play to FML again, I've downloaded the new version of fml client and I've installed the last version of wine (1.1.16), but it doesn't work. The first thing that does the fml client is connect to a server for updating it, and it doesn't work. I've tried test my network under wine (I use debian linux, unstable version, I've in my sources.list "deb http://www.lamaresh.net/apt sid main"), installing a program named "The Dude" ( http://wiki.mikrotik.com/wiki/Dude_Linux_Installation) It works, it opens, but it can't connect with localhost to a port, I think that wine doesn't work with my network config. I'm using wifi, I've an access point that provides dhcp. My linux box works with the network config perfectly. I've read the wine faq, and it says that I may look my hosts file, and it is correct. I have 127.0.0.1 for loopback, and my wifi interface IP with my FQDN and my hostname. Thanks beforehand and I'm sorry for my english, I'm spanish ;-) Thanks! Cheers...

1 0

Re: AppDB entries are being delete without contacting maintainer by Rozanne
by James Mckenzie 06 Mar '09

06 Mar '09

Austin English <austinenglish(a)gmail.com> wrote on March 6th: >Sent: Mar 6, 2009 4:47 PM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Wine Develop <wine-devel(a)winehq.org> >Subject: Re: AppDB entries are being delete without contacting maintainer by Rozanne > >On Fri, Mar 6, 2009 at 3:44 PM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> Austin English <austinenglish(a)gmail.com> wrote on March 6: >>>Sent: Mar 6, 2009 1:42 PM >>>To: Klaus Layer <klaus.layer(a)gmx.de>, Rosanne DiMesio <dimesio(a)earthlink.net> >>>Cc: Wine Develop <wine-devel(a)winehq.org> >>>Subject: Re: AppDB entries are being delete without contacting maintainer by Rozanne >>> >>>On Fri, Mar 6, 2009 at 2:36 PM, Klaus Layer <klaus.layer(a)gmx.de> wrote: >>>> Hi all, >>>> >>>> since several months a user Rozanne is changing AppDB entries without >>>> contacting the maintainers. Most of the changes so far were minor changes. >>>> But today I was informed that Rozanne just deleted an entry which was >>>> maintained by me. According to the email I received, there were duplicated >>>> entries for the programm Mapsource. I regard deleting entries from Appdb >>>> without giving the maintainer a chance to backup what they maintained a >>>> *very* unfriendly act. I would have merged the two entries under one to save >>>> the valuable information users added to AppDB. Just deleting entries from >>>> AppDB, deletes information the wine community collected to support using >>>> wine. Users spent a lot of time and just deleting their work is *not* >>>> acceptable. >>>> >>>> Can someone of the adminstrators of AppDB please make sure that Rozanne stops >>>> deleting entries from AppDB without informing the maintainers before. I would >>>> expect to be informed about such an action before and that I as a maintainer >>>> have the right to discuss was is being delete and what not. >>>> >>>> Thanks, >>>> >>>> Klaus >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: AppDB <appdb-noreply(a)winehq.org> >>>> To: appdb-noreply(a)winehq.org >>>> Date: Fri, 06 Mar 2009 08:42:12 -0600 >>>> Subject: [AppDB] Submitter screenshots deleted >>>> >>>> Submitter screenshots deleted >>>> ------------------------------------------------------- >>>> The screenshots you submitted for MapSource 6.13.7 have been deleted because MapSource 6.13.7 was deleted. >>>> The action was performed by Rosanne >>>> Reasons given >>>> The parent entry was deleted. The reason given for that deletion was: >>>> Duplicate entry >>>> >>>> Best regards. >>>> The AppDB team >>>> http://appdb.winehq.org/ >>>> >>>> >>>> If you don't want to receive any other e-mail, please change your preferences: >>>> http://appdb.winehq.org/preferences.php >>>> >>>> >>>> >>>> >>> >>>Well, Rozanne _is_ an AppDB administrator, hence the permission to >>>delete those entries. >>> >>>That said, yes, notice should be given. >>> >> Also, please be aware that entries referring to ReactOS, PlayonLinux and Crossover are also being removed. The latter is actually biting the hand that feeds us. CodeWeavers, the producers of Crossover, host WineHQ. What might be a better idea is to state: >> >> "This program has been shown to work better with Crossover, please visit their web site for more details. Please be aware that Crossover is a commercial product whose developers also support Wine." >> >> James McKenzie >> > >Codeweavers has their own AppDB type system: I am very well aware that this exists. However, folks with Wine may NOT. Putting a pointer in the AppDB for those programs that need a lot of work to run under Wine may prove helpful (remember that is the purpose of this system to get users to get their favorite Windows program running under Linux/UNIX.) We also have to remember that some folks picked up Linux/Wine because it is FREE, and sending them off to a product that may cost them money will just get the upset unless we 'warn' them first. So, my suggestion is just that, a suggestion. However, I have found that one of my favorite First Person Shooters will NOT run under Wine. No problem as it does with CrossOver (and it is actually worse under CrossOver Games for Mac), so I have it and I use it. The problem that causes the game to fail is outside of the scope of the Wine project, as CodeWeavers worked around the busted OpenGL in Apple's/XQuartz's X11 implementation. Thus if I were to write up the program under Wine it would be Garbage with a cavat that it does work under Crossover Mac. This is NOT needed for Linux as it runs just fine under most, if not all distros. I don't know or care about ReactOS or PlayOnLinux's abilities at this time. I would NOT like to see them in the AppDB for a number of reasons, mostly legal. It might also be possible to put the existance of CrossOver in the first page, but that would be up to the web masters. James McKenzie

1 0

Status of TWAIN and SANE
by Jeremy White 06 Mar '09

06 Mar '09

Alexandre is right; text files that bit rot are a rotten way to report status. Better is to write verbose emails that make people click delete quickly <grin>. I've been working on improving Wine's scanner support for the past few weeks, and it's come a long way. If anyone has a scanner, and wants to help me out, I'd sure appreciate testing. We could use other applications and other sane scanners as test data points. So here is a current status: What works For Me (TM): 1. Most of what the TWAIN 1.8 specification defines as mandatory is now implemented. I'll document the exceptions in the code shortly. 2. Scanning with IrfanView and Acrobat Professional seems to mostly behave. What doesn't work: 1. You can't use advanced Twain features like file transfer mode. 2. Memory xfer mode is almost certainly broken. 3. Acrobat lets you set a custom scan size, which we don't support (see DAT_IMAGELAYOUT, below). If anyone else wants to play, I'd appreciate it. Cheers, Jeremy

1 0

Re: Resubmit user32: TrackPopupMenu(Ex) fixes
by Reece Dunn 06 Mar '09

06 Mar '09

2009/3/6 Rein Klazes <wijn(a)online.nl>: > Hi, > > Several rounds of commits have gone by without this patch. > I thought it was rather noncontroversial, there must > be something that I am overlooking. Can I get a hint please? > > (cleaned up some white space errors, otherwise patch is unchanged. ) > > Fix another bug in the application of bug#9615. TrackMenuPopupEx is > called with a NULL menu handle, and the application crashes on the > returned NULL value in the following INITMENU message. > > for the Changelog: > Check for invalid menu handle passed to TrackPopupMenu and > TrackPopupMenuEx. > Add conformance tests for the correct handling of those invalid handles. > TrackPopupMenu should call TrackPopupMenuEx, not the other way. NOTE: I am going to refer to TrackPopupMenu as TPM and TrackPopupMenuEx as TPMEx in the rest of this reply. You probably want to split this up into 3 patches. Add the tests first - with appropriate todo_wine entries, then the fix, then the TPM -> TPMEx change. = Implementation Comments: + /* FIXME: this check is performed several times, here and in the called + functions. That could be optimized */ + if( !hMenu || !MENU_GetMenu( hMenu )) { + SetLastError( ERROR_INVALID_MENU_HANDLE) ; + return FALSE; + } Which called functions are doing this check? You should do the SetLastError call there instead (in MENU_TrackMenu?). -BOOL WINAPI TrackPopupMenuEx( HMENU hMenu, UINT wFlags, INT x, INT y, - HWND hWnd, LPTPMPARAMS lpTpm ) +BOOL WINAPI TrackPopupMenu( HMENU hMenu, UINT wFlags, INT x, INT y, + INT nReserved, HWND hWnd, const RECT *lpRect ) { - FIXME("not fully implemented\n" ); Why are you removing this FIXME? Do you know that your changes fully implement TPMEx (which does not have the FIXME in your patch)? - return TrackPopupMenu( hMenu, wFlags, x, y, 0, hWnd, - lpTpm ? &lpTpm->rcExclude : NULL ); + return TrackPopupMenuEx( hMenu, wFlags, x, y, hWnd, NULL); What is the rationale behind calling TPMEx from TPM? Is it so you can properly implement something in TPMEx that is not provided in TPM? If so, are there any tests to show that there are differences that require this change? You have two changes in this patch: fixing the last error value and calling TPMEx from TPM. These need to be separate patches as it is difficult to see what the changes are. +static int gflag_initmenupopup, Consider calling this something like gcalled_initmenupopup. +/* some TrackPopupMenu and TrackPopupMenuEx tests */ +/* the LastError values differ between NO_ERROR and invalid handle */ +/* between all windows versions tested. The first value is that valid on XP */ +/* Vista was the only that made returned different error values */ +/* between the TrackPopupMenu and TrackPopupMenuEx functions */ This is not needed - the code tells us this. + SetWindowLongPtr( hwnd, GWLP_WNDPROC, (LONG_PTR)menu_ownerdraw_wnd_proc); Why are you using the ownerdraw class? Create one for the TPM/TPMEx tests. + for( Ex = 0; Ex < 2; Ex++) { Reading the tests and trying to understand what they are doing is confusing. It is better to split it out into a TMP and a TPMEx test function (no MyTrackPopupMenu) like the SHCreateStreamOnFileA/W/Ex tests are doing (http://source.winehq.org/git/wine.git/?a=blob;f=dlls/shlwapi/tests/istream.…) You can add a trace at the top of each function so you don't need to write out which TPM/TPMEx function you are testing in every call (the Ex ? "Ex" : "" looks ugly - expecially in every trace call). Splitting it out also allows you later to do TPM or TPMEx specific tests that show the differences between these functions. + /* display the menu */ This comment is redundant. + /* start with an invalid menu handle */ Consider removing the "start with", e.g. "invalid argument tests". + ok( !(gflag_initmenupopup || gflag_entermenuloop || gflag_initmenu), + "got unexpected message(s)%s%s%s\n", + gflag_initmenupopup ? " WM_INITMENUPOPUP ": " ", + gflag_entermenuloop ? "WM_INITMENULOOP ": "", + gflag_initmenu ? "WM_INITMENU": ""); Break this out into 3 ok checks -- ok(!gflag_initmenupopup, "WM_INITMENUPOPUP should not be called on invalid arguments."). + ok( gle == NO_ERROR + || gle == ERROR_INVALID_MENU_HANDLE /* NT4, win2k and Vista in the TrackPopupMenuEx case */ In one of the above calls you have marked the NO_ERROR as broken. Why the difference? = General Use blank lines to separate out the blocks of functionality (see other tests, like the istream.c or ordinal.c (also in shlwapi) tests for examples) -- we are not constrained by the size of the source code, especially in tests. Readability is paramount in the tests. Since you are noting message sequences, see http://source.winehq.org/git/wine.git/?a=blob;f=dlls/comctl32/tests/monthca… for an example of how to do message sequence tests. = Minor Style / Grammar Nits: + /* FIXME: this check is performed several times, here and in the called + functions. That could be optimized */ You are missing a '.' at the end of the sentence. + SetLastError( ERROR_INVALID_MENU_HANDLE) ; The spacing is inconsistent here. The space at the end should be before the ), not after it. + ok( ret, "AppendMenA has failed!\n"); Typo: should be AppendMenuA. - Reece

2 2

Re: dlls/userenv: fixed stubs GetUserProfileDirectoryW/A (6)
by Paul Vriens 06 Mar '09

06 Mar '09

Andreas Rosenberg wrote: > > ------------------------------------------------------------------------ > > Hi, Error during compilation: userenv_main.c:181: warning: passing argument 1 of ‘GetUserNameW’ from incompatible pointer type Shouldn't that line be: res = GetUserNameW( userName, &sizeName ); -- Cheers, Paul.

2 4