April 2014 - Wine-Devel - list.winehq.org

Re: [PATCH] vbscript: Implemented IsNumeric
by Marvin April 23, 2014

April 23, 2014

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://testbot.winehq.org/JobDetails.pl?Key=6508 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvista (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w864 (32 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found === w864 (64 bit) === No test summary line found

1 0

Wine Talks at LinuxTag 2014
by Michael Stefaniuc April 22, 2014

April 22, 2014

Hello guys, here are the two Wine related talks that got accepted for LinuxTag 2014: Pipelight: Windows Plugins in Linux Browsers by Michael Müller (Pipelight-Team), Sebastian Lackner (Pipelight-Team), Erich Hoover (Pipelight-Team) Thursday, 8th May, Stage E, 18:30-19:15 CEST (UTC+2) http://www.linuxtag.org/2014/de/programm/vortragsdetails/?eventid=1342 Is Wine Still Relevant? - A Status Update on Wine by Michael Stefaniuc (Wine Project) Friday, 9th May, Stage C, 16:00-16:45 CEST (UTC+2) http://www.linuxtag.org/2014/de/programm/vortragsdetails/?eventid=2532 bye michael

1 0

Re: [patch]Japanese Translation for Wine 1.7.17(try 2)
by Akihiro Sagawa April 22, 2014

April 22, 2014

On Mon, 21 Apr 2014 05:56:33 -0400 (EDT), Toshiaki Hirose wrote: > From ce340a6aff2f17d41b35c217692ece6abb17d88e Mon Sep 17 00:00:00 2001 > From: Toshiaki Hirose <t_hirose(a)aol.com> > Date: Sun, 20 Apr 2014 13:34:34 +0900 > Subject: [PATCH] Japanese Translation for Wine 1.7.17 > > --- > po/ja.po | 59 ++++++++++++++++++++++++++++++++++++----------------------- > 1 file changed, 36 insertions(+), 23 deletions(-) Hello Hirose-san, Welcome to Wine development! I'm one of Japanese translation contributors of Wine. About your patch, it looks good at first glance. But, I found some (nit-picking) issues on that. Could you read the comments and give us your feedback? > @@ -1,18 +1,20 @@ > # Japanese translations for Wine > +# Toshiaki Hirose <t_hirose(a)aol.com>, 2014. I'm not sure this change is needed. Please keep it simple. > -"PO-Revision-Date: 2013-12-05 20:08+0900\n" > -"Last-Translator: Akira Nakagawa <matyapiro31(a)yahoo.co.jp>\n" > -"Language-Team: 日本語 <>\n" > +"PO-Revision-Date: 2014-04-20 11:53+0900\n" > +"Last-Translator: Toshiaki Hirose <t_hirose(a)aol.com>\n" > +"Language-Team: 日本語 < kobayashi-ubuntu(a)junkobayashi.jp >\n" The Language Team's e-mail address seems not valid, i.e. Jun Kobayashi is a male Japanese name. Did you get his approval? > "Language: Japanese\n" > "MIME-Version: 1.0\n" > "Content-Type: text/plain; charset=UTF-8\n" > "Content-Transfer-Encoding: 8bit\n" > "Plural-Forms: nplurals=1; plural=0;\n" > +"X-Generator: Gtranslator 2.91.6\n" I'm not sure about this, too. > @@ -11682,54 +11684,65 @@ msgid "" > " [/n] Do not call DllRegisterServer. This option must be used with [/i].\n" > "\n" > msgstr "" > +"用法:\n" > +" regsvr32 [/u] [/s] [/n] [/i[:cmdline]] Dll名\n" > +"\n" > +"オプション:\n" > +" [/u] サーバを登録消去\n" Please use a sentence form here, e.g. 「～消去します。」. Because original text is sentence. > @@ -11682,54 +11684,65 @@ msgid "" > " [/n] Do not call DllRegisterServer. This option must be used with [/i].\n" > "\n" > msgstr "" > +"用法:\n" Please translate `Usage' into 「使い方」 to keep consistency with other translations. For instance, see hostname.rc:30. > +" regsvr32 [/u] [/s] [/n] [/i[:cmdline]] Dll名\n" > +"\n" > +"オプション:\n" > +" [/s] サイレントモード (一切のメッセージが表示されません)。\n" Please insert a space character between adopted compound word, i.e. サイレントモード. This point based on MS's Japanese style guide [1] at the last line in p.19. [1] http://download.microsoft.com/download/B/3/4/B34F7185-AFCA-4846-8FBF-672A1B… > +" [/i] DllInstallを呼び出し、追加の[cmdline]をパスします。\n" I think 「パス」 is not commonly used in this case. > +"\t[/u]を付けて使った場合、DllInstallはアンインストールモードで呼び出されま" > +"す。 \n" Same as 「サイレントモード」 case. (compound word) > #: regsvr32.rc:41 > msgid "" > "regsvr32: Invalid or unrecognized switch [%1]\n" > "\n" > msgstr "" > +"regsvr32: 無効な選択または認識できない選択です[%1]\n" > +"\n" In my opinion, 「選択」 is not widely used in this situation. How about to use 「スイッチ」 instead? > #: regsvr32.rc:43 > msgid "regsvr32: %1 not implemented in DLL '%2'\n" > -msgstr "" > +msgstr "regsvr32: %1はDLL '%2'内で実装されていません。\n" Can you remove the last 「。」? As original text doesn't have full-stop character. > #: regsvr32.rc:44 > #: regsvr32.rc:45 > #: regsvr32.rc:46 > #: regsvr32.rc:47 > #: regsvr32.rc:48 > #: regsvr32.rc:49 > #: regsvr32.rc:50 > #: regsvr32.rc:51 Same as above. If you would like to contact me, please e-mail to me. Of course, I can understand Japanese. However, in wine development, I prefer open discussion on wine-devel mailing list. Regards, Akihiro Sagawa

1 0

Re: mshtml: Added IHTMLTable::width property implementation.
by Jacek Caban April 21, 2014

April 21, 2014

Hi Zhenbo, It looks better now. On 04/19/14 03:38, Zhenbo Li wrote: > @@ -395,15 +422,60 @@ static HRESULT WINAPI HTMLTable_get_rows(IHTMLTable *iface, IHTMLElementCollecti > static HRESULT WINAPI HTMLTable_put_width(IHTMLTable *iface, VARIANT v) > { > HTMLTable *This = impl_from_IHTMLTable(iface); > - FIXME("(%p)->(%s)\n", This, debugstr_variant(&v)); > - return E_NOTIMPL; > + nsAString val; > + HRESULT hres; > + nsresult nsres; > + > + TRACE("(%p)->(%s)\n", This, debugstr_variant(&v)); > + hres = var2str(&val, &v); > + > + if (hres != S_OK){ > + ERR("Set Width(%s) failed when initializing a nsAString!\n", > + debugstr_variant(&v)); > + nsAString_Finish(&val); val is not initialized here, so you shouldn't call nsAString_Finish on it. > + return hres; > + } > + > + nsres = nsIDOMHTMLTableElement_SetWidth(This->nstable, &val); > + nsAString_Finish(&val); > + > + if (NS_FAILED(nsres)){ > + ERR("Set Width(%s) failed!\n", debugstr_variant(&v)); > + return E_FAIL; > + } > + > + return S_OK; > } > > static HRESULT WINAPI HTMLTable_get_width(IHTMLTable *iface, VARIANT *p) > { > HTMLTable *This = impl_from_IHTMLTable(iface); > - FIXME("(%p)->(%p)\n", This, p); > - return E_NOTIMPL; > + nsAString val; > + nsresult nsres; > + DOUBLE width; > + const PRUnichar *str; > + > + TRACE("(%p)->(%p)\n", This, p); > + nsAString_Init(&val, NULL); > + nsres = nsIDOMHTMLTableElement_GetWidth(This->nstable, &val); > + if (NS_FAILED(nsres)){ > + ERR("Get Width(%s) failed!\n", debugstr_variant(p)); > + nsAString_Finish(&val); > + return E_FAIL; > + } > + > + nsAString_GetData(&val, &str); > + nsres = VarR8FromStr(str, 0, 0, &width); > + if (nsres == S_OK){ > + V_VT(p) = VT_I4; > + V_I4(p) = (LONG)width; > + } else { /* Symbols are in this string */ > + V_VT(p) = VT_BSTR; > + V_BSTR(p) = SysAllocString(str); > + if (!V_BSTR(p)) > + return E_OUTOFMEMORY; > + } > + return S_OK; > } > > static HRESULT WINAPI HTMLTable_put_height(IHTMLTable *iface, VARIANT v) > diff --git a/dlls/mshtml/tests/dom.c b/dlls/mshtml/tests/dom.c > index 23677f4..10aca6c 100644 > --- a/dlls/mshtml/tests/dom.c > +++ b/dlls/mshtml/tests/dom.c > @@ -5721,6 +5721,25 @@ static void _test_table_cell_spacing(unsigned line, IHTMLTable *table, const cha > VariantClear(&v); > } > > +#define cmp_length(a,b) _cmp_length(__LINE__,a,b) > +static void _cmp_length(unsigned line, VARIANT got, const char * exstr) > +{ > + static char buf[64]; > + ok_(__FILE__,line) (V_VT(&got)==VT_BSTR || V_VT(&got)==VT_I4, > + "V_VT is %hu, expected VT_BSTR(%hu) or VT_I4(%hu)\n", > + V_VT(&got), VT_BSTR, VT_I4); Please make it stricter and allow only one, exactly expected in given case, type. According to my quick tests (as I mentioned earlier), it's always VT_BSTR. Did you ever see it being VT_I4 in real Windows? If my testing is tight, this test hides a problem with your getter implementation. Cheers, Jacek

2 1

Re: [PATCH 1/4] msvcrt: Don't raise exception in _invalid_parameter (try2)
by Marvin April 21, 2014

April 21, 2014

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://testbot.winehq.org/JobDetails.pl?Key=6473 Your paranoid android. === wxppro (32 bit misc) === misc.c:335: Test failed: buf = C:\Documents and Settings\winetest\My Documents\msvcrt_test.exe misc popen misc.c:338: Test failed: _pclose returned 1, expected 0x37

2 1

The (broken) state of the WineTestBot
by Francois Gouget April 21, 2014

April 21, 2014

My apologies for this last bout of WineTestBot brokenness. It all started when the VM host froze late last Friday and could not be remotely rebooted. So Newman power-cycled it Monday morning. He also suggested upgrading the kernel in the hope that this would avoid further crashes which I agreed to. Then I decided to upgrade to QEMU 1.7 in the hope of fixing the Dr6 ntdll:exception failures, or at least be in a better position to do so. Of course that entails redoing all the live VM snapshots (1) but I was prepared to do so. Then things went south. The issues ---------- I initially ran into some SELinux incompatibilities and then into QEMU/Libvirt incompatibilities (2). Then the VMs were suspending after a few seconds which turned out to be because the disk was full. My fault: I keep too many VM backups so the new VM backups I created finished filling it. That corrupted some VMs which, ironically, I was able to restore from backup after deleting older backups. Now the host now has a sane amount of free disk space and monitor it closely. But the real problem is that now the VMs get corrupted after a bit of use. This manifests through a couple of symptoms: * Sometimes the build VM will detect EXT4 filesystem corruption, remount '/' as read-only and obviously stop working properly. * Sometimes no filesystem corruption is detected but the content of files gets corrupted. For instance this is what caused all the 'Missing build status line' errors when half of the WineTestBot Build.pl sscript got lost. I suspect this also caused a round of build failures related to memcmp() being missing. * Sometimes the wtbbuild ends up at the grub prompt and complains that it cannot find the filesystem. Since these are live snapshots this is presumably preceded by a crash+reboot of the guest. * Sometimes, after qemu has been properly stopped, a 'qemu-img check' finds a lot of errors. Sometimes not despite the VM being broken. * The Windows 2000 VM also sometimes goes south: it resets and fails to reboot complaining some checksum is corrupted (probably that of the Windows boot loader). Of course QEMU behaves while I'm updating a VM's live snapshot. It's only after I've spent time doing so and creating a backup that it break the VM (thus also casting doubt into the trustworthiness of the new backup). Further compounding the problems, once the WineTestBot is on a tear compiling a bunch of patches on the lone build VM it's unstoppable (3). It also tends to get stuck whenever I restart libvirt or the VM host (a known issue I was working on before this episode). The strange thing is that QEMU 1.7 seems to work fine on my test environment. However it now appears that QEMU has at least three very different codepaths: * User-mode emulation which is slow and should not be used. * kvm_intel, uses the Intel VMX instructions, is used on my (Intel) test environment, has the icebp bug, but seems to otherwise be reliable. * kvm_amd, uses the AMD SVM instructions, is used by the WineTestBot's (AMD) VM host, has the Dr6 bug, and has been unreliable since last weekend. As kvm_adm and kvm_intel are kernel modules, the kernel version might actually be more important than the QEMU one. Indeed my latest tests seem to indicate that reverting the kernel from the 3.13 to 3.2.0 fixes the VM corruption issues (I also tested 3.14rc7 which did not help). A corrollary is that any QEMU tests I can do in my home environment are likely to be poor predictors for what will happen on the production VM host. Indeed it's because QEMU 1.7.0 seems to work fine here that I decided to upgrade the VM host. Short term goal --------------- Restore the WineTestBot to a working state! The current hope is that just reverting to a pre-3.13 kernel, maybe 3.2.0 will do the trick. That would make it possible to stick with QEMU 1.7.0 (Debian 7.0 (Stable/Wheezy) has 1.1.2 which is really too old but Wheezy-Backports has moved on to 1.7.0 so there's no easily accessible 1.6.0 packages to go back to). Longer term goals ----------------- * Solve the VM host crashes. The memory has been tested quite extensively already, and I did a badblocks pass on the hard-drive. Neither found anything. I could then test the process using PrimeNet. but the MRTG graphs did not indicate a tendency to overheat or other such problems. It now seems the crashes may be caused by the 3.2.0 kernel, and probably specifically by the kvm/kvm_amd modules. So finding a more recent kernel that actually works might help. * While I hope the VM host will never crash again, it would be nice to be able to remotely power-cycle it. * It will also be necessary to fix the stability issues in the 3.13 and 3.14 kvm_amd module. However given that I don't have an AMD box at hand and already way too many other things to do I don't see how that's going to happen. Maybe through a bug report once I get a better handle on this. Still the VM host cannot remain stuck on 3.2.0 indefinitely. * Given that on AMD the Dr6 bug still seems to be present in QEMU 2.0/Linux 3.13, it still needs to be fixed. (And the icebp one on Intel would be nice too). * Fix the mysterious 'network timeout' errors we get while waiting for a WineTest task to complete. Unfortunately the first set of patches to tackle them were not really conclusive. So maybe switch to plan B, i.e. blindly reconnect to work around them. That would be quite unsatisfying though. * Then resume work on making the WineTestBot Engine (more) resilient to network outages and VM host crashes. I started patches for that but working on them it became clear that this was entangled with proper handling and diagnostics after 'network timeout' errors. * Then resume work on all the other features and bugs of the WineTestBot. (1) QEmu 1.7.0 cannot restore a 1.6.0 live snapshot made in qemu-system-x86_64 https://bugs.launchpad.net/qemu/+bug/1259499 (2) A known issue caused by QEMU changing the 'qemu-system-x86_64 -cpu help' output format which is parsed by Libvirt to figure out which kinds of CPUs can be emulated. (3) Bug 35946 - Cannot mark a VM for maintenance if it is running a task http://bugs.winehq.org/show_bug.cgi?id=35946 -- Francois Gouget <fgouget(a)codeweavers.com>

3 5

Re: msvcrt: Remove wine-specific exports
by Alexandre Julliard April 21, 2014

April 21, 2014

Piotr Caban <piotr(a)codeweavers.com> writes: > --- > dlls/msvcr100/msvcr100.spec | 4 ++-- > dlls/msvcr110/msvcr110.spec | 4 ++-- > dlls/msvcr70/msvcr70.spec | 4 ++-- > dlls/msvcr71/msvcr71.spec | 4 ++-- > dlls/msvcr80/msvcr80.spec | 4 ++-- > dlls/msvcr90/msvcr90.spec | 4 ++-- > dlls/msvcrt/mbcs.c | 7 ++---- > dlls/msvcrt/msvcrt.spec | 53 > --------------------------------------------- > dlls/msvcrt/string.c | 6 +++-- > 9 files changed, 18 insertions(+), 72 deletions(-) It doesn't work: ../../../tools/runtest -q -P wine -T ../../.. -M msvcrt.dll -p msvcrt_test.exe.so string && touch string.ok wine: Unhandled exception 0xc0000417 in thread 62 at address 0x7b83aa0e (thread 0062), starting debugger... Unhandled exception: 0xc0000417 in 32-bit code (0x7b83aa0e). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7b83aa0e ESP:0032f9a4 EBP:0032fa18 EFLAGS:00000246( - -- I Z- -P- ) EAX:7b826b79 EBX:7b8b5dac ECX:00000000 EDX:00000000 ESI:c0000417 EDI:00000000 Stack dump: 0x0032f9a4: 0032f9c4 009d0152 7bcc4514 c0000417 0x0032f9b4: 00000001 00000000 7b83aa0e 00000000 0x0032f9c4: 0032fa40 687415e1 68718cdf 00b100b0 0x0032f9d4: 00b300b2 039c00b4 681c8cc0 00000001 0x0032f9e4: 687415e0 0032fa28 6802d1bc 00000001 0x0032f9f4: 687415e0 68718cdf 68718c75 0032fa40 Backtrace: =>0 0x7b83aa0e RaiseException+0x5e(code=<couldn't compute location>, flags=<couldn't compute location>, nbargs=<couldn't compute location>, args=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/except.c:84] in kernel32 (0x0032fa18) 1 0x686c9b5d MSVCRT__invalid_parameter+0x8c() in msvcrt (0x0032fa78) 2 0x686da0c8 MSVCRT_memcpy_s+0x87(dest=0x6869112c, numberOfElements=0x8, src=0x68688415, count=0xf) [/home/julliard/wine/wine/dlls/msvcrt/heap.c:645] in msvcrt (0x0032fac8) 3 0x6865d547 test_memcpy_s+0x1f6() [/home/julliard/wine/wine/dlls/msvcrt/tests/string.c:581] in msvcrt_test (0x0032fb48) 4 0x686686c6 func_string+0xe55() [/home/julliard/wine/wine/dlls/msvcrt/tests/string.c:2737] in msvcrt_test (0x0032fd48) 5 0x6862b021 main+0x2f0(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/msvcrt/tests/../../../include/wine/test.h:584] in msvcrt_test (0x0032fe18) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: typo fixes - rebased - fixed
by Marvin April 20, 2014

April 20, 2014

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://testbot.winehq.org/JobDetails.pl?Key=6455 Your paranoid android. === w7u (32 bit msg) === msg.c:12058: Test failed: unexpected hwnd 0017014A msg.c:12080: Test failed: bad time 310a2/310b2

1 0

Re: typo fixes - rebased - fixed
by Marvin April 20, 2014

April 20, 2014

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://testbot.winehq.org/JobDetails.pl?Key=6454 Your paranoid android. === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w864 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A === w864 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A

1 0

Re: [PATCH 2/6] wined3d: Pass the volume texture level to the client libraries.
by Henri Verbeet April 20, 2014

April 20, 2014

On 17 April 2014 15:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > The goal is to remove volumes and surfaces from the wined3d public API. > This extra information is needed for the transition. We got rid of this not too long ago, adding it back doesn't sound very attractive. If you really need a way to find out a volume's level, I'd prefer wined3d_volume_get_level() instead, mostly because it doesn't need changes in every D3D library. I'm not convinced this is really necessary though, or that starting in d3d9 as opposed to wined3d with this is necessarily the right approach.

2 5

Re: typo fixes - rebased - fixed
by Marvin April 20, 2014

April 20, 2014

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://testbot.winehq.org/JobDetails.pl?Key=6447 Your paranoid android. === w7u (32 bit msg) === msg.c:12058: Test failed: unexpected hwnd 00070140 msg.c:12080: Test failed: bad time 3118c/3119c

1 0

Re: typo fixes - rebased - fixed
by Marvin April 20, 2014

April 20, 2014

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://testbot.winehq.org/JobDetails.pl?Key=6446 Your paranoid android. === w2008s64 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w7u (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w864 (32 bit moniker) === moniker: unhandled exception c0000005 at 004256A9 === w2008s64 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A === w864 (64 bit moniker) === moniker: unhandled exception c0000005 at 000000000042024A

1 0

Re: typo fixes - rebased - fixed
by Nikolay Sivov April 20, 2014

April 20, 2014

> - * INT oDefautlValue[nrargs]; > + * INT oDefaultlValue[nrargs]; This is wrong.

1 0

Re: [PATCH 10/10] vbscript/tests: Added tests for convert functions
by Marvin April 19, 2014

April 19, 2014

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://testbot.winehq.org/JobDetails.pl?Key=6431 Your paranoid android. === w7u (32 bit run) === run.c:973: Test failed: api.vbs: L"CStr(CDate(1.5)) = 1899/12/31 12:00:00" run.c:973: Test failed: api.vbs: L"CStr(CDate(-1.5)) = 1899/12/29 12:00:00"

1 0

Re: mshtml: Added IHTMLTable::bgColor property implementation.
by Nikolay Sivov April 19, 2014

April 19, 2014

On 4/6/2014 18:48, Zhenbo Li wrote: > try 2: > Don't free a string too early. > > --- > dlls/mshtml/htmltable.c | 41 +++++++++++++++++++++++++++++++++++++---- > dlls/mshtml/tests/dom.c | 35 +++++++++++++++++++++++++++++++++++ > 2 files changed, 72 insertions(+), 4 deletions(-) > Also please check for variant_to_nscolor() return value.

2 1

Wine test week 2 - nice apparent progress
by Jeremy White April 18, 2014

April 18, 2014

My script results are here: http://www.winehq.org/~jwhite/ebd5f96aea22.html We had a lot of tests that had failed on Windows 7 ultimate that we now skip; that has reduced the number of apparent failures on the new testbot machines down under 20. We've also had some nice work from folks like Dmitry (thanks!). I'll keep annotating the failures until they all have notes. I do have one that could use a sucker^H^H^H^H^H^Hvolunteer: http://test.winehq.org/data/ebd5f96aea22f4093d4ceb109bdead2657666c57/xp_new… I had asked Misha Koshelev (the apparent last person to meaningfully change those tests) if he wanted to look into it, but he's in the middle of a medical internship working brutal hours, so he demurred. Cheers, Jeremy

6 7

Re: [PATCH 1/6] d3d9: Retrieve the volume description from the container.
by Henri Verbeet April 18, 2014

April 18, 2014

On 17 April 2014 15:47, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > --- > dlls/d3d9/texture.c | 20 +++++++++++++------- > 1 file changed, 13 insertions(+), 7 deletions(-) > I suppose this works, but I don't think it's really necessary. At some point wined3d_texture_get_sub_resource() will go away of course, but I don't think there's a reason we can't e.g. have a wined3d_resource_get_sub_resource_desc(), or alternatively just store the information on d3d9 volume creation.

2 1

Re: [wined3d] Add DF16 and DF24 formats
by Henri Verbeet April 18, 2014

April 18, 2014

On 18 April 2014 16:46, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > + {WINED3DFMT_DF16, 0, 0, 0, 0, 16, 24, 8, 0, 0, 0, 0}, > + {WINED3DFMT_DF24, 0, 0, 0, 0, 24, 24, 8, 0, 0, 0, 0}, This is pretty much just wrong. > + {WINED3DFMT_DF16, GL_DEPTH24_STENCIL8_EXT, GL_DEPTH24_STENCIL8_EXT, 0, > + GL_DEPTH_STENCIL_EXT, GL_UNSIGNED_INT_24_8_EXT, 0, > + WINED3DFMT_FLAG_TEXTURE | WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING > + | WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL, WINED3DFMT_FLAG_STENCIL is suspicious here, since afaik these are depth only formats. Note that you can't expose these formats without also implementing "Fetch-4", since that's implied by DF24. See also http://developer.amd.com/wordpress/media/2012/10/Advanced-DX9-Capabilities-…. Does this patch help any application?

2 1

AW: [PATCH 2/2] user32: add tests for valid cbSize in GetMonitorInfoA
by siro＠das-labor.org April 18, 2014

April 18, 2014

should I iterate over all possible values other than sizeof(MONITORINFO) and sizeof(MONITORINFOEXA)‎ ? Kind Regards, Patrick Rudolph Originalnachricht Von: Alexandre Julliard Gesendet: Freitag, 18. April 2014 13:47 An: Patrick Rudolph Cc: wine-devel(a)winehq.org Betreff: Re: [PATCH 2/2] user32: add tests for valid cbSize in GetMonitorInfoA Patrick Rudolph <siro(a)das-labor.org> writes: > @@ -362,6 +363,21 @@ static void test_monitors(void) > monitor = pMonitorFromRect( &rc, MONITOR_DEFAULTTONULL ); > } > > + /* sanity check */ > + monitor = pMonitorFromRect( &rc, MONITOR_DEFAULTTONEAREST ); > + mi.cbSize = sizeof(mi); > + ret = pGetMonitorInfoA( monitor, &mi ); > + ok( ret, "GetMonitorInfo failed\n" ); > + > + miex.cbSize = sizeof(miex); > + ret = pGetMonitorInfoA( monitor, (LPMONITORINFO)&miex ); > + ok( ret, "GetMonitorInfo failed\n" ); > + > + /* specify invalid cbSize */ > + mi.cbSize = 0xdeadbeef; > + ret = pGetMonitorInfoA( monitor, &mi ); > + ok( !ret, "GetMonitorInfo succeded\n" ); That's not a very convincing test. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [2/5] user32: Add test calling EndMenu from WM_ENTERMENULOOP.
by Alexandre Julliard April 18, 2014

April 18, 2014

Vincent Povirk <madewokherd(a)gmail.com> writes: > @@ -14525,6 +14582,7 @@ START_TEST(msg) > test_layered_window(); > test_TrackPopupMenu(); > test_TrackPopupMenuEmpty(); > + test_TrackPopupMenuAbort(); There's no need to write a separate function for each test, you could do them all as part of the main popup menu test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] user32: add tests for valid cbSize in GetMonitorInfoA
by Alexandre Julliard April 18, 2014

April 18, 2014

Patrick Rudolph <siro(a)das-labor.org> writes: > @@ -362,6 +363,21 @@ static void test_monitors(void) > monitor = pMonitorFromRect( &rc, MONITOR_DEFAULTTONULL ); > } > > + /* sanity check */ > + monitor = pMonitorFromRect( &rc, MONITOR_DEFAULTTONEAREST ); > + mi.cbSize = sizeof(mi); > + ret = pGetMonitorInfoA( monitor, &mi ); > + ok( ret, "GetMonitorInfo failed\n" ); > + > + miex.cbSize = sizeof(miex); > + ret = pGetMonitorInfoA( monitor, (LPMONITORINFO)&miex ); > + ok( ret, "GetMonitorInfo failed\n" ); > + > + /* specify invalid cbSize */ > + mi.cbSize = 0xdeadbeef; > + ret = pGetMonitorInfoA( monitor, &mi ); > + ok( !ret, "GetMonitorInfo succeded\n" ); That's not a very convincing test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shell32: Use CREATE_NEW_CONSOLE when SEE_MASK_NOCONSOLE is omitted.
by Alistair Leslie-Hughes April 18, 2014

April 18, 2014

Hi Vincent, On 17/04/2014 7:11 AM, Vincent Povirk wrote: > MSDN specifically mentions that this flag is the opposite of > CREATE_NEW_CONSOLE: > http://msdn.microsoft.com/en-us/library/windows/desktop/bb759784%28v=vs.85%… > > I also wrote a test program (built with -mconsole), which uses > ShellExecuteEx to run cmd.exe. When running it from a command line on > windows, it creates a new console window for cmd.exe only when > SEE_MASK_NOCONSOLE is not in fMask. (If I compile with -mwindows, it > seems to create a new console window regardless of the value of the > flag or how I start it, which looks like another wine bug to me.) > I submitted a patch to do this but was reject since it causes the test to behave exactly like window. :( Look for "Correct create flags when SEE_MASK_NO_CONSOLE isn't specified" in January 2014 mailing lists. Best Regards Alistair Leslie-Hughes

2 5

Re: ole32/tests: Fix crashes in PropVariantClear tests under win2000 and XP.
by Marvin April 17, 2014

April 17, 2014

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://testbot.winehq.org/JobDetails.pl?Key=6384 Your paranoid android. === w2008s64 (64 bit propvariant) === propvariant: unhandled exception c0000005 at 000007FEFF6093CE

1 0

Re: [PATCH 6/6] d3d9: Decouple d3d9 volumes from wined3d volumes.
by Stefan Dösinger April 17, 2014

April 17, 2014

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fyi, doing the same for surfaces will take a while because a number of surface-related functions have to be moved out of the way first. If having a difference between volumes and surfaces is an issue skip this patch for now. Am 2014-04-17 15:47, schrieb Stefan Dösinger: > Releasing the partially created texture in case of an out of memory > error is a problem, see volumetexture_init. > > My choice to handle this would be to move the memory allocation into the > init function (and rename it), but a few years ago Henri has changed it > into the opposite direction everywhere. I'm open to other suggestions. > (And no, I don't like the idea of calculating the mipmap levels before > calling wined3d_texture_create.) > --- > dlls/d3d9/d3d9_private.h | 10 +++-- > dlls/d3d9/device.c | 15 +------ > dlls/d3d9/texture.c | 108 ++++++++++++++++++++++++++++++++--------------- > dlls/d3d9/volume.c | 30 ++----------- > 4 files changed, 85 insertions(+), 78 deletions(-) > > diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h > index 389cc95..2f59a2f 100644 > --- a/dlls/d3d9/d3d9_private.h > +++ b/dlls/d3d9/d3d9_private.h > @@ -184,14 +184,13 @@ struct d3d9_volume > { > IDirect3DVolume9 IDirect3DVolume9_iface; > struct d3d9_resource resource; > - struct wined3d_volume *wined3d_volume; > IUnknown *container; > IUnknown *forwardReference; > UINT level; > }; > > -void volume_init(struct d3d9_volume *volume, struct wined3d_volume *wined3d_volume, > - UINT level, const struct wined3d_parent_ops **parent_ops) DECLSPEC_HIDDEN; > +void d3d9_volume_init(struct d3d9_volume *volume, UINT level) DECLSPEC_HIDDEN; > +void d3d9_volume_destroy(void *sub_resource) DECLSPEC_HIDDEN; > > struct d3d9_swapchain > { > @@ -251,6 +250,11 @@ struct d3d9_texture > struct d3d9_resource resource; > struct wined3d_texture *wined3d_texture; > IDirect3DDevice9Ex *parent_device; > + > + void **sub_resource; > + void (*sub_resource_destroy)(void *sub_resource); > + UINT level_count, sub_resource_count; > + BOOL error_cleanup; > }; > > HRESULT cubetexture_init(struct d3d9_texture *texture, struct d3d9_device *device, > diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c > index 84184ec..11e13c5 100644 > --- a/dlls/d3d9/device.c > +++ b/dlls/d3d9/device.c > @@ -3448,22 +3448,11 @@ static HRESULT CDECL device_parent_volume_created(struct wined3d_device_parent * > void *container_parent, struct wined3d_volume *volume, UINT level, void **parent, > const struct wined3d_parent_ops **parent_ops) > { > - struct d3d9_volume *d3d_volume; > - > TRACE("device_parent %p, container_parent %p, volume %p, parent %p, parent_ops %p.\n", > device_parent, container_parent, volume, parent, parent_ops); > > - if (!(d3d_volume = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*d3d_volume)))) > - return E_OUTOFMEMORY; > - > - volume_init(d3d_volume, volume, level, parent_ops); > - *parent = d3d_volume; > - TRACE("Created volume %p.\n", d3d_volume); > - > - d3d_volume->container = container_parent; > - > - IDirect3DVolume9_Release(&d3d_volume->IDirect3DVolume9_iface); > - d3d_volume->forwardReference = container_parent; > + *parent_ops = &d3d9_null_wined3d_parent_ops; > + *parent = container_parent; > > return D3D_OK; > } > diff --git a/dlls/d3d9/texture.c b/dlls/d3d9/texture.c > index 7e8dd68..03c75fa 100644 > --- a/dlls/d3d9/texture.c > +++ b/dlls/d3d9/texture.c > @@ -1018,15 +1018,9 @@ static DWORD WINAPI d3d9_texture_3d_GetLOD(IDirect3DVolumeTexture9 *iface) > static DWORD WINAPI d3d9_texture_3d_GetLevelCount(IDirect3DVolumeTexture9 *iface) > { > struct d3d9_texture *texture = impl_from_IDirect3DVolumeTexture9(iface); > - DWORD ret; > > TRACE("iface %p.\n", iface); > - > - wined3d_mutex_lock(); > - ret = wined3d_texture_get_level_count(texture->wined3d_texture); > - wined3d_mutex_unlock(); > - > - return ret; > + return texture->level_count; > } > > static HRESULT WINAPI d3d9_texture_3d_SetAutoGenFilterType(IDirect3DVolumeTexture9 *iface, > @@ -1073,55 +1067,48 @@ static void WINAPI d3d9_texture_3d_GenerateMipSubLevels(IDirect3DVolumeTexture9 > static HRESULT WINAPI d3d9_texture_3d_GetLevelDesc(IDirect3DVolumeTexture9 *iface, UINT level, D3DVOLUME_DESC *desc) > { > struct d3d9_texture *texture = impl_from_IDirect3DVolumeTexture9(iface); > - HRESULT hr = D3D_OK; > - DWORD level_count; > + struct wined3d_resource *resource = wined3d_texture_get_resource(texture->wined3d_texture); > + struct wined3d_resource_desc wined3d_desc; > > TRACE("iface %p, level %u, desc %p.\n", iface, level, desc); > > - wined3d_mutex_lock(); > - level_count = wined3d_texture_get_level_count(texture->wined3d_texture); > - if (level >= level_count) > + if (level >= texture->level_count) > { > WARN("Invalid mipmap level specified, returning D3DERR_INVALIDCALL.\n"); > - hr = D3DERR_INVALIDCALL; > + return D3DERR_INVALIDCALL; > } > - else > - { > - struct wined3d_resource *resource = wined3d_texture_get_resource(texture->wined3d_texture); > - struct wined3d_resource_desc wined3d_desc; > > - wined3d_resource_get_desc(resource, &wined3d_desc); > - desc->Format = d3dformat_from_wined3dformat(wined3d_desc.format); > - desc->Type = D3DRTYPE_VOLUME; > - desc->Usage = wined3d_desc.usage & WINED3DUSAGE_MASK; > - desc->Pool = wined3d_desc.pool; > - desc->Width = max(wined3d_desc.width >> level, 1); > - desc->Height = max(wined3d_desc.height >> level, 1); > - desc->Depth = max(wined3d_desc.depth >> level, 1); > - hr = D3D_OK; > - } > + wined3d_mutex_lock(); > + wined3d_resource_get_desc(resource, &wined3d_desc); > + desc->Format = d3dformat_from_wined3dformat(wined3d_desc.format); > + desc->Type = D3DRTYPE_VOLUME; > + desc->Usage = wined3d_desc.usage & WINED3DUSAGE_MASK; > + desc->Pool = wined3d_desc.pool; > + desc->Width = max(wined3d_desc.width >> level, 1); > + desc->Height = max(wined3d_desc.height >> level, 1); > + desc->Depth = max(wined3d_desc.depth >> level, 1); > wined3d_mutex_unlock(); > > - return hr; > + return D3D_OK; > } > > static HRESULT WINAPI d3d9_texture_3d_GetVolumeLevel(IDirect3DVolumeTexture9 *iface, > UINT level, IDirect3DVolume9 **volume) > { > struct d3d9_texture *texture = impl_from_IDirect3DVolumeTexture9(iface); > - struct wined3d_resource *sub_resource; > struct d3d9_volume *volume_impl; > > TRACE("iface %p, level %u, volume %p.\n", iface, level, volume); > > wined3d_mutex_lock(); > - if (!(sub_resource = wined3d_texture_get_sub_resource(texture->wined3d_texture, level))) > + if (level >= texture->level_count) > { > + WARN("Invalid mipmap level specified, returning D3DERR_INVALIDCALL.\n"); > wined3d_mutex_unlock(); > return D3DERR_INVALIDCALL; > } > > - volume_impl = wined3d_resource_get_parent(sub_resource); > + volume_impl = texture->sub_resource[level]; > *volume = &volume_impl->IDirect3DVolume9_iface; > IDirect3DVolume9_AddRef(*volume); > wined3d_mutex_unlock(); > @@ -1234,9 +1221,18 @@ struct d3d9_texture *unsafe_impl_from_IDirect3DBaseTexture9(IDirect3DBaseTexture > > static void STDMETHODCALLTYPE d3d9_texture_wined3d_object_destroyed(void *parent) > { > + UINT i; > struct d3d9_texture *texture = parent; > d3d9_resource_cleanup(&texture->resource); > - HeapFree(GetProcessHeap(), 0, texture); > + > + if (texture->sub_resource) > + { > + for (i = 0; i < texture->sub_resource_count && texture->sub_resource[i]; i++) > + texture->sub_resource_destroy(texture->sub_resource[i]); > + HeapFree(GetProcessHeap(), 0, texture->sub_resource); > + } > + if (!texture->error_cleanup) > + HeapFree(GetProcessHeap(), 0, texture); > } > > static const struct wined3d_parent_ops d3d9_texture_wined3d_parent_ops = > @@ -1331,6 +1327,7 @@ HRESULT volumetexture_init(struct d3d9_texture *texture, struct d3d9_device *dev > { > struct wined3d_resource_desc desc; > HRESULT hr; > + DWORD i; > > texture->IDirect3DBaseTexture9_iface.lpVtbl = (const IDirect3DBaseTexture9Vtbl *)&d3d9_texture_3d_vtbl; > d3d9_resource_init(&texture->resource); > @@ -1350,15 +1347,56 @@ HRESULT volumetexture_init(struct d3d9_texture *texture, struct d3d9_device *dev > wined3d_mutex_lock(); > hr = wined3d_texture_create(device->wined3d_device, &desc, levels, 0, > texture, &d3d9_texture_wined3d_parent_ops, &texture->wined3d_texture); > - wined3d_mutex_unlock(); > if (FAILED(hr)) > { > WARN("Failed to create wined3d volume texture, hr %#x.\n", hr); > - return hr; > + goto error; > + } > + > + texture->level_count = wined3d_texture_get_level_count(texture->wined3d_texture); > + texture->sub_resource_count = texture->level_count; > + > + texture->sub_resource_destroy = d3d9_volume_destroy; > + texture->sub_resource = HeapAlloc(GetProcessHeap(), 0, > + sizeof(*texture->sub_resource) * texture->sub_resource_count); > + if (!texture->sub_resource) > + { > + hr = E_OUTOFMEMORY; > + goto error; > + } > + > + for (i = 0; i < texture->level_count; i++) > + { > + struct d3d9_volume *d3d9_volume; > + > + if (!(d3d9_volume = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*d3d9_volume)))) > + { > + hr = E_OUTOFMEMORY; > + goto error; > + } > + d3d9_volume_init(d3d9_volume, i); > + TRACE("Created volume %p.\n", d3d9_volume); > + > + d3d9_volume->container = (IUnknown *)&texture->IDirect3DBaseTexture9_iface; > + IDirect3DVolume9_Release(&d3d9_volume->IDirect3DVolume9_iface); > + d3d9_volume->forwardReference = d3d9_volume->container; > + texture->sub_resource[i] = d3d9_volume; > } > > texture->parent_device = &device->IDirect3DDevice9Ex_iface; > IDirect3DDevice9Ex_AddRef(texture->parent_device); > - > + wined3d_mutex_unlock(); > return D3D_OK; > + > +error: > + /* Once the wined3d texture is created there is no way to destroy it without running > + * d3d9_texture_wined3d_object_destroyed. The caller expects volumetexture_init not > + * to free texture in case of an error. */ > + if (texture->wined3d_texture) > + { > + texture->error_cleanup = TRUE; > + wined3d_texture_decref(texture->wined3d_texture); > + } > + wined3d_mutex_unlock(); > + return hr; > } > diff --git a/dlls/d3d9/volume.c b/dlls/d3d9/volume.c > index 07f15ca..916a949 100644 > --- a/dlls/d3d9/volume.c > +++ b/dlls/d3d9/volume.c > @@ -63,13 +63,6 @@ static ULONG WINAPI d3d9_volume_AddRef(IDirect3DVolume9 *iface) > refcount = InterlockedIncrement(&volume->resource.refcount); > TRACE("%p increasing refcount to %u.\n", iface, refcount); > > - if (refcount == 1) > - { > - wined3d_mutex_lock(); > - wined3d_volume_incref(volume->wined3d_volume); > - wined3d_mutex_unlock(); > - } > - > return refcount; > } > > @@ -89,13 +82,6 @@ static ULONG WINAPI d3d9_volume_Release(IDirect3DVolume9 *iface) > refcount = InterlockedDecrement(&volume->resource.refcount); > TRACE("%p decreasing refcount to %u.\n", iface, refcount); > > - if (!refcount) > - { > - wined3d_mutex_lock(); > - wined3d_volume_decref(volume->wined3d_volume); > - wined3d_mutex_unlock(); > - } > - > return refcount; > } > > @@ -213,26 +199,16 @@ static const struct IDirect3DVolume9Vtbl d3d9_volume_vtbl = > d3d9_volume_UnlockBox, > }; > > -static void STDMETHODCALLTYPE volume_wined3d_object_destroyed(void *parent) > +void d3d9_volume_destroy(void *sub_resource) > { > - struct d3d9_volume *volume = parent; > + struct d3d9_volume *volume = sub_resource; > d3d9_resource_cleanup(&volume->resource); > HeapFree(GetProcessHeap(), 0, volume); > } > > -static const struct wined3d_parent_ops d3d9_volume_wined3d_parent_ops = > -{ > - volume_wined3d_object_destroyed, > -}; > - > -void volume_init(struct d3d9_volume *volume, struct wined3d_volume *wined3d_volume, > - UINT level, const struct wined3d_parent_ops **parent_ops) > +void d3d9_volume_init(struct d3d9_volume *volume, UINT level) > { > volume->IDirect3DVolume9_iface.lpVtbl = &d3d9_volume_vtbl; > d3d9_resource_init(&volume->resource); > - wined3d_volume_incref(wined3d_volume); > - volume->wined3d_volume = wined3d_volume; > volume->level = level; > - > - *parent_ops = &d3d9_volume_wined3d_parent_ops; > } > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTT92RAAoJEN0/YqbEcdMwAe0P/2Nt/ZATqANNkVaY6o6BdknG qfw6wSQemhF3OvKX84aKSqdEdjOkHNqtQb9wHE1jEoGufkSO9VLINIOJRqa8M962 8cwg2fceNVlU148pwvdCYbkbvJofN0zqDT91IRTBfkKsoAo4Fcwo9fSzKp28gQQv KLBvcJksQ0DZNZAxHrjbGpu16xVinfTypVIa8KLrar4Ns+XPoYDikghKh7s+kSb6 Mvo5ZwmNTLYi6dLFblzjRV8ftLriN8gI6r4BxYoAotVTuN70FRG4ce+qs97Nwwe9 nAEfcSp752N5DQ2qLWiBZdaa/ZjX3y389hkaHB2uYz8RZH91hEecMgIV+6SzF4el SU5apNTF214x2SBKvGwL0jLRQ0J1QoEVbw2siwwyIS02id3yp19yekiEdOsfmq+4 CMaYdZSHHOBntcFNwz/TMli1y46ugTHWVPimVz1WGqNfWdxN1xyJX5YdIyRpIPC8 lzuzsobX9DyULFHAtrDz3RrBCMsztTFbag7bIAZ3ZbLLxEEMm0926eEQVBsGY1fZ uS5V6AKA8JLQ+OZfNCoZeiMASR70PfICoBpahld1rNo5NfjsB56P+h+kWWkP8l6q OOeXJgYYn3n40LndHl0EPk6EjXUqyUkZ9s1sPxcdgL6GD1iE9oRPHBmm2OC19+tF rswC/IHRuFD+4KHlR5OR =dY9X -----END PGP SIGNATURE-----

1 0

Re: riched20: Avoid releasing a non-existent interface.
by Nikolay Sivov April 17, 2014

April 17, 2014

> - This->txtSel->reOle = NULL; > - ITextSelection_Release(&This->txtSel->ITextSelection_iface); > - IOleClientSite_Release(&This->clientSite->IOleClientSite_iface); > + if(This->txtSel) > + { > + This->txtSel->reOle = NULL; > + ITextSelection_Release(&This->txtSel->ITextSelection_iface); > + } > + if(This->clientSite) > + { > + This->clientSite->reOle = NULL; > + IOleClientSite_Release(&This->clientSite->IOleClientSite_iface); > + } > heap_fr This can't happen. > IOleClientSiteImpl *This = impl_from_IOleClientSite(iface); > ULONG ref = InterlockedDecrement(&This->ref); > if (ref == 0) > + { > + if(This->reOle) > + This->reOle->clientSite = NULL; > heap_free(This); > + } > return ref; Why do you need this?

2 5