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

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer Nov. 22, 2020

Nov. 22, 2020

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

ODBC Databases: Jet/Access success
by Barry Bird June 14, 2018

June 14, 2018

Good Afternoon. In section 3.3.6.2 of your User Guide you ask readers to report successes with databases other than MS SQL. Well here's one (I know Access 2000 can work with Wine, but this doesn't require Access): How to set up Wine to enable Windows programs that read and write to Jet (Access) databases using ODBC. I write such programs in C and use the API defined in ODBC API Reference http://msdn.microsoft.com/en-us/library/ms714562%28VS.85%29.aspx They work fine on Windows and only require Mingw to be installed to compile and link them, both for console programs and those using Windows SDK. You then can write interactive programs in C which use a full-featured SQL database which comes bundled with Windows. No need to purchase Access. With the set-up below they will also run on Linux (Kubuntu 9.04) and Wine 1.1.26. You need to update the registry to install the Access drivers. Under Windows, export from the Registry to *.reg files the registry entries - HKLM\Software\ODBC - HKLM\Software\Microsoft\Jet all subsidiary keys and values come with them. You can carefully edit these files to remove drivers and DSNs you don't need. Import these files using the registry editor in wine: wine regedit.exe. You need to bring across from Windows to Windows\System32 under wine: clbcatq.dll comres.dll expsrv.dll msjet40.dll mswstr10.dll msjter40.dll msjint40.dll msjtes40.dll msrd3x40.dll odbc32.dll odbccp32.dll odbcji32.dll odbcjt32.dll odbcad32.exe odbcint.dll odbctrac.dll vbajet32.dll Register this server in wine: wine regsvr32.exe msjtes40.dll No need to install MDAC. To use Windows ODBC drivers, you have to override Wine's odbccp32.dll and odbc32.dll with the native versions because the Wine versions are currently wired directly to Linux's unixodbc. This can be done by setting up the ODBC Data Source Administrator odbcad32.exe using winecfg: - Add the program to the Applications tab - then in the libraries tab, pick from 'New override for library' drop-down odbc32.dll and odbccp32.dll add them and edit them to be Native for Windows. Then if you do wine odbcad32.exe this brings up the ODBC Data Source Administrator window as in the Windows Control Panel If needed, set up (System) DSNs using this program. Bring across the programs and *.mdb database files from Windows. Using winecfg, you need to set up each program you want to run with overrides for odbc32.dll and odbccp32.dll (Applications and Libraries tabs) as above. The programs should then run as they did in Windows but perhaps a bit slower with: wine Odbc-prog.exe This has been tested twice on a clean .wine install. I cannot vouch for support of all API and SQL facilities however. I hope someone finds this useful. Barry Bird

5 4

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

Re: XInput [1/4]: Implement XInputGetState
by Stefan Dösinger July 5, 2015

July 5, 2015

Am 09.07.2009 um 02:58 schrieb Michael Gruber: > This patch series implements parts of the XInput library. You can use > this to play games that support Xbox 360 Controllers. To be able to > use this you will need to have your Controller working on Linux via > the xpad kernel driver and the event interface. It will not work on > any OS other than Linux. It supports gamepads, should work with > guitars and wheels, but will not work with dance-mats. > <1-XInputGetState.patch> Is it possible to implement XInput on top of DirectInput? DirectInput already has some internal abstraction layers for differnet joystick APIs, and has basic support for OSX joysticks. Does DInput have enough capabilities to access all the Xbox controller's features? My gut says no, otherwise MS wouldn't have created a new lib. I guess its worth checking though.

5 6

What happened to the Fedora packages?
by Neal Gompa Aug. 2, 2014

Aug. 2, 2014

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?
by Detlef Riekenberg Oct. 9, 2013

Oct. 9, 2013

Hi. >From which configuration does the "ERROR_INVALID_NAME" came from, when calling GetDefaultPrinter(NULL, &size) and no Printer is installed? This Test is Present in the current "dlls/winspool/tests/info.c". MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer is installed: http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in this Situation. -- By By ... ... Detlef

3 3

Re: advpack: Only do_ocx_reg (and thus DllRegisterServer) from RegisterOCX when 'N' is passed as a flag. Clarify documentation.
by James Hawkins Sept. 24, 2011

Sept. 24, 2011

I'm very hesitant about this. MSDN has no documentation about RegisterOCX, so I'm not sure how you're justifying this change. It's been a long time since I worked on this, so I don't remember much, but I do remember testing this method and documenting the parameters correctly. Where are you getting information that 'I' is required when using 'N'? James On Tue, May 11, 2010 at 1:24 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > This is my humble attempt of addressing Alexandre's feeback at > > http://www.winehq.org/pipermail/wine-devel/2010-May/083518.html > > It does pass testing for me, even on FreeBSD/i386, but I will say I did > not find the MSDN documentation I located too helpful/clear, and may have > been misled. > > As a next step we'd need to look into DllInstall. This change, hopefully, > is a move in the right direction, though. If not, some guidance or one of > the pros looking into it will be appreciated. > > Gerald > > --- > dlls/advpack/advpack.c | 14 ++++++++++---- > 1 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/dlls/advpack/advpack.c b/dlls/advpack/advpack.c > index 112d38a..f040ec6 100644 > --- a/dlls/advpack/advpack.c > +++ b/dlls/advpack/advpack.c > @@ -486,8 +486,10 @@ HRESULT do_ocx_reg(HMODULE hocx, BOOL do_reg) > * NOTES > * OCX - Filename of the OCX to register. > * flags - Controls the operation of RegisterOCX. > - * 'I' Call DllRegisterServer and DllInstall. > - * 'N' Only call DllInstall. > + * 'I' Call DllInstall and, unless 'N' is specified as well, > + * DllRegisterServer. > + * 'N' Do not call DllRegisterServer; only valid if 'I' is > + * specified too. > * param - Command line passed to DllInstall. > */ > HRESULT WINAPI RegisterOCX(HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show) > @@ -519,8 +521,12 @@ HRESULT WINAPI RegisterOCX(HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show) > if (!hm) > goto done; > > - hr = do_ocx_reg(hm, TRUE); > - > + if(strchrW(str_flags,'I')) > + { > + if (!strchrW(str_flags,'N')) > + hr = do_ocx_reg(hm, TRUE); > + } > + > done: > FreeLibrary(hm); > HeapFree(GetProcessHeap(), 0, cmdline_copy); > -- > 1.6.6.2 > > >

2 3

re: make "bisected" a keyword in bugzilla?
by Dan Kegel Aug. 8, 2011

Aug. 8, 2011

I think it's a good idea. 'regression' isn't as strong as 'bisected'. Unless there are objections, I'll add the keyword on Monday.

11 15

CD-ROM ioctl support on MacOS?
by Joerg-Cyril.Hoehle＠t-systems.com June 6, 2011

June 6, 2011

Hi, what's the state of CD-ROM support on the Mac? ntdll/cdrom.c contains quite a few #ifdef apple. I'm asking because the mcicda currently uses these ioctl: 1. READ_RAW 2. READ_TOC 3. READ_Q -> POSITION MCICDA could be changed to avoid the third one entirely -- when using the dsound output. Would that be enough to use mcicda on MacOS to play music? Thanks for your help, Jörg Höhle

2 3

Two enhancement requests for winetricks
by Dan Kegel Feb. 21, 2011

Feb. 21, 2011

OK, filed http://code.google.com/p/winezeug/issues/detail?id=127 "want uninstall" and http://code.google.com/p/winezeug/issues/detail?id=128 "want status" - Dan

6 11

Re: Improve handling of invalid input in dlls/comctl32/datetime.c
by Nikolay Sivov Jan. 19, 2011

Jan. 19, 2011

On 12/25/2009 14:18, Gerald Pfeifer wrote: > Otherwise max_count will be undefined in the following loop may do > interesting things it seems. (Does Coverity diagnose similar items?) > > Gerald > > ChangeLog: > Improve handling of invalid input in DATETIME_ReturnFieldWidth. > > diff --git a/dlls/comctl32/datetime.c b/dlls/comctl32/datetime.c > index c240d4f..08c7082 100644 > --- a/dlls/comctl32/datetime.c > +++ b/dlls/comctl32/datetime.c > @@ -38,6 +38,7 @@ > * -- FORMATCALLBACK > */ > > +#include<assert.h> > #include<math.h> > #include<string.h> > #include<stdarg.h> > @@ -619,6 +620,9 @@ DATETIME_ReturnFieldWidth (const DATETIME_INFO *infoPtr, HDC hdc, int count, SHO > lctype = LOCALE_SMONTHNAME1; > max_count = 12; > break; > + default: > + assert(0); > + max_count=0; > } > > cx = 0; > Hi, Gerald. This can't even happen. spec if filtered later with: --- case THREECHARMONTH: case FULLMONTH: case THREECHARDAY: case FULLDAY: --- So no default case here.

3 6

Wine runs IE7!
by Hans Leidekker Nov. 26, 2010

Nov. 26, 2010

Well, sort of. I found bugs in shell32, rpcrt4, comctl32 and wininet that I had to implement, stub and override my way past before it would render a page, but finally, here's the obligatory screenshot. -Hans

3 2

current state of full screen on MacOS?
by Joerg-Cyril.Hoehle＠t-systems.com Oct. 21, 2010

Oct. 21, 2010

Hi, I'd like to know whether a MacOSX user can expect full screen modes to work, as I've heard only rumors and too little facts. My experience is this: + winecfg's window opens fine even with desktop set uo full screen, no window. E.g. as in the initial setting after rm -rf ~/.wine; wine winecfg. + Likewise, other programs opening windows work fine (regedit, notepad etc.). - Programs that offer a "select screen resolution" requester present a list whose largest vertical/Y resolution is 22 pixel less than what the monitor offers. I believe OSX reserves some place for its menu bar. Lower resolution entries, e.g. 1024x768 and 800x600, are listed normally. They work in desktop window mode. - Programs that want to make use of full screen fail or hang somehow. The issue may be two-fold: a) full screen does not work at all, or b) switching to full screen resolutions less than my LCD's native resolution does not work, and applications do not cope with that. E.g. many want to display a low-resolution intro video. - Approx. two monthes ago, a hybrid desktop mode was implemented in Wine: eliminate the desktop window when it matches the full screen size; recreate it when switching back to lower resolutions. I've not observed that effect either, but the idea is brilliant. I've heard that OSX would not switch to lower resolutions like Linux machines do with e.g. xrandr -s 1 or -s 2 etc. My LCD monitor can stretch low resolution VGA signals, e.g. when plugged to a Linux netbook. However the "early 2009" nVidia Macs do not produce analog video signals anymore, and I'm using the DVI-D output. What's the current state of Wine (and Darwine) w.r.t. full screen mode? Is it just my digital DVI + LCD setting or is there an issue with Wine? I've built Wine-1.1.24 with OSX 10.5.7 and XQuartz 2.3.3.2. Thank you, Jörg Höhle.

3 2

Ongoing Debian package maintenance.
by Ben Klein Oct. 14, 2010

Oct. 14, 2010

Hello everyone, My health has not improved at all since my last call for help with the Debian package management. I really need someone to take over from me, or at least some help to devise a new set of (semi-)automated build scripts. Any volunteers? Kind regards, Ben

5 11

Right-To-Left (RTL) languages and Wine
by Paul Vriens Sept. 29, 2010

Sept. 29, 2010

Hi, I've been in talks with a Hebrew translator for some time now and I'd like to have Wine being able to start doing more RTL stuff. I'm looking for example at http://bugs.winehq.org/show_bug.cgi?id=1158 If I run an English winmine.exe on an Arabic box (thanks to the testbot) the main window will shows as normal LTR window layout with the menu's left justified as well. So eventhough the locale is set to Arabic it doesn't turn 'everything' into RTL. If we don't change the resource files for the RTL languages, that same logic will give us LTR Wine applications or am I wrong here? -- Cheers, Paul.

4 16

Wine without X? Failing in dlls/winex11.drv
by Gerald Pfeifer Sept. 19, 2010

Sept. 19, 2010

Trying to build Wine on a new tester which initially had too few packages installed I ran into the following. In file included from bitblt.c:33: x11drv.h:30:22: error: X11/Xlib.h: No such file or directory x11drv.h:31:27: error: X11/Xresource.h: No such file or directory x11drv.h:32:23: error: X11/Xutil.h: No such file or directory x11drv.h:33:23: error: X11/Xatom.h: No such file or directory x11drv.h:44:21: error: X11/Xmd.h: No such file or directory x11drv.h:45:24: error: X11/Xproto.h: No such file or directory Indeed include/config.h has HAVE_X11_XLIB_H undefined since, well, all these headers indeed are missing. On the other hand, configure did not halt. In fact, configure did not even warn about this situation unlike it does in other cases. How to fix this? Should dlls/winex11.drv just not be built in such a case? Should configure error out? (We do have --without-x, too, though.) Anything else? Currently we do pass configure and then run into a compile failure later on. Gerald

3 3

Re: user32: warnings (around uninitialized variables).
by Alexandre Julliard Sept. 19, 2010

Sept. 19, 2010

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > @@ -388,6 +388,8 @@ static int DIB_GetBitmapInfo( const BITMAPINFOHEADER *header, LONG *width, > *compr = header->biCompression; > return 1; > } > + > + *width = *height = 0; > ERR("(%d): unknown/wrong size for header\n", header->biSize ); > return -1; > } 0 is not valid for a bitmap, these should never be used in the error case. -- Alexandre Julliard julliard(a)winehq.org

2 1

autoconf 2.62 failure due to AS_VAR_IF
by Gerald Pfeifer Sept. 19, 2010

Sept. 19, 2010

Using autoconf 2.62 on my primary test system I am getting: configure:26081: error: possibly undefined macro: AS_VAR_IF Indeed use of AS_VAR_IF appears relatively new, and it seems this may be similar to AS_VAR_APPEND where we have the following in configure.ac: dnl autoconf versions before 2.63b don't have AS_VAR_APPEND m4_ifdef([AS_VAR_APPEND],,[as_fn_append () { eval $[1]=\$$[1]\$[2]; } AC_DEFUN([AS_VAR_APPEND],[as_fn_append $1 $2])])dnl I assume we need something similar here, too? I am really far from an autoconf hacker -- is this something one of you could look into? Gerald

1 1

Re: Remove code which has been #if 0-ed for 11 years from DOSCONF_Device and DOSCONF_Install. (RESEND)
by Alexandre Julliard Sept. 19, 2010

Sept. 19, 2010

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > An alternate patch would be putting #if 0 around the first occurrence > of loadhigh, too, but this code has been marked dead for more than 11 > years, so I really think it can / should go? It doesn't make sense to parse and not do anything with it. If you want to remove dead code you can remove essentially the entire file. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Use GCC's -Wlogical-op if possible
by Austin English Sept. 19, 2010

Sept. 19, 2010

On Thu, Jun 18, 2009 at 12:32 PM, Gerald Pfeifer<gerald(a)pfeifer.com> wrote: > I verified this does not cause any extra warnings with GCC 4.4, whereas > GCC 4.5 will become quite a bit more useful in that regard and thus help > spot any issues. > > As with -Wtype-limits that I suggested last year, I pledge to keep close > an eye on this and to address any issues proactively as part of my nightly > test builds. > > Gerald > > ChangeLog: > Use GCC's -Wlogical-op if possible. > > diff --git a/configure.ac b/configure.ac > index bef311e..3f7a657 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1385,8 +1385,9 @@ then > WINE_TRY_CFLAGS([-fno-builtin],[AC_SUBST(BUILTINFLAG,"-fno-builtin")]) > WINE_TRY_CFLAGS([-fno-strict-aliasing]) > WINE_TRY_CFLAGS([-Wdeclaration-after-statement]) > - WINE_TRY_CFLAGS([-Wwrite-strings]) > + WINE_TRY_CFLAGS([-Wlogical-op]) > WINE_TRY_CFLAGS([-Wtype-limits]) > + WINE_TRY_CFLAGS([-Wwrite-strings]) > > dnl Check for noisy string.h > saved_CFLAGS="$CFLAGS" > > > Causes 106 more warnings on 4.3.3 of this sort: tab.c:693: warning: logical ‘&&’ with non-zero constant will always evaluate as true cert.c:1627: warning: logical ‘||’ with non-zero constant will always evaluate as true -- -Austin

8 18

re: [PATCH 2/7] d3dx9_36/tests: Added HLSL test suite
by Dan Kegel Sept. 13, 2010

Sept. 13, 2010

Henri wrote: > You still have basic formatting errors like trailing spaces, mixing > tabs and spaces, inconsistent "*" placement, etc. > ... unnecessary cast... > wine-patches reviews are supposed to catch non-trivial interactions with > other parts of the code, not trivial whitespace errors. Looking at http://wiki.winehq.org/SubmittingPatches, I didn't see a nice, concise checklist of things to check for, so I added one at the top, and linked to Henri's post. Improvements welcome. - Dan

3 2

Wine Gecko 1.1.0 RC1
by Jacek Caban Sept. 4, 2010

Sept. 4, 2010

HI all, (If you're not interested in details, please read the last paragraph). It's been over year since the last Gecko update. A lot has happen since then. I've been planning to update our build a bit later, with Firefox 4 codebase, but plans have changed. We had some serious problems with previous build (like bug 22157 and bug 24059, both should be fixed in the new build). Also there is *a lot* happening in Mozilla world. With upcoming Firefox 4, the backward compatibility is no longer supported and the code is changing with an impressive speed. I try to follow these changes, but I need a good solid base so that I can take care of our needs in Mozilla. This build is based on Firefox 4 beta 4 (that is expected to be released this week). It goes with massive improvements, but it's less interesting here. We finally have sane building procedure. Thanks to mingw-w64 project, we no longer have to maintain our own fixes to headers and libraries. Also I've fixed a bug so that moztools is no longer needed for crosscompiling. It means that we no longer need any binary files, which should make open source fanatics (in a good sense) happy. Well... almost. We still need to create .cab file, which I do via Filzip on Windows. That's something we can work around. We use .cab files, because that's the only archive format that Wine can deal with. We can teach Wine to use other formats, which would finally make it possible for Wine packagers to do their own builds, if they like. The new Gecko is also the first to support Win64. Not all tests pass yet, but failing ones are due to missing DispCallFunc implementation for Win64, so it's not a Gecko problem. It's not yet fully tested and I need help with this. I'd appreciate any help with testing. Almost all changes required by the new Gecko were possible to be committed to current Wine. The attached patch contains remaining bits. All you need to test it is current Wine Git (must be today's or later), the attached patch and a new Gecko build. You can find new builds [1] and win64 build [2]. Put .cab files according to generic instructions [3] (obviously with different file names due to different Gecko versions). Please let me know of any regressions. Thanks, Jacek [1] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86.cab [2] http://gerwazy.lo3.wroc.pl/~jcaban/wine_gecko-1.1.0-rc1-x86_64.cab [3] http://wiki.winehq.org/Gecko

4 7

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 3, 2010

Sept. 3, 2010

Octavian, >I just looked in mmddk.h and they have this: >#define MCI_INTEGER64 13 It's good you found out about MCI_INTEGER64. Yet it's completely crazy because googling it yields 6 hits in total, all about Wine bug 22146. Bing shows nothing at all. How can such a name be that invisible? >So, do you want to fix your patches and send them, or do you want me >to continue working on this patch set? I'm fine if you do (as I've plenty of other patches in my queue) especially if you also fix the parser to handle MCI_HWND (another DWORD_PTR), which is the second half needed for 64bit as I mention in http://bugs.winehq.org/show_bug.cgi?id=22146#c12 GetDWORD also needs some change to be able to parse DWORD_PTR things, e.g. window handles. I've not yet written a single test for that (no mciavi tests). I'll send you all the MCI tests I have written ASAP. Even without written tests, one can use WINEDEBUG=+mci and analyse the parser logs for individual commands sent e.g. via the interactive MCI shell you'll find in http://bugs.winehq.org/show_bug.cgi?id=20232#c10 You obviously own a 64bit system so it's easier for you to test. I don't and had to beg. Regards, Jörg Höhle

2 3

Re: shell32/tests: Test that a folder can be named when clicking "Make New Folder"
by Frank Richter Sept. 3, 2010

Sept. 3, 2010

On 10.08.2010 20:22, Michael Mc Donnell wrote: > When a user clicks the "Make New Folder" button a new folder is created. > The name of the folder is selected, and the dialog box waits for the user > to either accept the name or type in a new one. The test types in a > new folder name and checks that the new folder gets that name. Also, you seem to emit “Alt+M” as part of the test. This is rather fragile, as the hotkey for “Make new folder” is most likely _not_ M on Windows or Wine translated to other than English. I believe the safe way to deal with that is to send a WM_COMMAND message with the ID of the “Make new folder” button. Wine test bot has a number of non-English VMs, so make sure you try your patches there. -f.r.

2 1

banning spammer from the forum
by Rosanne DiMesio Sept. 3, 2010

Sept. 3, 2010

Can someone with forum admin rights please ban user Eden1023? I've had to delete multiple spam posts by this user every day for the past few days. -- Rosanne DiMesio <dimesio(a)earthlink.net>

4 5

re: RFC: test of 16 bit wine (DOS)
by Dan Kegel Sept. 2, 2010

Sept. 2, 2010

Morten Rønne wrote: > I have been working on creating tests for the 16 bit implementation of wine Great! Have you seen http://code.google.com/p/win16test/ ? That's for Win16 binaries, not DOS, but it might have some similarities. For instance, it also uses openwatcom. I had trouble back then getting the Linux version of openwatcom to produce win16 binaries, so I used 'winetricks openwatcom' to install the windows version. - Dan

2 5

Please report mcicda (CDROM audio) test results
by Joerg-Cyril.Hoehle＠t-systems.com Sept. 2, 2010

Sept. 2, 2010

Hi, Wine's testbt job #4280 http://testbot.winehq.org/JobDetails.pl?Key=4280 contains both a patch and a binary for new MCICDA=MCI CD-audio tests. It already contains most of what I want in the initial release but would benefit from testing on a broad range of native MS systems. Please invoke it as: mcicda_test.exe mcicda (it generates many failures on Wine but I already wrote several patches to fix them.) Some failures are still possible as there are a few rough edges, e.g. mcicda.c:222: Test failed: info upc: 0=NOERROR mcicda.c:322: Test failed: PLAY data to 00291d10: MCIERR_OUTOFRANGE mcicda: 98 tests executed (0 marked as todo, 2 failures), 0 skipped. It skips tests if - there's no disk in drive; - there are no audio tracks; Untested: blank RW disk Questions: - Is this patch right in mcicda/tests/ or should it be part of winmm/tests/? - Which kind of tests should I restrict to WINETEST_INTERACTIVE mode only? People may start to complain in the near future that running the Wine testsuite starts spinning their CD-ROM and even play music. (like somebody observed that the MIDI testsuite plays a few notes). Thank you for your contributions, Jörg Höhle

5 12

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)
by GOUJON Alexandre Sept. 1, 2010

Sept. 1, 2010

On 08/28/2010 02:12 PM, Alexandre Goujon wrote: > I know that libs/wine/c_1361.c is generated ("DO NOT EDIT!!"). > However (union cptable)cptable_1361.dbcs->lead_bytes needs to be modified according tests > [...] > diff --git a/libs/wine/c_1361.c b/libs/wine/c_1361.c > index b424cb1..50d2c47 100644 > --- a/libs/wine/c_1361.c > +++ b/libs/wine/c_1361.c > @@ -8902,6 +8902,6 @@ const struct dbcs_table cptable_1361 = > uni2cp_low, > uni2cp_high, > { > - 0x84, 0xd3, 0xd9, 0xde, 0xe0, 0xf9, 0x00, 0x00 > + 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9, 0x00, 0x00 > } > }; > May I ask some guidance to make this [1] patch accepted ? Tests prove that the values above needs to be modified. Actually, I don't know if "uni2cp_high" is generated from the Internet or cpmap.pl (maybe both) Anyway, I don't understand perl. May http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT be wrong ? Or may Windows doesn't fully comply with unicode ? Thanks --- [1] : http://source.winehq.org/patches/data/65550

4 8

Chinese translation of key pages on wiki.winehq.org?
by Dan Kegel Sept. 1, 2010

Sept. 1, 2010

Are there any Chinese speakers on the list? Any interest in starting a Chinese translation of wiki.winehq.org? I bring this up because a Chinese user/developer is asking for help getting started with submitting translations to Wine. I think he would find Chinese versions of http://wiki.winehq.org/SubmittingPatches and perhaps even http://wiki.winehq.org/Translating helpful. It seems strange for a translator to need help reading English documents, but perhaps it would help them come up the curve faster. - Dan

3 3

Wine 1.4 plans?
by Dan Kegel Sept. 1, 2010

Sept. 1, 2010

I suppose we'll hear what the goals for 1.4 are at Wineconf, but here's my little wish list: Bug 6971, the mouse problem affecting many FPS-style games (Alexandre thinks it would take a month of his time?) Solving Wine's problems with Pulseaudio (bug #10495) Mono integration similar to the current Gecko integration (go Vincent!) Finishing d3dx9_36 and friends (i.e. getting rid of the need to run winetricks to load bits of Direct3D9) Excellent continuous build and test services at winehq.org, including performance tests (ok, this isn't really a wine feature) Move away from using 2D graphics acceleration, as Windows has done (this is both a superset and a subset of the DIBEngine idea) (heard this from Roderick)

4 3

Re: d3dx9: Implement D3DXFVFFromDeclarator.
by Henri Verbeet Aug. 31, 2010

Aug. 31, 2010

On 30 August 2010 23:07, Misha Koshelev <misha680(a)gmail.com> wrote: > Looking forward to (constructive) comments. > Why are colors and normals special? What use is hasPosition? What happens when the source declaration has e.g. two color elements with usage index 0, or two position elements? Note that the booleans are redundant, you store that information in the FVF.

3 6

Re: kernel32/tests: Fix compilation on systems that don't support nameless unions or structs.
by testbot＠testbot.winehq.org Aug. 31, 2010

Aug. 31, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4872 Your paranoid android. === W98SE (32 bit process) === Failure running script in VM: Exceeded timeout limit of 315 sec

2 1

Re: [2/3] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx
by Henri Verbeet Aug. 31, 2010

Aug. 31, 2010

On 26 July 2010 23:05, Owen Rudge <owen(a)owenrudge.net> wrote: > + if ((filter & 0xFFFF) > D3DX_FILTER_BOX && filter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if ((mipfilter & 0xFFFF) > D3DX_FILTER_BOX && mipfilter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if (!filter || !mipfilter) > + return D3DERR_INVALIDCALL; I think those should be handled implicitly by D3DXLoadSurfaceFromFileInMemory() / D3DXFilterTexture(). > + if (filter == D3DX_DEFAULT) > + filter = D3DX_FILTER_TRIANGLE | D3DX_FILTER_DITHER; > + > + if (mipfilter == D3DX_DEFAULT) > + mipfilter = D3DX_FILTER_BOX; Same. > + if (width == 0 || width == D3DX_DEFAULT_NONPOW2) > + width = imginfo.Width; Probably depends on the device supporting NPOT textures again. > + if ((pool != D3DPOOL_DEFAULT) && (usage != D3DUSAGE_DYNAMIC)) Dynamic textures are a device capability. (Yeah, this is a mostly unchanged copy of my earlier comments.)

2 1

Re: [PATCH 4/4] ws2_32: implement AcceptEx and GetAcceptExSockaddrs
by Alexandre Julliard Aug. 31, 2010

Aug. 31, 2010

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > /*********************************************************************** > + * WS2_async_recv_accept (INTERNAL) > + * > + * This function is used to finish the read part of an accept request. It is > + * needed to place the completion on the correct socket (listener). > + */ > +static NTSTATUS WINAPI WS2_async_recv_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS status ) > +{ > + void *junk; > + struct ws2_accept_async *wsa = arg; > + > + status = WS2_async_recv( wsa->read, iosb, status, &junk ); > + if (status == STATUS_PENDING) > + return status; > + > + if (wsa->user_overlapped->hEvent) > + SetEvent(wsa->user_overlapped->hEvent); > + if (wsa->cvalue) > + WS_AddCompletion( HANDLE2SOCKET(wsa->listen_socket), wsa->cvalue, iosb->u.Status, iosb->Information ); > + HeapFree( GetProcessHeap(), 0, wsa->read ); > + HeapFree( GetProcessHeap(), 0, wsa ); > + > + return status; > +} > + > +/*********************************************************************** > + * WS2_async_accept (INTERNAL) > + * > + * This is the function called to satisfy the AcceptEx callback > + */ > +static NTSTATUS WINAPI WS2_async_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS status ) > +{ These are not valid async callbacks, the way async callbacks work has changed since the patch was first written. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use
by Henri Verbeet Aug. 31, 2010

Aug. 31, 2010

On 30 August 2010 18:37, Mikko Rasa <tdb(a)tdb.fi> wrote: > + ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session)); ... > - stream_sizes->cbHeader = 5; > - stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */ > + stream_sizes->cbHeader = ctx->header_bytes; > + stream_sizes->cbTrailer = ctx->trailer_bytes; Does this imply TLS record padding should be disabled? I imagine an encrypted message may not fit in the application provided buffers otherwise.

2 1

Re: [PATCH] Only process full TLS frames in schan_DecryptMessage
by Hans Leidekker Aug. 31, 2010

Aug. 31, 2010

On Mon, 2010-08-30 at 23:57 +0300, Mikko Rasa wrote: > + SIZE_T expected_size; > ssize_t received = 0; > ssize_t ret; > int idx; > - char *buf_ptr; > + unsigned char *buf_ptr; > unsigned int offset; > > TRACE("context_handle %p, message %p, message_seq_no %d, quality %p\n", > @@ -1230,12 +1243,22 @@ static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle > if (idx == -1) > return SEC_E_INVALID_TOKEN; > buffer = &message->pBuffers[idx]; > + buf_ptr = (unsigned char *)buffer->pvBuffer; > + > + expected_size = 5 + ((buf_ptr[3] << 8) | buf_ptr[4]); > + if(buffer->cbBuffer < expected_size) > + { > + TRACE("Expected %u bytes, but buffer only contains %u bytes\n", expected_size, buffer->cbBuffer); > + TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); > + return SEC_E_INCOMPLETE_MESSAGE; > + } This produces a compiler warning here: schannel.c: In function ‘schan_DecryptMessage’: schannel.c:1251: warning: format ‘%u’ expects type ‘unsigned int’, but argument 5 has type ‘SIZE_T’

1 0

Re: [PATCH 3/3] Fill buffers in schan_DecryptMessage the same way as windows does
by Hans Leidekker Aug. 31, 2010

Aug. 31, 2010

On Mon, 2010-08-30 at 19:37 +0300, Mikko Rasa wrote: > - memcpy(buffer->pvBuffer, data, received); > - buffer->cbBuffer = received; > + buf_ptr = (char *)buffer->pvBuffer; You don't need this cast. > + offset = ctx->header_bytes; > + memcpy(buf_ptr + offset, data, received); > HeapFree(GetProcessHeap(), 0, data); > > + schan_decrypt_fill_buffer(message, SECBUFFER_DATA, buf_ptr + offset, received); > + offset += received; > + > + schan_decrypt_fill_buffer(message, SECBUFFER_STREAM_TRAILER, buf_ptr + offset, buffer->cbBuffer - offset); > + offset += ctx->trailer_bytes; > + > + if(buffer->cbBuffer > offset) > + schan_decrypt_fill_buffer(message, SECBUFFER_EXTRA, buf_ptr + offset, buffer->cbBuffer - offset); > + > + buffer->BufferType = SECBUFFER_STREAM_HEADER; > + buffer->cbBuffer = ctx->header_bytes; > + FWIW, this patch set passes my tests.

1 0

Re: widl: Added default __midl, _WIN32 and _WIN64 defines.
by Alexandre Julliard Aug. 31, 2010

Aug. 31, 2010

Jacek Caban <jacek(a)codeweavers.com> writes: > They are defined by default by midl. __midl is supposed to be set to the midl compiler version, and I'm not entirely convinced it's appropriate for us to define it. Also, _WIN64 can't depend on how widl was built, since it can generate both 32-bit and 64-bit code. You'd have to parse everything twice if you wanted to make use of this. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.
by Francois Gouget Aug. 31, 2010

Aug. 31, 2010

http://source.winehq.org/patches/data/65442 According to http://source.winehq.org/patches/ this patch causes a build error (or maybe a new warning). However here (gcc 4.4) I see no warning at all. Does this patch cause warnings / errors for anyone? (it would be nice if the patches website could include the build error log<g>). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

3 3

Re: wined3d: separate driver info from GPU info (try3)
by Henri Verbeet Aug. 31, 2010

Aug. 31, 2010

On 31 August 2010 00:46, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > In the previous version of this patch, no version info was returned > for Windows versions which were not in the table. I verified on > Vista/Win7 what version numbers, gpu names and driver strings are > returned to applications running in 9x/2k/xp compatibility mode. It > appears that by default (perhaps the shim database can override it?) > these applications receive information about the current drivers > instead of fake information. For now I'm returning XP driver info if > no match was found. > > Future patches will add the 9x/Vista/Win7 info. When we reach that > stage and a user uses a Geforce 8800 and winver=win98, it will behave > the same as Windows (I assume XP is the default version number). > No. This will simply break currently working functionality. Regardless, I think it's a design flaw anyway to require separate entries for different Windows versions even though they're using the same driver model.

1 0

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized
by Octavian Voicu Aug. 31, 2010

Aug. 31, 2010

Try running: git config --global color.ui auto This will activate colorful output for all git commands (in particular for `git diff' too). Then, when you run `git diff' from a terminal you will see whitespace errors (eg. trailing whitespace) highlighted with a red background. Hope it helps, Octavian

6 8

Re: [1/3] mscoree: Store the AppDomain from CorExeMain, for use in other functions.
by Juan Lang Aug. 30, 2010

Aug. 30, 2010

Hi Vincent, + EnterCriticalSection(&mono_lib_cs); + if (!mono_handle) + { + ERR("CorExitProcess called on another thread?\n"); + return -1; you don't release mono_lib_cs here. Similarly, in patch 3, STDAPI ClrCreateManagedInstance(LPCWSTR pTypeName, REFIID riid, void **ppObject) (snip) + EnterCriticalSection(&mono_lib_cs); + if (!mono_handle) + { + ERR("CorExitProcess called on another thread?\n"); + return E_FAIL; you don't release mono_lib_cs here, and the error message looks suspicious. --Juan

2 2

DIB clarification
by Jeff Cook Aug. 30, 2010

Aug. 30, 2010

I hate to stir the pot, especially as an unknown in the community, but I've spent the last few hours reading WINE's history regarding DIB engines and it is pretty distressing. I have seen expressions of frustration from many regarding the handling of the mostly-functional DIB engine that Massimo wrote. AJ's terseness on the issue is puzzling. I find it really weird that such a major and long-standing thing would just be left to languish without any detailed reasons. Though I do not believe it, you can start to see why the slashdotter described Codeweavers' corporate agenda as "evil"; it almost feels like Codeweavers is holding DIB hostage, just waiting for someone to get fed up and fork over the cash for it. This wouldn't be a problem of course if it appeared that Alexandre was willing to work with external developers on the DIB engine, but he has given very sparse criticism. Should we all just accept that Massimo's engine is yet another DIB engine gone to waste and there is no future hope for it at all? Max's statements to that effect can be confusing out of context because of his non-native English, but everything I have seen indicates that he is totally willing to work on upstream merging if Alexandre is willing to cooperate. All cases of saying "it won't get merged" etc. by Max seem to reference AJ's reluctance to provide useful criticism on the code that gets posted. It is not my intention to start another huge flamewar or thread on the matter. I just want to promote a reliable roadmap and help resolve this -- it seems like a total shame that there have been multiple DIB engines written and no parts of any of them were deemed worthy of inclusion in WINE. Max at least has indicated a desire to modify the code as necessary if a useful road map or ideation were provided, so why is it so hard to get the road map? Alexandre is right that the architecture is a lot of work, but I am not asking for him to write out a complete spec, and I don't think the community is, either; the main thing, as far as I can tell, is that the interaction and feedback on a major step forward for WINE has been minimal. People are still reporting major speedups on bug #421 so I don't think this is a lost cause unworthy of effort as some suggest. The most feedback I was able to find from Alexandre was on May 2009's DIB engine passing all tests thread at http://www.winehq.org/pipermail/wine-devel/2009-May/thread.html#75864 . Alexandre's single major standing complaints seem to be a lack of test cases and Massimo not establishing a good record with simple patches. Are those still valid reasons? The complaint regarding driver loading was addressed, but it sounds like Alexandre wants it in the opposite direction (forwarding calls from winex11.drv (or whatever driver) to winedib.drv instead of the other way around). Is that a very serious problem? So, if we can, let's get a few points down on what needs to be modified for DIB to make it into WINE, even as an experimental branch: 1) Write more gdi32 and any other relevant test cases to prove that the DIB engine is generally well-behaved 2) Reverse the DIB ordering and call winedib.drv only as needed, instead of passing everything through winedib.drv first. 3) ? Or, in the case that Max's DIB is gone forever and is considered irreparable, why don't we discuss what's needed for a different DIB engine? 1) Write more gdi32 and any other relevant test cases to prove that the DIB engine is generally well-behaved 2) Works well with any wine display driver. (already in Max's code) 3) Applied and developed cooperatively and incrementally with the WINE community 4) Easily disabled / non-disruptive (already in Max's code) 5) ? What else needs to go here? Is this accurate? Others mentioned that benchmarks that prove the usefulness of a DIB engine might help. Do those still need to be performed? Thanks for reading. From Jeff

10 10

Re: user32: Make GetWindowPlacement() work for other process windows. Take 2.
by Alexandre Julliard Aug. 30, 2010

Aug. 30, 2010

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > This patch fixes the problem reported in the bug 12001. > > This version of the patch uses an internal message to fetch window state > from a foreign thread. Another aproach could be to store the window state in > the server, but that would require to introduce another server call for it. I'd be surprised if GetWindowPlacement required the other thread to be running a message loop on Windows... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 04/12] [Server]: enhanced the console input object so that it doesn't require a wineconsole to be running
by Alexandre Julliard Aug. 30, 2010

Aug. 30, 2010

Eric Pouech <eric.pouech(a)orange.fr> writes: > + if (tcgetattr(fd, &term) < 0) fprintf(stderr, "Couldn't get termios\n"); > + console_input->termios = term; > + term.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN); > + term.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON); Errors need to be handled properly in the server, you can't just print a message and continue as if nothing happened. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: DIB clarification
by James Mckenzie Aug. 30, 2010

Aug. 30, 2010

Michael Stefaniuc <mstefani(a)redhat.com> wrote: > >Now that "that waive with $$$" isn't very likely as the cost/benefit >ratio isn't very good. More likely is that Codeweavers will start >working on a Quartz driver and that work will make the DIB engine >"cheaper" to implement. Again, this is my *personal* opinion. > I would like to add my *personal* comment to the above. Both the DIB engine and implementing Auqa/Quartz on Wine are HUGE projects that will take a lot of time. Huw Davis (sp?) and Max put a lot of time into the DIB project and according to Tom Wickline, Max is still working on it (see Tom's message on in this thread for more information.) Emmanual Mallard and others put in a lot of time on the Aqua/Quartz implementation without a full implementation and Emmanual (to my knowledge) stopped working on it almost two years ago. These both *appear* to be interlinked as the DIB engine has to be implemented before full functionality is available for Aqua/Quartz will work (these are not my words and this was posted here in the Wine Development List.) My words of caution were misread by others here. I was going to work on the Quartz project based upon work that I had participated in another FOSS project, but after looking it over very carefully, I decided to set it aside and work on other much smaller, bigger bang for the time, projects. One I have been working on for two years and that work had to be abandoned as the implementation was not correct (thank you AJ for pointing this out in very blunt words.) What to do about these two 'features' missing? Maybe CodeWeavers will pick them up (they may already have.) Maybe someone or a team will take them over. I will move onto fixing bugs and missing features that are 'important' to me and leave the rest to others who have more time and ambition. Thank everyone here for your words of encouragement and I will continue to work on the three functions I would like to see implemented that will make some of the 'fixmes' go away. James McKenzie

1 0

Re: [PATCH] winedbg: gdb proxy mode: support qAttached packet
by Eric Pouech Aug. 30, 2010

Aug. 30, 2010

Paul Bolle a écrit : > Add support for the qAttached packet. Main benefit is that if gdb was > attached to a debuggee and it quits it will now ask if it should detach > from the debuggee instead of asking whether the debuggee should be > killed. (It still will ask whether the debuggee should be killed if it > launched the debuggee itself). > > Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> > --- > Would it be better to add a new member to gdbctx instead of using a > separate variable (qAttached_reply)? > yes, inclusion in gdbctx is preferred (and storage should rather be an integer rather than a string pointer) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 1

Re: msvcrt:locale Properly fix setlocale and clean up tests
by Alexandre Julliard Aug. 30, 2010

Aug. 30, 2010

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > I removed all broken() and ran the tests on all WineTestBot machines > (https://testbot.winehq.org/JobDetails.pl?Key=4829) > Then, I cleaned up tests accordingly : removed superflous broken() and extending ok(). > (https://testbot.winehq.org/JobDetails.pl?Key=4831) Now you are overdoing it. I said to remove broken() for minor spelling differences, not for everything. For instance confusing 936 and 950 codepages for Chinese is broken, it's not just a spelling difference. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 4/6] winealsa.drv: Append hw address to handle to prevent name collision. (resend)
by Vitaliy Margolen Aug. 30, 2010

Aug. 30, 2010

On 08/02/2010 05:49 PM, Jeff Cook wrote: > --- > dlls/winealsa.drv/waveinit.c | 9 +++++++-- > 1 files changed, 7 insertions(+), 2 deletions(-) > + sprintf(description, "%s %d:%d", snd_pcm_info_get_name(infop), snd_pcm_info_get_card(infop), Please use snprintf to prevent possible buffer overflow. > + memcpy(ww->ds_desc.szDesc, description, > + min( (sizeof(ww->ds_desc.szDesc) - 1), strlen(description)) ); This does not guarantee that ww->ds_desc.szDesc will be \0 terminated. Vitaliy.

2 2

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized
by James McKenzie Aug. 29, 2010

Aug. 29, 2010

David Adam wrote: Looks like you are trying very hard to avoid the [try 4] moniker. Please add this to each version of the patch you are submitting. Use the notes feature of git commit to put in why you are submitting a new try. Second, if the patch will NOT apply due to whitespace issues, it will NOT be approved. Please read the Wiki page on Patches. Third, it really appears that you are avoiding the friendly advise given here. We are trying to help you prevent resubmit and then another resubmit for the same problem. You have already aggravated one reviewer that has attempted to help you get this patch accepted. James McKenzie

1 0

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized
by Henri Verbeet Aug. 29, 2010

Aug. 29, 2010

On 29 August 2010 20:45, David Adam <david.adam.cnrs(a)gmail.com> wrote: > - You clearly ignored my previous comments about trailing spaces. - This patch changes a lot more things than just allowing DDSCL_NORMAL | DDSCL_FULLSCREEN. E.g. the call to IWineD3DDevice_AcquireFocusWindow(). - Still needs more tests. For example, is the whole wndproc replacement stuff a property of DDSCL_EXCLUSIVE or a property of DDSCL_FULLSCREEN? - I'm not going to look at or comment on any patch with basic whitespace issues anymore.

1 0

Re: ddraw [patch 2/2]: Add more combinaison tests for SetCooperativeLevels
by testbot＠testbot.winehq.org Aug. 29, 2010

Aug. 29, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4844 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)
by testbot＠testbot.winehq.org Aug. 29, 2010

Aug. 29, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4793 Your paranoid android. === W7PRO (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (64 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1)

3 3

HEAP and FarCry installer
by wylda＠volny.cz Aug. 29, 2010

Aug. 29, 2010

Hope i don't bother you much, but i guess you would tell me... I still have a problem with FarCry installer. During that i found HEAP issue - based on assumption, that message "Heap invalid in-use arena magic 00eefeee" is unhealthy. So program allocates 6fc bytes at 0x14c160 and free those bytes at the end of the following list, but immediately tries to free another heap at 14c188 which belongs to the freed area already, right?. Also there is no trace, that the program allocates that 14c188 memory. Is that bug or nothing unusual? Longer log attached. 0009:Call ntdll.RtlAllocateHeap(00110000,00000000,000006fc) ret=7dfef944 0009:Ret ntdll.RtlAllocateHeap() retval=0014c160 ret=7dfef944 0009:Call version.GetFileVersionInfoW(00157a88 L"C:\\Program Files\\Common Files\\InstallShield\\Driver\\9\\Intel 32\\IDriver.exe",00000000,000006fc,0014c160) ret=7dff45c1 ... 0009:Ret version.GetFileVersionInfoW() retval=00000001 ret=7dff45c1 0009:Call version.VerQueryValueW(0014c160,7e078b84 L"\\",0034beec,0034bee4) ret=7dff45e7 0009:Ret version.VerQueryValueW() retval=00000001 ret=7dff45e7 0009:Call ntdll.RtlFreeHeap(00110000,00000000,0014c160) ret=7dfefa1e 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7dfefa1e 0009:Call ntdll.RtlFreeHeap(00110000,00000000,0014c188) ret=7dfefa1e warn:heap:HEAP_ValidateInUseArena Heap 0x110000: invalid in-use arena magic 00eefeee for 0x14c180 0009:Ret ntdll.RtlFreeHeap() retval=00000000 ret=7dfefa1e

2 1

d3d9 equivalent of D3DXFVFFromDeclarator?
by Misha Koshelev Aug. 29, 2010

Aug. 29, 2010

Dear All: Thanks a lot Henri for your wonderful D3DXDeclaratorFromFVF patches. It is wonderful to be exposed to the "right" way to implement this function. I am starting to look at D3DXDeclaratorFromFVF, as this would be the next step before implementing ID3DXMesh. I am looking again at d3d9, but feel like I am running in circles a little bit trying to chase down where convFVF and convertedDecls is coming from. If you have any hints/advice, much appreciated. If there is a better place to look as well (like wined3d), please let me know. Thank you! Misha

2 3

Re: msvcrt:string Avoid size_t in ok()
by James McKenzie Aug. 29, 2010

Aug. 29, 2010

Alexandre Goujon wrote: > --- > dlls/msvcrt/tests/string.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/msvcrt/tests/string.c b/dlls/msvcrt/tests/string.c > index 94c2fa3..3c143d1 100644 > --- a/dlls/msvcrt/tests/string.c > +++ b/dlls/msvcrt/tests/string.c > @@ -1185,22 +1185,22 @@ static void test_mbstowcs(void) > mOut[4] = '!'; mOut[5] = '\0'; > > ret = mbstowcs(NULL, mSimple, 0); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "mbstowcs did not returned 4\n"); > > Alexandre: Can we avoid a typo by substituting: "Did not returned <value>\n" with "Did not return <value>\n" for each instance in the file? Thank you. James McKenzie

2 1

Re: [PATCH 5/6] winealsa.drv: Don't open the same card on every loop. (resend)
by Alexandre Julliard Aug. 29, 2010

Aug. 29, 2010

Jeff Cook <jeff(a)deserettechnology.com> writes: > @@ -753,7 +753,7 @@ static int ALSA_ScanDevices(int directhw, > char *pcmname = NULL; > snd_pcm_t *pcm; > > - sprintf(defaultpcmname, "default"); > + sprintf(defaultpcmname, "default:%d", card); We used to do that, but it was changed because it's not correct, cf. bug 10942. -- Alexandre Julliard julliard(a)winehq.org

2 1

HEAP corruption again?
by wylda＠volny.cz Aug. 29, 2010

Aug. 29, 2010

Hi, i wonder what is wine trying to tell me by "just discovered" message: warn:heap:HEAP_ValidateInUseArena Heap 0x110000: invalid in-use arena magic 00555555 for 0x118c10 Is that some kind of corruption or harmless? I found out, that ARENA_INUSE_MAGIC should be 0x455355. Then ARENA_INUSE_FILLER is 0x55, so it looks to me, that wine overwrites 455355 by several 55 and then complains ;) What is it good for to put there 455355 and then intentionally overwrite(??) that by different value? W.

1 0

Help with 6120d7cc145, causing bugs
by Jeff Cook Aug. 29, 2010

Aug. 29, 2010

Just wondering if I could get a bit more review on commit 6120d7cc145 which was committed in early August. Here's a link: http://source.winehq.org/git/wine.git/?a=commit;h=6120d7cc14522983fbc38026a… There have been a few bug reports filed against it recently, see http://bugs.winehq.org/show_bug.cgi?id=23902 and http://bugs.winehq.org/show_bug.cgi?id=24131 . It seems that in some relatively rare sound setups, an inappropriate sound element gets fed in to filllines_no_master which leads to a crash on audio initialize. To me this is weird because the program is currently written so that it flows into filllines_no_master only if there no is master control. A patch adding else if (micelem) instead of just else was recently committed and fixed at least one person's problem. Some people on the bug report are unable to provide full debug information so it makes this harder. If you have the time, please review the patch and let me know what errors you notice that may be causing the aforementioned bug. I am new to Wine dev so please forgive anything really stupid. :) Thanks From Jeff. -- Jeff Cook (801) 231-3157 jeff(a)deserettechnology.com

4 8

Re: [PATCH 1/6] winealsa.drv: Init mixer on cards with a single Mic control, like snd_usb_audio mics (try 2)
by Alexandre Julliard Aug. 29, 2010

Aug. 29, 2010

Jeff Cook <jeff(a)deserettechnology.com> writes: > @@ -245,6 +245,10 @@ static void fillcontrols(mixer *mmixer) > for (id = 0; id < mmixer->chans; ++id) > { > line *mline = &mmixer->lines[id]; > + if (!mline->elem) > + { > + break; > + } > int ofs = CONTROLSPERLINE * id; You can't do that: mixer.c: In function ‘fillcontrols’: mixer.c:252: error: ISO C90 forbids mixed declarations and code -- Alexandre Julliard julliard(a)winehq.org

5 5

Re: msvcrt:string Avoid size_t in ok()
by Jerome Leclanche Aug. 29, 2010

Aug. 29, 2010

Not to be pedantic, but "did not return" is what you meant. J. Leclanche On Sat, Aug 28, 2010 at 2:38 PM, Alexandre Goujon <ale.goujon(a)gmail.com> wrote: > --- > dlls/msvcrt/tests/string.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/msvcrt/tests/string.c b/dlls/msvcrt/tests/string.c > index 94c2fa3..3c143d1 100644 > --- a/dlls/msvcrt/tests/string.c > +++ b/dlls/msvcrt/tests/string.c > @@ -1185,22 +1185,22 @@ static void test_mbstowcs(void) > mOut[4] = '!'; mOut[5] = '\0'; > > ret = mbstowcs(NULL, mSimple, 0); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "mbstowcs did not returned 4\n"); > > ret = mbstowcs(wOut, mSimple, 4); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "mbstowcs did not returned 4\n"); > ok(!memcmp(wOut, wSimple, 4*sizeof(wchar_t)), "wOut = %s\n", wine_dbgstr_w(wOut)); > ok(wOut[4] == '!', "wOut[4] != \'!\'\n"); > > ret = wcstombs(NULL, wSimple, 0); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "wcstombs did not returned 4\n"); > > ret = wcstombs(mOut, wSimple, 6); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "wcstombs did not returned 4\n"); > ok(!memcmp(mOut, mSimple, 5*sizeof(char)), "mOut = %s\n", mOut); > > ret = wcstombs(mOut, wSimple, 2); > - ok(ret == 2, "ret = %d\n", ret); > + ok(ret == 2, "wcstombs did not returned 2\n"); > ok(!memcmp(mOut, mSimple, 5*sizeof(char)), "mOut = %s\n", mOut); > > if(!setlocale(LC_ALL, "Japanese_Japan.932")) { > @@ -1209,7 +1209,7 @@ static void test_mbstowcs(void) > } > > ret = mbstowcs(wOut, mHiragana, 6); > - ok(ret == 2, "ret = %d\n", ret); > + ok(ret == 2, "mbstowcs did not returned 2\n"); > ok(!memcmp(wOut, wHiragana, sizeof(wHiragana)), "wOut = %s\n", wine_dbgstr_w(wOut)); > > ret = wcstombs(mOut, wHiragana, 6); > -- > 1.7.0.4 > > > >

1 0

winebuild on sparc, RFC
by Austin English Aug. 28, 2010

Aug. 28, 2010

Howdy, Out of curiosity, I've been testing compiling Wine on Sparc. I've sent a few patches to fix a few problems that have crept up over the years. There are two big bugs left though: http://bugs.winehq.org/show_bug.cgi?id=24050 and http://bugs.winehq.org/show_bug.cgi?id=24142 The first blocks running wine, the second blocks building it. For the second, however, I found an old patch: http://www.mail-archive.com/wine-devel(a)winehq.org/msg23307.html and rediffed it to current wine. With it, wine mostly compiles (mshtml gets a 'Bus error' when compiling, but no gcc warning/error). I'm not sure if the patch is correct, and I've contacted Eric to ask him to submit the patch, but didn't receive a reply. If it's correct, I'll send it in, with his name on it. So, those of you who know winebuild (or better yet, Sparc), would you please check the attached patch. Thanks! -Austin

2 1

dbghelp: Remove unused functions?
by Andrew Talbot Aug. 28, 2010

Aug. 28, 2010

Hi, Static functions pe_get_sect() and pe_get_sect_size() in dbghelp/pe_module.c are not called. May I remove them or does anyone have plans for them? Thanks, Andy.

2 1

Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Octavian Voicu Aug. 27, 2010

Aug. 27, 2010

On Fri, Aug 27, 2010 at 4:25 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > 2010/8/27 Octavian Voicu octavian.voicu(a)gmail.com >> I didn't think it was necessary to test on native systems. The command >> parsing looks like internal winmm stuff, which makes no difference to >> the exported interfaces, as long as the command string is parsed into >> the corresponding MCI_ structures correctly. > > no the format of MCI string tables is public, and Wine aims at supporting > native MCI drivers (which can come with their own tables) > so binary compatibility in RC files is required We don't have this right now. Native winmm.dll uses integer resource ids (id 200 for core commands, and the MCI_DEVTYPE_ constants for the rest; can't figure what device is 524 though, last device is MCI_DEVTYPE_SEQUENCER which is 523). Wine currently uses string ids, with a table to map device ids to device name strings. Also, winmm_res.rc and others looks really bad because they use numeric constants (eg. 0x00000803L instead of MCI_OPEN, 0). >>In any case, using the MCI_XYZ_PARMS union looks much better :) Maybe >>also stick MCI_GENERIC_PARMS in there. > I don't agree here. IMO the parser should be the most agnostic possibly > against the real data structures (the MCI string table shall contain the > definition of the structures including type of data). so, using unions and > structures is going into the right direction (even if I agree that current > parser doesn't fully comply with that goal) Not sure if I understand exactly what you mean here. Bottom line is that unions & structures are the way to go, like in Joerg's patch, but maybe try to make it look prettier? Octavian PS: found this really useful pdf documenting MCI: http://mediaxw.sourceforge.net/files/tmp/Windows%20NT%20DDK%20-%20Multimedi…

1 0

Re: msvcrt:locale Properly fix setlocale()
by Alexandre Julliard Aug. 27, 2010

Aug. 27, 2010

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -431,7 +431,7 @@ static void test_setlocale(void) > ret = setlocale(LC_ALL, "non"); > ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); > if(ret) > - todo_wine ok((!strcmp( ret, "Norwegian-Nynorsk_Norway.1252")) > + ok((!strcmp( ret, "Norwegian-Nynorsk_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Bokmål)_Norway.1252")) > || broken(!strcmp(ret, "Norwegian_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Nynorsk)_Norway.1252")), "ret = %s\n", ret); > @@ -453,7 +453,7 @@ static void test_setlocale(void) > ret = setlocale(LC_ALL, "norwegian-nynorsk"); > ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); > if(ret) > - todo_wine ok(!strcmp(ret, "Norwegian-Nynorsk_Norway.1252") > + ok(!strcmp(ret, "Norwegian-Nynorsk_Norway.1252") > || broken(!strcmp(ret, "Norwegian_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Nynorsk)_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Bokmal)_Norway.1252")) I don't think it makes sense to declare minor spelling differences as broken, or to change the kernel resources for this. -- Alexandre Julliard julliard(a)winehq.org

2 2

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Octavian Voicu Aug. 27, 2010

Aug. 27, 2010

For some reason I forgot to hit reply to all. ---------- Forwarded message ---------- From: Octavian Voicu <octavian.voicu(a)gmail.com> Date: Thu, Aug 26, 2010 at 2:15 PM Subject: Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit. To: Joerg-Cyril.Hoehle(a)t-systems.com On Thu, Aug 26, 2010 at 1:11 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > are you aware of bug http://bugs.winehq.org/show_bug.cgi?id=22146 > and the partial patch and additional test cases there? First of all, I wasn't aware of it, so thanks for pointing it out. I just saw the crash on my system and tried to fix it; to my shame, I didn't search wine bug database. Sorry for the duplicate work. >>winmm: Add MCI_INTEGER_PTR return type for DWORD_PTR return values. >>+#define MCI_INTEGER_PTR 13 > What kind of testing did you perform on native systems to derive the existence of this value? > If such value does not exist, then I fear your patch set looses the ability to > drop in native dlls for compatibility testing and validation. > If it exists, then it's good news you found it. The only testing I ran is winmm:mci tests. With my patch set, 27 tests fail on 64 bit (compared to 23 on 32bit). I'm guessing the 4 extra failures are in other parts of the code. Not sure about TODOs, as I had no tests marked as TODO when I ran the tests from command line (the 23 tests that also fail on 32-bit are definitely marked as TODOs on test.winehq.org) I didn't think it was necessary to test on native systems. The command parsing looks like internal winmm stuff, which makes no difference to the exported interfaces, as long as the command string is parsed into the corresponding MCI_ structures correctly. MCI_GetDWord, MCI_GetString, MCI_ParseOptArgs, MCI_HandleReturnValues, the functions which I modified, are explicitly listed as internal functions. I just looked in mmddk.h and they have this: #ifdef _WIN64 #define MCI_INTEGER64 13 #endif // _WIN64 Which is really funny, because I wrote that patch without knowing anything about that. Gonna take a look at resources inside a 64-bit winmm.dll and report back, but it is pretty obvious what I'll find -- they wouldn't define MCI_INTEGER64 for nothing. >>-static DWORD MCI_ParseOptArgs(DWORD_PTR* data, int _offset, LPCWSTR lpCmd, >>+static DWORD MCI_ParseOptArgs(BYTE* data, int _offset, LPCWSTR lpCmd, >>- if (!MCI_GetDWord(&(data[offset+0]), &args) || >>- !MCI_GetDWord(&(data[offset+1]), &args) || >>- !MCI_GetDWord(&(data[offset+2]), &args) || >>- !MCI_GetDWord(&(data[offset+3]), &args)) { >>+ if (!MCI_GetDWord(data+offset+0*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+1*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+2*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+3*sizeof(DWORD), &args)) { > > The MCI_XYZ_PARMS structures are neither DWORD_PTR, not BYTE*, > they are DWORD with some DWORD_PTR in between. > Wouldn't using DWORD* data help avoid such pointer arithmetic > and eliminate several hunks of the patch ? The reason for which I opted for a BYTE* is so that I can use sizeof() to increment the pointer correctly. DWORD_PTR has a different size of 32- and 64-bit systems, so using DWORD* would make it more complicated to increment with sizeof(DWORD_PTR). Another reason is that offset is now in bytes, so supplying a pointer of different size wouldn't make much sense. Argument type in MCI_GetDWord and MCI_GetString was changed for consistency, it wouldn't matter very much there. For the same reason I changed all the &data[offset] into data+offset. In any case, using the MCI_XYZ_PARMS union looks much better :) Maybe also stick MCI_GENERIC_PARMS in there.

2 1

Try 4: SetCooperative Levels with Normal+Fullscreen+Exclusive is authorized
by paulo lesgaz Aug. 27, 2010

Aug. 27, 2010

Hello, I modified my patch to follow Henri's and Stefan's requests and hints. Do you have more observations to do with this one? As previously, all the tests go on passing. A+ David

2 1

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Octavian Voicu Aug. 27, 2010

Aug. 27, 2010

Same here. ---------- Forwarded message ---------- From: Octavian Voicu <octavian.voicu(a)gmail.com> Date: Thu, Aug 26, 2010 at 3:12 PM Subject: Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit. To: Joerg-Cyril.Hoehle(a)t-systems.com On Thu, Aug 26, 2010 at 2:15 PM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > I just looked in mmddk.h and they have this: > > #ifdef _WIN64 > #define MCI_INTEGER64 13 > #endif // _WIN64 > > Which is really funny, because I wrote that patch without knowing > anything about that. Gonna take a look at resources inside a 64-bit > winmm.dll and report back, but it is pretty obvious what I'll find -- > they wouldn't define MCI_INTEGER64 for nothing. I can confirm it, the 64-bit dll uses MCI_INTEGER64 (0x0000000D), while the 32-bit one uses MCI_INTEGER. Maybe we should also have #ifdefs in mmddk.h and winmm_res.rc. So, do you want to fix your patches and send them, or do you want me to continue working on this patch set? You should also send the mciParser test (btw, I tested my patch set with your extra tests and they all pass). Octavian

1 0

Any idea how to solve that ?
by GOUJON Alexandre Aug. 27, 2010

Aug. 27, 2010

Hi, No one have replied for my ["Spanish - Modern Sort_Spain.1252" locale on wine] mail. So I'm asking again if someone has an idea. If solved, msvcrt:locale test on wine will pass without any error. The situation is the following : setlocale(LC_ALL, "esn"); > ok(!strcmp(ret, "Spanish_Spain.1252") setlocale(LC_ALL, "spanish-modern"); > ok(!strcmp(ret, "Spanish - Modern Sort_Spain.1252") with static const char * const _country_synonyms[] = { ... "spanish-modern", "esn" } -> this has to be changed since above tests prove they're not the same I submitted a job for the WineTestBot for finding what esX '=' Spanish - Modern Sort_Spain.1252 And the result is : none. So, should I create another esX ? What template for this new one ? Another idea ? Each todo_wine we remove may resolve (or prevent) bugs.

1 1

Re: [1/5] msi/tests: Use a different product code in the package tests to avoid cascading test failures.
by testbot＠testbot.winehq.org Aug. 27, 2010

Aug. 27, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4818 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8385: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8396: Test failed: Expected "C:\winetest\", got "" package.c:8407: Test failed: Expected "C:\winetest\", got "" package.c:8457: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8468: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8477: Test failed: Expected "C:\", got "" package.c:8483: Test failed: Expected "C:\winetest\", got "" package.c:8504: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8513: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: kernel32: add error text for WSAECONNREFUSED
by Dmitry Timoshkov Aug. 27, 2010

Aug. 27, 2010

Dan Kegel <dank(a)kegel.com> wrote: > This gets Pando-based installers further, see > http://bugs.winehq.org/show_bug.cgi?id=24019 > > There's obviously more to do here, but this little bit is useful. Please simultaneously add it to all other language files. -- Dmitry.

1 0

Re: windowscodecs: support ICO files with embedded PNGs
by Vincent Povirk Aug. 27, 2010

Aug. 27, 2010

You mean you're not going to implement IWICStream::InitializeFromIStreamRegion? That's no fun. Also, that read loop is a bit silly. You might as well just lock the HGLOBAL and read into it directly. On Fri, Aug 27, 2010 at 12:30 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Changelog: > * windowscodecs: support ICO files with embedded PNGs > Closes #23708. > Damjan Jovanovic > > > >

2 1

Re: mpr: Fix translations
by James McKenzie Aug. 27, 2010

Aug. 27, 2010

Amine Khaldi wrote: [nothing] Can you please put some sort of tracking information when resubmitting a patch like [try2]. This will keep those of us who are manually tracking and applying your fixes in sync. Thank you. James McKenzie

1 0

RFC: Resolving a full screen bug
by Erich Hoover Aug. 27, 2010

Aug. 27, 2010

I've been periodically revisiting a patch I've been using to fix a bug with running Borderlands under Wine at the same resolution as the desktop ( original message: http://www.winehq.org/pipermail/wine-devel/2010-May/083339.html ). Attached is an iteration that appears to resolve the issue without impacting the other applications I normally run. It appears that the problem arises since Borderlands goes straight from being iconified to being exactly the desktop resolution, as a result Wine never turns off the "iconic" flag - so the application window is not sized or positioned properly. I would appreciate it if I could get some feedback on this patch, it doesn't seem to break anything but it would be nice to have an expert opinion. Erich Hoover ehoover(a)mines.edu

2 2

Re: user32: Make GetMessage and PeekMessage patchable
by Henri Verbeet Aug. 26, 2010

Aug. 26, 2010

On 26 August 2010 15:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)macbook.local> Please configure git properly?

2 1

Inviting Mono and pulseaudio to wineconf?
by Dan Kegel Aug. 26, 2010

Aug. 26, 2010

Would it be appropriate and useful to invite someone from Mono and Pulseaudio to attend Wineconf this year? We do have to work well with those projects, maybe that would help solve a couple current or future problems.

8 15

Re: [PATCH] inetcpl: Add initial applet
by Juan Lang Aug. 26, 2010

Aug. 26, 2010

Hi Detlef, were you planning to resubmit this patch? [1] A user asked how to import a certificate recently [2], and I directed him to install ie6 to do so, but that has a lot of side effects which may not be wanted. Using our own inetcpl.cpl would allow us to avoid that, by exposing cryptui.CryptUICertMgr without using any native DLLs. Thanks, --Juan [1] http://www.winehq.org/pipermail/wine-patches/2010-May/088373.html [2] http://forum.winehq.org/viewtopic.php?t=9399

2 1

Re: shell32: Add a navigation pane to the ExplorerBrowser control.
by Juan Lang Aug. 26, 2010

Aug. 26, 2010

Hi David, I know this was committed already, but something caught my eye that I didn't understand: + if(This->navpane.show ^ show_navpane) Is this a cute way to write if(This->navpane.show && show_navpane) ? If so, why ^ rather than &&? Thanks, --Juan

3 3

Re: ddraw/tests: New visual back buffer flipping tests. (try 3)
by Stefan Dösinger Aug. 26, 2010

Aug. 26, 2010

> + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > + "Attaching a back buffer to a front buffer returned %08x\n", hr); The patch looks OK. Out of curiosity, which windows system returns DDERR_CANNOTATTACHSURFACE? Allowing this result with broken() is OK since you have an application that depends on this behavior.

2 1

Re: Inviting Mono and pulseaudio to wineconf?
by James Mckenzie Aug. 26, 2010

Aug. 26, 2010

Vincent Povirk <madewokherd(a)gmail.com> wrote: >Sent: Aug 26, 2010 9:03 AM >To: Dan Kegel <dank(a)kegel.com> >Cc: wine-devel(a)winehq.org, Stefan Dösinger <stefandoesinger(a)gmx.at> >Subject: Re: Inviting Mono and pulseaudio to wineconf? > >> Mono: >> Vincent, what do you think? Probably they're not holding us up, >> but maybe they'd like to see a presentation from you about >> status of Mono integration? > >Oh geez. Um. Well, they are indeed not holding us up. In all my >communication with them, they've been very helpful. > Since Microsoft appears to have taken a hostile turn towards anything released with Windows 7, WMP 10, .NET .3.5 + working with Wine, it would be very interesting to see what the Mono team's stance is on integration with Wine and the path onward. At one time it was very hostile, now it seems to have changed to at least neutral and maybe even what we call 'hallway' friendly. >I don't know that the current status of Mono integration is much to talk about. > >> http://wiki.winehq.org/Mono is looking good. (Think there's a Summer >> of Code 2011 project or two in there?) > >Judging by bugzilla, there don't seem to be any large projects that >would help compatibility enough to be worthwhile. All the mscoree bugs >only affect one app. > Hmmm. Maybe we need to widen the 'gene pool' to see if other applications are affected. James McKenzie

1 0

Re: : Use SUBLANG_NEUTRAL for language-independent resources
by Greg Geldorp Aug. 26, 2010

Aug. 26, 2010

> From: Francois Gouget <fgouget(a)free.fr> > > According to past Winetest results these platforms could (should?) have > it though. A full log is strange but I don't how it could be cause by my > patch: > > gameux: start - - > Usage: C:\winetest\gameux_test64.exe test_name > > Valid test names: > gameexplorer > gamestatistics > gameux: done (1) > > No test summary line found Your patch only changed the .rc file. TestBot doesn't know what tests to run in that case (it determines the tests to run from the .c files that were changed). Same kind of thing happens when the .js files for the jscript.dll tests are changed. I'll see if I can teach it to just run all tests in these cases. Ge.

1 0

Re: [5/5] d3d10: Implement D3D10CompileShader, forward to d3dcompiler.
by Henri Verbeet Aug. 26, 2010

Aug. 26, 2010

On 26 August 2010 17:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > +#define COBJMACROS > #include "config.h" > #include "wine/port.h" > - > +#include "objbase.h" > +#include "d3dcompiler.h" > #include "d3d10_private.h" You should probably just include d3dcompiler.h from d3d10_private.h.

1 0

Re: [2/5] d3dcompiler: Stub D3DCompile implementation.
by Henri Verbeet Aug. 26, 2010

Aug. 26, 2010

On 26 August 2010 17:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Please stick to the coding style used in the rest of the d3d10 dlls (see e.g. blob.c for reference). This applies to patches 4 and 5 as well.

1 0

Re: gameux: Use SUBLANG_NEUTRAL for language-independent resources.
by testbot＠testbot.winehq.org Aug. 26, 2010

Aug. 26, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4787 Your paranoid android. === W98SE (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

2 1

Use SUBLANG_NEUTRAL for the Gaelic resources?
by Francois Gouget Aug. 26, 2010

Aug. 26, 2010

Are SUBLANG_GAELIC, SUBLANG_GAELIC_SCOTTISH and SUBLANG_GAELIC_MANX very different languages? If not it would be better to use SUBLANG_NEUTRAL instead of SUBLANG_GAELIC. For instance: dlls/mapi32/Ga.rc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/mapi32/Ga.rc b/dlls/mapi32/Ga.rc index e8aa3c0..104a658 100644 --- a/dlls/mapi32/Ga.rc +++ b/dlls/mapi32/Ga.rc @@ -22,7 +22,7 @@ #include "res.h" -LANGUAGE LANG_GAELIC, SUBLANG_GAELIC +LANGUAGE LANG_GAELIC, SUBLANG_NEUTRAL STRINGTABLE { -- 1.7.1

2 2

Re: [PATCH 4/5] shell32: Add INameSpaceTreeControlEvents stub to the ExplorerBrowser control.
by Nikolay Sivov Aug. 26, 2010

Aug. 26, 2010

On 8/26/2010 14:53, David Hedberg wrote: > + *ppvObject = NULL; > + if(IsEqualIID(riid,&IID_INameSpaceTreeControlEvents)) > + { > + *ppvObject = iface; > + } > + Why don't you allow IUnknown here?

2 1

Re: [PATCH 1/5] shell32: Check for ICommDlgBrowser from Site and use it in the IExplorerBrowser control.
by Nikolay Sivov Aug. 26, 2010

Aug. 26, 2010

On 8/26/2010 14:53, David Hedberg wrote: > --- > dlls/shell32/ebrowser.c | 98 +++++++++++++++++++---- > dlls/shell32/tests/ebrowser.c | 174 ++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 251 insertions(+), 21 deletions(-) > > diff --git a/dlls/shell32/ebrowser.c b/dlls/shell32/ebrowser.c > index b243aa0..1137880 100644 > --- a/dlls/shell32/ebrowser.c > +++ b/dlls/shell32/ebrowser.c > @@ -73,6 +73,8 @@ typedef struct _ExplorerBrowserImpl { > LPITEMIDLIST current_pidl; > > IUnknown *punk_site; > + ICommDlgBrowser3 *pcdb3_site; > + UINT cdb_site_supported; > } ExplorerBrowserImpl; I think a better way for this would be to store a pointer for each interface version, instead of having additional switch. When you have separate pointers a call looks more obvious like: if (pcdb_site) ICommDlgBrowser_*(pcdb_site).

2 1

Re: mpr: Fix Czech translation.
by Alexandre Julliard Aug. 26, 2010

Aug. 26, 2010

Amine Khaldi <amine.khaldi(a)reactos.org> writes: > Regards, > Amine. There's no need to send a separate patch for each language, it's the same change for all. Also make sure your mailer doesn't mangle the high bit chars. -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
by Joerg-Cyril.Hoehle＠t-systems.com Aug. 26, 2010

Aug. 26, 2010

Octavian, are you aware of bug http://bugs.winehq.org/show_bug.cgi?id=22146 and the partial patch and additional test cases there? >winmm: Add MCI_INTEGER_PTR return type for DWORD_PTR return values. >+#define MCI_INTEGER_PTR 13 What kind of testing did you perform on native systems to derive the existence of this value? If such value does not exist, then I fear your patch set looses the ability to drop in native dlls for compatibility testing and validation. If it exists, then it's good news you found it. >-static DWORD MCI_ParseOptArgs(DWORD_PTR* data, int _offset, LPCWSTR lpCmd, >+static DWORD MCI_ParseOptArgs(BYTE* data, int _offset, LPCWSTR lpCmd, >- if (!MCI_GetDWord(&(data[offset+0]), &args) || >- !MCI_GetDWord(&(data[offset+1]), &args) || >- !MCI_GetDWord(&(data[offset+2]), &args) || >- !MCI_GetDWord(&(data[offset+3]), &args)) { >+ if (!MCI_GetDWord(data+offset+0*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+1*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+2*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+3*sizeof(DWORD), &args)) { The MCI_XYZ_PARMS structures are neither DWORD_PTR, not BYTE*, they are DWORD with some DWORD_PTR in between. Wouldn't using DWORD* data help avoid such pointer arithmetic and eliminate several hunks of the patch ? Regards, Jörg Höhle

1 0

Re: winetrick & mono dot net 3.5 emmulation.
by Hin-Tak Leung Aug. 26, 2010

Aug. 26, 2010

apologies - for laziness, I picked one message with Dan Kegel and did a reply and emptied subject/body. I guess that messes up e-mail software that actually uses the invisible headers for threads. -------- Original Message -------- Subject: Re: winetrick & mono dot net 3.5 emmulation. Date: Wed, 25 Aug 2010 21:01:09 -0700 From: James McKenzie <jjmckenzie51(a)earthlink.net> To: Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> Hin-Tak Leung wrote: > The installer of one application I have requires Net 3.5 and refuses > to install > if it is not detected. Yet it runs adequately well with mono 2.6.x > (when installed to Vista then copied over). So I am wondering if there > should be a winetrick "lie about having .net 3.5" registry setting, > and go about seeing what needs to be done - e.g. how is that installer > detecting dot net 3.5 ? > > > > Can you open a separate thread for this? I'm going ahead and deleting all of the messages from the hijacked thread on my system and you have a very good point to make. James McKenzie

1 0

WineConf 2010
by Francois Gouget Aug. 25, 2010

Aug. 25, 2010

WineConf 2010 is now all set: Where: Hotel Ibis Bastille in Paris When: November, Saturday 20th ~9am to Sunday 21st ~5pm You should book your hotel room directly from the hotel; the sooner the better. Also if you have not booked your plane tickets yet, this is your reminder. All the details should be available on the WineConf 2010 wiki page: http://wiki.winehq.org/WineConf2010 Again, note that most further communication will happen on the wineconf(a)winehq.org mailing list. So subscribe there to be sure not to miss the latest news. This is also the place to go if you have questions, etc. I hope to see you all in Paris! -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

1 0

Re: [PATCH 2/7] d3dx9_36/tests: Added HLSL test suite
by Henri Verbeet Aug. 25, 2010

Aug. 25, 2010

On 25 August 2010 09:58, Travis Athougies <iammisc(a)gmail.com> wrote: > +static IDirect3DPixelShader9* compile_pixel_shader(IDirect3DDevice9* device, const char *shader, const char *profile,· > +»······»·······»·······»·······»·······»······· ID3DXConstantTable **constants) You still have basic formatting errors like trailing spaces, mixing tabs and spaces, inconsistent "*" placement, etc. > + hres = IDirect3DDevice9_CreateVertexShader(device_ptr, (DWORD*) ID3DXBuffer_GetBufferPointer(compiled), &vshader_passthru); Here's another unnecessary cast. For the record, I'm not going to point out every single flaw in every single patch. If I find an issue in a patch, you should take that as a hint that perhaps you didn't review your patches careful enough before sending them, and go over them again yourself. Anyway, we've decided to implement the shader assembler and compiler in the d3dcompiler dll. I think it makes sense to move any compiler/assembler tests there as well. Note that I'm going to request that d3dcompiler follows the same general style as used in dxgi/d3d10core/d3d10, this is different from the style used in most of d3dx9. Something else. In my opinion an internship should imply some level of guidance/training, not simply "cheap labor". In particular, while ideally you would have caught the issues mentioned in this and previous reviews yourself, whoever has been mentoring you certainly should have, these are basic C / Wine development issues. The process is supposed to look somewhat like this: 1. Carefully write the patch. 2. Carefully review the patch. 3. If you find any issues, carefully fix them and go back to 2. 4. Run the test suite. 5. If it finds any issues, carefully fix them and go back to 2. 6. Send the patch to your mentor for review. 7. If he finds any issues, carefully fix them and go back to 2. 8. If it's still the same day as on 1, consider waiting a day, so you can give the patch a fresh look in the next step. 9. Repeat steps 2 through 5 before sending the patch to wine-patches. 10. Send the patch to wine-patches. 11. If it finds any issues, carefully fix them and go back to 2. Replace "patch" with "patchset" if you're doing more complicated things. Ideally step 6 would produce something like a "Signed-off-by" or "Reviewed-by" tag. If you're at step 11 for the third or fourth time, and there are still problems with the patch, there are structural failures at 1, 2 and 6. Failures at 1 and 2 are somewhat expected for an internship, depending on what kind of standards a specific organization sets, but that's exactly what step 6 is supposed to catch. I.e., when I find an issue in a patch that means at the very least that you didn't catch it when writing the patch, didn't catch it when reviewing the patch the first time, your mentor didn't catch it, and you didn't catch it during review before sending the patch. The things wine-patches reviews are supposed to catch are non-trivial interactions with other parts of the code, not trivial whitespace errors.

1 0

Re: mscoree: improve GetCORSytemDirectory
by testbot＠testbot.winehq.org Aug. 25, 2010

Aug. 25, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4758 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)
by Henri Verbeet Aug. 25, 2010

Aug. 25, 2010

On 24 August 2010 05:05, Misha Koshelev <misha680(a)gmail.com> wrote: > + elements[idx].Stream = 0xFF; > + elements[idx].Offset = D3DXGetDeclVertexSize(elements, 0); > + elements[idx].Stream = 0; That's ugly. > + memcpy(Declaration, elements, size * sizeof(D3DVERTEXELEMENT9)); That's unnecessary.

3 4

"Spanish - Modern Sort_Spain.1252" locale on wine
by GOUJON Alexandre Aug. 25, 2010

Aug. 25, 2010

Hi everyone, I'm trying to fix msvcrt:locale on wine and it appears "Spanish - Modern Sort_Spain.1252" locale is missing. According to msdn (http://msdn.microsoft.com/en-us/library/39cwe7zf%28v=VS.71%29.aspx) "esn" and "spanish-modern" are equivalent which is false [quoted from msvcrt/tests/locale.c] ret = setlocale(LC_ALL, "esn"); ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); if(ret) ok(!strcmp(ret, "Spanish_Spain.1252") || broken(!strcmp(ret, "Spanish - Modern Sort_Spain.1252")), "ret = %s\n", ret); and ret = setlocale(LC_ALL, "spanish-modern"); ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); if(ret) ok(!strcmp(ret, "Spanish - Modern Sort_Spain.1252") || broken(!strcmp(ret, "Spanish_Spain.1252")), "ret = %s\n", ret); If I modify dlls/kernerl32/nls/esn.nls LOCALE_SENGLANGUAGE "Spanish" to LOCALE_SENGLANGUAGE "Spanish - Modern Sort" then it'll fix the second test and break the first one. So I'm wondering what to do. Create another nls file based on esn with a different LOCALE_SENGLANGUAGE ? (and change _country_synonyms[] in locale.c) Hard code this (i.e. if .. == "spanish-modern" .. ) ? Other advice ? Thanks in advance

1 0

Re: ddraw [try 3]: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by Henri Verbeet Aug. 25, 2010

Aug. 25, 2010

On 25 August 2010 08:48, David Adam <david.adam.cnrs(a)gmail.com> wrote: > + if(cooplevel == (DDSCL_NORMAL | DDSCL_EXCLUSIVE) ) So what happens if you set e.g. "DDSCL_NORMAL | DDSCL_EXCLUSIVE | DDSCL_FPUPRESERVE"? You also still have trailing spaces. The way this would conceptually make sense to me is if you always need either NORMAL or EXCLUSIVE, with NORMAL | EXCLUSIVE -> EXCLUSIVE and EXCLUSIVE requiring FULLSCREEN. (Well, except for SETFOCUSWINDOW, which seems to live in a world of its own.) I.e., something along these lines: if (coop & SETFOCUSWINDOW) { ... return; } if (coop & EXCLUSIVE) { if (!(coop & FULLSCREEN)) fail(); ... } else if (coop & NORMAL) { ... } else fail();

1 0

wined3d and visual studio: The remaining uglyness
by Stefan Dösinger Aug. 25, 2010

Aug. 25, 2010

Hi, I've spent some time to get wined3d to compile with visual studio on Windows. I sent some code fixes needed for that, but a few hacks are remaining. I'm sending them here for discussion. First, why did I look at Visual Studio: *) mingw on windows a bit messy. Cross Compiling all the time even more so *) msvc is the native toolkit, it opens up many other tools. I was interested in VsPerfKit specifically. Basically I set up a Visual Studio process to compile libport, libwine, wined3d, d3d8 and d3d9 out of tree, referencing the code files via relative paths(../../wine/dlls/wined3d/*.c). This was done manually, there's no integration with Wine's native build system. That's hack #1. Unfortunately I can't attach the project right now, it's on a different computer at home. I think we have a script to generate msvc projects for the tests. Maybe the right way is to extend this to the DLLs and programs. I wrote a hand-written config.h file defining a few HAVE_XXX_H constants. That is hack #2 and relates to Alexandre's concern about the libport isnan and isinf implementations. More specific code issues: *) MIDL uses cdecl as the default calling convention for exported functions. Patch 6 in the archive fixes wined3d.idl to work correctly with midl, but this change causes a segfault in widl. *) Msvc complains that -unsigned_int is still unsigned, and the integer overflow just happens to do what you want. The easiest way is to write 0 - unsigned_int, but I'm not sure about it. *) NaN and Inf generation *) msvc doesn't like the predeclaration of **environ. It causes a unknown symbol error at link time.

1 0

Re: ddraw: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by Stefan Dösinger Aug. 25, 2010

Aug. 25, 2010

Hi, Your CreateSurface tests are missing in this patch(assuming that paulo lesgaz is your alter ego) There's a comment above the SetCooperativeLevel implementation that needs adjustments. > if(cooplevel & DDSCL_NORMAL) > { > - /* Can't coexist with fullscreen or exclusive */ > - if(cooplevel & (DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE) ) > + /* Can't coexist with exclusive only*/ > + if(cooplevel = DDSCL_NORMAL | DDSCL_EXCLUSIVE ) This check doesn't do what you intend it to do. An application may pass NORMAL | EXCLUSIVE | FPUSETUP for instance Also, your test shows that NORMAL | EXCLUSIVE | FULLSCREEN means fullscreen mode. The CreateSurface test passes because the FULLSCREEN and EXCLUSIVE flags are added, but the window is still set up for windowed rendering. In this flag combination you want to enter the fullscreen setup codepath.

1 0

Re: ddraw [try 3]: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by testbot＠testbot.winehq.org Aug. 25, 2010

Aug. 25, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4741 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [3/3] d3dcompiler: Move D3DAssemble tests from d3dx9_36.
by testbot＠testbot.winehq.org Aug. 24, 2010

Aug. 24, 2010

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=4740 Your paranoid android. === WINEBUILD (build) === Reconfig failed

1 0