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

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