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

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=4739 Your paranoid android. === WINEBUILD (build) === Reconfig failed

1 0

Re: [4/4] oleaut32/tests: Some tests for IPicture::get_Handle()
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=4738 Your paranoid android. === W7PROX64 (64 bit olepicture) === olepicture.c:796: Test failed: got 0 olepicture.c:808: Test failed: got 0

1 0

Re: [3/4] oleaut32/olepicture: Fix ::get_hPal() behaviour for certain picture types
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=4737 Your paranoid android. === W7PROX64 (64 bit olepicture) === olepicture.c:765: Test failed: got 0 olepicture.c:777: Test failed: got 0

1 0

Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by Stefan Dösinger Aug. 24, 2010

Aug. 24, 2010

Hi, Can you add a test that tests in which mode ddraw is after such a call? Specfically, try to create a double buffered primary surface. If this succeeds, ddraw is in fullscreen mode. If ddraw is in normal mode you'll get DDERR_NOEXCLUSIVEMODE (or similar) back. Am 24.08.2010 um 10:00 schrieb David Adam: > Fixed a typo > > A+ > > David > <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch>

2 5

re: wine.inf: added .NET InstallRoot key
by Dan Kegel Aug. 24, 2010

Aug. 24, 2010

What is our intent with adding all these registry keys? It seems as if they are helpful for installing mono, but might get in the way of installing MS .net. If that's the intent, do y'all want me to make the dotnet20 winetricks verb remove any registry keys that confuse the dotnet20 installer?

5 6

Re: msvcrt:locale Remove todo_wine and add broken when necessary
by Octavian Voicu Aug. 24, 2010

Aug. 24, 2010

On Tue, Aug 24, 2010 at 12:44 PM, Alexandre Goujon <ale.goujon(a)gmail.com> wrote: > - todo_wine ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > + ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > + || broken(!strcmp(ret, "Chinese_People's Republic of China.936")) broken() only works for tests that fail on some Windows versions; it has no effect on Wine, see [1]. Proper way to fix this bug is to make setlocale replicate Windows behavior. Octavian [1] http://source.winehq.org/git/wine.git/?a=blob;f=include/wine/test.h;h=1a980…

2 1

Wine Gecko 1.1.0 RC1
by Luca Bennati Aug. 24, 2010

Aug. 24, 2010

Applied the patch to master, recompiled ok. I put the rc1 cab in /usr/share/wine/gecko/, as always. In the creation of a new prefix, it gave me an err which wasn't there before: err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057 but 'wine iexplore' works better than before (sites that crashed wine before don't crash it anymore). I investigated it a bit recreating a new prefix with 'WINEDEBUG=+mshtml winecfg' and here's the log: wine: created the configuration directory '/home/luca/.wine' trace:mshtml:register_server (1) trace:mshtml:load_gecko () trace:mshtml:install_cab (L"Z:\\usr\\bin\\..\\share\\wine\\gecko\\wine_gecko-1.1.0-rc1-x86.cab") trace:mshtml:check_version "Wine Gecko 1.1.0-rc1" trace:mshtml:load_xpcom (L"C:\\windows\\system32\\gecko\\1.1.0-rc1\\wine_gecko") fixme:system:SetProcessDPIAware stub! trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsISupports 0x33d374) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33d214) trace:mshtml:nsDirectoryServiceProvider_GetFile ("GreD" 0x33d2ec 0x33d2e8) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33d214) trace:mshtml:nsDirectoryServiceProvider_GetFile ("XCurProcD" 0x33d2ec 0x33d2e8) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33bfc4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("PrfDef" 0x33c09c 0x33c098) warn:mshtml:nsDirectoryServiceProvider_QueryInterface ({2f977d4b-5485-11d4-87e2-0010a4e75ef2} 0x33bff4) warn:mshtml:nsDirectoryServiceProvider_QueryInterface ({2f977d4b-5485-11d4-87e2-0010a4e75ef2} 0x33bff4) fixme:iphlpapi:NotifyAddrChange (Handle 0xf5e914, overlapped 0xf5e918): stub trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33bc64) trace:mshtml:nsDirectoryServiceProvider_GetFile ("AChrom" 0x33bd3c 0x33bd38) err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057 trace:mshtml:nsIOService_GetProtocolHandler ("file" 0x33cff8) trace:mshtml:nsIOService_NewURI ("file:///C:/windows/system32/gecko/1.1.0-rc1/wine_gecko/components/nsTryToClose.js" (null) (nil) 0x33d15c) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfDS" 0x33cd8c 0x33cd88) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfD" 0x33cd8c 0x33cd88) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfLDS" 0x33cd8c 0x33cd88) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33ccb4) trace:mshtml:nsDirectoryServiceProvider_GetFile ("ProfLD" 0x33cd8c 0x33cd88) trace:mshtml:nsIOService_NewURI ("resource://gre/modules/XPCOMUtils.jsm" (null) (nil) 0x33acb8) trace:mshtml:nsDirectoryServiceProvider_QueryInterface (IID_nsIDirectoryServiceProvider 0x33851c) trace:mshtml:nsDirectoryServiceProvider_GetFile ("CurProcD" 0x3385f4 0x3385f0) trace:mshtml:nsIOService_NewFileURI (0x7613b8 0x338674) trace:mshtml:nsIOService_NewFileURI (0x7613b8 0x338674) trace:mshtml:nsIOService_NewURI ("jar:chrome/toolkit.jar!/res/" (null) 0x75f6c8 0x3386e4) trace:mshtml:nsIOService_ExtractScheme ("jar:chrome/toolkit.jar!/res/" 0x3363d0) trace:mshtml:nsIOService_NewURI ("chrome/toolkit.jar!/res/" "" 0x75f6c8 0x7613cc) trace:mshtml:nsIOService_NewURI not wraping trace:mshtml:nsIOService_NewChannelFromURI (0x75fa90 0x33acb4) trace:mshtml:nsIOService_NewChannelFromURI Could not get nsWineURI: 80004002 trace:mshtml:nsIOService_NewChannel ("file:///C:/windows/system32/gecko/1.1.0-rc1/wine_gecko/modules/XPCOMUtils.jsm" (null) (nil) 0x33acb4) trace:mshtml:close_gecko () wine: configuration in '/home/luca/.wine' has been updated. Hope it helps :)

2 1

Re: mscoree: improve GetCORVersion
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=4727 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

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

Aug. 24, 2010

This looks suspicious to me, you have to assume the code wasn't just added for the hell of it, even though with ddraw you're never quite sure. Do other ddraw versions behave the same? Please don't add trailing spaces, neither in the code nor in TRACEs.

2 1

Re: explorerframe/tests: Add a trailing '\n' to an ok() call.
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=4711 Your paranoid android. === W2K8SE (32 bit nstc) === nstc.c:1889: Test failed: Got event 7, count 0 nstc.c:1891: Test failed: Got event 4, count 0 nstc.c:1898: Test failed: Got event 6, count 1 nstc.c:1904: Test failed: Got event 4, count 0 nstc.c:1956: Test failed: Got event 7, count 0 nstc.c:1965: Test failed: Item not expanded. nstc.c:1968: Test failed: itemstate is 0x00000000 nstc.c:1985: Test failed: itemstate is 0x00000000 nstc.c:2111: Test failed: Got event 7, count 0 nstc.c:2118: Test failed: itemstate is 0x00000000 nstc.c:2142: Test failed: itemstate is 0x0000000c nstc.c:2157: Test failed: itemstate is 0x0000000c nstc.c:2171: Test failed: itemstate is 0x00000004 nstc.c:2183: Test failed: itemstate is 0x00000004 nstc.c:2240: Test failed: Got event 7, count 0 nstc.c:2245: Test failed: Got (0x80004005) nstc.c:2246: Test failed: psi is 00000000

1 0

Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized
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=4710 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: [PATCH 1/5] server: move is_removeable to fd_ops
by Mike Kaplinskiy Aug. 24, 2010

Aug. 24, 2010

2 1

How managing crashing tests ?
by GOUJON Alexandre Aug. 24, 2010

Aug. 24, 2010

Hi guys, A patch has been committed today saying "Make .. crashing like it does on native". I know we have to follow (genuine) Windows behavior but I'm wondering how to handle these cases. For instance, how to add a test crashing on every Windows ? Is it useful ? I mean, none program can rely on it .. since it crashes. Anyway, I've seen mainly two approaches - if(0) - /* comment the crashing ok() */ What's the difference ? And why not #if 0 ? I maybe lack some basic C knowledges but I think that /**/ and #if 0 are not added to the executable (from preprocessing stage). If it's right, it means we can then 'enable' these blocks maybe with (gdb) edit something And what about a test crashing on a specific Windows ? I guess #ifdef CRASHES_ON_NT40 is not an elegant way (even if it's currently used). Commenting such tests prevent us to check wine behavior on 'working' Windows. I attempted to use __TRY ... __EXCEPT_PAGE_FAULT in a test but it got rejected. Any advice ? Thanks

2 2

Re: ddraw/tests: New visual back buffer flipping tests. (resend)
by Octavian Voicu Aug. 24, 2010

Aug. 24, 2010

2010/8/23 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > + // Check it out You have a C++ style comment in this patch and I don't think it's allowed. Octavian

3 2

Re: user32: Optimize the storage of default values
by Dmitry Timoshkov Aug. 24, 2010

Aug. 24, 2010

André Hentschel <nerv(a)dawncrow.de> wrote: > -static const char * const DefSysColors[] = > +static struct { > + const char *name; > + const COLORREF rgb; > +} DefSysColors[] = It should be 'static const struct {'. -- Dmitry.

1 0

RFC: test of 16 bit wine (DOS)
by Morten Rønne Aug. 24, 2010

Aug. 24, 2010

Hi I have been working on creating tests for the 16 bit implementation of wine, and now I have come so far that I would like some comments on the way I have chosen to do it. 16 bit programs require a compiler that is able to create the old style address method in order to be able to test those parts of wine. I have been told by Dmitry Timoshkov that I should use OpenWatcom for that. So that is what I have done. OpenWatcom also supports building DOS32 (using a number of extenders) and WIN 3.x programs. Since the DOS program can't run in the current test enviroment, because that is new style 32 bit address method, I am using a wrapper program which start the old style program from the 32 bit environment. The wrapper also makes it possible to do a skip message in case the needed DOS program is missing (due to no OpenWatcom compiler). In order to be able to create a stand-alone DOS program I have modified the wine/test.h file so that certain parts got omitted, while others were added. This means that writing a DOS test will be the same as writing normal 32 bit tests, except that you include a different test include file. The current version uses the define __WINE_WINE_DOS16_TEST_H from the include file that defines the DOS environment, since I haven't been able to find a better name. Suggestions for a better name are most welcome. The DOS test it self, is only a very simple one because I consider this more a proof of concept than a full test. Also a full test will require a number of changes in the current 16 bit tree to move a number of definitions from .c files to .h files so the test can reference them. Once this have been commited work can start towards making more complete test of the 16 bit environment. I hope that the naming will make Wine Testbot able to detect changes to the test suite. As can be seen above the OpenWatcom compiler is needed to build the DOS 16 bit programs. Currently only Linux 32 bit platform is supported. The compiler can't be built on 64 bit yet, this includes Mac. The easiest way to install the compiler is to download the binary installer from: http://www.openwatcom.org/index.php/Download Select one of the mirrors and download the file: open-watcom-c-linux-1.9 Ignore the fact that the main download page points to other places to get the linux version. This is a binary program that you have to run. It will ask you were to install OpenWatcom and all files will be installed under that tree. After that you must add a definition of WATCOM to your shell profile, pointing it to the directory you selected. After that change PATH to search in $WATCOM/binl as the LAST thing. Watcom includes programs that are called the same as some wine programs (wrc for one), so be sure you don't find these by searching OpenWatcom last. As a note I can tell that Debian have rejected the Sybase license (under which OpenWatcom is released) as not being free, and therefore there will be no official debian packages of OpenWatcom. Best Regards Morten Rønne

2 1

Re: ddraw/tests: New visual back buffer flipping tests. (try 2)
by Octavian Voicu Aug. 24, 2010

Aug. 24, 2010

2010/8/24 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF) || > + broken(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0), // broken driver > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); I hate to be the bearer of bad news, but you missed one :)

2 1

Re: [PATCH 1/2] quartz/tests: move shareable code to a separate file
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=4626 Your paranoid android. === WINEBUILD (build) === Make failed

3 3

Re: ddraw: SetCooperativeLevel with Full screen + exclusive + normal is authorized
by testbot＠testbot.winehq.org Aug. 23, 2010

Aug. 23, 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=4696 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

1 0

Re: gdiplus: add a stub for GdipWindingModeOutline
by Vincent Povirk Aug. 23, 2010

Aug. 23, 2010

You need to add it to the .spec file too. On Mon, Aug 23, 2010 at 4:45 PM, Austin English <austinenglish(a)gmail.com> wrote: > -- > -Austin > > > >

2 1

Re: d3dx9: Implement D3DXDeclaratorFromFVF.
by Henri Verbeet Aug. 23, 2010

Aug. 23, 2010

On 20 August 2010 21:16, Misha Koshelev <misha680(a)gmail.com> wrote: > Thank you for your helpful feedback on my tests. > > This is based mostly on dlls/d3d9/vertexdeclaration.c with some > changes specific to D3DXDeclaratorFromFVF. > > Again, if there are any suggested changes please let me know. > As you already mentioned, this is pretty much another copy/paste implementation, including e.g. the useless macros and typedef.

2 4

re: New winetricks 20100822: new verb lucida
by Dan Kegel Aug. 23, 2010

Aug. 23, 2010

Jacek wrote: > I still hope that gecko will be removed from winetricks at some point. > It clearly doesn't belong to winetricks. That would be nice. Does every distro install wine-gecko yet? > Also fakeie6 doesn't make sense anymore. We set these registries > by default for over 2.5 years now. OK, deleted. - Dan

2 1

Re: configure: Enable prelink on x86_64
by Alexandre Julliard Aug. 23, 2010

Aug. 23, 2010

Stefan Dösinger <stefan(a)codeweavers.com> writes: > From 98e8cc5d0b5b2d397c1d904d2537c326ed36d43c Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)codeweavers.com> > Date: Sun, 22 Aug 2010 19:49:58 +0200 > Subject: [PATCH 4/4] Enable prelink on x86_64 Which app needs this? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: avifil32: Removed sign comparison warning (sizeof expresions)
by Michael Stefaniuc Aug. 23, 2010

Aug. 23, 2010

Marko Nikolic wrote: > sizeof expresion always return unsigned type, so it is casted > when comparing with signed values. This is ugly. > --- > dlls/avifil32/wavfile.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/avifil32/wavfile.c b/dlls/avifil32/wavfile.c > index fd6d9ec..3fc934c 100644 > --- a/dlls/avifil32/wavfile.c > +++ b/dlls/avifil32/wavfile.c > @@ -803,7 +803,7 @@ static HRESULT WINAPI IAVIStream_fnSetFormat(IAVIStream *iface, LONG pos, > TRACE("(%p,%d,%p,%d)\n", iface, pos, format, formatsize); > > /* check parameters */ > - if (format == NULL || formatsize <= sizeof(PCMWAVEFORMAT)) > + if (format == NULL || formatsize <= (LONG)sizeof(PCMWAVEFORMAT)) IMHO gcc is *wrong* in emitting a warning there. sizeof(PCMWAVEFORMAT) is a compile time constant and gcc can see that sizeof(PCMWAVEFORMAT) falls well inside the number range expressible by a LONG. Logically there is no difference between formatsize <= sizeof(PCMWAVEFORMAT) and formatsize <= 16 One gives a bogus warning and the other doesn't. bye michael

4 6

Re: [PATCH 1/3] msvcp90/tests: Added basic_string<char> tests (try2)
by testbot＠testbot.winehq.org Aug. 23, 2010

Aug. 23, 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=4681 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: New winetricks 20100822: new verb lucida
by James Mckenzie Aug. 23, 2010

Aug. 23, 2010

Scott Ritchie <scott(a)open-vote.org> wrote: >Sent: Aug 23, 2010 6:37 AM >To: Wine Devel <wine-devel(a)winehq.org> >Subject: Re: New winetricks 20100822: new verb lucida > >On 08/23/2010 05:01 AM, Jacek Caban wrote: >> Hi Dan, >> >> On 8/22/10 8:57 PM, Dan Kegel wrote: >>> Dan Kegel: >>> gecko: make it work even if WINE isn't set. (How did this get >>> through?) >> >> I still hope that gecko will be removed from winetricks at some point. >> It clearly doesn't belong to winetricks. >> >> Also fakeie6 doesn't make sense anymore. We set these registries by >> default for over 2.5 years now. >> > >Well on Ubuntu at least installing the Wine package will pull in the >wine-gecko package and all will be well in the world. This is the >ultimate path forward, I think. > Any word from the RedHat/CentOS/Fedora crowd? I have to fix the video on my laptop (it's just messed up) and then I can check if this happens on CentOS 5.5 as well. James McKenzie

1 0

Re: [PATCH] ntdll: set correct protection flags on sections in builtin DLLs
by Alexandre Julliard Aug. 23, 2010

Aug. 23, 2010

Marcus Meissner <marcus(a)jet.franken.de> writes: > @@ -1406,7 +1409,18 @@ static void load_builtin_callback( void *module, const char *filename ) > } > virtual_create_system_view( module, nt->OptionalHeader.SizeOfImage, > VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED | > - VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC ); > + VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC, &view ); > + > + sec = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > + for (i=0;i<nt->FileHeader.NumberOfSections;i++) { > + DWORD flags = VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED; > + > + if (sec[i].Characteristics & IMAGE_SCN_MEM_EXECUTE) flags |= VPROT_EXEC; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_READ) flags |= VPROT_READ; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_WRITE) flags |= VPROT_WRITE; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_SHARED) flags |= VPROT_WRITECOPY; > + VIRTUAL_SetProt( view, (char*)module + sec[i].VirtualAddress, sec[i].Misc.VirtualSize, flags ); I don't think you want to actually change the permissions, our headers don't necessarily match the real ELF sections. (BTW, could you please convince your mailer to set a valid Message-Id?) -- Alexandre Julliard julliard(a)winehq.org

2 2

New winetricks 20100822: new verb lucida
by Dan Kegel Aug. 23, 2010

Aug. 23, 2010

Another fortnight, another Winetricks. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Changes: Austin English mdac26: can't download anymore, so make it a synonym for mdac27 firefox: fix install. (filenames can have spaces. Patch by depesz. Issue 153.) lucida: add new font verb lucida mingw: fix PATH Andrew Nguyen wsh57: Fix the wsh57 dependency check and remove calls to load_wsh56 helper. Dan Kegel: gecko: make it work even if WINE isn't set. (How did this get through?)

4 3

Re: [PATCH 4/6] shell32: Implement IExplorerBrowser::Advise and IExplorerBrowser::Unadvise.
by Alexandre Julliard Aug. 23, 2010

Aug. 23, 2010

David Hedberg <david.hedberg(a)gmail.com> writes: > +#define EBE_IMPL(iface) \ > + ((IExplorerBrowserEventsImpl*)iface) > [...] > +static ULONG WINAPI IExplorerBrowserEvents_fnAddRef(IExplorerBrowserEvents *iface) > +{ > + return InterlockedIncrement(&(EBE_IMPL(iface)->ref)); That's ugly, declare a proper This pointer instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [5/5] libport: Add msvc isnan and isinf implementations
by Alexandre Julliard Aug. 23, 2010

Aug. 23, 2010

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -31,6 +31,14 @@ int isinf(double x) > return (!(finite(x) || isnand(x))); > } > > +#elif defined(HAVE_FLOAT_H) && defined(_MSC_VER) > +#include <float.h> You should use proper configure checks instead of _MSC_VER, like we do for other similar cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
by testbot＠testbot.winehq.org Aug. 23, 2010

Aug. 23, 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=4676 Your paranoid android. === WVISTAADM (32 bit gameexplorer) === gameexplorer.c:450: Test failed: cannot find expected registry value gameexplorer.c:468: Test failed: cannot find expected registry value

1 0

Re: [2/6] wincodec.idl: invent an ICNS encoder CLSID
by Alexandre Julliard Aug. 23, 2010

Aug. 23, 2010

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * wincodec.idl: invent an ICNS encoder CLSID If it's invented it shouldn't be in a public header. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32: Remove unused last parameter from TOOLTIPS_EnumToolsT.
by Nikolay Sivov Aug. 23, 2010

Aug. 23, 2010

On 8/23/2010 00:51, Gerald Pfeifer wrote: > --- > dlls/comctl32/tooltips.c | 6 ++---- > 1 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/dlls/comctl32/tooltips.c b/dlls/comctl32/tooltips.c > index 688d3b5..d17f067 100644 > --- a/dlls/comctl32/tooltips.c > +++ b/dlls/comctl32/tooltips.c > @@ -1177,8 +1177,7 @@ TOOLTIPS_DelToolT (TOOLTIPS_INFO *infoPtr, const TTTOOLINFOW *ti, BOOL isW) > } > > static LRESULT > -TOOLTIPS_EnumToolsT (const TOOLTIPS_INFO *infoPtr, UINT uIndex, TTTOOLINFOW *ti, > - BOOL isW) > +TOOLTIPS_EnumToolsT (const TOOLTIPS_INFO *infoPtr, UINT uIndex, TTTOOLINFOW *ti) > { > TTTOOL_INFO *toolPtr; > > @@ -2176,8 +2175,7 @@ TOOLTIPS_WindowProc (HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) > uMsg == TTM_DELTOOLW); > case TTM_ENUMTOOLSA: > case TTM_ENUMTOOLSW: > - return TOOLTIPS_EnumToolsT (infoPtr, (UINT)wParam, (LPTTTOOLINFOW)lParam, > - uMsg == TTM_ENUMTOOLSW); > + return TOOLTIPS_EnumToolsT (infoPtr, (UINT)wParam, (LPTTTOOLINFOW)lParam); > case TTM_GETBUBBLESIZE: > return TOOLTIPS_GetBubbleSize (infoPtr, (LPTTTOOLINFOW)lParam); > This needs to be implemented properly instead of being removed. Significant part is here: --- /* ti->lpszText = toolPtr->lpszText; */ ti->lpszText = NULL; /* FIXME */ --- which needs some tests. It's really doubtful that text is not returned when A/W messages exist.

1 0

Re: [5/5] gdiplus: Test flags of loaded images.
by testbot＠testbot.winehq.org Aug. 22, 2010

Aug. 22, 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=4650 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found === W7PRO (32 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010 === W7PROX64 (32 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010 === W7PROX64 (64 bit image) === image.c:103: Test failed: Expected 00012010, got 00013010 image.c:103: Test failed: Expected 00013088, got 00013010

2 1

Re: msvideo: Forward MCIWndCreate16 to MCIWndCreateA (2nd)
by Alexandre Julliard Aug. 22, 2010

Aug. 22, 2010

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > + HINSTANCE hinst32; > + if (hinst16 == GetModuleHandle16("msvideo.dll")) > + hinst32 = GetModuleHandleA("msvfw32.dll"); > + else > + hinst32 = HINSTANCE_32(GetExePtr( hinst16 )); This doesn't seem right. Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: appwiz.cpl: Removed sign comparison warning
by Nikolay Sivov Aug. 22, 2010

Aug. 22, 2010

On 8/20/2010 20:04, Marko Nikolic wrote: > Changed variable type to match function return type. > --- > dlls/appwiz.cpl/appwiz.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/appwiz.cpl/appwiz.c b/dlls/appwiz.cpl/appwiz.c > index ffd2b24..1b3370b 100644 > --- a/dlls/appwiz.cpl/appwiz.c > +++ b/dlls/appwiz.cpl/appwiz.c > @@ -406,7 +406,7 @@ static void UpdateButtons(HWND hWnd) > { > APPINFO *iter; > LVITEMW lvItem; > - DWORD selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, LVM_GETNEXTITEM, -1, > + LRESULT selitem = SendDlgItemMessageW(hWnd, IDL_PROGRAMS, LVM_GETNEXTITEM, -1, > LVNI_FOCUSED | LVNI_SELECTED); > BOOL enable_modify = FALSE; > There's no need for that, return value means integer item index. What are you fixing with that?

2 3

Re: [4/5] gdiplus: Set bitmap has alpha flag based on format.
by testbot＠testbot.winehq.org Aug. 22, 2010

Aug. 22, 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=4649 Your paranoid android. === WVISTAADM (32 bit image) === No test summary line found

1 0

Re: wineboot: More architectures and vendorIDs in create_hardware_registry_keys
by André Hentschel Aug. 22, 2010

Aug. 22, 2010

> +#ifdef __i386__ > + /* get VendorID from CPUID, eax = 0 */ > + unsigned int regs[3]; Hello Konrad, you are generating declerations after some code here. -- Best Regards, André Hentschel

2 2

problem with ./configure & libGLU vs. libice-dev
by wylda＠volny.cz Aug. 22, 2010

Aug. 22, 2010

Hi, isn't there a problem with wine's configure script? I'm running on new Debian Squezee and noticed (luckily), that when libice-dev is installed, than ./configure can't find "-lGLU". But libice-dev doesn't have any influence on file "libGLU.so.1". So why configure says me "-lGLU... not found" when file "/usr/lib/libGLU.so.1" is present? Desperate W.

4 5

Re: [PATCH 2/5] ddraw/tests: New visual back buffer flipping tests. (try 5, resend)
by Stefan Dösinger Aug. 21, 2010

Aug. 21, 2010

This test contains a C++ comment, please remove it. Otherwise it looks ok, as does patch 1 Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/visual.c | 123 +++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 123 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/visual.c b/dlls/ddraw/tests/visual.c > index 290cb76..aecc2ab 100644 > --- a/dlls/ddraw/tests/visual.c > +++ b/dlls/ddraw/tests/visual.c > @@ -2920,6 +2920,128 @@ static void depth_clamp_test(IDirect3DDevice7 *device) > ok(SUCCEEDED(hr), "SetViewport failed, hr %#x.\n", hr); > } > > +static void DX1_BackBufferFlipTest(void) > +{ > + HRESULT hr; > + int ret; > + IDirectDraw *DirectDraw1 = NULL; > + IDirectDrawSurface *Primary = NULL; > + IDirectDrawSurface *Backbuffer = NULL; > + WNDCLASS wc = {0}; > + DDSURFACEDESC ddsd; > + DDBLTFX ddbltfx; > + COLORREF color; > + const DWORD white = 0xffffff; > + const DWORD red = 0xff0000; > + BOOL attached = FALSE; > + > + wc.lpfnWndProc = DefWindowProc; > + wc.lpszClassName = "DX1_BackBufferFlipTest_wc"; > + RegisterClass(&wc); > + window = CreateWindow("DX1_BackBufferFlipTest_wc", "DX1_BackBufferFlipTest", > + WS_MAXIMIZE | WS_VISIBLE | WS_CAPTION , 0, 0, 640, 480, 0, 0, 0, 0); > + > + hr = DirectDrawCreate( NULL, &DirectDraw1, NULL ); > + ok(hr==DD_OK || hr==DDERR_NODIRECTDRAWSUPPORT, "DirectDrawCreate returned: %x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDraw_SetCooperativeLevel(DirectDraw1, window, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN); > + ok(hr==DD_OK, "SetCooperativeLevel returned: %x\n", hr); > + if(FAILED(hr)) goto out; > + > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 32); > + if(FAILED(hr)) { > + /* 24 bit is fine too */ > + hr = IDirectDraw_SetDisplayMode(DirectDraw1, 640, 480, 24); > + } > + ok(hr==DD_OK || hr == DDERR_UNSUPPORTED, "SetDisplayMode returned: %x\n", hr); > + if (FAILED(hr)) { > + goto out; > + } > + > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > + ddsd.dwSize = sizeof(DDSURFACEDESC); > + ddsd.dwFlags = DDSD_CAPS; > + ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Primary, NULL); > + ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: %08x\n", hr); > + > + memset(&ddsd, 0, sizeof(DDSURFACEDESC)); > + ddsd.dwSize = sizeof(DDSURFACEDESC); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT | DDSD_PIXELFORMAT; > + ddsd.ddsCaps.dwCaps = DDSCAPS_BACKBUFFER; > + ddsd.dwWidth = 640; > + ddsd.dwHeight = 480; > + ddsd.ddpfPixelFormat.dwSize = sizeof(ddsd.ddpfPixelFormat); > + ddsd.ddpfPixelFormat.dwFlags = DDPF_RGB; > + U1(ddsd.ddpfPixelFormat).dwRGBBitCount = 32; > + U2(ddsd.ddpfPixelFormat).dwRBitMask = 0x00ff0000; > + U3(ddsd.ddpfPixelFormat).dwGBitMask = 0x0000ff00; > + U4(ddsd.ddpfPixelFormat).dwBBitMask = 0x000000ff; > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &Backbuffer, NULL); > + todo_wine ok(hr==DD_OK, "IDirectDraw_CreateSurface returned: %08x\n", hr); > + if(FAILED(hr)) goto out; > + > + 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); > + if (FAILED(hr)) goto out; > + > + attached = TRUE; > + > + memset(&ddbltfx, 0, sizeof(ddbltfx)); > + ddbltfx.dwSize = sizeof(ddbltfx); > + U5(ddbltfx).dwFillColor = red; > + hr = IDirectDrawSurface_Blt(Backbuffer, NULL, NULL, NULL, DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); > + ok(hr == DD_OK, "IDirectDrawSurface_Blt returned: %x\n", hr); > + > + U5(ddbltfx).dwFillColor = white; > + hr = IDirectDrawSurface_Blt(Primary, NULL, NULL, NULL, DDBLT_COLORFILL | DDBLT_WAIT, &ddbltfx); > + ok(hr == DD_OK, "IDirectDrawSurface_Blt returned: %x\n", hr); > + > + // Check it out > + color = getPixelColor_GDI(Primary, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF, > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + color = getPixelColor_GDI(Backbuffer, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0, > + "got R %02X G %02X B %02X, expected R FF G 00 B 00\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + hr = IDirectDrawSurface_Flip(Primary, NULL, DDFLIP_WAIT); > + todo_wine ok(hr == DD_OK, "IDirectDrawSurface_Flip returned 0x%08x\n", hr); > + > + if (hr == DD_OK) > + { > + color = getPixelColor_GDI(Primary, 5, 5); > + ok(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0, > + "got R %02X G %02X B %02X, expected R FF G 00 B 00\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + > + color = getPixelColor_GDI(Backbuffer, 5, 5); > + ok((GetRValue(color) == 0xFF && GetGValue(color) == 0xFF && GetBValue(color) == 0xFF) || > + broken(GetRValue(color) == 0xFF && GetGValue(color) == 0 && GetBValue(color) == 0), // broken driver > + "got R %02X G %02X B %02X, expected R FF G FF B FF\n", > + GetRValue(color), GetGValue(color), GetBValue(color)); > + } > + > + out: > + > + if (Backbuffer) > + { > + if (attached) > + IDirectDrawSurface_DeleteAttachedSurface(Primary, 0, Backbuffer); > + IDirectDrawSurface_Release(Backbuffer); > + } > + if (Primary) IDirectDrawSurface_Release(Primary); > + if (DirectDraw1) IDirectDraw_Release(DirectDraw1); > + if (window) DestroyWindow(window); > +} > + > START_TEST(visual) > { > HRESULT hr; > @@ -2983,6 +3105,7 @@ START_TEST(visual) > > D3D3_ViewportClearTest(); > p8_primary_test(); > + DX1_BackBufferFlipTest(); > > return ; > > -- > 1.7.2 > > >

2 1

Specifying Reply-To header in patches email using git-send-email?
by Frédéric Delanoy Aug. 21, 2010

Aug. 21, 2010

I've tried for some time to specify the wine-devel Reply-To using git-send-email, with little success so far Any idea how this might be done? Here's how my git config looks like: [sendemail] <smtp server config> from = user <email> to = wine-patches <wine-patches(a)winehq.org> assume8bitEncoding = UTF-8 suppresscc = self chainreplyto = false thread = false suppressfrom = true Frédéric

3 5

Re: [PATCH 2/2] quartz: implement IBaseFilter_FindPin
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4627 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

dlls/d3dx9_36/bytecodewriter.c oddity
by Gerald Pfeifer Aug. 21, 2010

Aug. 21, 2010

Metteo et al, I noticed d3dx9_36/bytecodewriter.c can be simplified as follows, but somewhat tells me this may rather point out a problem somewhere in that code, so I am not sending this to wine-patches. (The only functional difference should be the missing WARN in some cases, and I could restore that if desired, but...see above.) Thoughts? Guidance? Gerald diff --git a/dlls/d3dx9_36/bytecodewriter.c b/dlls/d3dx9_36/bytecodewriter.c index 07f96e7..e7bd8a5 100644 --- a/dlls/d3dx9_36/bytecodewriter.c +++ b/dlls/d3dx9_36/bytecodewriter.c @@ -1035,7 +1035,7 @@ static const struct bytecode_backend vs_1_x_backend = { static void instr_ps_1_0123_texld(struct bc_writer *This, const struct instruction *instr, struct bytecode_buffer *buffer) { - DWORD idx, srcidx; + DWORD idx; struct shader_reg reg; DWORD swizzlemask; @@ -1074,17 +1074,6 @@ static void instr_ps_1_0123_texld(struct bc_writer *This, /* map the temp dstreg to the ps_1_3 texture temporary register */ This->funcs->dstreg(This, &instr->dst, buffer, instr->shift, instr->dstmod); } else if(instr->src[0].type == BWRITERSPR_TEMP) { - if(instr->src[0].regnum == T0_REG) { - srcidx = 0; - } else if(instr->src[0].regnum == T1_REG) { - srcidx = 1; - } else if(instr->src[0].regnum == T2_REG) { - srcidx = 2; - } else if(instr->src[0].regnum == T3_REG) { - srcidx = 3; - } else { - WARN("Invalid address data source register r%u\n", instr->src[0].regnum); - } swizzlemask = (3 << BWRITERVS_SWIZZLE_SHIFT) | (3 << (BWRITERVS_SWIZZLE_SHIFT + 2)) |

2 2

Re: crypt32: Correct CryptVerifyMessageSignature's use of pcbDecoded
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4624 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 5/5] shell32: Implement IExplorerBrowser::SetRect.
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4604 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 4/5] shell32: Implement IExplorerBrowser::Initialize.
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4603 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 3/5] shell32: Add IShellBrowser stub.
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4602 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 2/5] shell32/tests: Add initial tests for the IExplorerBrowser control.
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4601 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH] ntdll/tests: Add tests for RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 5]
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4600 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: advpakc/tests: Removed sign comparison warning in advpack tests
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4599 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 7/8] msvcp90/tests: Added basic_string<char> tests
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4597 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 2/2] d3dcompiler: Add D3DCreateBlob() test.
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4596 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH try 2] ntdll: IMAGE_REL_BASED_HIGH, IMAGE_REL_BASED_LOW and IMAGE_REL_BASED_HIGHLOW should be supported on win64.
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4595 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [7/7] comctl32/imagelist: Fail to create imagelist with zero or negative image dimensions
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4594 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [6/7] comctl32/imagelist: Fail in ImageList_GetIconSize on null parameters
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4593 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [5/7] comctl32/tests: More imagelist tests to show broken parameter validation
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4592 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [4/7] comctl32/imagelist: Fix failure code for IImageList_Remove()
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4591 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [3/7] comctl32/imagelist: Fix failure code for IImageList_Draw()
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4590 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [2/7] comctl32/tests: Use reduced IMAGELISTDRAWPARAMS structure size for tests
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4589 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [1/7] comctl32/tests: Use better names for test functions, discover some new test failures
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4588 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: oleau32: Try both SYS_WIN64 and SYS_WIN32 syskind in QueryPathOfRegTypeLib on win64.
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4582 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4581 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 4/4] explorerframe: Some additional basic tests.
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4578 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 3/4] explorerframe: Implement EnsureItemVisible.
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4577 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH 2/4] explorerframe: Implement HitTest
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4576 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4574 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [5/5] urlmon/tests: Added tests for IUriBuilder_GetFragment
by testbot＠testbot.winehq.org Aug. 21, 2010

Aug. 21, 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=4571 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [website]Japanese Translation for "About Wine" page
by Jeremy Newman Aug. 20, 2010

Aug. 20, 2010

I'll accept this patch when we also have a JA translation of the Front landing page. No point having other pages translated without at least that. -Newman On 08/17/2010 11:00 PM, kikuchy.h(a)gmail.com wrote: > From: Hiroshi Kikuchi<kikuchy.h(a)gmail.com> > > I want to join wine project. Nice to meet you. > Hiroshi Kikuchi > --- > templates/ja/about.template | 27 +++++++++++++++++++++++++++ > 1 files changed, 27 insertions(+), 0 deletions(-) > create mode 100644 templates/ja/about.template > > diff --git a/templates/ja/about.template b/templates/ja/about.template > new file mode 100644 > index 0000000..b83fad7 > --- /dev/null > +++ b/templates/ja/about.template > @@ -0,0 +1,27 @@ > + > + > + > +<h1 class="title">Wine について</h1> > + > +<p>Wine は、 Windows のソフトウェアを Windows 以外のOSで動作させるものです。Wine を使えば、Windows でするように Windows アプリケーションのインストールと実行が出来るようになります。</p> > + > +<p>Wine は現在活発に開発されています。まだ全てのプログラムが動作する訳ではありませんが、すでに<a href="http://wiki.winehq.org/UsageStatistics" title="Wine Usage Statistics">何人もの人たちが</a> Wine を使ってソフトウェアを動かしています。</p> > + > +<h3>オープンソース、そしてユーザーによる支援</h3> > + > +<p>Wine は未来永劫<a href="http://wiki.winehq.org/Licensing" title="Wine licensing">フリーソフト</a>です。Wine のソースコードのおよそ半分がボランティアによって書かれています。残り半分は商業的利潤のため、特にサポートがあるバージョンの Wine を発売している<a href="http://www.codeweavers.com/products/" title="Codeweavers Crossover Office">Codeweavers</a>によって支えられています。</p> > + > +<p>Wine はユーザーコミュニティに大きく頼っています。ユーザーのテストが私たちの、プログラムの動作状況を記録した<a href="http://appdb.winehq.org/" title="Wine Application Database">アプリケーションデータベース</a>を埋めてくれていますし、<a href="http://forums.winehq.org/" title="WineHQ Forums">フォーラム</a>の質問に対する答えも全てボランティアによるものです。</p> > + > +<h3>こちらもご覧ください:</h3> > +<ul> > +<li><a href="http://wiki.winehq.org/ImportanceOfWine">Wine が重要な理由</a></li> > +<li><a href="http://wiki.winehq.org/Debunking_Wine_Myths">Wine にまつわるウソ・ホント</a></li> > +<li><a href="http://wiki.winehq.org/WineHistory">Wine プロジェクトの歴史</a></li> > +<li><a href="http://wiki.winehq.org/ProjectOrganization">Organization and Leadership</a></li> > +</ul> > + > +<hr> > +<div class="link-container"> > +<p class="right-link">Wine の歴史:<a href="{$root}/history">次へ</a></p> > +</div> > > > >

1 0

RE: The Test Bot seems to be having issues
by Greg Geldorp Aug. 20, 2010

Aug. 20, 2010

Hi Thomas, > From: Thomas Mallaly > > First off, I'm not sure who should be contacted about this, but, it appears > that the test bot has got itself stuck while trying to run tests on a patch > submitted last night. Sorry, hadn't noticed it got stuck. Usually it doesn't need much baby-sitting, so I don't keep a close look on it. You can always use the "Feedback" link on the TestBot home page. > The job in question is here [1], it's been over 12 > hours since any progress has been made on it and no other submissions have > run since then. Also, the Windows 98SE has been "reverting" this whole time, > so I'm not sure if this is the culprit or not. > > I also hate to admit that the job in question is from one of my patches I > sent in last night (although I'm pretty sure it doesn't have anything to do > with the quality of the code in the patch ;-) ). The Win9x VMs are on a different (physical) machine, it appears there was a network problem between the Test Bot host and the machine hosting the Win9x VMs. The Win98SE VM getting stuck in the "reverting" state is the cause of the problems, nothing to do with your patch. > Anyways, I'm hoping that somebody in charge of the test bot might be able to > fix the traffic jam it's causing. It's back up and running again, trying to catch up. Ge.

2 1

CVS gateway down for good
by Alexandre Julliard Aug. 20, 2010

Aug. 20, 2010

Folks, The git->CVS gateway broke again, so I'm going to pull the plug on it. It doesn't make sense for me to spend more time fixing something that sees so little usage at this point. If you are still using CVS, you'll have to switch to git (or volunteer to host the gateway yourself...) Sorry about the inconvenience. -- Alexandre Julliard julliard(a)winehq.org

1 0

The Test Bot seems to be having issues
by Thomas Mullaly Aug. 20, 2010

Aug. 20, 2010

Hi all, First off, I'm not sure who should be contacted about this, but, it appears that the test bot has got itself stuck while trying to run tests on a patch submitted last night. The job in question is here [1], it's been over 12 hours since any progress has been made on it and no other submissions have run since then. Also, the Windows 98SE has been "reverting" this whole time, so I'm not sure if this is the culprit or not. I also hate to admit that the job in question is from one of my patches I sent in last night (although I'm pretty sure it doesn't have anything to do with the quality of the code in the patch ;-) ). Anyways, I'm hoping that somebody in charge of the test bot might be able to fix the traffic jam it's causing. [1] https://testbot.winehq.org/JobDetails.pl?Key=4570 <https://testbot.winehq.org/JobDetails.pl?Key=4570> -- Thomas Mullaly thomas.mullaly(a)gmail.com

2 2

Re: user32/dialog.c: GetNextDlgTabItem returns hwndDlg if it does not contain controls. [try 2]
by Alexandre Julliard Aug. 20, 2010

Aug. 20, 2010

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > GetNextDlgTabItem returns hwndDlg if it does not contain controls and > searching next item. > GetNextDlgTabItem returns the first child if next TABSTOP control not > found. > > And returns 0 in both cases if searching prev item It breaks the tests: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so propsheet.c && touch propsheet.ok propsheet.c:312: Test failed: Focus should have been set to the Next button. Expected: 12324, Found: 65535 propsheet.c:363: Test failed: Focus should have been set to the Next button. Expected: 12324, Found: 65535 make[1]: *** [propsheet.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] gdi32/enhmfdrv: Do not leak a HDC
by Alexandre Julliard Aug. 20, 2010

Aug. 20, 2010

Detlef Riekenberg <wine.dev(a)web.de> writes: > --- > dlls/gdi32/enhmfdrv/init.c | 14 ++++++++------ > 1 files changed, 8 insertions(+), 6 deletions(-) It would be cleaner to move the CreateDCW call where it's needed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: cmd: Improved a FIXME in WCMD_filesize64
by Alexandre Julliard Aug. 20, 2010

Aug. 20, 2010

"Konrad Wartke" <kwartke(a)googlemail.com> writes: > cmd: Improved a FIXME in WCMD_filesize64 by using a better algorithm. It's not much better. Anyway, this should be done by using one of the existing formatting functions, maybe VarFormatNumber. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 7/8] msvcp90/tests: Added basic_string<char> tests
by Alexandre Julliard Aug. 20, 2010

Aug. 20, 2010

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -0,0 +1,30 @@ > +/* > + * Copyright 2010 Piotr Caban for CodeWeavers > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +/* basic_string<char, char_traits<char>, allocator<char>> */ > +#define BUF_SIZE_CHAR 16 > +typedef struct _basic_string_char > +{ > + void *allocator; > + union _data { > + char buf[BUF_SIZE_CHAR]; > + char *ptr; > + } data; > + size_t size; > + size_t res; > +} basic_string_char; Unless there's going to be a ton of definitions in there used by many different files, it's better to put that sort of thing directly in the C file to make it easier to build stand-alone. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32: Properly set ERROR_NOACCESS when GetObject receives invalid arguments
by Octavian Voicu Aug. 19, 2010

Aug. 19, 2010

On Thu, Aug 19, 2010 at 4:56 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > Broken programs will crash on wine if they, for example, pass > arguments to GetObject in the wrong order. > This fixes bug #18864. > + if (buffer && ((ULONG_PTR)buffer >> 16) == 0) Wouldn't a __TRY ... __EXCEPT_PAGE_FAULT be better / safer? Octavian

2 1

PDB files generated by Intel C++ Compiler
by Peter Urbanec Aug. 19, 2010

Aug. 19, 2010

I have some x64 binaries and associated PDBs that have been generated using Intel C++ Compiler 11.1. These PDBs cause issues such as this: 1 0x00000000781cc1ba in msvcr80 (+0x9c1b9) (0x00007ff047a4c840) fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670 err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 2 0x000000006189a00d in lua5.1 (+0xa00c) (0x00007ff047a4c840) Now, from a quick look at mscvpdb.h, it looks like these PDBs contain datatypes with 64-bit near pointers, however wine does not seem to understand this mode. How would one go about adding support for this type of PDB? I actually don't have access to the Intel C++ Compiler to do much testing. :-(

2 1

winepath bug without arguments?
by Jerome Leclanche Aug. 19, 2010

Aug. 19, 2010

Hi After fixing a bug in MPQEdit related to opening directories, I noticed winepath returns a different result with and without quotes: adys(a)azura:~/.wine/drive_c$ winepath -w adys(a)azura:~/.wine/drive_c$ winepath -w "" C:\ With quotes it returns the current directory. Is that intended? If not I'll open a bug... J. Leclanche

3 2

Re: [01/11] d3dx10: Add stub for d3dx10_43
by Henri Verbeet Aug. 19, 2010

Aug. 19, 2010

On 18 August 2010 23:01, Owen Rudge <orudge(a)codeweavers.com> wrote: > +BOOL WINAPI D3DX10CheckVersion(UINT d3dsdkvers, UINT d3dxsdkvers) > +{ > + if ((d3dsdkvers == D3D10_SDK_VERSION) && (d3dxsdkvers == 43)) > + return TRUE; > + > + return FALSE; > +} Is it really safe to assume D3D10_SDK_VERSION will always keep the same value? (I know d3dx9 does it as well.) For d3d9 the SDK version changed between d3d9b and d3d9c, for example.

2 2

Re: [PATCH 3/5] ddraw/tests: New CreateSurface for 3D DDSCAPS_BACKBUFFER tests. (try 5, resend)
by Stefan Dösinger Aug. 19, 2010

Aug. 19, 2010

Hi, Can you try to create a d3d device with this surface? In the first d3d version this works by querying the d3d device ID from the surface. Patch 4 looks OK. Thank you for your persistence with the patches by the way! Cheers, Stefan Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > --- > dlls/ddraw/tests/d3d.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 82 insertions(+), 0 deletions(-) > > diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c > index 53ef04b..a83b0d5 100644 > --- a/dlls/ddraw/tests/d3d.c > +++ b/dlls/ddraw/tests/d3d.c > @@ -3536,6 +3536,87 @@ static void FindDevice(void) > "Expected IDirect3D1::FindDevice to return D3D_OK, got 0x%08x\n", hr); > } > > +static void BackBuffer3DCreateSurfaceTest(void) > +{ > + DDSURFACEDESC ddsd; > + DDSURFACEDESC created_ddsd; > + DDSURFACEDESC2 ddsd2; > + IDirectDrawSurface *surf; > + IDirectDrawSurface4 *surf4; > + IDirectDrawSurface7 *surf7; > + HRESULT hr; > + IDirectDraw2 *dd2; > + IDirectDraw4 *dd4; > + IDirectDraw7 *dd7; > + DDCAPS ddcaps; > + > + const DWORD caps = DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE; > + const DWORD expected_caps = DDSCAPS_BACKBUFFER | DDSCAPS_3DDEVICE | DDSCAPS_VIDEOMEMORY | DDSCAPS_LOCALVIDMEM; > + > + memset(&ddcaps, 0, sizeof(ddcaps)); > + ddcaps.dwSize = sizeof(DDCAPS); > + hr = IDirectDraw_GetCaps(DirectDraw1, &ddcaps, NULL); > + if (!(ddcaps.ddsCaps.dwCaps & DDSCAPS_VIDEOMEMORY)) > + { > + skip("DDraw reported no VIDEOMEMORY cap. Broken video driver? Skipping surface caps tests.\n"); > + return ; > + } > + > + memset(&ddsd, 0, sizeof(ddsd)); > + ddsd.dwSize = sizeof(ddsd); > + ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd.dwWidth = 64; > + ddsd.dwHeight = 64; > + ddsd.ddsCaps.dwCaps = caps; > + memset(&ddsd2, 0, sizeof(ddsd2)); > + ddsd2.dwSize = sizeof(ddsd2); > + ddsd2.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT; > + ddsd2.dwWidth = 64; > + ddsd2.dwHeight = 64; > + ddsd2.ddsCaps.dwCaps = caps; > + memset(&created_ddsd, 0, sizeof(created_ddsd)); > + created_ddsd.dwSize = sizeof(DDSURFACEDESC); > + > + hr = IDirectDraw_CreateSurface(DirectDraw1, &ddsd, &surf, NULL); > + todo_wine ok(SUCCEEDED(hr), "IDirectDraw_CreateSurface failed: 0x%08x\n", hr); > + if (surf != NULL) > + { > + hr = IDirectDrawSurface_GetSurfaceDesc(surf, &created_ddsd); > + ok(SUCCEEDED(hr), "IDirectDraw_GetSurfaceDesc failed: 0x%08x\n", hr); > + todo_wine ok(created_ddsd.ddsCaps.dwCaps == expected_caps, > + "GetSurfaceDesc returned caps %x, expected %x\n", created_ddsd.ddsCaps.dwCaps, > + expected_caps); > + IDirectDrawSurface_Release(surf); > + } > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw2, (void **) &dd2); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw2_CreateSurface(dd2, &ddsd, &surf, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw2_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw2_Release(dd2); > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw4, (void **) &dd4); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw4_CreateSurface(dd4, &ddsd2, &surf4, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw4_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw4_Release(dd4); > + > + hr = IDirectDraw_QueryInterface(DirectDraw1, &IID_IDirectDraw7, (void **) &dd7); > + ok(SUCCEEDED(hr), "IDirectDraw_QueryInterface failed: 0x%08x\n", hr); > + > + hr = IDirectDraw7_CreateSurface(dd7, &ddsd2, &surf7, NULL); > + ok(hr == DDERR_INVALIDCAPS, "IDirectDraw7_CreateSurface didn't return %x08x, but %x08x\n", > + DDERR_INVALIDCAPS, hr); > + > + IDirectDraw7_Release(dd7); > +} > + > START_TEST(d3d) > { > init_function_pointers(); > @@ -3571,6 +3652,7 @@ START_TEST(d3d) > TextureLoadTest(); > ViewportTest(); > FindDevice(); > + BackBuffer3DCreateSurfaceTest(); > D3D1_releaseObjects(); > } > > -- > 1.7.2 > > >

1 0

Re: user32/dialog.c: GetNextDlgTabItem returns hwndDlg if it does not contain controls.
by Alexandre Julliard Aug. 19, 2010

Aug. 19, 2010

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > @@ -1695,7 +1696,19 @@ HWND WINAPI GetNextDlgTabItem( HWND hwndDlg, HWND hwndCtrl, > */ > if (!hwndCtrl && fPrevious) return 0; > > - return DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious); > + nextItem = DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious); > + > + /* if next tab item not found return the first child even if it does not have TABSTOP > + Checked on XP > + */ > + if (!nextItem && !fPrevious) nextItem = GetWindow(hwndDlg,GW_CHILD); > + > + /* if there is no controls on hwndDlg return hwndDlg > + Checked on XP > + */ > + if (!nextItem && !fPrevious) nextItem = hwndDlg; > + > + return nextItem; You should test the fPrevious case too, it's probably similar. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oleau32: Use correct sysking in QueryPathOfRegTypeLib.
by Alexandre Julliard Aug. 19, 2010

Aug. 19, 2010

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/oleaut32/typelib.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) It breaks the 64-bit tests: ../../../../wine/tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so ../../../../wine/dlls/oleaut32/tests/typelib.c && touch typelib.ok typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.0) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.1) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.22) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.37) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(3.40) returned 8002801d typelib.c:784: Test failed: QueryPathOfRegTypeLib(65535.65535) returned 8002801d make: *** [typelib.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)
by Stefan Dösinger Aug. 19, 2010

Aug. 19, 2010

Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička: > + if(DDSD->ddsCaps.dwCaps & DDSCAPS_FRONTBUFFER) { > + WARN("Application tried to create an explicit front buffer\n"); > LeaveCriticalSection(&ddraw_cs); > return DDERR_INVALIDCAPS; > } This test seems redundant now. The ddraw1 thunk removes the flag, and all other thunks check for the frontbuffer flag on their own.

1 0

have all MCI tests in winmm/tests/ or distributed across mci*/tests/?
by Joerg-Cyril.Hoehle＠t-systems.com Aug. 19, 2010

Aug. 19, 2010

Hi, although my patch creates mcicda/tests/ I'd like to query whether it would make more sense to have all mci tests grouped in winmm/tests/. Pro: + Future fixes to winmm/mci.c would affect winmm/tests/*.c only. E.g. when I'll make "stop all" work I'd have to touch mcicda/tests/mcicda.c as well to eliminate the todo_wine there. Same when I'll patch mciparse to accept [TT:]MM:SS:FF format. + When Maarten will write mciqtz tests, perhaps resources could be reused to execute mciavi tests as well (the file creation code need not be duplicated). Similar tests could be written for: "open foo.avi" (mciavi) and "open foo.avi type mpegvideo" (mciqtz) or "open foo.wav" (micwave) and "open foo.wav type mpegvideo" although there's some difference in behaviour. + The functions test_notification could be in one file only, not repeated. I can rewrite my current mcicda/tests/mcicda.c patch to live in winmm/tests/. What do you think? Jörg Höhle

2 1

Re: [1/2] user32: add a way to poll for messages on extra handles
by Alexandre Julliard Aug. 19, 2010

Aug. 19, 2010

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > diff --git a/dlls/user32/driver.c b/dlls/user32/driver.c > index f2f9892..05c83d4 100644 > --- a/dlls/user32/driver.c > +++ b/dlls/user32/driver.c > @@ -126,6 +126,7 @@ static const USER_DRIVER *load_driver(void) > GET_USER_FUNC(WindowMessage); > GET_USER_FUNC(WindowPosChanging); > GET_USER_FUNC(WindowPosChanged); > + GET_USER_FUNC(GetExtraMessageHandles); That's ugly, it doesn't correspond to anything in the Windows API. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] ntdll/tests: Add tests for RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 4]
by Alexandre Julliard Aug. 19, 2010

Aug. 19, 2010

Detlef Riekenberg <wine.dev(a)web.de> writes: > + ok( (res == (void *)~0) || > + broken(res == (NULL + len)), /* XP and w2003 */ You can't do that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] comctl32/tests: DateTimePicker and MonthCalendar controls only support Gregorian calendar.
by Nikolay Sivov Aug. 19, 2010

Aug. 19, 2010

On Thu, Aug 19, 2010 at 9:50 AM, Austin Lund <austin.lund(a)gmail.com> wrote: > http://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx Hi, Austin. This information is outdated probably. There's a message to set a calendar for MonthCal at least, see: http://msdn.microsoft.com/en-us/library/bb760995%28VS.85%29.aspx Not sure about DateTimePicker, it uses Monthcal internally so a calendar could still be switched. Anyway this won't work on pre-Vista and without a manifest for v6, but you could enable tests using V6 loading helpers that we have already and MCM_SETCALID message, so tests will run on Arabic or some Asian boxes.

2 1

Re: [PATCH 5/5] ddraw: Allow creating back buffer for DirectX 1 interfaces. (try 5, resend)
by testbot＠testbot.winehq.org Aug. 19, 2010

Aug. 19, 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=4557 Your paranoid android. === W2KPROSP4 (32 bit visual) === visual.c:1619: Test failed: Got color 000a246a, expected 00ff0040 or near visual.c:1625: Test failed: Got color 006b8bbd, expected 00ff0080 or near === W98SE (32 bit dsurface) === No test summary line found

1 0

Re: [PATCH 1/5] ddraw/tests: Add test for bad size of surface caps in CreateSurface. (try 5, resend)
by testbot＠testbot.winehq.org Aug. 19, 2010

Aug. 19, 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=4553 Your paranoid android. === W98SE (32 bit dsurface) === No test summary line found

1 0

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

Aug. 19, 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=4552 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout

1 0

Re: ntdll: IMAGE_REL_BASED_HIGH, IMAGE_REL_BASED_HIGH and IMAGE_REL_BASED_HIGHLOW are supported on win64.
by testbot＠testbot.winehq.org Aug. 19, 2010

Aug. 19, 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=4548 Your paranoid android. === W98SE (32 bit rtl) === Failure running script in VM: Exceeded timeout limit of 315 sec

1 0

Re: [PATCH 1/3] gameux: Add definitions of resource identifiers to header file
by Vincent Povirk Aug. 18, 2010

Aug. 18, 2010

> @@ -32,7 +33,6 @@ > > #include "wine/test.h" > > - > static void test_create(BOOL* gameExplorerAvailable, BOOL* gameExplorer2Available) > { > HRESULT hr; Don't put formatting changes in functional patches, please. I think it would be helpful if you passed a string description to your _validate functions so that in case of failure, you can tell where the original call to _validateGameRegistryKey was, instead of just the line containing the ok() call.

3 3

Re: [PATCH 3/3] gameux/tests: verifying registry values created by GameExplorer
by testbot＠testbot.winehq.org Aug. 18, 2010

Aug. 18, 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=4540 Your paranoid android. === W98SE (32 bit gameexplorer) === Failure running script in VM: Exceeded timeout limit of 315 sec === W2KPROSP4 (32 bit gameexplorer) === Timeout === WXPPROSP3 (32 bit gameexplorer) === Timeout

4 5

Re: [PATCH 5/6] gameux: Add initial implementation of IGameExplorer2::CheckAccess method
by Mariusz Pluciński Aug. 18, 2010

Aug. 18, 2010

Hello W dniu 16.08.2010 10:00, Mariusz Pluciński pisze: > --- > dlls/gameux/gameexplorer.c | 7 +++++-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > This is patch I sent to wine-patches yesterday. It was marked as "Pending". I know that what I sent is not proper solution. But as I wrote in FIXME, it's in my opinion impossible to implement it properly, cause from what I know Wine does not support parental control. So, instead of doing real check, my function simply always grants access. My question is: what should I do with it? It cannot be left stub, as there's already bug caused by this (bug #23850). And probably every game which uses Game Explorer will behave that same. Should I write test case to demonstrate that native works that same in most cases?

1 0

Re: [PATCH 1/1] d3dx9: Add tests for FVF <-> declaration conversion.
by Alexandre Julliard Aug. 18, 2010

Aug. 18, 2010

Misha Koshelev <misha680(a)gmail.com> writes: > +#define VDECL_CHECK(fcall) \ > + if(fcall != S_OK) \ > + trace(" Test failed on line #%d\n", __LINE__); > + > +#define VDECL_CHECK_FAIL(fcall) \ > + if(fcall != E_FAIL) \ > + trace(" Test failed on line #%d\n", __LINE__); That's ugly. If the goal is to print the line number, you should pass it to the test function. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] ntdll: Implement RtlIpv4AddressToString / RtlIpv4AddressToStringEx [try 3]
by Alexandre Julliard Aug. 18, 2010

Aug. 18, 2010

Detlef Riekenberg <wine.dev(a)web.de> writes: > + in = *pin; What is this for? -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine64 debugger
by Peter Urbanec Aug. 18, 2010

Aug. 18, 2010

Hi, I'm trying to get a fairly complex Win64 application to work with wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. I thought that I would employ winedbg to help me, but I can't get very far. I don't have any luck with winedbg even on a simple x64 Win32 app. For my simplified test, I used MSVC2005 to generate an x64 executable created from the standard MSVC2005 template Win32 application. This is a simple app that just creates an empty window. As simple as one could get for a Win32 test and it executes correctly when run as "./wine Test1.exe". When I try to execute this test app under winedbg, I get an assert failure: ./wine winedbg Test1.exe WineDbg starting on pid 001a ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode == AddrModeFlat' failed. wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting debugger... Unhandled exception: assertion failed in 64-bit code (0x00007fec2fa657c5). Any ideas about why I can not use winedbg to run Win32 x64 code? Thanks, Peter Urbanec

4 4

Re: [PATCH] advapi32: Add magic codes to HCRYPTKEY and HCRYPTHASH.
by Hans Leidekker Aug. 18, 2010

Aug. 18, 2010

On Wed, 2010-08-18 at 10:14 +1000, Austin Lund wrote: > #define MAGIC_CRYPTPROV 0xA39E741F > +#define MAGIC_CRYPTKEY 0xA39E741F > +#define MAGIC_CRYPTHASH 0xA39E741F The app might pass a crypto handle of the wrong type, so it would be better to use different magic values.

3 4

Re: wldap32: Fix handling of zero timeout value in ldap_search_extW. (try 2)
by testbot＠testbot.winehq.org Aug. 18, 2010

Aug. 18, 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=4530 Your paranoid android. === W2KPROSP4 (32 bit parse) === parse.c:101: Test failed: ldap_search_extW failed 0x00000034 parse.c:105: Test failed: ldap_search_extW failed 0x00000051

2 1

Re: [4/5] msi: Handle signature filenames in short|long notation.
by testbot＠testbot.winehq.org Aug. 18, 2010

Aug. 18, 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=4528 Your paranoid android. === W7PROX64 (32 bit package) === package.c:8348: Test failed: Expected "C:\Program Files\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", got "C:\Program Files (x86)\VMware\VMware Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\" === 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