Re: [PATCH] ntdll/tests: Added tests for ObjectTypeInformation class in NtQueryObject
On 07/05/2011 07:20 PM, Austin Lund wrote: +todo_wine ok( len>= sizeof(UNICODE_STRING) + 88 + sizeof(type_event) + sizeof(WCHAR), "unexpected len %u\n", len ); What is that magic number "88"? If it's a size of some structure - then please use it explicitly. Vitaliy.
Re: [1/10] dinput: Implement IDirectInput::RunControlPanel.
On 07/05/2011 06:18 AM, Andrew Nguyen wrote: --- dlls/dinput/dinput_main.c | 15 - dlls/dinput/tests/Makefile.in |1 + dlls/dinput/tests/dinput.c| 69 + 3 files changed, 84 insertions(+), 1 deletions(-) create mode 100644 dlls/dinput/tests/dinput.c Patches look good to me. Vitaliy.
Re: [PATCH 1/5] d3dx9_36: Implement D3DXHANDLE more robustly
On 5 July 2011 23:45, Travis Athougies wrote:
> Fixes bug 26583.
>
> Allows deadspace 2 to run without native dlls.
This contains no useful information about what issue this is supposed
to fix, unless you expect people to actually debug it themselves
first. And I even went through the trouble to lookup the bug.
> +static WORD new_handle_with_desc_and_name(ID3DXConstantTableImpl* This,
> D3DXCONSTANT_DESC* desc, LPCSTR name, LPCSTR full_name)
> +{
> + ++This->handle_count;
> + if (This->handles)
> + This->handles = HeapReAlloc(GetProcessHeap(), 0, This->handles,
> sizeof(ctab_handle) * This->handle_count);
> + else
> + This->handles = HeapAlloc(GetProcessHeap(), 0, sizeof(ctab_handle) *
> This->handle_count);
> +
> + This->handles[This->handle_count - 1].desc = *desc;
> + This->handles[This->handle_count - 1].desc.Name = strdup(name);
> + This->handles[This->handle_count - 1].full_name = strdup(full_name);
> +
> + return This->handle_count;
> +}
That's just terrible.
Re: d3dx9_36: Push down the scope of two variables. (RESEND)
I think the point is more that (in general) this kind of patch is unlikely to be accepted unless you're actively maintaining the code.
Re: d3dx9_36: Push down the scope of two variables. (RESEND)
Am 05.07.2011 20:33, schrieb Gerald Pfeifer: On Tue, 5 Jul 2011, Alexandre Julliard wrote: This does not fix a bug or add a feature, but it makes the coder easier to follow. Narrower scope tends to be a good thing for variables, both for human readers and compilers (though modern ones should not need the hint). Not necessarily, that's a matter of taste (IOW, not something you should "fix" in other people's code). The reason I came up with this patch is that trying to debug something I got lost a bit, and reducing the scope of these variables really helped make things easier to follow. When you are referring to "other people's code", according to git log Tony has been the primary contributor, so that would be his call then? Tony, this is http://www.winehq.org/pipermail/wine-patches/2011-July/103866.html -- what's your take? Gerald I doubt this change is critical enough to justify any need for the original author's opinion :P I personally prefer narrow scope as well usually... if you want to change it, sure, I'm unlikely to touch that code ever again anyway.. Best regards, Tony
Re: [PATCH 1/2] d3dx9/line: Implement Begin and End methods. (try 2)
On Tue, Jul 5, 2011 at 2:46 PM, Charles Welton wrote: > Is there a reason why this patch and it's brother weren't merged in yet? > This has been sitting for a few days and no comments about it yet. > According to http://source.winehq.org/patches/ #75906 it has yet to be looked at by AJ. Just have to wait it out. --John
Re: [PATCH 1/2] d3dx9/line: Implement Begin and End methods. (try 2)
Is there a reason why this patch and it's brother weren't merged in yet? This has been sitting for a few days and no comments about it yet. On 06/29/2011 07:08 PM, Charles Welton wrote: > Since the last patch spent some time without comments and wasn't > commited, I'm resending. > > Try 2 because of TRACE calls and whitespace fixes. > > --- > dlls/d3dx9_36/line.c | 73 > +++--- > 1 files changed, 69 insertions(+), 4 deletions(-) > > -- Charles Welton
Re: [4/9] msxml3: Implement IXMLDOMNodeList::QueryInterface(IEnumVARIANT).
On 07/05/2011 11:23 AM, Nikolay Sivov wrote:
On Tue, Jul 5, 2011 at 8:11 PM, Adam Martinson
wrote:
---
dlls/msxml3/nodelist.c | 33 -
dlls/msxml3/selection.c | 34 --
2 files changed, 64 insertions(+), 3 deletions(-)
+else if ( IsEqualGUID( riid,&IID_IEnumVARIANT ) )
+{
+if (!This->enumv&&
+(This->enumv = create_nodelist_enum(&This->IXMLDOMNodeList_iface)))
+IXMLDOMNodeList_Release(iface); /*
create_nodelist_enum() adds a ref, and we don't here. */
+
+if (!This->enumv)
+{
+*ppvObject = NULL;
+return E_OUTOFMEMORY;
+}
+
+IEnumVARIANT_AddRef(This->enumv);
+*ppvObject = This->enumv;
+return S_OK;
+}
Shouldn't this->enumv be protected somehow to work with multiple
threads? I know that so called FreeThreaded* thing is only reported to
be supported, but still. Maybe something like pointer exchange call
will work.
I like that idea, thanks!
Re: [PATCH] wscript: implemented Host_get_BuildVersion
On 07/04/2011 11:28 PM, Michał Ziętek wrote: +ok(typeof(WScript.BuildVersion) === "number", "typeof(WScript.BuldVersion) = " + typeof(WScript.BuldVersion)); Patch is already committed but there is a typo here 'BuldVersion' instead of 'BuildVersion'. -- Cheers, Paul.
Re: [4/9] msxml3: Implement IXMLDOMNodeList::QueryInterface(IEnumVARIANT).
On Tue, Jul 5, 2011 at 8:11 PM, Adam Martinson
wrote:
> ---
> dlls/msxml3/nodelist.c | 33 -
> dlls/msxml3/selection.c | 34 --
> 2 files changed, 64 insertions(+), 3 deletions(-)
>
>
+else if ( IsEqualGUID( riid, &IID_IEnumVARIANT ) )
+{
+if (!This->enumv &&
+(This->enumv = create_nodelist_enum(&This->IXMLDOMNodeList_iface)))
+IXMLDOMNodeList_Release(iface); /*
create_nodelist_enum() adds a ref, and we don't here. */
+
+if (!This->enumv)
+{
+*ppvObject = NULL;
+return E_OUTOFMEMORY;
+}
+
+IEnumVARIANT_AddRef(This->enumv);
+*ppvObject = This->enumv;
+return S_OK;
+}
Shouldn't this->enumv be protected somehow to work with multiple
threads? I know that so called FreeThreaded* thing is only reported to
be supported, but still. Maybe something like pointer exchange call
will work.
Re: winedevice: eliminate the driver_name global variable
On Tue, Jul 5, 2011 at 4:23 PM, Alexandre Julliard wrote: > Damjan Jovanovic writes: > >> Changelog: >> * winedevice: eliminate the driver_name global variable >> >> This is part of general refactoring to make the driver loading code reusable. > > Have you fixed it since last time or is it the same patch? Either way > it's still crashing. > > -- > Alexandre Julliard > julli...@winehq.org > It's a subset of the previous patch. I've finally found the problem, it only shows up with a clean wineprefix. Damjan
Re: d3dx9_36: Push down the scope of two variables. (RESEND)
Gerald Pfeifer writes: > This does not fix a bug or add a feature, but it makes the coder easier > to follow. Narrower scope tends to be a good thing for variables, both > for human readers and compilers (though modern ones should not need the > hint). Not necessarily, that's a matter of taste (IOW, not something you should "fix" in other people's code). -- Alexandre Julliard julli...@winehq.org
Re: winedevice: eliminate the driver_name global variable
Damjan Jovanovic writes: > Changelog: > * winedevice: eliminate the driver_name global variable > > This is part of general refactoring to make the driver loading code reusable. Have you fixed it since last time or is it the same patch? Either way it's still crashing. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 03/10] winmm: Implement waveOut* on top of MMDevAPI
Andrew Eikum writes:
> +static MMRESULT WINMM_SendDeviceThreadMessage(UINT msg, WPARAM wp)
> +{
> +DWORD wait;
> +MMRESULT res;
> +
> +EnterCriticalSection(&g_devthread_lock);
> +
> +if(!PostThreadMessageW(g_devthread_id, msg, wp, (DWORD_PTR)&res)){
> +ERR("PostThreadMessage failed: %d\n", GetLastError());
> +LeaveCriticalSection(&g_devthread_lock);
> +return MMSYSERR_ERROR;
> +}
> +
> +wait = WaitForSingleObject(g_devthread_evt, INFINITE);
> +
> +LeaveCriticalSection(&g_devthread_lock);
If you are going to wait for a reply it would be better to create a
HWND_MESSAGE window and do a SendMessage to it, then you get all the
synchronization for free.
--
Alexandre Julliard
julli...@winehq.org
Re: d3dx9_36: Use cross-platform versions of infinity and NaN.
On Tue, Jul 5, 2011 at 8:27 AM, Marvin wrote: > === WXPPROSP3 (32 bit math) === > math.c:2275: Test failed: Got , expected 7fff or 7fff for index 18. 0.0f/0.0f = -nan (0xffc0) -(0.0f/0.0f) = nan (0x7fc0) msvc complains about dividing by zero. I found the following works around the error for MS Visual Studio 2010, although later version might try to be "smarter". static const float z = 0.0f; const float neg_nan = 0.0f/z; const float pos_nan = -(0.0f/z); Note that neg_nan and pos_nan can't be static.
Re: Glitch-free iTunes?
Hey, On 07/05/2011 10:49 AM, Charles Davis wrote: > On 7/5/11 2:23 AM, Damjan Jovanovic wrote: >> On Tue, Jul 5, 2011 at 10:13 AM, Stefan Dösinger >> wrote: >>> Do we need full-fledged support for USB drivers for iTunes? I've been told >>> in >>> the past that all we need to do is properly report the new USB drive to >>> iTunes >>> when an iPod is attached, and can leave the USB mass storage handling to the >>> Linuy OS. Of course "properly reporting" isn't as simple as creating a drive >>> letter and setting its type to USB drive. >>> >>> I'm sorry to interrupt this nice project management discussion by throwing >>> in >>> a technical question :-) >>> >>> >> It used to work that way, but Dan Kegel's analysis of a recent version >> of iTunes seems to indicate it now pulls in USBD.SYS. Maybe they >> changed it or maybe they now do direct USB I/O in addition to going >> through the mass storage interface? > I have a Mac, and an iPod Touch. When I plug the iPod in, it doesn't > show up as an external disk in the Finder. So on Mac, iTunes definitely > does direct USB I/O. It's probably safe to assume it does on Windows, too. There are 2 ways really. Old ipods used usb mass storage which I had working at 1 point, but in a hacky way. ipod touch and iphone need direct usb, which never worked. ~Maarten
Re: [3/6] wined3d: Use dummy textures for all the texture targets when the texture is unset.
On 4 July 2011 22:32, Matteo Bruni wrote:
> +if ((!texture && old_texture_type != GL_NONE) || (texture &&
> texture->target != old_texture_type))
> +{
Actually, just thought of this now, but I'm not sure you can do this
like that. The way you're using old_texture_type it's context state,
not device state.
Re: [3/6] wined3d: Use dummy textures for all the texture targets when the texture is unset.
On 4 July 2011 22:32, Matteo Bruni wrote:
> +TRACE("Dummy 2D texture %d given name %d.\n", i,
> device->dummyTextureName[i]);
This is pretty minor, but those are unsigned.
Re: gdi32: Make GdiTransparentBlt clipping aware (try2)
Piotr Caban writes:
> @@ -392,6 +394,15 @@ BOOL WINAPI GdiTransparentBlt( HDC hdcDest, int xDest,
> int yDest, int widthDest,
> hdcWork = CreateCompatibleDC(hdcDest);
> bmpWork = CreateCompatibleBitmap(hdcDest, widthDest, heightDest);
> oldWork = SelectObject(hdcWork, bmpWork);
> +use_clip_rect = GetClipBox(hdcDest, &clip_rect);
> +if(use_clip_rect) {
> +clip_rect.left -= xDest;
> +clip_rect.top -= yDest;
> +clip_rect.right -= xDest;
> +clip_rect.bottom -= yDest;
> +IntersectClipRect(hdcWork, clip_rect.left, clip_rect.top,
> clip_rect.right, clip_rect.bottom);
> +}
You need to handle logical coordinates mapping.
--
Alexandre Julliard
julli...@winehq.org
Re: d3dx9_36: Use cross-platform versions of infinity and NaN.
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 http://testbot.winehq.org/JobDetails.pl?Key=12221 Your paranoid android. === WXPPROSP3 (32 bit math) === math.c:2275: Test failed: Got , expected 7fff or 7fff for index 18. === W2K3R2SESP2 (32 bit math) === math.c:2275: Test failed: Got , expected 7fff or 7fff for index 18. === WVISTAADM (32 bit math) === math.c:2275: Test failed: Got , expected 7fff or 7fff for index 18. === W2K8SE (32 bit math) === math.c:2275: Test failed: Got , expected 7fff or 7fff for index 18. === W7PRO (32 bit math) === math.c:2275: Test failed: Got , expected 7fff or 7fff for index 18. === W7PROX64 (32 bit math) === math.c:2275: Test failed: Got , expected 7fff or 7fff for index 18.
Re: [6/6] wined3d: Don't apply and invalidate the framebuffer when clearing the device's fb (try 2)
On 5 July 2011 10:27, Stefan Dösinger wrote: > -/* TODO: This is not necessary if the framebuffer is the device's > current framebuffer */ > -context_invalidate_state(context, STATE_FRAMEBUFFER, > device->StateTable); But you do need to invalidate if it isn't.
Re: propkeydef.h: Fixed DEFINE_PROPERTYKEY define
On 07/05/11 13:50, Alexandre Julliard wrote:
> Jacek Caban writes:
>
>> @@ -33,18 +33,16 @@
>> #ifdef INITGUID
>> #ifdef __cplusplus
>> #define DEFINE_PROPERTYKEY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8,
>> pid) \
>> -EXTERN_C const PROPERTYKEY name DECLSPEC_HIDDEN DECLSPEC_SELECTANY;
>> \
>> -EXTERN_C const PROPERTYKEY name = \
>> +EXTERN_C const PROPERTYKEY DECLSPEC_SELECTANY name = \
>> { { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }, pid }
>> #else
>> #define DEFINE_PROPERTYKEY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8,
>> pid) \
>> -const PROPERTYKEY name DECLSPEC_HIDDEN DECLSPEC_SELECTANY; \
>> -const PROPERTYKEY name = \
>> +const PROPERTYKEY DECLSPEC_SELECTANY name = \
>> { { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }, pid }
>> #endif
>> #else
>> #define DEFINE_PROPERTYKEY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8,
>> pid) \
>> -EXTERN_C const PROPERTYKEY name DECLSPEC_HIDDEN DECLSPEC_SELECTANY
>> +EXTERN_C const PROPERTYKEY name
> Do you really want to remove DECLSPEC_HIDDEN?
My main point was to use DECLSPEC_SELECTANY properly. It just looked
wrong to add our extensions to public headers, but on the second
thought, DECLSPEC_HIDDEN seems right. I've sent an updated patch.
Thanks,
Jacek
Re: propkeydef.h: Fixed DEFINE_PROPERTYKEY define
Jacek Caban writes:
> @@ -33,18 +33,16 @@
> #ifdef INITGUID
> #ifdef __cplusplus
> #define DEFINE_PROPERTYKEY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8,
> pid) \
> -EXTERN_C const PROPERTYKEY name DECLSPEC_HIDDEN DECLSPEC_SELECTANY; \
> -EXTERN_C const PROPERTYKEY name = \
> +EXTERN_C const PROPERTYKEY DECLSPEC_SELECTANY name = \
> { { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }, pid }
> #else
> #define DEFINE_PROPERTYKEY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8,
> pid) \
> -const PROPERTYKEY name DECLSPEC_HIDDEN DECLSPEC_SELECTANY; \
> -const PROPERTYKEY name = \
> +const PROPERTYKEY DECLSPEC_SELECTANY name = \
> { { l, w1, w2, { b1, b2, b3, b4, b5, b6, b7, b8 } }, pid }
> #endif
> #else
> #define DEFINE_PROPERTYKEY(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8,
> pid) \
> -EXTERN_C const PROPERTYKEY name DECLSPEC_HIDDEN DECLSPEC_SELECTANY
> +EXTERN_C const PROPERTYKEY name
Do you really want to remove DECLSPEC_HIDDEN?
--
Alexandre Julliard
julli...@winehq.org
Re: Glitch-free iTunes?
Perhaps such response is due to my language barrier, but... * On Mon, 4 Jul 2011, Keith Curtis wrote: > > I bring up Linus because he can focus efforts. You don't need Linus. You > just need the same result -- focused efforts. There is another name for this > concept -- teams. Maybe WINE needs sub-teams? Keith, maybe you should contact Codeweavers to persuade the right persons? :) > However, you have accomplished so much already. Year after year, you > accomplish more, and yet you just think that it is hopeless or > something. What makes you say the last part (mentioning hopelessness)? > And one worthy goal is iTunes runs better than on Windows. If you had > that as a goal 5 years ago, you would have succeeded by now. Then 64-bit Wine port, DIB engine/rewrite wouldn't be started; XI2, XRender, Xcursor support, IO completion ports wouldn't have been born; Winsock, OpenGL in child windows, Systray would work in much buggier way; and APC would fail in addition to 16-32 bit thunking issues. I've forgot to mention countless fixes for window handling subsystem (in managend and unmanaged mode), COM mechanisms such as proxy delegations, marshaling, stubless proxies, RPC, Widl, X11 CopyPaste support, Inetcomm, Winhttp, implementations. Plus ton of Unicode fixes. All that would stay broken / unfixed / unimplemented. But iTunes would probably work (in possibly wrongly architectured way). Would such tradeoff be OK for the community? No offense, but I doubt it. > I understand that WINE has many apps that you want to work. You are doing > well. It is just missing some features that are not being caught by your > random work. I know you'll get there, in the next 10 years. Perhaps by the > time Apple no longer matters you'll have it working. BTW, Keith, could you please estimate how much people / work hrs were used to make XP a final product + produce security fixes? (And that's counting 25 years!) I guess a lot more people / hrs than it is used for Wine. My rough guess is 10 times. In the case of Linux kernel, it is very different game, IMHO. (less restrictions and INSANE compatibility issues:) But you could always contact our "dictator-in-chief" Alexandre to hear the last decision on project managament:) My two cents, S.
Re: Misha Koshelev : d3dx9_36: Implement and add tests for D3DXFloat16To32Array .
Hello Misha,
Alexandre Julliard wrote:
> Module: wine
> Branch: master
> Commit: a6b40624dbc457ba7b0b4b307b1eb88617c67197
> URL:
> http://source.winehq.org/git/wine.git/?a=commit;h=a6b40624dbc457ba7b0b4b307b1eb88617c67197
>
> Author: Misha Koshelev
> Date: Wed Jun 29 11:16:29 2011 -0400
>
> d3dx9_36: Implement and add tests for D3DXFloat16To32Array.
>
> ---
>
> dlls/d3dx9_36/d3dx9_36.spec |2 +-
> dlls/d3dx9_36/math.c| 32 +++
> dlls/d3dx9_36/tests/math.c | 60
> +++
> 3 files changed, 93 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/d3dx9_36/tests/math.c b/dlls/d3dx9_36/tests/math.c
> index 5ad1924..aa3f135 100644
> --- a/dlls/d3dx9_36/tests/math.c
> +++ b/dlls/d3dx9_36/tests/math.c
> @@ -2215,6 +2216,64 @@ static void test_D3DXVec_Array(void)
...
> +{ NAN, 0x7fff, 0x7fff, 131008.0f, 131008.0f },
> +{ -NAN, 0x, 0x, -131008.0f, -131008.0f },
this breaks compilation on systems that don't have NAN.
bye
michael
Re: Glitch-free iTunes?
On 7/5/11 2:23 AM, Damjan Jovanovic wrote: > On Tue, Jul 5, 2011 at 10:13 AM, Stefan Dösinger > wrote: >> Do we need full-fledged support for USB drivers for iTunes? I've been told in >> the past that all we need to do is properly report the new USB drive to >> iTunes >> when an iPod is attached, and can leave the USB mass storage handling to the >> Linuy OS. Of course "properly reporting" isn't as simple as creating a drive >> letter and setting its type to USB drive. >> >> I'm sorry to interrupt this nice project management discussion by throwing in >> a technical question :-) >> >> > > It used to work that way, but Dan Kegel's analysis of a recent version > of iTunes seems to indicate it now pulls in USBD.SYS. Maybe they > changed it or maybe they now do direct USB I/O in addition to going > through the mass storage interface? I have a Mac, and an iPod Touch. When I plug the iPod in, it doesn't show up as an external disk in the Finder. So on Mac, iTunes definitely does direct USB I/O. It's probably safe to assume it does on Windows, too. Chip
Re: Glitch-free iTunes?
On Tue, Jul 5, 2011 at 10:13 AM, Stefan Dösinger wrote: > On Tuesday 05 July 2011 06:13:32 Damjan Jovanovic wrote: >> fix requires device drivers, changes to multiple systems, knowledge of >> Windows and Wine internals -> W is large > Do we need full-fledged support for USB drivers for iTunes? I've been told in > the past that all we need to do is properly report the new USB drive to iTunes > when an iPod is attached, and can leave the USB mass storage handling to the > Linuy OS. Of course "properly reporting" isn't as simple as creating a drive > letter and setting its type to USB drive. > > I'm sorry to interrupt this nice project management discussion by throwing in > a technical question :-) > > It used to work that way, but Dan Kegel's analysis of a recent version of iTunes seems to indicate it now pulls in USBD.SYS. Maybe they changed it or maybe they now do direct USB I/O in addition to going through the mass storage interface?
Re: Glitch-free iTunes?
On Tuesday 05 July 2011 06:13:32 Damjan Jovanovic wrote: > fix requires device drivers, changes to multiple systems, knowledge of > Windows and Wine internals -> W is large Do we need full-fledged support for USB drivers for iTunes? I've been told in the past that all we need to do is properly report the new USB drive to iTunes when an iPod is attached, and can leave the USB mass storage handling to the Linuy OS. Of course "properly reporting" isn't as simple as creating a drive letter and setting its type to USB drive. I'm sorry to interrupt this nice project management discussion by throwing in a technical question :-) signature.asc Description: This is a digitally signed message part.
