Re: ddraw: Remove a test that fails in VMs
On Sat, Apr 26, 2008 at 1:11 AM, Reece Dunn <[EMAIL PROTECTED]> wrote: > 2008/4/26 James Hawkins <[EMAIL PROTECTED]>: > > > Hi, > > > > The tests aren't run anyway in this case. > > > > Changelog: > > * Remove a test that fails in VMs. > ... > > hr = IDirect3D7_CreateDevice(Direct3D, > &IID_IDirect3DRefDevice, Surface, &Direct3DDevice); > > } > > } > > -ok(hr == D3D_OK, "IDirect3D7_CreateDevice failed with %08x\n", hr); > > Wouldn't it be better to move the ok line to directly after the > IDirect3D7_CreateDevice call? That way, on VM machines the test will > not get run and on non-VM machines it will, as it is a valid test in > that case. > No, the test will still be run in all cases, VM or not, and will fail in VMs. The function just sets up the direct3d device object for other tests; there's no point in an ok test in this function, especially when it doesn't pass for all systems. -- James Hawkins
Re: cabinet: Revert "cabinet: Fix for FDICopy with an empty cabinet file."
On Sat, Apr 26, 2008 at 1:03 AM, Reece Dunn <[EMAIL PROTECTED]> wrote: > 2008/4/26 James Hawkins <[EMAIL PROTECTED]>: > > > Hi, > > > > The test was incorrect and failed on all platforms. Vitaly, please > > ask someone to test your patches on a real windows system in the > > future if you don't have access to one. > > Wouldn't it be better to actually fix the test case than revert it all > together? > > Just simply change line 630: > > -ok(ret, "Expected FDICopy to succeed\n"); > +ok(!ret, "Expected FDICopy to fail\n"); > > and remove the todo_wine. Adding a GetLastError check would be good as well. > Have you actually read the patch or the changelog for that matter? -- James Hawkins
Re: [PATCH] advapi32: attempt to use UuidToStringA if UuidToStringW isnot available.
"Lei Zhang" <[EMAIL PROTECTED]> wrote: > This adds more checks in CRYPT_CreateMachineGuid(), and attempt to use > UuidToStringA if UuidToStringW is not available. Instead of duplicating and complicating the code, IMO it would be more straightforward to use ansi APIs without trying unicode first. -- Dmitry.
download.template: Update Mandriva download info (try 2)
Any reason this patch wasn't applied? http://www.winehq.org/pipermail/wine-patches/2008-April/053911.html
Re: Kusanagi Kouichi : winex11: Destroy the handle to the composition string after it is cancelled.
On Fri, Apr 25, 2008 at 02:44:00PM -0500, Aric Stewart wrote: > No, from updateCompStr > > if (old == NULL && compstr == NULL && len == 0) > return NULL; > > Otherwise it returns a compstr. So it only should return NULL if all the > incoming parameters are NULL, which i do not believe should ever happen > after i went through and made sure that the hCompStr was never NULL. > > -aric Oh, I mistook && for ||. All right, I'll send a patch.
Wine 1.0 release plan update
Alexandre's taking a vacation in May, and the schedule is bending slightly to fit. We're also not promising a particular release date, though the previously predicted date is still as likely as it was before. http://wiki.winehq.org/WineReleasePlan now says: --- snip --- * 0.9.61 - 2 May 2008 - start of code freeze for 1.0 * 1.0.0-rc1 - 9 May 2008 (early because of Alexandre's vacation) * No release 16 May (Alexandre on vacation) * 1.0.0-rc2 - 23 May (early because of Alexandre's vacation) The exact date of the 1.0.0 release can't be predicted; we'll keep on doing release candidates until we're comfortable with it. We expect it will be in June. --- snip ---
Re: SOC 2008 Projects Announced
> Could the students come forward and say something about themself? Hello Wine world, my name is Adam Petaccia, and this summer I will be working on Wine's GDI+ implementation, so more applications can work "out of the box". I am currently a student at the University of North Carolina, Greensboro (US), and look forward to getting to coding, once I'm done with those pesky exams. Its exciting to see how far Wine has come (I remember running Starcraft as root with nice -20 just so that the game could be somwhat playable -- thank [deity] we don't have to do that now) and I look forward to making Wine even greater. signature.asc Description: This is a digitally signed message part
Re: Kusanagi Kouichi : winex11: Destroy the handle to the composition string after it is cancelled.
No, from updateCompStr
if (old == NULL && compstr == NULL && len == 0)
return NULL;
Otherwise it returns a compstr. So it only should return NULL if all the
incoming parameters are NULL, which i do not believe should ever happen
after i went through and made sure that the hCompStr was never NULL.
-aric
Kusanagi Kouichi wrote:
> On Fri, Apr 25, 2008 at 09:36:36AM -0500, Aric Stewart wrote:
>> Comming in a bit late on this one, (missed the patch submission)
>>
>> I do not think this is correct as far as i know hCompStr should never be
>> NULL. Much of our code depends on that not being NULL.
>>
>> I would recommend using ImeCreateBlankCompStr instead. (something like
>> below)
>>
>> diff --git a/dlls/winex11.drv/ime.c b/dlls/winex11.drv/ime.c
>> index f50549f..8fa6f6f 100644
>> --- a/dlls/winex11.drv/ime.c
>> +++ b/dlls/winex11.drv/ime.c
>> @@ -778,7 +778,7 @@ BOOL WINAPI NotifyIME(HIMC hIMC, DWORD dwAction,
>> DWORD dwInd
>> if (lpIMC->hCompStr)
>> {
>> ImmDestroyIMCC(lpIMC->hCompStr);
>> -lpIMC->hCompStr = NULL;
>> +lpIMC->hCompStr = ImeCreateBlankCompStr();
>> }
>>
>> myPrivate =
>> (LPIMEPRIVATE)ImmLockIMCC(lpIMC->hPrivate);
>>
>> -aric
>
> Then, are these also wrong? updateCompStr returns NULL if NULL or 0 is given.
>748newCompStr =
> updateCompStr(lpIMC->hCompStr, NULL, 0);
>749ImmDestroyIMCC(lpIMC->hCompStr);
>750lpIMC->hCompStr = newCompStr;
>
>897newCompStr = updateCompStr(lpIMC->hCompStr, NULL,
> 0);
>898ImmDestroyIMCC(lpIMC->hCompStr);
>899lpIMC->hCompStr = newCompStr;
>
>
Re: 1.0 idea - ntdll - add a messagebox for missing dlls
On Fri, Apr 25, 2008 at 8:50 AM, Steven Edwards <[EMAIL PROTECTED]> wrote: > does not even work, let alone because if it finds the EXE there is no > error as far as CreateProcess cares. On the other had, The child > process returns an exit code such as STATUS_ENTRYPOINT_NOT_FOUND but I > don't see how to get this information from the parent process, return > it to start.exe.so and have start do something like print an error or > display a message box. Can anyone lurking point me to an example of > how to get the child's return value and pass that back to the parent? A few ideas: * have start.exe examine the import table of the exe and do an explicit check (hard) * have start.exe set an environment variable saying "show graphical error box on dll load failure", and clear that before calling executed apps' WinMain() (easy)
Re: d3d8: Fix a few test failures in win2k3
Am Freitag, 25. April 2008 03:36:04 schrieb James Hawkins: > Hi, > > Changelog: > * Fix a few test failures in win2k3. > > dlls/d3d8/tests/device.c |9 ++--- > 1 files changed, 6 insertions(+), 3 deletions(-) Looks ok to me Somewhen we may want to move all this multiple times copypasted device init code into a shared function :-/
Re: ddraw: Fix tests that fail with the reference rasterizer
On Fri, Apr 25, 2008 at 12:36 PM, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Am Freitag, 25. April 2008 05:38:40 schrieb James Hawkins: > > > Hi, > > > > Changelog: > > * Fix tests that fail with the reference rasterizer. > > >if (SUCCEEDED(IDirectDrawSurface7_AddAttachedSurface(surface1, > surface4))) > >refrast = TRUE; > Do you take care of detaching the surface again? > I'll send in a patch to fix that. > Did you try checking the DirectDraw description or GUID? Maybe there's a > better way to detet the refrast, if you want the teest to succeeed in a VM > I'm sorry, I'm not that familiar with ddraw. -- James Hawkins
Re: ddraw: Fix tests that fail with the reference rasterizer
Am Freitag, 25. April 2008 05:38:40 schrieb James Hawkins: > Hi, > > Changelog: > * Fix tests that fail with the reference rasterizer. >if (SUCCEEDED(IDirectDrawSurface7_AddAttachedSurface(surface1, surface4))) >refrast = TRUE; Do you take care of detaching the surface again? Did you try checking the DirectDraw description or GUID? Maybe there's a better way to detet the refrast, if you want the teest to succeeed in a VM
Re: Safedisc for 1.0+ ?
Darragh Bailey wrote: > There has been some movement in the past to split up the Safedisc bug > and deal with the individual versions separately. Would it be useful to > advance this? I'm certain that I have a number of games that listed as > apps affected by this bug that no longer have a problem. So I'm not sure > that it works well to maintain the same bug for all versions of > safedisc. I think that's a good idea
Re: ddraw: ComputeSphereVisibility
Am Freitag, 25. April 2008 04:20:11 schrieb David Adam: > Hello, > > I am trying to debug the demo of The Sting. Now, the main is that the > screen is almost black. It is surely related to the following FIXME: > fixme:d3d7:IDirect3DDeviceImpl_7_ComputeSphereVisibility > > Unfortunately, I did not find any informations about this function. Does > anyone know what this function does, ( and better knows a possible > implementation)? There's something in the DirectX SDK, and I added some implementation ideas to the comments in the ddraw code. I think it comes down to a bit of vector math, but I think you'll have to write some test cases to check if it really does what that the MSDN says
Re: Kusanagi Kouichi : winex11: Destroy the handle to the composition string after it is cancelled.
On Fri, Apr 25, 2008 at 09:36:36AM -0500, Aric Stewart wrote:
> Comming in a bit late on this one, (missed the patch submission)
>
> I do not think this is correct as far as i know hCompStr should never be
> NULL. Much of our code depends on that not being NULL.
>
> I would recommend using ImeCreateBlankCompStr instead. (something like
> below)
>
> diff --git a/dlls/winex11.drv/ime.c b/dlls/winex11.drv/ime.c
> index f50549f..8fa6f6f 100644
> --- a/dlls/winex11.drv/ime.c
> +++ b/dlls/winex11.drv/ime.c
> @@ -778,7 +778,7 @@ BOOL WINAPI NotifyIME(HIMC hIMC, DWORD dwAction,
> DWORD dwInd
> if (lpIMC->hCompStr)
> {
> ImmDestroyIMCC(lpIMC->hCompStr);
> -lpIMC->hCompStr = NULL;
> +lpIMC->hCompStr = ImeCreateBlankCompStr();
> }
>
> myPrivate =
> (LPIMEPRIVATE)ImmLockIMCC(lpIMC->hPrivate);
>
> -aric
Then, are these also wrong? updateCompStr returns NULL if NULL or 0 is given.
748 newCompStr = updateCompStr(lpIMC->hCompStr,
NULL, 0);
749 ImmDestroyIMCC(lpIMC->hCompStr);
750 lpIMC->hCompStr = newCompStr;
897 newCompStr = updateCompStr(lpIMC->hCompStr, NULL, 0);
898 ImmDestroyIMCC(lpIMC->hCompStr);
899 lpIMC->hCompStr = newCompStr;
Re: [PATCH] user32: edit controls should ignore WM_KEYDOWN on control + enter.
On Fri, Apr 25, 2008 at 6:07 AM, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: > > Lei Zhang wrote: > > On Thu, Apr 24, 2008 at 10:22 PM, Lei Zhang <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> This should be the last bit in getting control + enter working in > >> multiline edit controls. I attempted to write a test for this using > >> SendInput() or SetKeyState() + SendMessage(), but I couldn't get seem > >> to simulate holding down the control key. > >> > > > Should work. You can also look at keybd_event() how it does it. It's pretty > much a wrapper around SendInput(). > All you'll need is keybd_event(VK_CONTROL, 0, 0, 0); to press it. And > keybd_event(VK_CONTROL, 0, KEYEVENTF_KEYUP, 0); to release it. > I tried that too. Also tried SetFocus(hedit) first. No luck.
Re: [2/2] [try2] user32:mdi.c Fix creating MDI child window according with test. [resend]
Alexandre Julliard wrote: > It doesn't work: > > msg.c:3065: Test failed: Create visible MDI child window: the msg sequence is > not complete: expected - actual 0046 > msg.c:3120: Test failed: ShowWindow(SW_MAXIMIZE):invisible MDI child: the msg > 0x0047 was expected, but got msg 0x0046 instead > msg.c:3120: Test failed: ShowWindow(SW_MAXIMIZE):invisible MDI child: the msg > 0x0005 was expected, but got msg 0x0083 instead > msg.c:3120: Test failed: ShowWindow(SW_MAXIMIZE):invisible MDI child: the msg > 0x0046 was expected, but got msg 0x0047 instead > msg.c:3120: Test failed: ShowWindow(SW_MAXIMIZE):invisible MDI child: the msg > 0x0083 was expected, but got msg 0x0047 instead > msg.c:3120: Test failed: ShowWindow(SW_MAXIMIZE):invisible MDI child: the msg > 0x0047 was expected, but got msg 0x0005 instead > msg.c:3120: Test failed: ShowWindow(SW_MAXIMIZE):invisible MDI child: the msg > sequence is not complete: expected - actual 0046 > msg.c:3345: Test failed: ShowWindow(SW_MAXIMIZE):invisible maximized MDI > child: the msg 0x0047 was expected, but got msg 0x0046 instead > msg.c:3345: Test failed: ShowWindow(SW_MAXIMIZE):invisible maximized MDI > child: the msg sequence is not complete: expected - actual 0083 > msg.c:3484: Test failed: Create MDI child window with invisible parent: the > msg sequence is not complete: expected - actual 0046 > > I muff this regression, thank you. I sent a new version of this patch. -- Best regards Anatoly Lyutin.
Re: 1.0 idea - ntdll - add a messagebox for missing dlls
On Thu, Apr 24, 2008 at 11:12 AM, Alexandre Julliard
<[EMAIL PROTECTED]> wrote:
> It depends which cases you are trying to catch, but for the case of
> users starting an app from their desktop, you could probably do it in
> start.exe.
As per our discussion on IRC, start uses CreateProcess which according
to Raymond and my own testing does not wait around and return anything
of any meaning, see
http://blogs.msdn.com/oldnewthing/archive/2005/01/19/356048.aspx
So checking the return value and doing something like
WINE_ERR("start failed, error %d\n", GetLastError());
does not even work, let alone because if it finds the EXE there is no
error as far as CreateProcess cares. On the other had, The child
process returns an exit code such as STATUS_ENTRYPOINT_NOT_FOUND but I
don't see how to get this information from the parent process, return
it to start.exe.so and have start do something like print an error or
display a message box. Can anyone lurking point me to an example of
how to get the child's return value and pass that back to the parent?
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Re: John Klehm : winex11: Add support for IsXExtensionPointer tablet devices.
This patch break compilation on my RHEL5 box with
xorg-x11-proto-devel-7.1-9.fc6 which misses the IsXExtensionPointer define.
bye
michael
Alexandre Julliard wrote:
> Module: wine
> Branch: master
> Commit: 2c26ea609d6b2b8a25be20984c0014ceb202466a
> URL:
> http://source.winehq.org/git/wine.git/?a=commit;h=2c26ea609d6b2b8a25be20984c0014ceb202466a
>
> Author: John Klehm <[EMAIL PROTECTED]>
> Date: Tue Apr 22 20:11:28 2008 -0500
>
> winex11: Add support for IsXExtensionPointer tablet devices.
>
> ---
>
> dlls/winex11.drv/wintab.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/winex11.drv/wintab.c b/dlls/winex11.drv/wintab.c
> index 37596ba..b086e44 100644
> --- a/dlls/winex11.drv/wintab.c
> +++ b/dlls/winex11.drv/wintab.c
> @@ -530,14 +530,15 @@ void X11DRV_LoadTabletInfo(HWND hwnddefault)
> devices[loop].use == IsXKeyboard ? "IsXKeyboard" :
> devices[loop].use == IsXPointer ? "IsXPointer" :
> devices[loop].use == IsXExtensionDevice ?
> "IsXExtensionDevice" :
> +devices[loop].use == IsXExtensionPointer ?
> "IsXExtensionPointer" :
> "Unknown"
> );
>
> -if (devices[loop].use == IsXExtensionDevice)
> +if ((devices[loop].use == IsXExtensionDevice) || (devices[loop].use
> == IsXExtensionPointer))
> {
> LPWTI_CURSORS_INFO cursor;
>
> -TRACE("Is Extension Device\n");
> +TRACE("Is XExtension%s\n", (devices[loop].use ==
> IsXExtensionDevice)? "Device":"Pointer");
> cursor_target++;
> target = &devices[loop];
> cursor = &gSysCursor[cursor_target];
>
>
>
--
Michael Stefaniuc Tel.: +49-711-96437-199
Consulting Communications Engineer Fax.: +49-711-96437-111
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei Muenchen
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
Re: Kusanagi Kouichi : winex11: Destroy the handle to the composition string after it is cancelled.
Comming in a bit late on this one, (missed the patch submission)
I do not think this is correct as far as i know hCompStr should never be
NULL. Much of our code depends on that not being NULL.
I would recommend using ImeCreateBlankCompStr instead. (something like
below)
diff --git a/dlls/winex11.drv/ime.c b/dlls/winex11.drv/ime.c
index f50549f..8fa6f6f 100644
--- a/dlls/winex11.drv/ime.c
+++ b/dlls/winex11.drv/ime.c
@@ -778,7 +778,7 @@ BOOL WINAPI NotifyIME(HIMC hIMC, DWORD dwAction,
DWORD dwInd
if (lpIMC->hCompStr)
{
ImmDestroyIMCC(lpIMC->hCompStr);
-lpIMC->hCompStr = NULL;
+lpIMC->hCompStr = ImeCreateBlankCompStr();
}
myPrivate =
(LPIMEPRIVATE)ImmLockIMCC(lpIMC->hPrivate);
-aric
Alexandre Julliard wrote:
> Module: wine
> Branch: master
> Commit: 4f2330ac0c951ec5fb05e2fb152c59723c3af336
> URL:
> http://source.winehq.org/git/wine.git/?a=commit;h=4f2330ac0c951ec5fb05e2fb152c59723c3af336
>
> Author: Kusanagi Kouichi <[EMAIL PROTECTED]>
> Date: Fri Apr 25 12:08:24 2008 +0900
>
> winex11: Destroy the handle to the composition string after it is cancelled.
>
> ---
>
> dlls/winex11.drv/ime.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/dlls/winex11.drv/ime.c b/dlls/winex11.drv/ime.c
> index 6614213..f50549f 100644
> --- a/dlls/winex11.drv/ime.c
> +++ b/dlls/winex11.drv/ime.c
> @@ -775,6 +775,12 @@ BOOL WINAPI NotifyIME(HIMC hIMC, DWORD dwAction, DWORD
> dwIndex, DWORD dwValue)
>
> X11DRV_ForceXIMReset(lpIMC->hWnd);
>
> +if (lpIMC->hCompStr)
> +{
> +ImmDestroyIMCC(lpIMC->hCompStr);
> +lpIMC->hCompStr = NULL;
> +}
> +
> myPrivate = (LPIMEPRIVATE)ImmLockIMCC(lpIMC->hPrivate);
> if (myPrivate->bInComposition)
> {
>
>
>
Re: ntoskrnl.exe: Change calling conventions [try 2]
> Why didn't you fix InterlockedExchangeAdd too?
Yes, this function also should be fixed. I will send new patch. Sorry. I got
confused because this function worked:
#include "wdm.h"
#pragma code_seg("INIT")
NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath)
{
LONG a = 0xaa, b = 0xbb, *ptr = &b, ret = 0xcc;
ret = InterlockedExchangeAdd(ptr, a);
DbgPrint("*ptr %x, ret %x\n", *ptr, ret);
return STATUS_SUCCESS;
}
#pragma code_seg()
...
10628: c7 45 fc aa 00 00 00movl $0xaa,0xfffc(%ebp)
1062f: c7 45 f4 bb 00 00 00movl $0xbb,0xfff4(%ebp)
10636: 8d 45 f4lea0xfff4(%ebp),%eax
10639: 89 45 f8mov%eax,0xfff8(%ebp)
1063c: c7 45 f0 cc 00 00 00movl $0xcc,0xfff0(%ebp)
10643: 8b 55 fcmov0xfffc(%ebp),%edx
10646: 8b 4d f8mov0xfff8(%ebp),%ecx
10649: e8 42 fe ff ff call 0x10490
...
Re: Safedisc for 1.0+ ?
On Thu, Apr 24, 2008 at 09:57:39PM -0600, Vitaliy Margolen wrote: > TheBlunderbuss wrote: > > It has just occurred to me that safedisc copy protection (bug 219!) > > wasn't put on the Wine 1.0 task list. It's a pretty major bug and covers > > a wide range of programs, with a wide range of safedisc versions. > > Considering this, how should we plan for this implementation? > > > Some versions should work. Newer versions mos likely won't. But as usual in > these cases your mileage may vary. Since there are so many variables. > > Setting target for such bugs to 1.0 won't magically fix them. Nor will it > keep them from breaking. There has been some movement in the past to split up the Safedisc bug and deal with the individual versions separately. Would it be useful to advance this? I'm certain that I have a number of games that listed as apps affected by this bug that no longer have a problem. So I'm not sure that it works well to maintain the same bug for all versions of safedisc. -- Darragh "Nothing is foolproof to a sufficiently talented fool."
Re: [PATCH] user32: edit controls should ignore WM_KEYDOWN on control + enter.
Lei Zhang wrote: > On Thu, Apr 24, 2008 at 10:22 PM, Lei Zhang <[EMAIL PROTECTED]> wrote: >> Hi, >> >> This should be the last bit in getting control + enter working in >> multiline edit controls. I attempted to write a test for this using >> SendInput() or SetKeyState() + SendMessage(), but I couldn't get seem >> to simulate holding down the control key. >> > Should work. You can also look at keybd_event() how it does it. It's pretty much a wrapper around SendInput(). All you'll need is keybd_event(VK_CONTROL, 0, 0, 0); to press it. And keybd_event(VK_CONTROL, 0, KEYEVENTF_KEYUP, 0); to release it. Vitaliy.
Re: ntoskrnl.exe: Change calling conventions [try 2]
Alexander Morozov <[EMAIL PROTECTED]> writes: > Changelog: > ntoskrnl.exe: Change calling conventions for InterlockedExchange, > InterlockedCompareExchange, InterlockedDecrement and InterlockedIncrement > > --- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > +++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec > @@ -28,11 +28,11 @@ > @ stub Exfi386InterlockedExchangeUlong > @ stub Exfi386InterlockedIncrementLong > @ stub HalExamineMBR > -@ stdcall InterlockedCompareExchange(ptr long long) > kernel32.InterlockedCompareExchange > -@ stdcall InterlockedDecrement(ptr) kernel32.InterlockedDecrement > -@ stdcall InterlockedExchange(ptr long) kernel32.InterlockedExchange > +@ stdcall -norelay InterlockedCompareExchange(ptr long long) > NTOSKRNL_InterlockedCompareExchange > +@ stdcall -norelay InterlockedDecrement(ptr) NTOSKRNL_InterlockedDecrement > +@ stdcall -norelay InterlockedExchange(ptr long) NTOSKRNL_InterlockedExchange > @ stdcall InterlockedExchangeAdd(ptr long ) kernel32.InterlockedExchangeAdd > -@ stdcall InterlockedIncrement(ptr) kernel32.InterlockedIncrement > +@ stdcall -norelay InterlockedIncrement(ptr) NTOSKRNL_InterlockedIncrement Why didn't you fix InterlockedExchangeAdd too? -- Alexandre Julliard [EMAIL PROTECTED]
Re: [Resend 2/5] imm32: Add the header for private imm32 function.
ByeongSik Jeon <[EMAIL PROTECTED]> writes: > Unknown function in the SDK/DDK's header. > --- > include/wine/imm_private.h | 35 +++ You don't want to add a new header for that, especially not a global one. The function is exported on Windows too, so it's OK to declare it in the DDK header. -- Alexandre Julliard [EMAIL PROTECTED]
ddraw: ComputeSphereVisibility
Hello, I am trying to debug the demo of The Sting. Now, the main is that the screen is almost black. It is surely related to the following FIXME: fixme:d3d7:IDirect3DDeviceImpl_7_ComputeSphereVisibility Unfortunately, I did not find any informations about this function. Does anyone know what this function does, ( and better knows a possible implementation)? Thanks, David Adam
Re: user32 : Temporarily disable test for _WIN64.
2008/4/25 Erik de Castro Lopo <[EMAIL PROTECTED]>: > Dmitry Timoshkov wrote: > > > I'll let you figure this out on your own, that's a helpful thing to learn. > > Try looking up GetWindowLongPtr in MSDN. That should be enough of a hint to help you to get the edit.c tests building properly with _WIN64 defined (as well as supporting WIN32). - Reece
Re: user32 : Temporarily disable test for _WIN64.
Francois Gouget wrote: > That's ok to do in your local Git repository. > > However you have to understand that we cannot very well commit patch > that disables a test which is very useful in garanteeing there won't be > regressions in the very much used and about to go stable 32bit version > for hypothetical progress in the 64bit version. My patch only disabled this one test for Win64. It remained enabled and active for Win32. However, after some rather subtle prompting from Dmitry Timoshkov and Reece Dunn, I have fixed the test so that it compiles correctly for Win32 and Win64. Cheers, Erik -- - Erik de Castro Lopo - "What is freedom of expression? Without the freedom to offend, it ceases to exist." - Salman Rushdie
Re: user32 : Temporarily disable test for _WIN64.
On Fri, 25 Apr 2008, Erik de Castro Lopo wrote: [...] > > user32 is not required for a simple "Hello World" app, isn't it? > > I didn't disable test for user32, I disabled a single test. That > test was testing edit controls and I am 100% sure that edit controls > are not needed for a simple hello world program that prints to > stdout. That's ok to do in your local Git repository. However you have to understand that we cannot very well commit patch that disables a test which is very useful in garanteeing there won't be regressions in the very much used and about to go stable 32bit version for hypothetical progress in the 64bit version. But by all means hack and slash your local tree so you can get to the crux of the matter quickly. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U
