November 2007 - Wine-Devel - list.winehq.org

Re: Valgrind results for Oct 9: still lots of hangs

by Dan Kegel

I think the d3d9 test ran ok this time. I figured it would, after your attractively-titled patch "d3d9: Release the window after the visual tests." - Dan On Nov 9, 2007 5:27 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi Dan, > > Did the d3d9 test crash again? Or did it run this time? > > > > Results for today's git (plus my dde patch) are online at > > http://kegel.com/wine/valgrind/20071109/ > > > > ole32/tests/marshall.c has always been hanging > > when run under valgrind. In the last two days, > > the following additional tests hang under valgrind: > > mshtml/tests/dom.c > > mshtml/tests/htmldoc.c > > ole32/tests/marshal.c > > shdocvw/tests/webbrowser.c > > > > I can reproduce one hang with > > cd dlls/mshtml/tests > > make testclean > > wineserver -k > > RUNTEST_USE_VALGRIND=1 make test > > (with the wine-vg-utils.patch I provide. > > Make by itself does not behave well under valgrind, > > so you can't just do "valgrind make test"). > > > > Sadly, I don't have time to do a regression test, but > > it's pretty easy to repeat my results. See > > http://wiki.winehq.org/Wine_and_Valgrind > > It'd be nice if somebody else verified that > > these hangs occur for them too, that they didn't > > occur with wine-0.9.48, and maybe > > did a regression test to find out when they started... > > - Dan > -- Wine for Windows ISVs: http://kegel.com/wine/isv

Nov. 10, 2007

Re: Valgrind results for Oct 9: still lots of hangs

by Stefan Dösinger

Hi Dan, Did the d3d9 test crash again? Or did it run this time? > Results for today's git (plus my dde patch) are online at > http://kegel.com/wine/valgrind/20071109/ > > ole32/tests/marshall.c has always been hanging > when run under valgrind. In the last two days, > the following additional tests hang under valgrind: > mshtml/tests/dom.c > mshtml/tests/htmldoc.c > ole32/tests/marshal.c > shdocvw/tests/webbrowser.c > > I can reproduce one hang with > cd dlls/mshtml/tests > make testclean > wineserver -k > RUNTEST_USE_VALGRIND=1 make test > (with the wine-vg-utils.patch I provide. > Make by itself does not behave well under valgrind, > so you can't just do "valgrind make test"). > > Sadly, I don't have time to do a regression test, but > it's pretty easy to repeat my results. See > http://wiki.winehq.org/Wine_and_Valgrind > It'd be nice if somebody else verified that > these hangs occur for them too, that they didn't > occur with wine-0.9.48, and maybe > did a regression test to find out when they started... > - Dan

Nov. 10, 2007

Re: CryptAcquireContext Failure, default/Type 024 requested

by Vijay Kiran Kamuju

Hi, I am sending two patches one is the old patch. The new patch contains the missing aes.c implementation and provider implementation for AES. Tests are failing for me. Could you please tell why its failng? I will improve my tests once the failures are resolved. Thanks, VJ On Nov 9, 2007 2:49 PM, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi Juan > > > On Nov 9, 2007 2:21 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > > Hi Vijay, > > > > you forgot aes.c in your patch - please remember to git add it, then > > commit it along with the rest of the changes. > > > > From what you've sent, your patch looks pretty good so far. A few comments: > > > > @@ -161,6 +162,10 @@ static const PROV_ENUMALGS_EX > > aProvEnumAlgsEx[4][RSAENH_MAX_ENUMALGS+1] = > > {CALG_RC2, 40, 40, 56,0, 4,"RC2", > > 24,"RSA Data Security's RC2"}, > > {CALG_RC4, 40, 40, 56,0, 4,"RC4", > > 24,"RSA Data Security's RC4"}, > > {CALG_DES, 56, 56, 56,0, 4,"DES", > > 31,"Data Encryption Standard (DES)"}, > > + {CALG_AES, 128,128, 128,0, 4,"AES", > > 35,"Advanced Encryption Standard (AES)"}, > > + {CALG_AES_128, 128,128, 128,0, 8,"AES-128", > > 39,"Advanced Encryption Standard (AES-128)"}, > > + {CALG_AES_192, 192,192, 192,0, 8,"AES-192", > > 39,"Advanced Encryption Standard (AES-192)"}, > > + {CALG_AES_256, 256,256, 256,0, 8,"AES-256", > > 39,"Advanced Encryption Standard (AES-256)"}, > > > > I'm not sure AES support should be included in every "personality" of > > rsaenh. Specifically, some cryptographic providers don't support it. > > Here's a blog that mentions how the MS_ENHANCED_PROV provider doesn't > > support it, but the MS_ENH_RSA_AES_PROV does: > > http://sys.cs.rice.edu/~sethn/wordpress/?p=19 > I think I'll split the patch into 3 parts > 1) basic AES implementation in rsaenh > 2) Add AES provider info with registering MS_ENH_RSA_AES_PROV. > I have to make aProvEnumAlgsEx[4][RSAENH_MAX_ENUMALGS+1] to > aProvEnumAlgsEx[5][RSAENH_MAX_ENUMALGS+1] > and add the new algorithms, can you help me what algo's should I add > to the new one. > Add the registering code for type24 provider. > 3) Tests > > > > > + if (!result) { > > + /* rsaenh compiled without OpenSSL */ > > + ok(GetLastError()==NTE_BAD_ALGID, "%08x\n", GetLastError()); > > + return; > > + } > > > > Our rsaenh hasn't built against OpenSSL in some time, so this test > > should be removed from existing tests. You don't need to do that if > > you don't want, but don't bother adding it to new tests. > > > > + result = CryptEncrypt(hKey, (HCRYPTHASH)NULL, TRUE, 0, pbData, &dwLen, 16); > > + ok(result, "%08x\n", GetLastError()); > > + > > + result = CryptDecrypt(hKey, (HCRYPTHASH)NULL, TRUE, 0, pbData, &dwLen); > > + ok(result, "%08x\n", GetLastError()); > > > > You should check that the encrypted output matches some expected > > value, and that the decrypted output matches the plaintext input. > Well, I have tested the decrypted output by putting printf's. > I will make sure we have good tests for it. > Will send new patch set soon. > > > > > Thanks very much for getting this started. > > --Juan > > >

Nov. 9, 2007

Re: [14/15] WineD3D: Get rid of the conditionals in shader_glsl_compare

by Mirek Slugeň

Thanks, this patch works. Mirek Slugen Stefan Dösinger napsal(a): > Hi, > I wrote a test, and I think I found the issue. Can you try the attached patch? >

Nov. 9, 2007

Re: CryptAcquireContext Failure, default/Type 024 requested

by Vijay Kiran Kamuju

Hi Juan On Nov 9, 2007 2:21 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi Vijay, > > you forgot aes.c in your patch - please remember to git add it, then > commit it along with the rest of the changes. > > From what you've sent, your patch looks pretty good so far. A few comments: > > @@ -161,6 +162,10 @@ static const PROV_ENUMALGS_EX > aProvEnumAlgsEx[4][RSAENH_MAX_ENUMALGS+1] = > {CALG_RC2, 40, 40, 56,0, 4,"RC2", > 24,"RSA Data Security's RC2"}, > {CALG_RC4, 40, 40, 56,0, 4,"RC4", > 24,"RSA Data Security's RC4"}, > {CALG_DES, 56, 56, 56,0, 4,"DES", > 31,"Data Encryption Standard (DES)"}, > + {CALG_AES, 128,128, 128,0, 4,"AES", > 35,"Advanced Encryption Standard (AES)"}, > + {CALG_AES_128, 128,128, 128,0, 8,"AES-128", > 39,"Advanced Encryption Standard (AES-128)"}, > + {CALG_AES_192, 192,192, 192,0, 8,"AES-192", > 39,"Advanced Encryption Standard (AES-192)"}, > + {CALG_AES_256, 256,256, 256,0, 8,"AES-256", > 39,"Advanced Encryption Standard (AES-256)"}, > > I'm not sure AES support should be included in every "personality" of > rsaenh. Specifically, some cryptographic providers don't support it. > Here's a blog that mentions how the MS_ENHANCED_PROV provider doesn't > support it, but the MS_ENH_RSA_AES_PROV does: > http://sys.cs.rice.edu/~sethn/wordpress/?p=19 I think I'll split the patch into 3 parts 1) basic AES implementation in rsaenh 2) Add AES provider info with registering MS_ENH_RSA_AES_PROV. I have to make aProvEnumAlgsEx[4][RSAENH_MAX_ENUMALGS+1] to aProvEnumAlgsEx[5][RSAENH_MAX_ENUMALGS+1] and add the new algorithms, can you help me what algo's should I add to the new one. Add the registering code for type24 provider. 3) Tests > > + if (!result) { > + /* rsaenh compiled without OpenSSL */ > + ok(GetLastError()==NTE_BAD_ALGID, "%08x\n", GetLastError()); > + return; > + } > > Our rsaenh hasn't built against OpenSSL in some time, so this test > should be removed from existing tests. You don't need to do that if > you don't want, but don't bother adding it to new tests. > > + result = CryptEncrypt(hKey, (HCRYPTHASH)NULL, TRUE, 0, pbData, &dwLen, 16); > + ok(result, "%08x\n", GetLastError()); > + > + result = CryptDecrypt(hKey, (HCRYPTHASH)NULL, TRUE, 0, pbData, &dwLen); > + ok(result, "%08x\n", GetLastError()); > > You should check that the encrypted output matches some expected > value, and that the decrypted output matches the plaintext input. Well, I have tested the decrypted output by putting printf's. I will make sure we have good tests for it. Will send new patch set soon. > > Thanks very much for getting this started. > --Juan >

Nov. 9, 2007

Valgrind results for Oct 9: still lots of hangs

by Dan Kegel

Results for today's git (plus my dde patch) are online at http://kegel.com/wine/valgrind/20071109/ ole32/tests/marshall.c has always been hanging when run under valgrind. In the last two days, the following additional tests hang under valgrind: mshtml/tests/dom.c mshtml/tests/htmldoc.c ole32/tests/marshal.c shdocvw/tests/webbrowser.c I can reproduce one hang with cd dlls/mshtml/tests make testclean wineserver -k RUNTEST_USE_VALGRIND=1 make test (with the wine-vg-utils.patch I provide. Make by itself does not behave well under valgrind, so you can't just do "valgrind make test"). Sadly, I don't have time to do a regression test, but it's pretty easy to repeat my results. See http://wiki.winehq.org/Wine_and_Valgrind It'd be nice if somebody else verified that these hangs occur for them too, that they didn't occur with wine-0.9.48, and maybe did a regression test to find out when they started... - Dan

Nov. 9, 2007

Re: CryptAcquireContext Failure, default/Type 024 requested

by Juan Lang

Hi Vijay, you forgot aes.c in your patch - please remember to git add it, then commit it along with the rest of the changes. >From what you've sent, your patch looks pretty good so far. A few comments: @@ -161,6 +162,10 @@ static const PROV_ENUMALGS_EX aProvEnumAlgsEx[4][RSAENH_MAX_ENUMALGS+1] = {CALG_RC2, 40, 40, 56,0, 4,"RC2", 24,"RSA Data Security's RC2"}, {CALG_RC4, 40, 40, 56,0, 4,"RC4", 24,"RSA Data Security's RC4"}, {CALG_DES, 56, 56, 56,0, 4,"DES", 31,"Data Encryption Standard (DES)"}, + {CALG_AES, 128,128, 128,0, 4,"AES", 35,"Advanced Encryption Standard (AES)"}, + {CALG_AES_128, 128,128, 128,0, 8,"AES-128", 39,"Advanced Encryption Standard (AES-128)"}, + {CALG_AES_192, 192,192, 192,0, 8,"AES-192", 39,"Advanced Encryption Standard (AES-192)"}, + {CALG_AES_256, 256,256, 256,0, 8,"AES-256", 39,"Advanced Encryption Standard (AES-256)"}, I'm not sure AES support should be included in every "personality" of rsaenh. Specifically, some cryptographic providers don't support it. Here's a blog that mentions how the MS_ENHANCED_PROV provider doesn't support it, but the MS_ENH_RSA_AES_PROV does: http://sys.cs.rice.edu/~sethn/wordpress/?p=19 + if (!result) { + /* rsaenh compiled without OpenSSL */ + ok(GetLastError()==NTE_BAD_ALGID, "%08x\n", GetLastError()); + return; + } Our rsaenh hasn't built against OpenSSL in some time, so this test should be removed from existing tests. You don't need to do that if you don't want, but don't bother adding it to new tests. + result = CryptEncrypt(hKey, (HCRYPTHASH)NULL, TRUE, 0, pbData, &dwLen, 16); + ok(result, "%08x\n", GetLastError()); + + result = CryptDecrypt(hKey, (HCRYPTHASH)NULL, TRUE, 0, pbData, &dwLen); + ok(result, "%08x\n", GetLastError()); You should check that the encrypted output matches some expected value, and that the decrypted output matches the plaintext input. Thanks very much for getting this started. --Juan

Nov. 9, 2007

Re: CryptAcquireContext Failure, default/Type 024 requested

by Vijay Kiran Kamuju

Hi, I have implemented the AES support for rsaenh.dll Please test the attached patch. Thanks, VJ On Sep 24, 2007 12:04 PM, Rob Seger <rob.seger(a)gmail.com> wrote: > Sweet! Thanks! > > I'll see what I can do and probably end up asking some more specific > questions later ;) > > Rob > > > On 9/24/07, Juan Lang <juan.lang(a)gmail.com> wrote: > > > I found the wincrypt.h #define line that says what type 024 > > > is: #define PROV_RSA_AES 24. > > > > In that case, it should be straightforward enough to add an AES > > implementation to Wine's rsaenh.dll. There's free (as in speech) > > source available for it. Take a look at rsaenh.c and implglue.c in > > dlls/rsaenh; you'd want to add it as a new block cipher. > > > > --Juan > > > > >

Nov. 9, 2007

Re: winetest.exe broken

by Paul Vriens

Stefan Leichter wrote: > Hello, > > as you all may have noticed winetest.exe does not longer build (see > http://quisquiliae.physics.gla.ac.uk/crossbuild-logs/20071109-11:05.txt ). > The patch: > > 65d865d96313d96889bf8cbe88c931b5e1e9bb74 is first bad commit > commit 65d865d96313d96889bf8cbe88c931b5e1e9bb74 > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Thu Nov 8 12:21:10 2007 +0100 > > libwine: Refuse to use a WINEPREFIX dir owned by a different user. > > :040000 040000 1bf2b5da793741040732f222ce4a90ebd3f54b74 > ee36bfdcf5d65ec8bb1c8ee478e74e0af8679039 M libs > > broke the build. Can someone please fix this. > > Thanks Stefan > > > I think Paul Millar sent a fix already. -- Cheers, Paul.

Nov. 9, 2007

Re: winetest.exe broken

by John Klehm

Hi Stefan, On Nov 9, 2007 1:26 PM, Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: > Hello, > > as you all may have noticed winetest.exe does not longer build (see > http://quisquiliae.physics.gla.ac.uk/crossbuild-logs/20071109-11:05.txt ). > The patch: > > 65d865d96313d96889bf8cbe88c931b5e1e9bb74 is first bad commit > commit 65d865d96313d96889bf8cbe88c931b5e1e9bb74 > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Thu Nov 8 12:21:10 2007 +0100 > > libwine: Refuse to use a WINEPREFIX dir owned by a different user. > > :040000 040000 1bf2b5da793741040732f222ce4a90ebd3f54b74 > ee36bfdcf5d65ec8bb1c8ee478e74e0af8679039 M libs > > broke the build. Can someone please fix this. I think Paul Millar sent in a patch already: http://www.winehq.org/pipermail/wine-patches/2007-November/046515.html --John

Nov. 9, 2007