wine-devel March 2012

wine-devel@winehq.org

93 participants
206 discussions

Re: po: Update Lithuanian translation (resend)
by Alexandre Julliard 14 Mar '12

14 Mar '12

Aurimas Fišeras <aurimas(a)gmail.com> writes: > @@ -2190,16 +2190,14 @@ msgstr "" > "atšauktų liudijimų sąrašą ar patikintų liudijimų sąrašą:" > > #: cryptui.rc:296 > -#, fuzzy > #| msgid "Cryptographic Message Syntax Standard/PKCS #7 Messages (.p7b)" > msgid "Cryptographic Message Syntax Standard/PKCS #7 Messages (*.p7b)" > -msgstr "Kriptografinio pranešimo sintaksės standarto/PKCS #7 pranešimai (.p7b)" > +msgstr "Kriptografinio pranešimo sintaksės standarto/PKCS #7 pranešimai (*.p7b)" You should also remove the previous string comment when updating fuzzy entries. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: jscript: Add VT_I2 support
by Jacek Caban 14 Mar '12

14 Mar '12

Hi Alistair, On 03/14/12 10:00, Alistair Leslie-Hughes wrote: > --- a/dlls/jscript/jsutils.c > +++ b/dlls/jscript/jsutils.c > @@ -187,11 +187,14 @@ HRESULT to_primitive(script_ctx_t *ctx, VARIANT *v, jsexcept_t *ei, VARIANT *ret > case VT_EMPTY: > case VT_NULL: > case VT_BOOL: > - case VT_I2: First of all, this is not a patch against current Git. You're changing core parts of jscript and I'd really like an evidence that it's done in the right direction. There are many parts of code that assume given types are returned as result, so I'm really picky about getting this right. In your previous test you had getVT that was hiding the difference between VT_I4 and VT_I2. I've asked you about better test and now you've removed tests that were using getVT at all and took my guesses as assumptions for implementation. Please add proper tests that really show your implementing things really the right way. Hint: it may be easier to concentrate one one aspect, say to_number which is easy to test, first. That patch may be well split. Cheers, Jacek

1 0

Re: kernel32/tests: Verify the stability of CreateTimerQueue.
by Austin English 14 Mar '12

14 Mar '12

On Wed, Mar 14, 2012 at 05:32, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > this should have been labeled [PATCH 3/3] because tests will fail without my 2 ntdll patches. > > First a note unrelated to my patches: if you run the tests in git in a loop, > sometimes one DeleteTimerQueueTimer(INVALID_HANDLE_VALUE) > fails (presumably with IO_PENDING) because a callback was executing concurrently. > Did Dan or anybody else running tests repeatedly observe this? > Surprisingly, test.winehq shows next to nothing like this: > http://test.winehq.org/data/tests/kernel32:sync.html > but one failure comes close (not sure if it's the same): > http://test.winehq.org/data/e79644e6a96eae419082ec78ce8ff3294888d05d/2000_f… > sync.c:867: Test failed: DeleteTimerQueueTimer The list of tests that are skipped by buildbot is at: http://code.google.com/p/winezeug/source/browse/trunk/buildbot/dotests_blac… kernel32/sync is not on the list (nor do I see any emails from buildbot for it failing). -- -Austin

1 0

Having problems with building a deb package of the sources
by Rahul Ghose 14 Mar '12

14 Mar '12

I am using the 1.4-rc6 source code to build the deb package. The source compiles smoothly but debuild -us -uc fails with this message: (last few lines, I hope which are more relevant) ../../../tools/runtest -q -P wine -M atl.dll -T ../../.. -p atl_test.exe.soatl_ax.c && touch atl_ax.ok Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. err:systray:initialize_systray Could not create tray window Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. fixme:atl:OleClientSite_ShowObject (0x170ed0) - stub fixme:atl:OleClientSite_ShowObject (0x178cb0) - stub fixme:atl:OleClientSite_ShowObject (0x178cf8) - stub atl_ax.c:110: Test failed: Expected AtlAxAttachControl to return S_OK, got 0x00000001 make[2]: *** [atl_ax.ok] Error 1 make[2]: Leaving directory `/home/rahul/Programming/Projects/Downloaded/Wine/wine-1.4-rc6/dlls/atl/tests' make[1]: *** [dlls/atl/tests/__test__] Error 2 make[1]: Leaving directory `/home/rahul/Programming/Projects/Downloaded/Wine/wine-1.4-rc6' dh_auto_test: make -j1 test returned exit code 2 make: *** [build] Error 29 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1348: dpkg-buildpackage -rfakeroot -D -us -uc failed Any help regarding this? (I am not sure if this is the best mailing list to send this query to, but I got no help from the wine-users mailing list) Thanks in advance.

3 2

Re: gdiplus: Use StretchBlt instead of GdiAlphaBlend if device doesn't support alpha blending.
by Vincent Povirk 14 Mar '12

14 Mar '12

Uh, in many cases this will be worse than a failed draw.

2 7

Preprocessing asm shaders
by Józef Kucia 13 Mar '12

13 Mar '12

Hi, I'm writing because I found a bug in asm shader preprocessor in Wine and I'm not sure what's the best way to fix it. The D3DPreprocess function is an universal shader preprocess for HLSL and asm shaders. In fact, it's C-like language preprocessor and it doesn't understand assembler style comments (comments from ';' to the end of line). The fact that it doesn't understand these comments is a root of whole problem. Valid asm shaders can contain single or double quotation characters in assembler style comments, and these quotation characters will be treated as a beginning of quoted string constants while preprocessing. The Wine's implementation of D3DPreprocess behaves differently than Windows implementation in respect to strings passing the end of line. Generally, strings passing the end of line are an error in C, but they can result in a correct asm shader when contained in a assembler style comment. D3DPreprocess on Windows works fine for shaders which contains single or double quotation marks. It only issues an error in case of unmatched double quotation mark, but returns D3D_OK anyway. In Wine situation is different, wpp tries to find a matching quotation mark to the end of file, while shader preprocessor on Windows gives up on parsing a string when it gets a first newline character. The result of wpp's behavior is a truncated output and an error returned from D3DPreprocess. I wonder if it's fine to change wpp behavior for strings passing the end of line to mimic the behavior observed on Windows. Perhaps, strings passing the end of line could be treated as an error by default. Whereas D3DCompiler would activate an option to treat such strings as a warning. Thanks, Józef Kucia

3 5

Re: msvcp90/tests: Don't redefine __thiscall (resend).
by Alexandre Julliard 13 Mar '12

13 Mar '12

Nicolas Le Cam <niko.lecam(a)gmail.com> writes: > @@ -60,11 +60,13 @@ static char* (__cdecl *p_Copy_s)(char*, size_t, const char*, size_t); > static unsigned short (__cdecl *p_wctype)(const char*); > static MSVCP__Ctypevec (__cdecl *p__Getctype)(void); > > +#ifndef __thiscall > #ifdef __i386__ > #define __thiscall __stdcall > #else > #define __thiscall __cdecl > #endif > +#endif That seems dangerous, we don't know what it has been defined to. -- Alexandre Julliard julliard(a)winehq.org

2 1

use assert etc. in Wine dlls? What is better?
by Joerg-Cyril.Hoehle＠t-systems.com 13 Mar '12

13 Mar '12

Hi, Maarten's wine-pulse contains several instances of assert() I've been thinking about adding a bit of protection against inconcsistencies within mmdevapi code too. There are two variants that could be applicable depending on the situation: /* this should not happen, but if we detect it early, we can work-around the situation */ if (a > limit) { ERR("%d > %d\n", a, limit); a = limit; } or assert(a <= limit, "whatever %d", a); I'm not too fond of assert. An assert in DSound was one of my first bug fixes in Wine, years ago. It was not obvious why the app should not continue running -- perhaps without sound. OTOH, if an assert is violated, as a programmer, I'd like to hear about it. I found little on that topic in Wine. In 2002, Alexandre Julliard wrote: http://www.winehq.org/pipermail/wine-devel/2002-October/009766.html >A better approach would be to leave assert() alone, and raise an >exception on the SIGABRT signal. What is current opinion on this topic? Thank you, Jörg Höhle

4 3

What happens upon mmdevapi capture overrun on native?
by Joerg-Cyril.Hoehle＠t-systems.com 13 Mar '12

13 Mar '12

Hi, Maarten Lankhorst wrote in winepulse: Add pulseaudio driver, v9: >- Reworked capture logic to always capture, since that seems to be the case on windows, > when stopped we simply drop whole packets, but keep firing the event. Does anybody know what precisely happens upon overrun during capture? A. mmdevapi fills the whole buffer once. It keeps firing events and sets the DISCONTINUITY flag upon the next CaptureClient_GetBuffer. This is like mciwave's "record from 0 to 5000" command. The client can read the oldest recorded samples. B. mmdevapi continuously overwrites the circular buffer. It keeps firing events and sets the DISCONTINUITY flag too. The client gets to see the newest recorded samples. It's like your TV recorder's time shift function that can only travel back by as much as the buffer holds. C. Other, e.g. mixing newest with older packets (current winealsa). In other words, what data does the dlls/mmdevapi/capture test see in: http://source.winehq.org/source/dlls/mmdevapi/tests/capture.c?v=wine-1.4-rc… I think A makes sense but really I don't know. The tests show a position jump by one period worth of frames when reading the next packet after an overrun. That's not what I'd expect from behaviour A. But from behaviour B I'd expect a much larger position jump, as large as elapsed time. We really need somebody with a microphone and Vista/w2k8/w7 to tell us what happens. Does anybody know what DSound does in such a case? (not that it matters...) Thank you, Jörg Höhle

2 3

Re: jscript: Add VT_I2 support
by Jacek Caban 13 Mar '12

13 Mar '12

Hi Alistair, On 03/13/12 10:36, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > jscript: Add VT_I2 support static inline BOOL is_num_vt(enum VARENUM vt) { - return vt == VT_I4 || vt == VT_R8; + return vt == VT_I4 || vt == VT_I2 ||vt == VT_R8; } I'm not sure we want this handled this way. I'd much rather make sure VT_I2 (which is not internal jscript type, so it may come only from external/host objects) is never supposed to return TRUE here. If it's unavoidable, it requires convincing tests. static inline DOUBLE num_val(const VARIANT *v) { - return V_VT(v) == VT_I4 ? V_I4(v) : V_R8(v); + switch(V_VT(v)) + { + case VT_I2: + return V_I2(v); + case VT_I4: + return V_I4(v); + case VT_R8: + return V_R8(v); + } + + return 0; } It's similar here, I don't think we want to allow num_val calls on VT_I2. @@ -187,6 +187,7 @@ HRESULT to_primitive(script_ctx_t *ctx, VARIANT *v, jsexcept_t *ei, VARIANT *ret case VT_EMPTY: case VT_NULL: case VT_BOOL: + case VT_I2: That seems like a likely place for VT_I2->VT_I4 conversion. @@ -569,6 +574,9 @@ HRESULT to_string(script_ctx_t *ctx, VARIANT *v, jsexcept_t *ei, BSTR *str) case VT_NULL: *str = SysAllocString(nullW); break; + case VT_I2: + *str = int_to_bstr(V_I2(v)); + break; I'd like to see it covered by tests. @@ -76,7 +76,9 @@ static HRESULT Number_toString(script_ctx_t *ctx, vdisp_t *jsthis, WORD flags, D return throw_type_error(ctx, ei, JS_E_INVALIDARG, NULL); } - if(V_VT(&number->num) == VT_I4) + if(V_VT(&number->num) == VT_I2) + val = V_I2(&number->num); + else if(V_VT(&number->num) == VT_I4) I'd much rather keep the assumption that Number stores only VT_I4 or VT_R8. +objI2 = createVT_I2(); +ok(getVT(objI2) === "VT_I4", "getVT(obj) = " + getVT(objI2)); Hmm, this together with this: @@ -603,6 +608,7 @@ static HRESULT WINAPI Global_InvokeEx(IDispatchEx *iface, DISPID id, LCID lcid, case VT_NULL: V_BSTR(pvarRes) = a2bstr("VT_NULL"); break; + case VT_I2: case VT_I4: V_BSTR(pvarRes) = a2bstr("VT_I4"); break; loses the point of this test. +ok(objI2.toString() === "2", "obj = " + objI2.toString()); +function funcLoopI2() +{ + var i = 0; + /* Tests: to_primitive, to_number */ + for(; i < objI2; i++) + ; + ok(i == objI2, "i(" + i + ") != 1"); +} + +funcLoopI2(); These tests don't really show much about how VT_I2 is handled. Please try to make them striker and closer to implementation details. Also objI2 is not really a nice name for something that's not an object. + if(!strcmp_wa(bstrName, "createVT_I2")) { + *pid = DISPID_GLOBAL_CREATE_I2; + return S_OK; + } A better name would be nice. Cheers, Jacek

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2012