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

Re: [PATCH] vbscript: Fixed CBool

by Shuai Meng

Thank you, I got it. And I'll correct it. 2014-04-30 16:05 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > On 04/30/14 02:42, Shuai Meng wrote: > > Thank you. > > > 2014-04-30 1:13 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > >> On 04/29/14 17:25, Shuai Meng wrote: >> >>> 2014-04-29 22:25 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com >>> <mailto:piotr.caban(a)gmail.com>>: >>> >>> No, I mean that you should do something like this: >>> VARIANT v; >>> ... >>> V_VT(&v) = VT_EMPTY; >>> hr = VariantChangeType(..., &v); >>> if(FAILED(hr)) >>> return hr; >>> ... >>> >>> if(res) >>> *res = v; >>> else >>> VariantClear(&v); >>> >>> what will be returned after *res = v; or VariantClear(&v); ? >>> >> S_OK, because the function has succeeded. >> >> > Then I think this the same as return VariantChangeType directly. How > about writing like this: > > if(res) > { > V_VT(res) = VT_EMPTY; > return VariantChangeType(res, arg, 0, VT_BOOL); > } > return S_OK; > > Because whether the change succeed or not, VariantChangeType will return > a value indicating the situation. > > > Even if res is NULL (meaning that the return value is not used by the > script), the semantic of the code needs to be the same as if it was used. > It's just an optimization and optimizations can't change semantics. For > example: > > call CBool("blah") > > needs to return an error and you need to perform the conversion to > recognize the error. An other example why this is wrong is if you try to > convert an object. In such case, default value getter needs to be called > (and it's called by VariantChangeType in this case). > > Jacek >

April 30, 2014

Re: [PATCH 01/10] vbscript: Fixed CBool(try 3)

by Shuai Meng

ok, I will add those tests. 2014-04-30 17:37 GMT+08:00 Jacek Caban <jacek(a)codeweavers.com>: > On 04/29/14 13:11, Shuai Meng wrote: > > > Also I'd really like to see tests on object default >> values. See the attached patch for an example. >> > > I copied the example, and found that though tests on object default > values passed in testbot, they can't pass in wine. I think this is because > VariantChangeType function can't change an object into a VT_BOOL. So I > delete them. > > > This patch should fix the problem: > http://source.winehq.org/patches/data/104259 > > Please add those tests back when you resend. > > Cheers, > Jacek >

April 30, 2014

Re: dpnet: Forward declare IDirectPlay8Address when you include dpaddr.h (try 2)

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > Hi, > Change struct to interface, hopefully it will compile on the MAC this > time. Obviously this won't make any difference. -- Alexandre Julliard julliard(a)winehq.org

April 30, 2014

Re: [PATCH 1/1] ddraw/tests: Add some basic material tests.

by Marvin

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=6681 Your paranoid android. === w864 (32 bit ddraw2) === ddraw2.c:5103: Test failed: Got unexpected refcount 3. ddraw2.c:5122: Test failed: Got unexpected refcount 3. ddraw2.c:5129: Test failed: Got unexpected hr 0. ddraw2.c:5132: Test failed: Got unexpected refcount 3. ddraw2.c:5134: Test failed: Got unexpected refcount 2. ddraw2.c:5140: Test failed: Got unexpected hr 0. ddraw2.c:5143: Test failed: Got unexpected refcount 2. ddraw2.c:5145: Test failed: Got unexpected refcount 1. === w864 (32 bit ddraw1) === ddraw1.c:4027: Test failed: Got unexpected refcount 3. ddraw1.c:4046: Test failed: Got unexpected refcount 3. ddraw1.c:4053: Test failed: Got unexpected hr 0. ddraw1.c:4056: Test failed: Got unexpected refcount 3. ddraw1.c:4058: Test failed: Got unexpected refcount 2. ddraw1.c:4064: Test failed: Got unexpected hr 0. ddraw1.c:4067: Test failed: Got unexpected refcount 2. ddraw1.c:4069: Test failed: Got unexpected refcount 1. === w864 (32 bit ddraw7) === ddraw7.c:5635: Test failed: Got unexpected refcount 3. ddraw7.c:5654: Test failed: Got unexpected refcount 3. ddraw7.c:5661: Test failed: Got unexpected hr 0. ddraw7.c:5664: Test failed: Got unexpected refcount 3. ddraw7.c:5666: Test failed: Got unexpected refcount 2. ddraw7.c:5672: Test failed: Got unexpected hr 0. ddraw7.c:5675: Test failed: Got unexpected refcount 2. ddraw7.c:5677: Test failed: Got unexpected refcount 1. ddraw7.c:5679: Test failed: Got unexpected refcount 6. ddraw7.c:5796: Test failed: Failed to set cooperative level, hr 0x8876023b. === w864 (32 bit ddraw4) === ddraw4.c:5794: Test failed: Got unexpected refcount 3. ddraw4.c:5813: Test failed: Got unexpected refcount 3. ddraw4.c:5820: Test failed: Got unexpected hr 0. ddraw4.c:5823: Test failed: Got unexpected refcount 3. ddraw4.c:5825: Test failed: Got unexpected refcount 2. ddraw4.c:5831: Test failed: Got unexpected hr 0. ddraw4.c:5834: Test failed: Got unexpected refcount 2. ddraw4.c:5836: Test failed: Got unexpected refcount 1. ddraw4.c:5838: Test failed: Got unexpected refcount 6. ddraw4.c:5958: Test failed: Failed to set cooperative level, hr 0x8876023b. ddraw4.c:5997: Test failed: Failed to attach surface, hr 0x887600e1. ddraw4.c:6000: Test failed: Got unexpected hr 0. ddraw4.c:6002: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:6005: Test failed: Failed to attach surface, hr 0x887601c2. ddraw4.c:6008: Test failed: Got unexpected hr 0x887601c2. ddraw4.c:6010: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:6013: Test failed: Failed to attach surface, hr 0x887601c2. ddraw4.c:6015: Test failed: Failed to detach surface, hr 0x887601c2. ddraw4.c:6018: Test failed: Got unexpected hr 0x887600e1. ddraw4.c:6020: Test failed: Got unexpected hr 0x887601c2.

April 30, 2014

Re: [PATCH 1/2] vbscript: Allow property getters to take arguments.

by Marvin

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=6678 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

April 30, 2014

Re: msi/tests: Fix a couple of memory leaks (valgrind).

by Marvin

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=6675 Your paranoid android. === w2000pro (32 bit package) === package.c:3956: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:3962: Test failed: Expected "C:\\FileName2", got "C:\FileName2" package.c:3968: Test failed: Expected "C:\\FileName3", got "C:\FileName3" package.c:3980: Test failed: Expected "C:\\FileName5", got "C:\FileName5" package.c:3986: Test failed: Expected "C:\\", got "C:\" package.c:3992: Test failed: Expected "C:\\", got "C:\" package.c:4008: Test failed: Expected "C:\\FileName8.dll", got "C:\FileName8.dll" package.c:4019: Test failed: Expected "C:\\FileName10.dll", got "C:\FileName10.dll" package.c:4478: Test failed: Expected ERROR_SUCCESS, got 1627 package.c:4570: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4581: Test failed: Expected "C:\\", got "C:\" package.c:4592: Test failed: Expected "C:\\", got "C:\" package.c:4642: Test failed: Expected "C:\\FileName3.dll", got "C:\FileName3.dll" package.c:4653: Test failed: Expected "C:\\FileName5.dll", got "C:\FileName5.dll" package.c:4668: Test failed: Expected "C:\\", got "C:\" package.c:4673: Test failed: Expected "", got "C:\" package.c:4689: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4698: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4948: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4959: Test failed: Expected "C:\\", got "C:\" package.c:4965: Test failed: Expected "C:\\", got "C:\" package.c:4986: Test failed: Expected "C:\\FileName2.dll", got "C:\FileName2.dll" package.c:4997: Test failed: Expected "C:\\FileName4.dll", got "C:\FileName4.dll" package.c:5237: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:5243: Test failed: Expected "C:\\", got "C:\" package.c:5260: Test failed: Expected "C:\\one\two\three\FileName2", got "C:\one\two\three\FileName2" package.c:5271: Test failed: Expected "C:\\one\two\three\FileName2", got "C:\one\two\three\FileName2" package.c:5279: Test failed: Expected "C:\\FileName3.dll", got "C:\FileName3.dll" package.c:5623: Test failed: Expected C:\\winetest-package.msi, got C:\winetest-package.msi package.c:6255: Test failed: Expected C:\\abelisaurus or empty string, got C:\abelisaurus package.c:6279: Test failed: Expected C:\\ or empty string, got C:\ package.c:6323: Test failed: Expected C:\\ or empty string, got C:\ package.c:6332: Test failed: Expected C:\\neosodon\ or empty string, got C:\neosodon\ package.c:6562: Test failed: Expected "C:\\", got "C:\" package.c:6563: Test failed: Expected 4, got 3 package.c:6570: Test failed: Expected "C:\\", got "C:\" package.c:6571: Test failed: Expected 4, got 3 package.c:6587: Test failed: Expected "C:\\", got "C:\" package.c:6588: Test failed: Expected 4, got 3 package.c:6594: Test failed: Expected "C:\\", got "C:\" package.c:6595: Test failed: Expected 4, got 3 package.c:6602: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6603: Test failed: Expected 14, got 13 package.c:6610: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6611: Test failed: Expected 19, got 18 package.c:6621: Test failed: Expected "C:\\", got "C:\" package.c:6622: Test failed: Expected 4, got 3 package.c:6629: Test failed: Expected "C:\\", got "C:\" package.c:6630: Test failed: Expected 4, got 3 package.c:6646: Test failed: Expected "C:\\", got "C:\" package.c:6647: Test failed: Expected 4, got 3 package.c:6653: Test failed: Expected "C:\\", got "C:\" package.c:6654: Test failed: Expected 4, got 3 package.c:6661: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6662: Test failed: Expected 14, got 13 package.c:6669: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6670: Test failed: Expected 19, got 18 package.c:6680: Test failed: Expected "C:\\", got "C:\" package.c:6681: Test failed: Expected 4, got 3 package.c:6688: Test failed: Expected "C:\\", got "C:\" package.c:6689: Test failed: Expected 4, got 3 package.c:6705: Test failed: Expected "C:\\", got "C:\" package.c:6706: Test failed: Expected 4, got 3 package.c:6712: Test failed: Expected "C:\\", got "C:\" package.c:6713: Test failed: Expected 4, got 3 package.c:6720: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6721: Test failed: Expected 14, got 13 package.c:6728: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6729: Test failed: Expected 19, got 18 package.c:6739: Test failed: Expected "C:\\", got "C:\" package.c:6740: Test failed: Expected 4, got 3 package.c:6747: Test failed: Expected "C:\\", got "C:\" package.c:6748: Test failed: Expected 4, got 3 package.c:6764: Test failed: Expected "C:\\", got "C:\" package.c:6765: Test failed: Expected 4, got 3 package.c:6771: Test failed: Expected "C:\\", got "C:\" package.c:6772: Test failed: Expected 4, got 3 package.c:6779: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6780: Test failed: Expected 14, got 13 package.c:6787: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6788: Test failed: Expected 19, got 18 package.c:6803: Test failed: Expected 4, got 3 package.c:6820: Test failed: Expected 4, got 3 package.c:6826: Test failed: Expected ERROR_MORE_DATA, got 0 package.c:6829: Test failed: Expected 4, got 3 package.c:6836: Test failed: Expected "C:\\", got "C:\" package.c:6837: Test failed: Expected 4, got 3 package.c:6848: Test failed: Expected "C:\\", got "C:\" package.c:6849: Test failed: Expected 4, got 3 package.c:6944: Test failed: Expected "C:\\", got "C:\" package.c:6945: Test failed: Expected 4, got 3 package.c:6952: Test failed: Expected "C:\\", got "C:\" package.c:6953: Test failed: Expected 4, got 3 package.c:6962: Test failed: Expected "C:\\", got "C:\" package.c:6963: Test failed: Expected 4, got 3 package.c:6971: Test failed: Expected "C:\\", got "C:\" package.c:6972: Test failed: Expected 4, got 3 package.c:6978: Test failed: Expected "C:\\", got "C:\" package.c:6979: Test failed: Expected 4, got 3 package.c:6986: Test failed: Expected "C:\\", got "C:\" package.c:6987: Test failed: Expected 4, got 3 package.c:6994: Test failed: Expected "C:\\", got "C:\" package.c:6995: Test failed: Expected 4, got 3 package.c:7005: Test failed: Expected "C:\\", got "C:\" package.c:7006: Test failed: Expected 4, got 3 package.c:7013: Test failed: Expected "C:\\", got "C:\" package.c:7014: Test failed: Expected 4, got 3 package.c:7023: Test failed: Expected "C:\\", got "C:\" package.c:7024: Test failed: Expected 4, got 3 package.c:7032: Test failed: Expected "C:\\", got "C:\" package.c:7033: Test failed: Expected 4, got 3 package.c:7039: Test failed: Expected "C:\\", got "C:\" package.c:7040: Test failed: Expected 4, got 3 package.c:7047: Test failed: Expected "C:\\", got "C:\" package.c:7048: Test failed: Expected 4, got 3 package.c:7055: Test failed: Expected "C:\\", got "C:\" package.c:7056: Test failed: Expected 4, got 3 package.c:7066: Test failed: Expected "C:\\", got "C:\" package.c:7067: Test failed: Expected 4, got 3 package.c:7074: Test failed: Expected "C:\\", got "C:\" package.c:7075: Test failed: Expected 4, got 3 package.c:7084: Test failed: Expected "C:\\", got "C:\" package.c:7085: Test failed: Expected 4, got 3 package.c:7093: Test failed: Expected "C:\\", got "C:\" package.c:7094: Test failed: Expected 4, got 3 package.c:7100: Test failed: Expected "C:\\", got "C:\" package.c:7101: Test failed: Expected 4, got 3 package.c:7108: Test failed: Expected "C:\\", got "C:\" package.c:7109: Test failed: Expected 4, got 3 package.c:7116: Test failed: Expected "C:\\", got "C:\" package.c:7117: Test failed: Expected 4, got 3 package.c:7127: Test failed: Expected "C:\\", got "C:\" package.c:7128: Test failed: Expected 4, got 3 package.c:7135: Test failed: Expected "C:\\", got "C:\" package.c:7136: Test failed: Expected 4, got 3 package.c:7145: Test failed: Expected "C:\\", got "C:\" package.c:7146: Test failed: Expected 4, got 3 package.c:7154: Test failed: Expected "C:\\", got "C:\" package.c:7155: Test failed: Expected 4, got 3 package.c:7161: Test failed: Expected "C:\\", got "C:\" package.c:7162: Test failed: Expected 4, got 3 package.c:7169: Test failed: Expected "C:\\", got "C:\" package.c:7170: Test failed: Expected 4, got 3 package.c:7177: Test failed: Expected "C:\\", got "C:\" package.c:7178: Test failed: Expected 4, got 3 package.c:7275: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7276: Test failed: Expected 9, got 8 package.c:7285: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7286: Test failed: Expected 9, got 8 package.c:7295: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7296: Test failed: Expected 9, got 8 package.c:7307: Test failed: Expected "C:\\two\", got "C:\two\" package.c:7308: Test failed: Expected 8, got 7 package.c:7319: Test failed: Expected "C:\\four\", got "C:\four\" package.c:7320: Test failed: Expected 9, got 8 package.c:7331: Test failed: Expected "C:\\six\", got "C:\six\" package.c:7332: Test failed: Expected 8, got 7 package.c:7343: Test failed: Expected "C:\\eight\", got "C:\eight\" package.c:7344: Test failed: Expected 10, got 9 package.c:7355: Test failed: Expected "C:\\ten\", got "C:\ten\" package.c:7356: Test failed: Expected 8, got 7 package.c:7367: Test failed: Expected "C:\\twelve\", got "C:\twelve\" package.c:7368: Test failed: Expected 11, got 10 package.c:7419: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7420: Test failed: Expected 10, got 9 package.c:7429: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7430: Test failed: Expected 10, got 9 package.c:7439: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7440: Test failed: Expected 10, got 9 package.c:7451: Test failed: Expected "C:\\one\", got "C:\one\" package.c:7452: Test failed: Expected 8, got 7 package.c:7463: Test failed: Expected "C:\\three\", got "C:\three\" package.c:7464: Test failed: Expected 10, got 9 package.c:7475: Test failed: Expected "C:\\five\", got "C:\five\" package.c:7476: Test failed: Expected 9, got 8 package.c:7487: Test failed: Expected "C:\\seven\", got "C:\seven\" package.c:7488: Test failed: Expected 10, got 9 package.c:7499: Test failed: Expected "C:\\nine\", got "C:\nine\" package.c:7500: Test failed: Expected 9, got 8 package.c:7511: Test failed: Expected "C:\\eleven\", got "C:\eleven\" package.c:7512: Test failed: Expected 11, got 10 package.c:7648: Test failed: Expected "C:\\", got "C:\" package.c:7649: Test failed: Expected 4, got 3 package.c:7660: Test failed: Expected "C:\\", got "C:\" package.c:7661: Test failed: Expected 4, got 3 package.c:7668: Test failed: Expected "C:\\", got "C:\" package.c:7669: Test failed: Expected 4, got 3 package.c:7766: Test failed: Expected "C:\\", got "C:\" package.c:7767: Test failed: Expected 4, got 3 package.c:7774: Test failed: Expected "C:\\", got "C:\" package.c:7775: Test failed: Expected 4, got 3 package.c:7782: Test failed: Expected "C:\\", got "C:\" package.c:7783: Test failed: Expected 4, got 3 package.c:7802: Test failed: Expected "C:\\", got "C:\" package.c:7803: Test failed: Expected 4, got 3 package.c:7810: Test failed: Expected "C:\\", got "C:\" package.c:7811: Test failed: Expected 4, got 3 package.c:7830: Test failed: Expected "C:\\", got "C:\" package.c:7831: Test failed: Expected 4, got 3 package.c:7838: Test failed: Expected "C:\\", got "C:\" package.c:7839: Test failed: Expected 4, got 3 package.c:7858: Test failed: Expected "C:\\", got "C:\" package.c:7859: Test failed: Expected 4, got 3 package.c:7866: Test failed: Expected "C:\\", got "C:\" package.c:7867: Test failed: Expected 4, got 3 === w7u (32 bit msi) === The test timed out === wxppro (32 bit install) === The test timed out === w7u (32 bit install) === Failure running script in VM: timed out waiting for the child process === wxppro (32 bit action) === The test timed out === w2008s64 (32 bit action) === Failure running script in VM: timed out waiting for the child process === w7u (32 bit action) === Failure running script in VM: timed out waiting for the child process === w864 (32 bit action) === The test timed out

April 30, 2014

Re: [PATCH 01/10] vbscript: Fixed CBool(try 3)

by Jacek Caban

On 04/29/14 13:11, Shuai Meng wrote: > > Also I'd really like to see tests on object default > values. See the attached patch for an example. > > > I copied the example, and found that though tests on object default > values passed in testbot, they can't pass in wine. I think this is > because VariantChangeType function can't change an object into a > VT_BOOL. So I delete them. This patch should fix the problem: http://source.winehq.org/patches/data/104259 Please add those tests back when you resend. Cheers, Jacek

April 30, 2014

Re: wbemproxy: Fix invalid HRESULT assignment in class_object_Next.

by Hans Leidekker

On Tue, 2014-04-29 at 19:41 +0200, Victor Martinez wrote: > From 9cfa2abd78c6cd23c3bd5a48c6fb5f5259edd9e4 Mon Sep 17 00:00:00 2001 > From: Victor Martinez Calvo <vmartinez(a)reactos.org> > Date: Tue, 29 Apr 2014 17:36:27 +0200 > Subject: wbemproxy: Fix invalid HRESULT assignment in class_object_Next. Thanks. As it happens I have just rewritten this function and included the same fix: http://source.winehq.org/patches/data/104254

April 30, 2014

Re: [PATCH] vbscript: Fixed CBool

by Jacek Caban

On 04/30/14 02:42, Shuai Meng wrote: > Thank you. > > > 2014-04-30 1:13 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com > <mailto:piotr.caban(a)gmail.com>>: > > On 04/29/14 17:25, Shuai Meng wrote: > > 2014-04-29 22:25 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com > <mailto:piotr.caban(a)gmail.com> > <mailto:piotr.caban(a)gmail.com <mailto:piotr.caban(a)gmail.com>>>: > > No, I mean that you should do something like this: > VARIANT v; > ... > V_VT(&v) = VT_EMPTY; > hr = VariantChangeType(..., &v); > if(FAILED(hr)) > return hr; > ... > > if(res) > *res = v; > else > VariantClear(&v); > > what will be returned after *res = v; or VariantClear(&v); ? > > S_OK, because the function has succeeded. > > > Then I think this the same as return VariantChangeType directly. How > about writing like this: > > if(res) > { > V_VT(res) = VT_EMPTY; > return VariantChangeType(res, arg, 0, VT_BOOL); > } > return S_OK; > > Because whether the change succeed or not, VariantChangeType will > return a value indicating the situation. Even if res is NULL (meaning that the return value is not used by the script), the semantic of the code needs to be the same as if it was used. It's just an optimization and optimizations can't change semantics. For example: call CBool("blah") needs to return an error and you need to perform the conversion to recognize the error. An other example why this is wrong is if you try to convert an object. In such case, default value getter needs to be called (and it's called by VariantChangeType in this case). Jacek

April 30, 2014

D3D11CreateDevice

by Dyweni - Wine-Devel

Hi All, I'm curious to know if anyone has an idea of when D3D11CreateDevice will be implemented to at least D3D_FEATURE_LEVEL_10_0? http://bugs.winehq.org/show_bug.cgi?id=34008 Thanks, Dyweni!

April 30, 2014

Re: [PATCH] bcrypt: Add stub for BCryptOpenAlgorithmProvider.

by Dmitry Timoshkov

Alex Henrie <alexhenrie24(a)gmail.com> wrote: > +@ stdcall BCryptOpenAlgorithmProvider(ptr ptr ptr long) It should be (ptr wstr wstr long) > +NTSTATUS WINAPI BCryptOpenAlgorithmProvider(BCRYPT_ALG_HANDLE *phAlgorithm, LPCWSTR pszAlgId, > + LPCWSTR pszImplementation, DWORD dwFlags) > +{ > + FIXME("%p, %s, %s, %08x - stub\n", phAlgorithm, wine_dbgstr_w(pszAlgId), wine_dbgstr_w(pszImplementation), dwFlags); > + > + *phAlgorithm = NULL; > + > + return STATUS_NOT_IMPLEMENTED; > +} Probably there should be a test for NULL before writing to *phAlgorithm. Also please avoid using hungarian notation for variable naming in Wine. -- Dmitry.

April 30, 2014

Re: [PATCH] vbscript: Fixed CBool

by Shuai Meng

Thank you. 2014-04-30 1:13 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 04/29/14 17:25, Shuai Meng wrote: > >> 2014-04-29 22:25 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com >> <mailto:piotr.caban(a)gmail.com>>: >> >> No, I mean that you should do something like this: >> VARIANT v; >> ... >> V_VT(&v) = VT_EMPTY; >> hr = VariantChangeType(..., &v); >> if(FAILED(hr)) >> return hr; >> ... >> >> if(res) >> *res = v; >> else >> VariantClear(&v); >> >> what will be returned after *res = v; or VariantClear(&v); ? >> > S_OK, because the function has succeeded. > > Then I think this the same as return VariantChangeType directly. How about writing like this: if(res) { V_VT(res) = VT_EMPTY; return VariantChangeType(res, arg, 0, VT_BOOL); } return S_OK; Because whether the change succeed or not, VariantChangeType will return a value indicating the situation. > > yes, I made a mistake. The error occurs when I test an empty string as >> Jacek have asked: >> 477 Call ok(CBool("") = True, "CBool("""") = " & CBool("")) >> 478 Call ok(getVT(CBool("")) = "VT_BOOL", "getVT(CBool("""")) = " & >> getVT(CBool(""))) >> I have tried to solve it like this: >> 477 Call ok(CBool("") = True, "CBool("") = " & CBool("")) >> 478 Call ok(getVT(CBool("")) = "VT_BOOL", "getVT(CBool("")) = " & >> getVT(CBool(""))) >> and this: >> 477 Call ok(CBool("") = True, "CBool(" & "" & ") = " & CBool("")) >> 478 Call ok(getVT(CBool("")) = "VT_BOOL", "getVT(CBool(" & "" & ")) = " >> & getVT(CBool(""))) >> They all don't work...The problem is how describe an empty string >> between two quotation marks. >> > It's ok to use "" for empty string. The CBool is simply failing for that > argument. It can be tested in similar way as "#FALSE# string. > I got it. I will do like this. Thank you.

April 30, 2014

Re: [PATCH 5/5] ddraw/tests: Add some basic material tests.

by Marvin

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=6673 Your paranoid android. === w864 (32 bit ddraw1) === ddraw1.c:4938: Test failed: Got unexpected color 0x000000ff, test 0.

April 29, 2014

Re: WINE mutex functions speed.

by John Found

Thanks, Sebastian. I changed my program to use critical sections (it needs only thread syncronization) instead of mutex and the speed increased up to 10 times in Wine. In Windows the speed increase is not so big. I know that it is not recommended to shape the application after WINE, but my program is actually hybrid anyway - it uses Linux system calls and other Linux features when in Linux, so it is not a big deal. Thanks also to all responders for the help. P.S.: If anyone is interested, the application we're talking about is this: http://fresh.flatassembler.net On Tue, 29 Apr 2014 20:21:31 +0200 Sebastian Lackner <sebastian(a)fds-team.de> wrote: > Hi John, > > If this is your own application and depending on which features you need > exactly (synchronization in one application or between multiple > processes?), the easiest way is just to use a different set of > synchronization primitives. > > You could either use CriticalSections (which internally use very fast > futex commands on Linux) or slim reader/writer locks (see: > http://msdn.microsoft.com/en-us/library/windows/desktop/ms681930(v=vs.85).a… > ), which only use wineserver calls when they are blocking. Both methods > should definitely bring some performance boost. > > Regards, > Sebastian > > Am 29.04.2014 19:40, schrieb Vincent Povirk: > > This is because every call involving a kernel object handle is done > > via RPC to the wineserver process. > > > > The semantics of things like DuplicateHandle, and all of the various > > types of waitable kernel objects, need to be reproduced exactly. Even > > in the case of a single object used by a single thread, in order to > > optimize out the wineserver call you'd have to somehow be sure no one > > had duplicated that object into another process. Or you'd have to give > > the wineserver enough information to duplicate it while letting you > > wait for/manipulate the object without an RPC call. > > > > So, I don't know that it's necessarily a fundamental architecture > > problem, but there's a lot you have to think about. And I can't > > recommend taking on a project like this to a new Wine developer. > > > > > > > -- asm32.info <johnfound(a)asm32.info>

April 29, 2014

Re: WINE mutex functions speed.

by Sebastian Lackner

Hi John, If this is your own application and depending on which features you need exactly (synchronization in one application or between multiple processes?), the easiest way is just to use a different set of synchronization primitives. You could either use CriticalSections (which internally use very fast futex commands on Linux) or slim reader/writer locks (see: http://msdn.microsoft.com/en-us/library/windows/desktop/ms681930(v=vs.85).a… ), which only use wineserver calls when they are blocking. Both methods should definitely bring some performance boost. Regards, Sebastian Am 29.04.2014 19:40, schrieb Vincent Povirk: > This is because every call involving a kernel object handle is done > via RPC to the wineserver process. > > The semantics of things like DuplicateHandle, and all of the various > types of waitable kernel objects, need to be reproduced exactly. Even > in the case of a single object used by a single thread, in order to > optimize out the wineserver call you'd have to somehow be sure no one > had duplicated that object into another process. Or you'd have to give > the wineserver enough information to duplicate it while letting you > wait for/manipulate the object without an RPC call. > > So, I don't know that it's necessarily a fundamental architecture > problem, but there's a lot you have to think about. And I can't > recommend taking on a project like this to a new Wine developer. > >

April 29, 2014

Re: WINE mutex functions speed.

by John Found

So, thinking about changes in my code, are critical sections faster than mutexes in WINE? On Tue, 29 Apr 2014 12:40:01 -0500 Vincent Povirk <madewokherd(a)gmail.com> wrote: > This is because every call involving a kernel object handle is done > via RPC to the wineserver process. > > The semantics of things like DuplicateHandle, and all of the various > types of waitable kernel objects, need to be reproduced exactly. Even > in the case of a single object used by a single thread, in order to > optimize out the wineserver call you'd have to somehow be sure no one > had duplicated that object into another process. Or you'd have to give > the wineserver enough information to duplicate it while letting you > wait for/manipulate the object without an RPC call. > > So, I don't know that it's necessarily a fundamental architecture > problem, but there's a lot you have to think about. And I can't > recommend taking on a project like this to a new Wine developer. -- asm32.info <johnfound(a)asm32.info>

April 29, 2014

Re: WINE mutex functions speed.

by Vincent Povirk

This is because every call involving a kernel object handle is done via RPC to the wineserver process. The semantics of things like DuplicateHandle, and all of the various types of waitable kernel objects, need to be reproduced exactly. Even in the case of a single object used by a single thread, in order to optimize out the wineserver call you'd have to somehow be sure no one had duplicated that object into another process. Or you'd have to give the wineserver enough information to duplicate it while letting you wait for/manipulate the object without an RPC call. So, I don't know that it's necessarily a fundamental architecture problem, but there's a lot you have to think about. And I can't recommend taking on a project like this to a new Wine developer.

April 29, 2014

Re: [PATCH] vbscript: Fixed CBool

by Piotr Caban

On 04/29/14 17:25, Shuai Meng wrote: > 2014-04-29 22:25 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com > <mailto:piotr.caban(a)gmail.com>>: > No, I mean that you should do something like this: > VARIANT v; > ... > V_VT(&v) = VT_EMPTY; > hr = VariantChangeType(..., &v); > if(FAILED(hr)) > return hr; > ... > > if(res) > *res = v; > else > VariantClear(&v); > > what will be returned after *res = v; or VariantClear(&v); ? S_OK, because the function has succeeded. > yes, I made a mistake. The error occurs when I test an empty string as > Jacek have asked: > 477 Call ok(CBool("") = True, "CBool("""") = " & CBool("")) > 478 Call ok(getVT(CBool("")) = "VT_BOOL", "getVT(CBool("""")) = " & > getVT(CBool(""))) > I have tried to solve it like this: > 477 Call ok(CBool("") = True, "CBool("") = " & CBool("")) > 478 Call ok(getVT(CBool("")) = "VT_BOOL", "getVT(CBool("")) = " & > getVT(CBool(""))) > and this: > 477 Call ok(CBool("") = True, "CBool(" & "" & ") = " & CBool("")) > 478 Call ok(getVT(CBool("")) = "VT_BOOL", "getVT(CBool(" & "" & ")) = " > & getVT(CBool(""))) > They all don't work...The problem is how describe an empty string > between two quotation marks. It's ok to use "" for empty string. The CBool is simply failing for that argument. It can be tested in similar way as "#FALSE# string.

April 29, 2014

WINE mutex functions speed.

by John Found

Hi. Recently, I am working on an multi-thread application that widely uses mutex functions, namely: WaitForSingleObject and ReleaseMutex. After some benchmarks I found that these functions are 50..100 times(sic!) slower than in Windows. And this is when only one thread tries to use the mutex - i.e. there is nothing to be waiting for. The test program compiled natively for Linux (using pthreads library) demonstrates only 1.5 times slower functions (compared to the same program not using mutexes at all) which is pretty acceptable. So, what can I do in order to speed up these functions? Is it a bug (that need to be reported and fixed) or some fundamental architecture problem? Should I think about different way of mutex implementation? -- asm32.info <johnfound(a)asm32.info>

April 29, 2014

Re: [PATCH] vbscript: Fixed CBool

by Shuai Meng

2014-04-29 22:25 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 04/29/14 16:04, Shuai Meng wrote: > >> >> Thank you for commenting. >> >> 2014-04-29 21:30 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com >> <mailto:piotr.caban(a)gmail.com>>: >> >> >> On 04/29/14 15:06, Shuai Meng wrote: >> >> + if(!res) >> + return S_OK; >> >> You can't return early if res is NULL. You still need to do the >> conversion and return error if it fails. >> >> I don't quite get it, do you mean I should do like this: >> if(res) >> { >> .... >> } >> return S_OK; >> > No, I mean that you should do something like this: > VARIANT v; > ... > V_VT(&v) = VT_EMPTY; > hr = VariantChangeType(..., &v); > if(FAILED(hr)) > return hr; > ... if(res) > *res = v; > else > VariantClear(&v); > > what will be returned after *res = v; or VariantClear(&v); ? It would be nice to add following tests (these are the tests Jacek >> was asking for): >> >> Call ok(CBool("True") = true, "CBool(""True"") = " & CBool("True")) >> Call ok(CBool("fAlSe") = false, "CBool(""fAlSe"") = " & >> CBool("fAlSe")) >> >> >> I do notice it, but they failed in testbot. Just as MSDN says, If >> /expression/ can't be interpreted as a numeric value, a run-time error >> occurs. >> > You must have done something else incorrectly. Here's a run that > succeeded: https://testbot.winehq.org/JobDetails.pl?Key=6665. It shows > that CBool("True") returns true. yes, I made a mistake. The error occurs when I test an empty string as Jacek have asked: 477 Call ok(CBool("") = True, "CBool("""") = " & CBool("")) 478 Call ok(getVT(CBool("")) = "VT_BOOL", "getVT(CBool("""")) = " & getVT(CBool(""))) I have tried to solve it like this: 477 Call ok(CBool("") = True, "CBool("") = " & CBool("")) 478 Call ok(getVT(CBool("")) = "VT_BOOL", "getVT(CBool("")) = " & getVT(CBool(""))) and this: 477 Call ok(CBool("") = True, "CBool(" & "" & ") = " & CBool("")) 478 Call ok(getVT(CBool("")) = "VT_BOOL", "getVT(CBool(" & "" & ")) = " & getVT(CBool(""))) They all don't work...The problem is how describe an empty string between two quotation marks. > > > sub testCBoolError >> on error resume next >> >> call Err.clear() >> call CBool("#FALSE#") >> call ok(Err.number = 458, "Err.number = " & Err.number) >> end sub >> Call testCBoolError >> >> Is this function written to provoke an error on purpose in order to test >> CBool("#FALSE#")? >> > It's meant to handle error returned by CBool("#FALSE#"). Other invalid > parameters may be tested in the same way. > > Cheers, > Piot > r >

April 29, 2014

Re: [PATCH] vbscript: Fixed CBool

by Piotr Caban

On 04/29/14 16:04, Shuai Meng wrote: > > Thank you for commenting. > > 2014-04-29 21:30 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com > <mailto:piotr.caban(a)gmail.com>>: > > On 04/29/14 15:06, Shuai Meng wrote: > > + if(!res) > + return S_OK; > > You can't return early if res is NULL. You still need to do the > conversion and return error if it fails. > > I don't quite get it, do you mean I should do like this: > if(res) > { > .... > } > return S_OK; No, I mean that you should do something like this: VARIANT v; ... V_VT(&v) = VT_EMPTY; hr = VariantChangeType(..., &v); if(FAILED(hr)) return hr; ... if(res) *res = v; else VariantClear(&v); > It would be nice to add following tests (these are the tests Jacek > was asking for): > > Call ok(CBool("True") = true, "CBool(""True"") = " & CBool("True")) > Call ok(CBool("fAlSe") = false, "CBool(""fAlSe"") = " & CBool("fAlSe")) > > > I do notice it, but they failed in testbot. Just as MSDN says, If > /expression/ can't be interpreted as a numeric value, a run-time error > occurs. You must have done something else incorrectly. Here's a run that succeeded: https://testbot.winehq.org/JobDetails.pl?Key=6665. It shows that CBool("True") returns true. > sub testCBoolError > on error resume next > > call Err.clear() > call CBool("#FALSE#") > call ok(Err.number = 458, "Err.number = " & Err.number) > end sub > Call testCBoolError > > Is this function written to provoke an error on purpose in order to test > CBool("#FALSE#")? It's meant to handle error returned by CBool("#FALSE#"). Other invalid parameters may be tested in the same way. Cheers, Piotr

April 29, 2014

Re: [PATCH] vbscript: Fixed CBool

by Shuai Meng

Thank you for commenting. 2014-04-29 21:30 GMT+08:00 Piotr Caban <piotr.caban(a)gmail.com>: > On 04/29/14 15:06, Shuai Meng wrote: > >> + if(!res) >> + return S_OK; >> > You can't return early if res is NULL. You still need to do the conversion > and return error if it fails. > I don't quite get it, do you mean I should do like this: if(res) { .... } return S_OK; > > +Call ok(CBool(Empty) = False, "CBool(Empty) = " & CBool(Empty)) >> +Call ok(getVT(CBool(Empty)) = "VT_BOOL", "getVT(CBool(Empty)) = " & >> getVT(CBool(Empty))) >> +Call ok(CBool(1) = True, "CBool(1) = " & CBool(1)) >> +Call ok(getVT(CBool(1)) = "VT_BOOL", "getVT(CBool(1)) = " & >> getVT(CBool(1))) >> +Call ok(CBool(0) = False, "CBool(0) = " & CBool(0)) >> +Call ok(getVT(CBool(0)) = "VT_BOOL", "getVT(CBool(0)) = " & >> getVT(CBool(0))) >> +Call ok(CBool(-0.56) = True, "CBool(-0.56) = " & CBool(-0.56)) >> +Call ok(getVT(CBool(-0.56)) = "VT_BOOL", "getVT(CBool(-0.56)) = " & >> getVT(CBool(-0.56))) >> +Call ok(CBool("-1") = True, "CBool(""-1"") = " & CBool("-1")) >> +Call ok(getVT(CBool("-1")) = "VT_BOOL", "getVT(CBool(""-1"")) = " & >> getVT(CBool("-1"))) >> > It would be nice to add following tests (these are the tests Jacek was > asking for): Call ok(CBool("True") = true, "CBool(""True"") = " & CBool("True")) > Call ok(CBool("fAlSe") = false, "CBool(""fAlSe"") = " & CBool("fAlSe")) > I do notice it, but they failed in testbot. Just as MSDN says, If *expression* can't be interpreted as a numeric value, a run-time error occurs. sub testCBoolError > on error resume next > > call Err.clear() > call CBool("#FALSE#") > call ok(Err.number = 458, "Err.number = " & Err.number) > end sub > Call testCBoolError > > Is this function written to provoke an error on purpose in order to test CBool("#FALSE#")? Can CBool("True") assume the same form? Because CBool("True") always fails in testbot as I have said.

April 29, 2014

Re: msctf: Added ITfInputProcessorProfileMgr interface stub implementation.

by Marvin

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=6663 Your paranoid android. === w864 (32 bit inputprocessor) === inputprocessor.c:791: Test failed: Deactivation came unexpectedly

April 29, 2014

Re: [PATCH] vbscript: Fixed CBool

by Piotr Caban

On 04/29/14 15:06, Shuai Meng wrote: > + if(!res) > + return S_OK; You can't return early if res is NULL. You still need to do the conversion and return error if it fails. > +Call ok(CBool(Empty) = False, "CBool(Empty) = " & CBool(Empty)) > +Call ok(getVT(CBool(Empty)) = "VT_BOOL", "getVT(CBool(Empty)) = " & getVT(CBool(Empty))) > +Call ok(CBool(1) = True, "CBool(1) = " & CBool(1)) > +Call ok(getVT(CBool(1)) = "VT_BOOL", "getVT(CBool(1)) = " & getVT(CBool(1))) > +Call ok(CBool(0) = False, "CBool(0) = " & CBool(0)) > +Call ok(getVT(CBool(0)) = "VT_BOOL", "getVT(CBool(0)) = " & getVT(CBool(0))) > +Call ok(CBool(-0.56) = True, "CBool(-0.56) = " & CBool(-0.56)) > +Call ok(getVT(CBool(-0.56)) = "VT_BOOL", "getVT(CBool(-0.56)) = " & getVT(CBool(-0.56))) > +Call ok(CBool("-1") = True, "CBool(""-1"") = " & CBool("-1")) > +Call ok(getVT(CBool("-1")) = "VT_BOOL", "getVT(CBool(""-1"")) = " & getVT(CBool("-1"))) It would be nice to add following tests (these are the tests Jacek was asking for): Call ok(CBool("True") = true, "CBool(""True"") = " & CBool("True")) Call ok(CBool("fAlSe") = false, "CBool(""fAlSe"") = " & CBool("fAlSe")) sub testCBoolError on error resume next call Err.clear() call CBool("#FALSE#") call ok(Err.number = 458, "Err.number = " & Err.number) end sub Call testCBoolError

April 29, 2014

Re: [PATCH] vbscript: Fixed CBool

by Marvin

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=6662 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

April 29, 2014