October 2013 - 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

ntoskrnl.exe: unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces
by Qian Hong Sept. 28, 2018

Sept. 28, 2018

Dear all, While test another online bank with wine ActiveX, I got an unimplemented fuction of ntoskrnl: IoGetDeviceInterfaces, I found it listed in http://source.winehq.org/WineAPI/ntoskrnl.html as a stup, so I can't understand this log: wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 0022), starting debugger... Grateful for any explain! env: wine1.3.12 on Ubuntu 10.04 Here are the steps: 1. install an ActiveX from https://e.bank.ecitic.com/perbank5/plugs/CNCBSecPkg_EN.exe $ rm -rf ~/.wine $ winetricks -q mfc42 $ wine CNCBSecPkg_EN.exe fixme:ole:DllRegisterServer stub fixme:win:DisableProcessWindowsGhosting : stub fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:msg:ChangeWindowMessageFilter c057 00000001 fixme:ole:CoCreateInstance no instance created for interface {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002 fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\\4e2d\4fe1\94f6\884c\7f51\94f6\5b89\5168\63a7\4ef6\\unins000.exe") stub fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 -1: stub! fixme:win:WINNLSEnableIME hUnknown1 0x1011a bUnknown2 0: stub! wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces called at address 0x7b839552 (thread 002b), starting debugger... wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting wine: Call from 0x7b839552 to unimplemented function ntoskrnl.exe.IoGetDeviceInterfaces, aborting 2. open the online bank entry with wine builtin IE, then IE will crash: $ wine iexplore https://e.bank.ecitic.com/perbank5/signIn.do Please checkout the full log here: http://pastebin.com/rbAg7gwj Should I file a singel bug in ntoskrnl component , or separate bugs, one for ntoskrnl and one for the IE crashing? Generalliy what component should I switch while file a bug about IE crashing? Many thanks! -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

5 6

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

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.
by Alexandre Julliard April 23, 2015

April 23, 2015

Qian Hong <qhong(a)codeweavers.com> writes: > --- > dlls/user32/tests/winstation.c | 57 > ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) Can you please fix the test failures introduced by your previous changes first? cf. https://test.winehq.org/data/tests/user32:winstation.html -- Alexandre Julliard julliard(a)winehq.org

3 8

Re: configure: Add -linotify when present, for non-Linux platforms.
by Alexandre Julliard Aug. 23, 2014

Aug. 23, 2014

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > A FreeBSD user ran into this when sys/inotify.h was present via an > extra package and Wine went ahead using that, only to fail at link- > time. We'd want to use kqueue instead on FreeBSD. -- Alexandre Julliard julliard(a)winehq.org

2 1

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

FOSDEM '14 Call for Papers
by Jeremy White Dec. 2, 2013

Dec. 2, 2013

Folks, There will a Wine devroom at FOSDEM '14 on Sunday, February 2, 2014. Last year we had a great time, and I think it was valuable for us to connect with the broader Free software community. I'd like to now invite you to submit proposals for talks. I'd really like to encourage everyone to think of something fun to share with the 5,000 geeks that will be swarming Brussels. If you have an topic you'd like to discuss, or an idea you want to present, please submit it to: https://penta.fosdem.org/submission You will create an account (if you don't have one from a previous year), and select the "Wine devroom" as the track. Please either submit for lengths of 30 or 60 minutes. The deadline for submissions is December 1st. I think it would be great if we branched out a bit, and submitting a crazy off the wall proposal will just burn churn a few electrons. So submit it! For further discussion, please follow up to wineconf(a)winehq.org. Cheers, Jeremy

1 1

WineTestBot status update
by Francois Gouget Nov. 14, 2013

Nov. 14, 2013

We switched to the new WineTestBot near the start of September. Early on it ran into a problem when it was flooded with tests due to the __WINESRC__ tests work and it failed to keep up. The reason is that as time went on the time it takes to get the VMs back to a clean state ready to run the tests (the revert time) kept increasing as can be seen on this graph: http://fgouget.free.fr/wtb/vm1-revtimes.png There one can see the increased activity in september that what was caused by the surge in test patches. But the most remarkable feature is the Windows XP revert times which increase linearly, reaching over 30 minutes. The revert times for the other VMs are much more random but still seem to increase somewhat (1). The reason for the increase is still unknown. The revert time fell down a few times and now I suspect this corresponds to times when the VM was restored from backup. So at the start of October I upgraded to QEMU 1.6.0 and restored all the VMs from backup, hoping this would solve the problem. The revert times did get much better and the WineTestBot now manages to keep up: http://fgouget.free.fr/wtb/vm1-revtimes-new.png The upgrade happened around the 2nd of october and the revert times fell at that point. But looking at more recent data it's clear that the Windows XP revert times are increasing again, while those of the other VMs remain stable (see vm1-revtimes.xls for the raw data). That XP VM is one of the first ones I created, so it probably was created with a pretty old QEMU version. Futhermore it was only an out of the box SP2 and did not have any of the later updates. So I decided to recreate it from scratch, using QEMU 1.6.0, and to add all the other updates as I was at it. And I'm hoping that this time things will be better. That's why this VM is currently in 'maintenance' mode. I also took down the 32-bit Windows 8 VM for maintenance. It too is missing proper updates and the plan is to upgrade it to Windows 8.1. Another issue has been that the tests are running a bit slow, a particular point of pain was msi:action and msi:install which were regularly timing out. See: http://fgouget.free.fr/wtb/runtimes.htm So while rebuilding the Windows XP VM I did some performance tests. That paid off. I found that switching the emulated disk cache mode from writeback to default roughly halves the msi run times: http://fgouget.free.fr/wtb/runtimes2.htm msi:action and msi:install went from an average of 99 and 90 seconds down to 48 and 39 seconds and they are not timing out anymore. The remaining troublesome tests are now ddraw:ddraw{2,4,7}, shell32:shlexec, and winspool.drv:info. I also uncovered two other potential performance issues: * Some VMs have Windows Defender and apparently it was starting a full disk scan as soon as the VM was ready to run the tests. That's clearly not good so I disabled Windows Defender in all VMs. * Most VMs were still using 20% of the CPU when idle. That's fine if only one VM is running but could impact performance (through increased interrupt rates) if many are running at once (like on the WineTestBot). Apparently the culprit is the USB Tablet device that's added by default. So I removed it from all VMs too (and now the mouse is even more laggy than before when I work on the VMs :-( But that does not impact the tests). So there is still a lot of work to do on the WineTestBot, and that's not even counting fixing all the failing tests. (1) It's almost as if the increasing Windows XP revert times were pulling up the other VM revert times. Yet there's only one revert at a given time, so I don't see how this would be possible. (2) Setting the cache mode to writeback was improving the performance quite a bit with the pre-upgrade QEMU version. But obviously it's not true anymore. Another interesting point is that the Virtio mode improves performance by a factor of 10 (down from 450 seconds to 45 in msi:action). Yet Windows 8 posts the fastest times yet in the basic IDE mode (~23 seconds). I couldn't get Windows 8 working with the Virtio disk yet and I have not verified that it's really doing the same set of tests. So that remains to be confirmed. Here is some performance data taken from the Windows XP VM while the TestBot was idle. From it cache=default looks like it's a completely separate mode! msi:action | msi:install | msi:msi 448 460 520| 487 439 | 238 229 VGA, qcow2 ide disk, cache:default 44 45 42 | 47 49 46 | 24 23 21 VGA, qcow2 virtio disk, cache:default 48 45 50 | 47 48 48 | 23 23 24 VMVGA/VGA, qcow2 virtio disk, cache:default 47 46 | 48 46 | 23 22 22 VMVGA, qcow2 virtio disk, cache:default 47 47 | 49 48 | 24 23 VMVGA, raw virtio disk, cache:default 62 67 67 | 64 60 63 | 29 27 27 VMVGA, raw virtio disk, cache:none 111 92 72 113 | 101 101 | 37 37 40 VMVGA, raw virtio disk, cache:writethrough 61 64 53 | 70 59 58 | 36 28 29 VMVGA, raw virtio disk, cache:writeback 46 44 | | VMVGA, raw virtio disk, cache:default 71 55 68 | | VMVGA, raw virtio disk, cache:writeback 65 71 72 69| | VMVGA, raw virtio disk, cache:none 76 118 111 | | VMVGA, raw virtio disk, cache:writethrough 50 48 47 | | VMVGA, raw virtio disk, cache:default And the preliminary Windows 8 performance. I hope it holds up. msi:action | msi:install | msi:msi 23 22 22 | 16 15 16 | 13 13 15 VGA, qcow2 ide disk, cache:default -- Francois Gouget <fgouget(a)codeweavers.com>

6 12

Re: winex11.drv: Add TIMESTAMP to X clipboard TARGETS
by Alexandre Julliard Nov. 1, 2013

Nov. 1, 2013

Andrey Vostrikov <andrey.vostrikov(a)cogentembedded.com> writes: > + else if(event->target == x11drv_atom(TIMESTAMP)) /* Return event timestamp */ > + { > + /* TIMESTAMP selection request */ > + XChangeProperty(display, request, rprop, event->target, > + 32, PropModeReplace, (unsigned char*)&event->time, 1); That's not the correct timestamp. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: [PATCH] quartz/tests: Enable compilation with -D__WINESRC__
by Marvin Nov. 1, 2013

Nov. 1, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3099 Your paranoid android. === w864 (32 bit filtergraph) === filtergraph: unhandled exception c0000005 at 00404347 === w864 (64 bit filtergraph) === filtergraph: unhandled exception c0000005 at 0000000000403DF2

3 2

Re: [PATCH 3/3] opengl32: Use opengl xml registry files.
by Alexandre Julliard Oct. 31, 2013

Oct. 31, 2013

Rico Schüller <kgbricola(a)web.de> writes: > --- > dlls/opengl32/make_opengl | 316 > +++++++++++++++++++--------------------------- > dlls/winemac.drv/opengl.c | 8 +- > dlls/winex11.drv/opengl.c | 8 +- > 3 Dateien geändert, 136 Zeilen hinzugefügt(+), 196 Zeilen entfernt(-) It's not generating quite the same thing as the previous version, and some of the differences look wrong, for instance: -static void WINAPI glBindAttribLocation( GLuint program, GLuint index, const GLchar* name ) { +static void WINAPI glBindAttribLocation( GLhandleARB programObj, GLuint index, const GLcharARB* name ) { -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [PATCH 3/5] ddraw/tests: Use explicit A calls.
by Marvin Oct. 31, 2013

Oct. 31, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3136 Your paranoid android. === w8 (32 bit ddraw7) === ddraw7.c:3055: Test failed: SetDisplayMode failed, hr 0x80004001. === wvista (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w2008s64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w8 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w864 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w864 (32 bit visual) === visual.c:2616: Test failed: unexpected colortable on offscreen surface

1 0

Re: [PATCH 1/5] d3d9/tests: Use color_match() in more places.
by Marvin Oct. 31, 2013

Oct. 31, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3134 Your paranoid android. === w8 (32 bit visual) === visual.c:6533: Test failed: Test blendindices returned color 0x00333333, expected 0x00000000. === w864 (32 bit visual) === visual.c:6533: Test failed: Test blendindices returned color 0x00333333, expected 0x00000000. === w864 (64 bit visual) === visual.c:6533: Test failed: Test blendindices returned color 0x00333333, expected 0x00000000.

1 0

Re: server: Make it possible for WaitCommEvent to detect recursive requests.
by Marvin Oct. 31, 2013

Oct. 31, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3133 Your paranoid android. === w7pro64 (32 bit comm) === comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:870: recovering after WAIT_TIMEOUT... comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1500) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting comm.c:1550: test_AbortWaitCts timeout 500 handle 000000F8 comm.c:1517: Changing CommMask on the fly for handle 000000F8 after timeout 500

1 0

Re: shell32: Check number of bytes returned by ReadFile.
by Dmitry Timoshkov Oct. 31, 2013

Oct. 31, 2013

What is the reason for setting state of this patch as 'pending'? -- Dmitry.

2 1

Re: [PATCH 2/3] winmm/tests: Use the explicit mciSendCommandA() version.
by Marvin Oct. 30, 2013

Oct. 30, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3126 Your paranoid android. === w7pro64 (32 bit mci) === mci.c:988: Test failed: 394ms is not in the expected 400-600ms range mci.c:995: Test failed: 394ms is not even in the expected 400-1000ms range

1 0

Re: [PATCH 1/3] winmm/tests: Avoid duplicating the tested call in the ok() message.
by Marvin Oct. 30, 2013

Oct. 30, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3125 Your paranoid android. === wvista (32 bit mci) === mci.c:987: Test failed: 398ms is not in the expected 400-600ms range mci.c:994: Test failed: 398ms is not even in the expected 400-1000ms range === w864 (32 bit mci) === mci.c:987: Test failed: 398ms is not in the expected 400-600ms range mci.c:994: Test failed: 398ms is not even in the expected 400-1000ms range === w7pro64 (64 bit mci) === mci.c:856: Test failed: mci status mode: playing after play from 0 to 0

1 0

Re: shlwapi: Test and fix the behaviour of the CopyTo method for file sizes not multiple of the internal buffer size, on SHC
by Marvin Oct. 30, 2013

Oct. 30, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3116 Your paranoid android. === wvista (32 bit istream) === istream.c:669: Test failed: SHCreateStreamOnFileEx failed with ret=0x8007007b === w2008s64 (64 bit istream) === istream.c:669: Test failed: SHCreateStreamOnFileEx failed with ret=0x8007007b

1 0

Re: shlwapi: Test and fix the behaviour of the CopyTo method for file sizes not multiple of the internal buffer size, on SHCreateStreamOnFileEx-returned IStreams. (try 4)
by Alexandre Julliard Oct. 30, 2013

Oct. 30, 2013

"David Quintana (gigaherz)" <gigaherz(a)gmail.com> writes: > +{ > + HRESULT ret; > + IStream* src; > + IStream* dst; > + ULARGE_INTEGER count, read, written; > + > + CHAR srcPathA[MAX_PATH]; > + CHAR dstPathA[MAX_PATH]; > + > + WCHAR srcPath[MAX_PATH]; > + WCHAR dstPath[MAX_PATH]; > + > + const CHAR *srcFileName = "SHCreateStreamOnFileEx-src.dat"; > + const CHAR *dstFileName = "SHCreateStreamOnFileEx-dst.dat"; > + > + GetTempPathA(MAX_PATH, srcPathA); > + lstrcatA(srcPathA, srcFileName); > + MultiByteToWideChar(CP_ACP, 0, srcPathA, -1, srcPath, MAX_PATH); > + > + GetTempPathA(MAX_PATH, dstPathA); > + lstrcatA(dstPathA, dstFileName); > + MultiByteToWideChar(CP_ACP, 0, dstPathA, -1, dstPath, MAX_PATH); There's no reason to use such specific file names, just use GetTempFileName or something like that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/5] d3d9/tests: Use explicit A calls.
by Marvin Oct. 30, 2013

Oct. 30, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3115 Your paranoid android. === w864 (32 bit device) === device: unhandled exception c0000005 at 74C714C8 === w864 (64 bit device) === device: unhandled exception c0000005 at 000007F9366B90EB

1 0

Re: [PATCH 2/5] d3d9/tests: Avoid windowsx.h.
by Marvin Oct. 30, 2013

Oct. 30, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3114 Your paranoid android. === w864 (32 bit device) === device: unhandled exception c0000005 at 74C714C8 === w864 (64 bit device) === device: unhandled exception c0000005 at 000007F9366B90EB

1 0

Re: crypt32: Check number of bytes returned by ReadFile and avoid a memory leak on error path.
by Dmitry Timoshkov Oct. 29, 2013

Oct. 29, 2013

This patch is marked as superseded in the tracker but it is not. -- Dmitry.

1 0

Re: [PATCH 3/5] d3d8/tests: Use explicit A calls.
by Marvin Oct. 29, 2013

Oct. 29, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3095 Your paranoid android. === w864 (32 bit device) === device.c:2494: Test failed: Expected foreground window 0004017A, got 0001007A. device.c:3190: Test failed: Expected wndproc 0x40ff80, got 0x40ff80.

1 0

Re: [PATCH 2/5] d3d8/tests: Avoid windowsx.h.
by Marvin Oct. 29, 2013

Oct. 29, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3094 Your paranoid android. === w7pro64 (32 bit device) === device.c:2465: Test failed: Expected foreground window 00030170, got 00060144. === w864 (32 bit device) === device.c:2483: Test failed: Expected foreground window 0004017A, got 0001007A. device.c:3176: Test failed: Expected wndproc 0x40ff80, got 0x40ff80.

1 0

Re: [PATCH 2/5] ddraw/tests: Allow some flags to fail surface creation in test_rt_caps (try 2).
by Marvin Oct. 28, 2013

Oct. 28, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3085 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2.c:3915: Test failed: Test 16: Got unexpected caps 0x22800, expected 0x10026000. ddraw2.c:3915: Test failed: Test 17: Got unexpected caps 0x20800, expected 0x10024000. === w864 (32 bit ddraw1) === ddraw1.c:3289: Test failed: Test 16: Got unexpected caps 0x22800, expected 0x10026000. ddraw1.c:3289: Test failed: Test 17: Got unexpected caps 0x20800, expected 0x10024000.

1 0

Wine Mono 4.5.0 Release
by Vincent Povirk Oct. 28, 2013

Oct. 28, 2013

I have published version 4.5.0 of Wine Mono on sourceforge. It's been a little over a year since the last release, and I'm sorry I waited so long to do it. I have also changed the versioning scheme. The major and minor version numbers will now indicate the highest supported .NET runtime version. The source tarball is at https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.0/wine-mono-4.5… The binary is at https://sourceforge.net/projects/wine/files/Wine%20Mono/4.5.0/wine-mono-4.5… For developers, the source repository is at https://github.com/madewokherd/wine-mono Changes since 0.0.8: * Fixed build on machines using bash as their sh implementation. * .NET Framework directories now include mscorlib.dll (fixes wine bug #31888). * Fixed build on machines running Mac OS X. (Josh DuBois) * Added a security.config file to the .NET 2.0 directory. (Alistair Leslie-Hughes) * Microsoft's Managed C++ compiler sometimes generates broken IL code ending in an unreachable ret statement. This code would be accepted by the .NET runtime but rejected by Mono. Mono is correctly following the spec in this case, but since our goal is compatibility we now accept code that does this. * Building with the -t switch will now build runtime tests. Previously, it only built class library tests. * Added registry keys to indicate the presence of .NET 4.5. * Added user-agent strings to the registry, which allow javascript embedded in web pages to detect .NET. * Updated Mono from 2.11.4 to 3.2.3 plus some additional commits. I'm no longer using Mono's release tags, because they don't seem to help me find revisions that are stable or even buildable. Anyway, here are some highlights of the changes brought in from Mono: * The new 'sgen' garbage collector has been greatly improved and is now the default instead of the old 'boehm' gc, which in our case means it's the only one shipped. It is an improvement over boehm in many ways and should be generally more efficient. * Mono now has support for Portable Class Libraries. * Beginnings of support for System.Windows.Forms.AxHost. (Alistair Leslie-Hughes) * Added support for P/Invoke methods with the thiscall calling convention, which are used by Managed C++ assemblies. * Improved IDispatch interface on managed objects. (Alistair Leslie-Hughes)

3 2

Re: [PATCH 1/5] ddraw/tests: Accept nvidia return values in test_rt_caps (try 2).
by Marvin Oct. 28, 2013

Oct. 28, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3084 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2: unhandled exception c0000005 at 00420E6B

1 0

Re: [Patch]try 2: Bug 33164 - row-resize / col-resize cursor is wrong (Listview)‏
by Vincent Povirk Oct. 28, 2013

Oct. 28, 2013

Your patch is being mangled somehow, even in the attachment. The blank line should contain a space. Also, please use your name transliterated to Latin characters when sending patches.

1 0

Re: shlwapi: Test and fix the behaviour of the CopyTo method for file sizes not multiple of the internal buffer size, on SHCreateStreamOnFileEx-returned IStreams.
by David Quintana (gigaherz) Oct. 28, 2013

Oct. 28, 2013

Hello people, I fixed Vincent's comment, and submitted the new version of the patch. It has been quite a few days already so I'd like to know if there is anything else left to do before the patch is looked at, or if there's just too much going on at the moment, in which case I can re-submit the patch in a few days/weeks, so that it can be looked at properly when there's more time. Vincent Povirk wrote: > We should probably still exit the loop if fewer bytes were read than > requested, rather than do another read at the end of the file.

2 1

Re: [3/8] crypt32: Remove unused variable and avoid a memory leak on error path.
by Alexandre Julliard Oct. 28, 2013

Oct. 28, 2013

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/crypt32/filestore.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/dlls/crypt32/filestore.c b/dlls/crypt32/filestore.c > index 44b9bbb..6084395 100644 > --- a/dlls/crypt32/filestore.c > +++ b/dlls/crypt32/filestore.c > @@ -117,9 +117,8 @@ static BOOL CRYPT_ReadBlobFromFile(HANDLE file, PCERT_BLOB blob) > blob->pbData = CryptMemAlloc(blob->cbData); > if (blob->pbData) > { > - DWORD read; > - > - ret = ReadFile(file, blob->pbData, blob->cbData, &read, NULL); > + ret = ReadFile(file, blob->pbData, blob->cbData, NULL, NULL); > + if (!ret) CryptMemFree(blob->pbData); In general if the read size is not checked that's a bug. -- Alexandre Julliard julliard(a)winehq.org

1 0

[3/8] crypt32: Remove unused variable and avoid a memory leak on error path.
by Thomas Faber Oct. 28, 2013

Oct. 28, 2013

Hi, On 2013-10-28 09:28, Dmitry Timoshkov wrote: > - ret = ReadFile(file, blob->pbData, blob->cbData, &read, NULL); > + ret = ReadFile(file, blob->pbData, blob->cbData, NULL, NULL); the lpNumberOfBytesRead parameter is not optional on Windows for synchronous I/O, so could you keep it please? I've had to add it back in elsewhere to prevent Wine functions from crashing on Win. Thanks! Best, Thomas

1 0

Re: [01/02] d3d9: update locked_rect only if wined3d_surface_map succeeds
by Marvin Oct. 28, 2013

Oct. 28, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=2909 Your paranoid android. === w864 (32 bit device) === device: unhandled exception c0000005 at 740D14C8 === w864 (64 bit device) === device: unhandled exception c0000005 at 000007F84EDD90EB

3 3

Re: d3d9: update locked_rect only if wined3d_surface_map succeeds (try 2)
by Marvin Oct. 28, 2013

Oct. 28, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3077 Your paranoid android. === w864 (32 bit device) === device: unhandled exception c0000005 at 74C714C8 === w864 (64 bit device) === device: unhandled exception c0000005 at 000007F9366B90EB

1 0

Re: msvcrt: add support for _chsize_s (try #3)
by Piotr Caban Oct. 28, 2013

Oct. 28, 2013

Hi, On 10/26/13 04:58, Mike Koss wrote: > This patch adds the _chsize_s() to the mscvrt and corresponding mscvr*s. > Incorporates previous feedback and now includes an updated test file. > > --- > dlls/msvcr100/msvcr100.spec | 2 +- > dlls/msvcr110/msvcr110.spec | 2 +- > dlls/msvcr80/msvcr80.spec | 2 +- > dlls/msvcr90/msvcr90.spec | 2 +- > dlls/msvcrt/file.c | 63 > +++++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/msvcrt.spec | 2 +- > dlls/msvcrt/tests/file.c | 37 ++++++++++++++++++++++++++ > 7 files changed, 105 insertions(+), 5 deletions(-) There're few more issues with this patch: - _chsize_s is not defined in headers (please make sure that your code compiles without warnings) - _chsize_s is not available in some versions of msvcrt.dll, you should load it using GetProcAddress like in other *_s functions tests - the tests are failing on windows, it's probably also caused by lack of _chsize_s header Thanks, Piotr

1 0

Re: [PATCH] wined3d: Use GL_ARB_texture_mirror_clamp_to_edge when available.
by Henri Verbeet Oct. 28, 2013

Oct. 28, 2013

On 21 October 2013 21:20, Rico Schüller <kgbricola(a)web.de> wrote: > As wgl.h is a bit out of date, it still uses the > GL_MIRROR_CLAMP_TO_EDGE_ATI instead of GL_MIRROR_CLAMP_TO_EDGE (which is > only available in headers for OpenGL 4.4). > The wine/wgl.h header is generated from the GL .spec files by dlls/opengl32/make_opengl, so in principle all you'd have to do would be to run that script to get the new constant. Unfortunately Khronos seems to have decided to no longer update the .spec files, since there are shiny new XML files now.

2 2

Re: [PATCH 1/4] comctl32: Set updown control value to min or max in out of range case
by Piotr Caban Oct. 28, 2013

Oct. 28, 2013

On 10/28/13 09:35, Alistair Leslie-Hughes wrote: > On 17/10/2013 1:34 AM, Piotr Caban wrote: >> --- >> dlls/comctl32/updown.c | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> - } else return FALSE; >> + } if ((infoPtr->MaxVal > infoPtr->MinVal && >> infoPtr->CurVal+delta > infoPtr->MaxVal) > ^^^ >> + || (infoPtr->MaxVal < infoPtr->MinVal && >> infoPtr->CurVal+delta < infoPtr->MaxVal)) { >> + delta = infoPtr->MaxVal - infoPtr->CurVal; > > Should the "if" be one its own line or was the else missed? The 'else' was missed. I've sent a fix for it. Thanks, Piotr

1 0

Re: kernel32/tests: Update trace message to report actually used timeout value.
by Marvin Oct. 28, 2013

Oct. 28, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3074 Your paranoid android. === w2008s64 (32 bit comm) === comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:870: recovering after WAIT_TIMEOUT... comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1500) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting comm.c:1551: test_AbortWaitCts timeout 500 handle 000000C4 comm.c:1518: Changing CommMask on the fly for handle 000000C4 after timeout 500

1 0

Re: winspool.drv/tests: Fix the OpenPrinter() tests error reporting.
by Marvin Oct. 27, 2013

Oct. 27, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3070 Your paranoid android. === w864 (32 bit info) === info.c:2923: Test failed: AddJobA() failed le=50 info.c:2929: Test failed: GetJobA() failed le=87 info: unhandled exception c0000005 at 0040B24A === w864 (64 bit info) === info.c:2923: Test failed: AddJobA() failed le=50 info.c:2929: Test failed: GetJobA() failed le=87 info.c:2972: Test failed: AddJobA() failed le=50 info.c:2978: Test failed: GetJobA() failed le=87 info: unhandled exception c0000005 at 00000000004099E0

1 0

Re: Raise the minimum version of FreeBSD to 8.0.
by Frédéric Delanoy Oct. 26, 2013

Oct. 26, 2013

On Sun, Mar 3, 2013 at 12:22 AM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > We've had this as a requirement in the FreeBSD ports for quite a > while (and the Wiki describes some background). > > Gerald > --- > - FreeBSD 7.0 or later > + FreeBSD 8.0 or later > ... > FreeBSD info: > - Wine will generally not work properly on versions before FreeBSD 7.0. > + Wine will generally not work properly on versions before FreeBSD 8.0. You should also change the version in the various README.xx translations (in 'documentation' directory). Frédéric

3 2

Re: ddraw/tests: Fix compilation on systems that don't support nameless unions.
by Marvin Oct. 26, 2013

Oct. 26, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3061 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2: unhandled exception c0000005 at 00420E52 === w864 (32 bit ddraw1) === ddraw1: unhandled exception c0000005 at 0041212F

1 0

Re: shell32/tests: Fix compilation with -D__WINESRC__
by Marvin Oct. 26, 2013

Oct. 26, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3060 Your paranoid android. === w2008s64 (32 bit shlexec) === shlexec.c:1539: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt453.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt453.tmp\test file.shlexec' shlexec.c:2607: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt453.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt453.tmp\test2.exe' shlexec.c:2620: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt453.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt453.tmp\test2.exe' shlexec.c:2632: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt453.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt453.tmp\test2.exe' === w864 (32 bit shlexec) === shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1507: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1539: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc', but key not found or empty shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1507: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1539: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\wt47C9.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\wt47C9.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2060: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt47C8.tmp\wt47C9.tmp" Exec") succeeded: rc=42 === w2008s64 (64 bit shlexec) === shlexec.c:1539: Test failed: argvA4 expected 'C:/Users/ADMINI~1/AppData/Local/Temp/wt2FC.tmp/test file.shlexec', got 'C:\Users\Administrator\AppData\Local\Temp\wt2FC.tmp\test file.shlexec' shlexec.c:2607: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt2FC.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt2FC.tmp\test2.exe' shlexec.c:2620: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt2FC.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt2FC.tmp\test2.exe' shlexec.c:2632: Test failed: longPath expected 'C:\Users\ADMINI~1\AppData\Local\Temp\wt2FC.tmp\test2.exe', got 'C:\Users\Administrator\AppData\Local\Temp\wt2FC.tmp\test2.exe' === w864 (64 bit shlexec) === shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc") WaitForSingleObject returned 258 shlexec.c:1507: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc") failed: rc=33 err=2 shlexec.c:1539: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc', but key not found or empty shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.shlexec.noassoc") WaitForSingleObject returned 258 shlexec.c:1507: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.shlexec.noassoc") failed: rc=33 err=2 shlexec.c:1539: Test failed: argvA4 expected 'C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.shlexec.noassoc', but key not found or empty shlexec.c:138: Test failed: ShellExecute(verb="", file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\wt4598.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:138: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\wt4598.tmp" Exec") WaitForSingleObject returned 258 shlexec.c:2060: Test failed: ShellExecute(file="C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\test file.noassoc", params="shlexec "C:\Users\winetest\AppData\Local\Temp\wt4597.tmp\wt4598.tmp" Exec") succeeded: rc=42 === w864 (64 bit shlfolder) === shlfolder: unhandled exception c0000005 at 000007F93936ABDC

1 0

Re: msvcrt: add support for _chsize_s (try #3)
by Marvin Oct. 25, 2013

Oct. 25, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3053 Your paranoid android. === wvista (32 bit file) === Failure running script in VM: timed out waiting for the child process === w2008s64 (32 bit file) === Failure running script in VM: timed out waiting for the child process === w7pro64 (32 bit file) === file.c:1574: Test failed: Wrong file size Timeout === w864 (32 bit file) === Failure running script in VM: timed out waiting for the child process

1 0

Re: [PATCH 1/2] advapi32: HKCR merge: foundation
by Alexandre Julliard Oct. 25, 2013

Oct. 25, 2013

George Stephanos <gaf.stephanos(a)gmail.com> writes: > @@ -224,13 +248,138 @@ static NTSTATUS open_key( HKEY *retkey, ACCESS_MASK access, OBJECT_ATTRIBUTES *a > > } > > +static LSTATUS create_hkcr_struct( HKEY *hkey, opened_hkcr_t **hkcr ) > +{ > + UINT_PTR handle = nb_hkcr_handles, i; > + LSTATUS ret = ERROR_SUCCESS; > + > + EnterCriticalSection( &hkcr_handles_cs ); > + > + for (i = 0; i < nb_hkcr_handles; i++) > + { > + if (!hkcr_handles[i]) > + { > + handle = i; > + break; > + } > + } You need some sort of free list instead of a linear search. Also you can probably avoid one level of pointers and store objects directly. Returning a pointer to the object outside of the critical section is not a good idea. > +static HKEY resolve_hkcr( HKEY hkey ) > +{ > + HKEY ret; > + UINT_PTR idx = (UINT_PTR)hkey >> 2; > + opened_hkcr_t *hkcr; > + if (idx <= nb_hkcr_handles) > + { > + EnterCriticalSection( &hkcr_handles_cs ); The count needs to be protected by the critical section too. Also please write a better subject line for the commit. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH 1/5] ddraw/tests: Accept nvidia return values in test_rt_caps.
by Henri Verbeet Oct. 25, 2013

Oct. 25, 2013

On 25 October 2013 00:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > --- > dlls/ddraw/tests/ddraw2.c | 26 ++++++++++++++++++++++++-- > dlls/ddraw/tests/ddraw7.c | 27 ++++++++++++++++++++++++--- > 2 files changed, 48 insertions(+), 5 deletions(-) > > diff --git a/dlls/ddraw/tests/ddraw2.c b/dlls/ddraw/tests/ddraw2.c > index f4702f1..801135d 100644 > --- a/dlls/ddraw/tests/ddraw2.c > +++ b/dlls/ddraw/tests/ddraw2.c > @@ -3663,6 +3663,7 @@ static void test_rt_caps(void) > DWORD caps_out; > HRESULT create_device_hr; > HRESULT set_rt_hr; > + HRESULT alternative_set_rt_hr; > } > test_data[] = > { This kind of construction doesn't generally make me very happy, but on the other hand I'm not sure I can come up with something that's much better either. I do think we should mark the alternative results as broken. Some of the Evergreen results in later patches in this series are a bit surprising to me. I wrote the test on Windows 7 / AMD Cayman, which should be very close to Evergreen hardware.

2 2

Re: [PATCH 2/5] ddraw/tests: Allow some flags to fail surface creation in test_rt_caps.
by Marvin Oct. 25, 2013

Oct. 25, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3031 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2.c:3915: Test failed: Test 16: Got unexpected caps 0x22800, expected 0x10026000. ddraw2.c:3915: Test failed: Test 17: Got unexpected caps 0x20800, expected 0x10024000. === w864 (32 bit ddraw1) === ddraw1.c:3289: Test failed: Test 16: Got unexpected caps 0x22800, expected 0x10026000. ddraw1.c:3289: Test failed: Test 17: Got unexpected caps 0x20800, expected 0x10024000.

2 1

Re: [3/4] kernel32/tests: WaitCommEvent may sometimes return immediately on a busy system when write operation to a COM-port
by Marvin Oct. 24, 2013

Oct. 24, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3039 Your paranoid android. === w2008s64 (64 bit comm) === comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1000) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting === w7pro64 (64 bit comm) === comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:870: recovering after WAIT_TIMEOUT... comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1000) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting comm.c:1552: test_AbortWaitCts timeout 500 handle 0000000000000068 comm.c:1519: Changing CommMask on the fly for handle 0000000000000068 after timeout 500

1 0

Re: [2/4] kernel32/tests: Increase the timeout for completion of write to a COM-port.
by Marvin Oct. 24, 2013

Oct. 24, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3038 Your paranoid android. === w2008s64 (64 bit comm) === comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1000) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting === w7pro64 (64 bit comm) === comm.c:859: Test failed: WaitCommEvent failed with a timeout comm.c:870: recovering after WAIT_TIMEOUT... comm.c:880: Test failed: WaitCommEvent error 0 comm.c:881: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:885: WaitCommEvent for EV_TXEMPTY took 1513 ms (timeout 1000) comm.c:886: Test failed: WaitCommEvent used 1513 ms for waiting comm.c:1552: test_AbortWaitCts timeout 500 handle 0000000000000068 comm.c:1519: Changing CommMask on the fly for handle 0000000000000068 after timeout 500

1 0

Re: [PATCH 5/5] d3d8/tests: Port z_range_test to d3d8.
by Marvin Oct. 24, 2013

Oct. 24, 2013

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 https://newtestbot.winehq.org/JobDetails.pl?Key=3034 Your paranoid android. === w864 (32 bit visual) === visual.c:1619: Test failed: Failed to create vertex shader, hr 0x8876086c. visual.c:1649: Test failed: Failed to delete vertex shader, hr 0x8876086c. visual.c:1657: Test failed: Z range failed: Got color 0x00ffffff, expected 0x00ff0000. visual.c:1664: Test failed: Z range failed: Got color 0x00ffffff, expected 0x000000ff. visual.c:1666: Test failed: Z range failed: Got color 0x00ffffff, expected 0x000000ff.

1 0