Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().
On 01.10.2013 12:40, Alexandre Julliard wrote: > Ralf Habacker writes: > >> On 01.10.2013 12:12, Alexandre Julliard wrote: >>> Ralf Habacker writes: >>> With other patches i have been told to implement such stuff in the dib driver. Unfortunally this do not works in this case, because in the top level function it looks like having driver specific stuff using display coordinates. >>> It would still most likely have to be in the driver, >> which is freetype_GetTextExtentExPoint() ? >> >>> though maybe the driver would not be calling that exact entry point. >> not sure i understand right: >> >> GetTextExtentExPointW() calls get_char_positions(), which runs >> dev->funcs->pGetTextExtentExPoint(), which is mapped to >> freetype_GetTextExtentExPoint(), which is in the driver. Which entry >> point your are refering else ? > The various text rendering entry points in the graphics drivers. > >>> In any case, you can't change the DC transform like this >> then a real solution requires to move the transformation to logical >> coordinates stuff in BOOL GetTextExtentExPointW() to >> freetype_GetTextExtentExPoint() and to manipulate the related matrixes >> in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ? > No, I don't think so. The transform is only used to determine the font > scaling factor. how then ? >>> and you'll need test cases. >>> >> Do you mean in detail: >> >> 1. Create a specific font >> 2. Run GetTextExtentExPointW() which specific parameters >> 3. check if it results expected values > Well, yes, that's what all tests do. >
Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().
On 01.10.2013 12:12, Alexandre Julliard wrote: > Ralf Habacker writes: > >> With other patches i have been told to implement such stuff in the dib >> driver. Unfortunally this do not works in this case, because in the top >> level function it looks like having driver specific stuff using display >> coordinates. > It would still most likely have to be in the driver, which is freetype_GetTextExtentExPoint() ? > though maybe the driver would not be calling that exact entry point. not sure i understand right: GetTextExtentExPointW() calls get_char_positions(), which runs dev->funcs->pGetTextExtentExPoint(), which is mapped to freetype_GetTextExtentExPoint(), which is in the driver. Which entry point your are refering else ? > In any case, you can't change the DC transform like this then a real solution requires to move the transformation to logical coordinates stuff in BOOL GetTextExtentExPointW() to freetype_GetTextExtentExPoint() and to manipulate the related matrixes in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ? > and you'll need test cases. > Do you mean in detail: 1. Create a specific font 2. Run GetTextExtentExPointW() which specific parameters 3. check if it results expected values Regards Ralf
Re: mshtml: Added support for 'document' and 'window' script for attribute values.
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://newtestbot.winehq.org/JobDetails.pl?Key=2427 Your paranoid android. === build (build) === Patch failed to apply
Re: imm32: ImmGetCandidateWindow should not return unset data
Ok, fixed and resent -aric On 10/1/13 2:13 PM, Alexandre Julliard wrote: > Aric Stewart writes: > >> @@ -663,6 +663,8 @@ HIMC WINAPI ImmCreateContext(void) >> gl->dwSize = sizeof(GUIDELINE); >> ImmUnlockIMCC(new_context->IMC.hGuideLine); >> >> +memset(new_context->IMC.cfCandForm, -1, >> sizeof(new_context->IMC.cfCandForm)); >> + > > That's ugly. If you are using the index for validity checking then you > should put some appropriate value in there, there's no reason to put > garbage in the whole structure. >
Re: imm32: ImmGetCandidateWindow should not return unset data
Aric Stewart writes: > @@ -663,6 +663,8 @@ HIMC WINAPI ImmCreateContext(void) > gl->dwSize = sizeof(GUIDELINE); > ImmUnlockIMCC(new_context->IMC.hGuideLine); > > +memset(new_context->IMC.cfCandForm, -1, > sizeof(new_context->IMC.cfCandForm)); > + That's ugly. If you are using the index for validity checking then you should put some appropriate value in there, there's no reason to put garbage in the whole structure. -- Alexandre Julliard julli...@winehq.org
Re: mscoree: Implement CreateInterface
Any reason not to share code with CLRCreateInstance?
Re: [4/5] gdi32: Fix the B spacing value of empty glyph. (try 2)
Akihiro Sagawa writes: > Try 2: >- Get rid of redundant trace message in the last patch. > > --- > dlls/gdi32/freetype.c |2 +- > dlls/gdi32/tests/font.c |8 +++- > 2 files changed, 8 insertions(+), 2 deletions(-) This is causing failures here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:1133: Test succeeded inside todo block: LTR -1 advanced: abcA's sign should be unchanged font.c:1141: Test succeeded inside todo block: LTR -1 advanced: abcfA's sign should be unchanged font.c:1133: Test succeeded inside todo block: RTL 1 advanced: abcA's sign should be unchanged font.c:1141: Test succeeded inside todo block: RTL 1 advanced: abcfA's sign should be unchanged -- Alexandre Julliard julli...@winehq.org
Re: [3/3] ws2_32: Always return the source address from WSAAccept.
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://newtestbot.winehq.org/JobDetails.pl?Key=2421 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (b0): unexpectedly at the OOB mark: 0 sock: unhandled exception c005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (5a0): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (624): unexpectedly at the OOB mark: 0
Re: kernel32/tests: Fix the test_waittxempty() timeout.
On Tue, 1 Oct 2013, Francois Gouget wrote: [...] > The timeout was too short and would only work for UARTs that have a > FIFO and where the trigger level was set just right. With this patch > we calculate how much time sending the test data will actually take > and tack on a small margin to take into account scheduling delays. I should note that this does not fix the test failuers on the QEmu VMs, specifically the WineTestBot ones. If QEmu 1.1.2 is anything like QEmu 1.6.0, then the serial port seems to operate at a fixed speed of about 180bps. This is so out of line with the 150bps that we request that it causes the test to fail. [...] > * Windows reports that all bytes have been sent not when the UART's >buffer is empty but when they all made it to the UART's buffer. Note >that this can be tested (see next mail). And here is this test. IT IS NOT MEANT TO BE COMMITTED. (but seeing the WineTestBot results would still be interesting) On my one Windows PC with a real UART (Intel(R) 82801DBM LPC Interface Controller - 24CC, i.e. ICH4 which emulates a 16550A UART) I get the following results which clearly illustrate the impact of the FIFO/trigger level. comm.c:1100: WaitCommEvent(1 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(2 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(3 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(4 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(5 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(6 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(7 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(8 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(9 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(10 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(11 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(12 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(13 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(14 bytes) for EV_TXEMPTY took 0 ms comm.c:1100: WaitCommEvent(15 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(16 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(17 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(18 bytes) for EV_TXEMPTY took 872 ms comm.c:1100: WaitCommEvent(19 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(20 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(21 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(22 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(23 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(24 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(25 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(26 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(27 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(28 bytes) for EV_TXEMPTY took 871 ms comm.c:1100: WaitCommEvent(29 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(30 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(31 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(32 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(33 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(34 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(35 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(36 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(37 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(38 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(39 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(40 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(41 bytes) for EV_TXEMPTY took 1802 ms comm.c:1100: WaitCommEvent(42 bytes) for EV_TXEMPTY took 1803 ms comm.c:1100: WaitCommEvent(43 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(44 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(45 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(46 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(47 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(48 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(49 bytes) for EV_TXEMPTY took 2734 ms comm.c:1100: WaitCommEvent(50 bytes) for EV_TXEMPTY took 2734 ms -- Francois Gouget http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".commit d6f4c73ceb4640332c79561b4e8e7c23619aa669 Author: Francois Gouget Date: Mon Sep 30 19:26:50 2013 +0200 kernel32/tests: Serial port trigger-level test patch. This is just an exploration patch and is not meant to be committed. See the following for reference: http://www.tldp.org/HOWTO/Serial-HOWTO-18.html http://www.winehq.org/pipermail/wine-devel/2013-September/101160.html http://www.winehq
Re: [2/3] ws2_32: Return an error from accept if the address buffer is too small.
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://newtestbot.winehq.org/JobDetails.pl?Key=2420 Your paranoid android. === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (5a0): unexpectedly at the OOB mark: 0 sock: unhandled exception c005 at 757A9799 === w7pro64 (32 bit sock) === sock.c:528: Test failed: oob_server (778): not at the OOB mark: 1 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (7f8): unexpectedly at the OOB mark: 0
Re: [PATCH] dsound: fixup IDirectSoundCaptureBuffer_QueryInterface
Seems reasonable, but could you put together some tests to show this?
Andrew
On Sat, Sep 28, 2013 at 10:41:15AM +0200, Maarten Lankhorst wrote:
> diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c
> index 40f1702..0fe300c 100644
> --- a/dlls/dsound/capture.c
> +++ b/dlls/dsound/capture.c
> @@ -51,7 +51,7 @@ typedef struct IDirectSoundCaptureBufferImpl
> IDirectSoundCaptureBuffer8 IDirectSoundCaptureBuffer8_iface;
> IDirectSoundNotify IDirectSoundNotify_iface;
> LONGnumIfaces; /* "in use interfaces"
> refcount */
> -LONGref, refn;
> +LONGref, refn, has_dsc8;
> /* IDirectSoundCaptureBuffer fields */
> DirectSoundCaptureDevice*device;
> DSCBUFFERDESC *pdscbd;
> @@ -241,8 +241,9 @@ static HRESULT WINAPI
> IDirectSoundCaptureBufferImpl_QueryInterface(IDirectSoundC
>
> *ppobj = NULL;
>
> -if ( IsEqualGUID( &IID_IDirectSoundCaptureBuffer, riid ) ||
> - IsEqualGUID( &IID_IDirectSoundCaptureBuffer8, riid ) ) {
> +if ( IsEqualIID( &IID_IUnknown, riid ) ||
> + IsEqualIID( &IID_IDirectSoundCaptureBuffer, riid ) ||
> + (This->has_dsc8 && IsEqualIID( &IID_IDirectSoundCaptureBuffer8,
> riid )) ) {
> IDirectSoundCaptureBuffer8_AddRef(iface);
> *ppobj = iface;
> return S_OK;
> @@ -1239,6 +1240,8 @@ static HRESULT WINAPI
> IDirectSoundCaptureImpl_CreateCaptureBuffer(IDirectSoundCa
>
> if (hr != DS_OK)
> WARN("IDirectSoundCaptureBufferImpl_Create failed\n");
> +else
> +This->device->capture_buffer->has_dsc8 = This->has_dsc8;
>
> return hr;
> }
>
>
>
Re: [1/3] ws2_32: Always clear res on error in getaddrinfo/GetAddrInfoW.
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://newtestbot.winehq.org/JobDetails.pl?Key=2419 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (2a4): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (774): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (884): unexpectedly at the OOB mark: 0 === w7pro64 (64 bit sock) === sock.c:509: Test failed: oob_server (af8): unexpectedly at the OOB mark: 0 sock.c:519: Test failed: oob_server (af8): unexpectedly at the OOB mark: 0 sock.c:288: Test failed: do_synchronous_recv (af8): error 10054: sock.c:534: Test failed: oob_server (af8): not at the OOB mark: 1
Re: [3/3] ws2_32: Always return the source address from WSAAccept.
On Tue, 2013-10-01 at 09:32 -0300, Bruno Jesus wrote:
> On Tue, Oct 1, 2013 at 6:37 AM, Hans Leidekker wrote:
> > ---
> > dlls/ws2_32/socket.c | 9 +
> > dlls/ws2_32/tests/sock.c | 6 +++---
> > 2 files changed, 4 insertions(+), 11 deletions(-)
> >
> > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c
> > index c34de4b..6855298 100644
> > --- a/dlls/ws2_32/socket.c
> > +++ b/dlls/ws2_32/socket.c
> > @@ -6546,12 +6546,8 @@ SOCKET WINAPI WSAAccept( SOCKET s, struct
> > WS_sockaddr *addr, LPINT addrlen,
> > TRACE("Socket %04lx, sockaddr %p, addrlen %p, fnCondition %p,
> > dwCallbackData %ld\n",
> > s, addr, addrlen, lpfnCondition, dwCallbackData);
> >
> > -
> > - size = sizeof(src_addr);
> > - cs = WS_accept(s, &src_addr, &size);
> > -
> > + cs = WS_accept(s, addr, addrlen);
>
> The parameter addr may be NULL in WSAAccept, I can't check the source
> code right now but what will WS_accept do in this case?
It will skip the WS_getpeername call. Good point, I'll add some tests for this
case
and resubmit the series.
Re: [3/3] ws2_32: Always return the source address from WSAAccept.
On Tue, Oct 1, 2013 at 6:37 AM, Hans Leidekker wrote:
> ---
> dlls/ws2_32/socket.c | 9 +
> dlls/ws2_32/tests/sock.c | 6 +++---
> 2 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c
> index c34de4b..6855298 100644
> --- a/dlls/ws2_32/socket.c
> +++ b/dlls/ws2_32/socket.c
> @@ -6546,12 +6546,8 @@ SOCKET WINAPI WSAAccept( SOCKET s, struct WS_sockaddr
> *addr, LPINT addrlen,
> TRACE("Socket %04lx, sockaddr %p, addrlen %p, fnCondition %p,
> dwCallbackData %ld\n",
> s, addr, addrlen, lpfnCondition, dwCallbackData);
>
> -
> - size = sizeof(src_addr);
> - cs = WS_accept(s, &src_addr, &size);
> -
> + cs = WS_accept(s, addr, addrlen);
The parameter addr may be NULL in WSAAccept, I can't check the source
code right now but what will WS_accept do in this case?
Best wishes,
Bruno
Re: [PATCH 2/5] wined3d: Move location management into the resource.
Please split this.
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Dmitry Timoshkov writes: > The tests show that this is how fully up to date Windows versions starting > from XP behave, isn't that convincing enough? If not, what else do you need > to see? An application that breaks because of this. -- Alexandre Julliard julli...@winehq.org
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Alexandre Julliard wrote: > > Do you propose to leave NtWriteFile/NtReadFile in the state when they > > return STATUS_SUCCESS for overlapped writes and reads? But that's clearly > > not how Windows implements this accordingto the tests, and that would > > require changing all the tests to accept both values so that they pass > > under Wine. > > Well, the tests fail mostly because you have decided that this behavior > is broken. I'm not convinced. The tests show that this is how fully up to date Windows versions starting from XP behave, isn't that convincing enough? If not, what else do you need to see? -- Dmitry.
Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().
Ralf Habacker writes: > On 01.10.2013 12:12, Alexandre Julliard wrote: >> Ralf Habacker writes: >> >>> With other patches i have been told to implement such stuff in the dib >>> driver. Unfortunally this do not works in this case, because in the top >>> level function it looks like having driver specific stuff using display >>> coordinates. >> It would still most likely have to be in the driver, > which is freetype_GetTextExtentExPoint() ? > >> though maybe the driver would not be calling that exact entry point. > not sure i understand right: > > GetTextExtentExPointW() calls get_char_positions(), which runs > dev->funcs->pGetTextExtentExPoint(), which is mapped to > freetype_GetTextExtentExPoint(), which is in the driver. Which entry > point your are refering else ? The various text rendering entry points in the graphics drivers. >> In any case, you can't change the DC transform like this > > then a real solution requires to move the transformation to logical > coordinates stuff in BOOL GetTextExtentExPointW() to > freetype_GetTextExtentExPoint() and to manipulate the related matrixes > in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ? No, I don't think so. The transform is only used to determine the font scaling factor. >> and you'll need test cases. >> > Do you mean in detail: > > 1. Create a specific font > 2. Run GetTextExtentExPointW() which specific parameters > 3. check if it results expected values Well, yes, that's what all tests do. -- Alexandre Julliard julli...@winehq.org
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Dmitry Timoshkov writes: > Do you propose to leave NtWriteFile/NtReadFile in the state when they > return STATUS_SUCCESS for overlapped writes and reads? But that's clearly > not how Windows implements this accordingto the tests, and that would > require changing all the tests to accept both values so that they pass > under Wine. Well, the tests fail mostly because you have decided that this behavior is broken. I'm not convinced. -- Alexandre Julliard julli...@winehq.org
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Alexandre Julliard wrote: > >> I don't see the point. Do you actually have an app that depends on this? > > > > When I started to work on this I had an app that has one of the reasons to > > require running under Vista+ was the difference in overlapped IO behavior. > > On the other hand the tests clearly show that up-to-date Windows versions > > (including Windows XP) always return STATUS_PENDING for asynchronous read > > and write on disk files. Is there another way to remove all those todo_wine > > statements from the tests? > > The tests also show that returning success is allowed for other file > types, so I don't see a need to add complexity to treat files > differently, unless there's a demonstrated need. Do you propose to leave NtWriteFile/NtReadFile in the state when they return STATUS_SUCCESS for overlapped writes and reads? But that's clearly not how Windows implements this accordingto the tests, and that would require changing all the tests to accept both values so that they pass under Wine. -- Dmitry.
Re: ntdll: Fix the version reported for 64-bit Windows XP.
Hans Leidekker writes:
> @@ -129,11 +129,19 @@ static const RTL_OSVERSIONINFOEXW
> VersionData[NB_WINDOWS_VERSIONS] =
> 4, 0, 0, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field
> with a value! */
> },
> /* WINXP */
> +#ifdef _WIN64
> +{
> +sizeof(RTL_OSVERSIONINFOEXW), 5, 2, 0xECE, VER_PLATFORM_WIN32_NT,
> +{'S','e','r','v','i','c','e',' ','P','a','c','k',' ','1',0},
> +1, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 0
> +},
> +#else
> {
> sizeof(RTL_OSVERSIONINFOEXW), 5, 1, 0xA28, VER_PLATFORM_WIN32_NT,
> {'S','e','r','v','i','c','e',' ','P','a','c','k',' ','3',0},
> 3, 0, VER_SUITE_SINGLEUSERTS, VER_NT_WORKSTATION, 30 /* FIXME:
> Great, a reserved field with a value! */
> },
> +#endif
This would mean that the 32-bit side sees a different version. I don't
think that's correct.
--
Alexandre Julliard
julli...@winehq.org
Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().
Ralf Habacker writes: > With other patches i have been told to implement such stuff in the dib > driver. Unfortunally this do not works in this case, because in the top > level function it looks like having driver specific stuff using display > coordinates. It would still most likely have to be in the driver, though maybe the driver would not be calling that exact entry point. In any case, you can't change the DC transform like this. and you'll need test cases. -- Alexandre Julliard julli...@winehq.org
mscoree: Implement CreateInterface
Hi,
Changelog:
mscoree: Implement CreateInterface
Best Regards
Alistair Leslie-Hughes
>From 6e4b9aff1f2a8776be0ad3cf6e9d0404dd5bec29 Mon Sep 17 00:00:00 2001
From: Alistair Leslie-Hughes
Date: Tue, 1 Oct 2013 10:17:50 +1000
Subject: [PATCH 2/2] Implement CreateInterface
---
dlls/mscoree/mscoree.spec| 1 +
dlls/mscoree/mscoree_main.c | 12
dlls/mscoree/tests/mscoree.c | 29 -
3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/dlls/mscoree/mscoree.spec b/dlls/mscoree/mscoree.spec
index ad883c6..93248e2 100644
--- a/dlls/mscoree/mscoree.spec
+++ b/dlls/mscoree/mscoree.spec
@@ -30,6 +30,7 @@
@ stub CorTickleSvc
@ stdcall CreateConfigStream(wstr ptr)
@ stdcall CreateDebuggingInterfaceFromVersion(long wstr ptr)
+@ stdcall CreateInterface(ptr ptr ptr)
@ stdcall -private DllCanUnloadNow()
@ stdcall -private DllGetClassObject(ptr ptr ptr)
@ stdcall -private DllRegisterServer()
diff --git a/dlls/mscoree/mscoree_main.c b/dlls/mscoree/mscoree_main.c
index de37706..f4c6c7d 100644
--- a/dlls/mscoree/mscoree_main.c
+++ b/dlls/mscoree/mscoree_main.c
@@ -594,6 +594,18 @@ HRESULT WINAPI CLRCreateInstance(REFCLSID clsid, REFIID riid, LPVOID *ppInterfac
return CLASS_E_CLASSNOTAVAILABLE;
}
+HRESULT WINAPI CreateInterface(REFCLSID clsid, REFIID riid, LPVOID *ppInterface)
+{
+TRACE("(%s,%s,%p)\n", debugstr_guid(clsid), debugstr_guid(riid), ppInterface);
+
+if (IsEqualGUID(clsid, &CLSID_CLRMetaHost))
+return CLRMetaHost_CreateInstance(riid, ppInterface);
+
+FIXME("not implemented for class %s\n", debugstr_guid(clsid));
+
+return CLASS_E_CLASSNOTAVAILABLE;
+}
+
HRESULT WINAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, LPVOID* ppv)
{
mscorecf *This;
diff --git a/dlls/mscoree/tests/mscoree.c b/dlls/mscoree/tests/mscoree.c
index f8de6fa..41844ef 100644
--- a/dlls/mscoree/tests/mscoree.c
+++ b/dlls/mscoree/tests/mscoree.c
@@ -21,6 +21,7 @@
#include "corerror.h"
#include "mscoree.h"
+#include "metahost.h"
#include "shlwapi.h"
#include "wine/test.h"
@@ -31,6 +32,7 @@ static HRESULT (WINAPI *pGetCORSystemDirectory)(LPWSTR, DWORD, DWORD*);
static HRESULT (WINAPI *pGetRequestedRuntimeInfo)(LPCWSTR, LPCWSTR, LPCWSTR, DWORD, DWORD, LPWSTR, DWORD, DWORD*, LPWSTR, DWORD, DWORD*);
static HRESULT (WINAPI *pLoadLibraryShim)(LPCWSTR, LPCWSTR, LPVOID, HMODULE*);
static HRESULT (WINAPI *pCreateConfigStream)(LPCWSTR, IStream**);
+static HRESULT (WINAPI *pCreateInterface)(REFCLSID, REFIID, VOID**);
static BOOL init_functionpointers(void)
{
@@ -47,8 +49,10 @@ static BOOL init_functionpointers(void)
pGetRequestedRuntimeInfo = (void *)GetProcAddress(hmscoree, "GetRequestedRuntimeInfo");
pLoadLibraryShim = (void *)GetProcAddress(hmscoree, "LoadLibraryShim");
pCreateConfigStream = (void *)GetProcAddress(hmscoree, "CreateConfigStream");
+pCreateInterface = (void *)GetProcAddress(hmscoree, "CreateInterface");
-if (!pGetCORVersion || !pGetCORSystemDirectory || !pGetRequestedRuntimeInfo || !pLoadLibraryShim)
+if (!pGetCORVersion || !pGetCORSystemDirectory || !pGetRequestedRuntimeInfo || !pLoadLibraryShim ||
+!pCreateInterface)
{
win_skip("functions not available\n");
FreeLibrary(hmscoree);
@@ -386,6 +390,28 @@ static void test_createconfigstream(void)
DeleteFileW(file);
}
+void test_createinstance(void)
+{
+HRESULT hr;
+ICLRMetaHost *host;
+
+if(!pCreateInterface)
+{
+win_skip("Function CreateInterface not found.\n");
+return;
+}
+
+hr = pCreateInterface(&CLSID_CLRMetaHost, &IID_ICLRMetaHost, (void**)&host);
+if(SUCCEEDED(hr))
+{
+ICLRMetaHost_Release(host);
+}
+else
+{
+win_skip(".NET 4 not installed.\n");
+}
+}
+
START_TEST(mscoree)
{
if (!init_functionpointers())
@@ -394,6 +420,7 @@ START_TEST(mscoree)
test_versioninfo();
test_loadlibraryshim();
test_createconfigstream();
+test_createinstance();
FreeLibrary(hmscoree);
}
--
1.8.4.rc3
oledb32: Implement IDataSourceLocator get/put hWnd (try 4)
Hi,
Corrected warnings.
Changelog: Implement IDataSourceLocator get/put hWnd
Best Regards
Alistair Leslie-Hughes
>From 13b8466033f24db028bfed6de609c4cd5f84b14a Mon Sep 17 00:00:00 2001
From: Alistair Leslie-Hughes
Date: Mon, 30 Sep 2013 14:05:01 +1000
Subject: [PATCH 1/2] Implement IDataSourceLocator get/put hWnd
---
dlls/oledb32/dslocator.c | 13
dlls/oledb32/tests/database.c | 48 +++
2 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/dlls/oledb32/dslocator.c b/dlls/oledb32/dslocator.c
index f8a98f5..cf9512c 100644
--- a/dlls/oledb32/dslocator.c
+++ b/dlls/oledb32/dslocator.c
@@ -42,6 +42,7 @@ typedef struct DSLocatorImpl
IDataSourceLocator IDataSourceLocator_iface;
LONG ref;
+HWND hwnd;
} DSLocatorImpl;
static inline DSLocatorImpl *impl_from_IDataSourceLocator( IDataSourceLocator *iface )
@@ -139,18 +140,22 @@ static HRESULT WINAPI dslocator_get_hWnd(IDataSourceLocator *iface, COMPATIBLE_L
{
DSLocatorImpl *This = impl_from_IDataSourceLocator(iface);
-FIXME("(%p)->(%p)\n",This, phwndParent);
+TRACE("(%p)->(%p)\n",This, phwndParent);
-return E_NOTIMPL;
+*phwndParent = (COMPATIBLE_LONG)This->hwnd;
+
+return S_OK;
}
static HRESULT WINAPI dslocator_put_hWnd(IDataSourceLocator *iface, COMPATIBLE_LONG hwndParent)
{
DSLocatorImpl *This = impl_from_IDataSourceLocator(iface);
-FIXME("(%p)->(%p)\n",This, (HWND)hwndParent);
+TRACE("(%p)->(%p)\n",This, (HWND)hwndParent);
-return E_NOTIMPL;
+This->hwnd = (HWND)hwndParent;
+
+return S_OK;
}
static HRESULT WINAPI dslocator_PromptNew(IDataSourceLocator *iface, IDispatch **ppADOConnection)
diff --git a/dlls/oledb32/tests/database.c b/dlls/oledb32/tests/database.c
index d0eb9ff..13637c1 100644
--- a/dlls/oledb32/tests/database.c
+++ b/dlls/oledb32/tests/database.c
@@ -547,6 +547,53 @@ static void test_rowpos_setrowposition(void)
IRowPosition_Release(rowpos);
}
+static void test_dslocator(void)
+{
+IDataSourceLocator *dslocator = NULL;
+HRESULT hr;
+
+hr = CoCreateInstance(&CLSID_DataLinks, NULL, CLSCTX_INPROC_SERVER, &IID_IDataSourceLocator,(void**)&dslocator);
+ok(hr == S_OK, "got %08x\n", hr);
+if(SUCCEEDED(hr))
+{
+COMPATIBLE_LONG hwnd = 0;
+
+/* Crashes under Window 7
+hr = IDataSourceLocator_get_hWnd(dslocator, NULL);
+ok(hr == E_INVALIDARG, "got %08x\n", hr);
+*/
+
+hr = IDataSourceLocator_get_hWnd(dslocator, &hwnd);
+ok(hr == S_OK, "got %08x\n", hr);
+ok(hwnd == 0, "got %p\n", (HWND)hwnd);
+
+hwnd = 0xDEADBEEF;
+hr = IDataSourceLocator_get_hWnd(dslocator, &hwnd);
+ok(hr == S_OK, "got %08x\n", hr);
+ok(hwnd == 0, "got %p\n", (HWND)hwnd);
+
+hwnd = 0xDEADBEEF;
+hr = IDataSourceLocator_put_hWnd(dslocator, hwnd);
+ok(hr == S_OK, "got %08x\n", hr);
+
+hwnd = 0xDEADBEEF;
+hr = IDataSourceLocator_get_hWnd(dslocator, &hwnd);
+ok(hr == S_OK, "got %08x\n", hr);
+ok(hwnd == 0xDEADBEEF, "got %p\n", (HWND)hwnd);
+
+hwnd = 0;
+hr = IDataSourceLocator_put_hWnd(dslocator, hwnd);
+ok(hr == S_OK, "got %08x\n", hr);
+
+hwnd = 0xDEADBEEF;
+hr = IDataSourceLocator_get_hWnd(dslocator, &hwnd);
+ok(hr == S_OK, "got %08x\n", hr);
+ok(hwnd == 0, "got %p\n", (HWND)hwnd);
+
+IDataSourceLocator_Release(dslocator);
+}
+}
+
START_TEST(database)
{
OleInitialize(NULL);
@@ -554,6 +601,7 @@ START_TEST(database)
test_database();
test_errorinfo();
test_initializationstring();
+test_dslocator();
/* row position */
test_rowposition();
--
1.8.4.rc3
Re: [4/5] ntdll: Make asynchronous NtWriteFile on a disk file always return STATUS_PENDING.
Dmitry Timoshkov writes: > Alexandre Julliard wrote: > >> I don't see the point. Do you actually have an app that depends on this? > > When I started to work on this I had an app that has one of the reasons to > require running under Vista+ was the difference in overlapped IO behavior. > On the other hand the tests clearly show that up-to-date Windows versions > (including Windows XP) always return STATUS_PENDING for asynchronous read > and write on disk files. Is there another way to remove all those todo_wine > statements from the tests? The tests also show that returning success is allowed for other file types, so I don't see a need to add complexity to treat files differently, unless there's a demonstrated need. -- Alexandre Julliard julli...@winehq.org
Re: ws2_32: Implement WSASendMsg() (try 3)
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://newtestbot.winehq.org/JobDetails.pl?Key=2414 Your paranoid android. === wxppro (32 bit sock) === sock.c:519: Test failed: oob_server (210): unexpectedly at the OOB mark: 0 sock: unhandled exception c005 at 71AB8D62 === w2008s64 (32 bit sock) === sock.c:519: Test failed: oob_server (5a0): unexpectedly at the OOB mark: 0 === w2008s64 (64 bit sock) === sock.c:519: Test failed: oob_server (6b0): unexpectedly at the OOB mark: 0
