That's what I was going for originally, but AJ on IRC deemed it not necessary.
J. Leclanche
On Fri, Aug 20, 2010 at 12:27 AM, Octavian Voicu
wrote:
> On Thu, Aug 19, 2010 at 4:56 PM, Jerome Leclanche wrote:
>> Broken programs will crash on wine if they, for example, pass
>> arguments to GetO
On Thu, Aug 19, 2010 at 4:56 PM, Jerome Leclanche wrote:
> Broken programs will crash on wine if they, for example, pass
> arguments to GetObject in the wrong order.
> This fixes bug #18864.
> +if (buffer && ((ULONG_PTR)buffer >> 16) == 0)
Wouldn't a __TRY ... __EXCEPT_PAGE_FAULT be bett
Le 19/08/2010 19:36, Peter Urbanec a écrit :
I have some x64 binaries and associated PDBs that have been generated
using Intel C++ Compiler 11.1. These PDBs cause issues such as this:
1 0x781cc1ba in msvcr80 (+0x9c1b9) (0x7ff047a4c840)
fixme:dbghelp_msc:codeview_fetch_type Cann
Hi all,
First off, I'm not sure who should be contacted about this, but, it appears
that the test bot has got itself stuck while trying to run tests on a patch
submitted last night. The job in question is here [1], it's been over 12
hours since any progress has been made on it and no other submiss
I have some x64 binaries and associated PDBs that have been generated
using Intel C++ Compiler 11.1. These PDBs cause issues such as this:
1 0x781cc1ba in msvcr80 (+0x9c1b9) (0x7ff047a4c840)
fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670
err:dbghelp_msc:pe_load_debug
On Mon, Aug 9, 2010 at 5:41 AM, Paul Chitescu wrote:
> On Monday 09 August 2010 01:23:24 pm Jerome Leclanche wrote:
>> Hi
>>
>> After fixing a bug in MPQEdit related to opening directories, I
>> noticed winepath returns a different result with and without quotes:
>>
>> a...@azura:~/.wine/drive_c$
At least with all d3dx10 DLLs released so far, D3D10_SDK_VERSION has not
changed. Obviously, if it does change in the future, we will need to
accommodate that in new DLLs.
Although I suppose we could hard-code the SDK version into the DLLs now,
rather than having to change it later, which I gue
Is it really safe to assume D3D10_SDK_VERSION will always keep the
same value? (I know d3dx9 does it as well.) For d3d9 the SDK version
changed between d3d9b and d3d9c, for example.
At least with all d3dx10 DLLs released so far, D3D10_SDK_VERSION has not
changed. Obviously, if it does change in
Hi,
Can you try to create a d3d device with this surface? In the first d3d version
this works by querying the d3d device ID from the surface. Patch 4 looks OK.
Thank you for your persistence with the patches by the way!
Cheers,
Stefan
Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička:
> ---
> d
"Mikhail Maroukhine" writes:
> @@ -1695,7 +1696,19 @@ HWND WINAPI GetNextDlgTabItem( HWND hwndDlg, HWND
> hwndCtrl,
> */
> if (!hwndCtrl && fPrevious) return 0;
>
> -return DIALOG_GetNextTabItem(hwndDlg,hwndDlg,hwndCtrl,fPrevious);
> +nextItem = DIALOG_GetNextTabItem(hwndDlg
Jacek Caban writes:
> ---
> dlls/oleaut32/typelib.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
It breaks the 64-bit tests:
../../../../wine/tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p
oleaut32_test.exe.so ../../../../wine/dlls/oleaut32/tests/typelib.c && touch
This test contains a C++ comment, please remove it. Otherwise it looks ok, as
does patch 1
Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička:
> ---
> dlls/ddraw/tests/visual.c | 123 +
> 1 files changed, 123 insertions(+), 0 deletions(-)
>
> diff --git
Am 18.08.2010 um 22:01 schrieb Oldřich Jedlička:
> +if(DDSD->ddsCaps.dwCaps & DDSCAPS_FRONTBUFFER) {
> +WARN("Application tried to create an explicit front buffer\n");
> LeaveCriticalSection(&ddraw_cs);
> return DDERR_INVALIDCAPS;
> }
This test seems redundant now.
On 18 August 2010 23:01, Owen Rudge wrote:
> +BOOL WINAPI D3DX10CheckVersion(UINT d3dsdkvers, UINT d3dxsdkvers)
> +{
> +if ((d3dsdkvers == D3D10_SDK_VERSION) && (d3dxsdkvers == 43))
> +return TRUE;
> +
> +return FALSE;
> +}
Is it really safe to assume D3D10_SDK_VERSION will always
writes:
> although my patch creates mcicda/tests/
> I'd like to query whether it would make more
> sense to have all mci tests grouped in winmm/tests/.
That's probably better, yes.
--
Alexandre Julliard
julli...@winehq.org
Damjan Jovanovic writes:
> diff --git a/dlls/user32/driver.c b/dlls/user32/driver.c
> index f2f9892..05c83d4 100644
> --- a/dlls/user32/driver.c
> +++ b/dlls/user32/driver.c
> @@ -126,6 +126,7 @@ static const USER_DRIVER *load_driver(void)
> GET_USER_FUNC(WindowMessage);
> GET_U
Detlef Riekenberg writes:
> +ok( (res == (void *)~0) ||
> +broken(res == (NULL + len)),/* XP and w2003 */
You can't do that.
--
Alexandre Julliard
julli...@winehq.org
Stefan Leichter writes:
> +HINSTANCE hinst32;
> +if (hinst16 == GetModuleHandle16("msvideo.dll"))
> +hinst32 = GetModuleHandleA("msvfw32.dll");
> +else
> +hinst32 = HINSTANCE_32(GetExePtr( hinst16 ));
This doesn't seem right. Why do you need this?
--
Alexandre Julli
18 matches
Mail list logo
