2008/8/19 Markus Hitter [EMAIL PROTECTED]:
Am 19.08.2008 um 00:41 schrieb James Hawkins:
when the patch doesn't get committed, you should look back at it
and really think
outside the box about what could possibly be wrong with the patch.
Essentially, you ask to change code on unfounded
At 03:25 AM 2008-08-20, Dan Kegel wrote:
Hongbo, it looks like your patch failed to apply because you did not
preserve whitespace exactly. Your patch uses all spaces
for the context, but the file contains tabs, so it does not match,
and patch fails.
Thank you Dan, and thanks to Patchwatcher.
I
This patch fixes Bug 14784.
As requested by Dmitry Timoshkov, I have created a standalone test case
for DLL injection via SetWindowHookEx. It has been attached in Bug 14784
with MSVC source code and compiled exe and dll.
With LoadLibraryExW(module, NULL, LOAD_WITH_ALTERED_SEARCH_PATH), the
On Wednesday 20 August 2008 20:34:43 Gerald Pfeifer wrote:
This minor change on top of Hans' contributions in the recent days
unbreaks the build on FreeBSD (and likely other BSDs and possibly
Darwin/MacOS).
Thanks. I didn't want to copy all of the ifdef blocks from wininet
because I can't
These changes may be correct, but they need a test. Take a look at
dlls/d3d9/tests/device.c to see how the other tests look. I guess the changes
are likely to be correct, but they have to be tested
2008/8/21 Stefan Dösinger [EMAIL PROTECTED]:
These changes may be correct, but they need a test. Take a look at
dlls/d3d9/tests/device.c to see how the other tests look. I guess the changes
are likely to be correct, but they have to be tested
Not in its current form, there's a C++ comment
Roy Shea [EMAIL PROTECTED] writes:
+TaskImpl *This = (TaskImpl*)
+((char*)(iface) - offsetof(TaskImpl, persistVtbl));
Please define an inline function for this like many other interfaces do.
--
Alexandre Julliard
[EMAIL PROTECTED]
Alexander Nicolaysen Sørnes [EMAIL PROTECTED] writes:
HRESULT DPNET_CreateDirectPlay8Peer(LPCLASSFACTORY iface, LPUNKNOWN
punkOuter, REFIID riid, LPVOID *ppobj) {
- WARN((%p, %s, %p): stub.\n, punkOuter, debugstr_guid(riid), ppobj);
- return CLASS_E_CLASSNOTAVAILABLE;
+
I noticed a patch that was submitted by John Griffiths on the 13th of
July that forwards functions by mwsock.c using the following code:
(commit: 2da98052d90591474c65bed853ca75e1da714823)
+static void get_fn(SOCKET s, GUID* guid, FARPROC* fn)
+{
+FARPROC func;
+DWORD len;
+if
Don't all go out and vote - we don't want to skew the results - but check out
http://www.linuxjournal.com/node/1007221/results
What do you use to run Windows applications on your Linux desktop?
August 19th, 2008 by LJ Staff
Cedega 1% (8 votes)
Crossover 4% (38 votes)
VirtualBox 22% (195 votes)
diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c
index ddeaca3..dfbf818 100644
--- a/dlls/d3d9/device.c
+++ b/dlls/d3d9/device.c
@@ -746,7 +746,8 @@ static HRESULT WINAPI
IDirect3DDevice9Impl_GetDepthStencilSurface(LPDIRECT3DDE
}
} else {
WARN(Call to
On Thu, Aug 21, 2008 at 12:59 PM, Scott Lindeneau [EMAIL PROTECTED] wrote:
Simple overlapped server based on AcceptEx added to the test list
using simple clients.
Tests must always 'pass'. That is, the individual ok tests must all
pass, or if they fail you must wrap the failing tests in
Hi, apparently none of my patches is making it into git, nor did i recieve any
response from Alexandre about what's wrong with them. I guess i'm kind of
blacklisted because of my dxdiag patch from a few months ago, where i took
some code from a directX tutorial ( i thought tutorials were free
On Tue, Aug 19, 2008 at 4:14 PM, Louis. Lenders
[EMAIL PROTECTED] wrote:
Fixes a crash in Dameware utilities
@@ -6,7 +6,7 @@
8 stub ADsBuildVarArrayInt
9 stdcall ADsOpenObject(wstr wstr wstr long ptr ptr)
12 stub ADsSetLastError
-13 stub ADsGetLastError
+13 stdcall ADsGetLastError(ptr wstr
Scott Lindeneau [EMAIL PROTECTED] writes:
Fixes a bug in the async implementation. When checking for waiting
elements on a queue you need to check to see if ANY element is waiting,
not just the first element. When waking elements up you should ALERT an
element that is not already alerted.
On Wed, Aug 20, 2008 at 3:24 AM, Louis. Lenders
[EMAIL PROTECTED] wrote:
Hi , this interface is needed to get governor if poker running
(http://bugs.winehq.org/show_bug.cgi?id=14139). these first 3 patches is
only preliminary stuff, the rest of the stuff i'll send later on.
The I'll send the
Thanks for reviewing the patch James
@@ -6,7 +6,7 @@
8 stub ADsBuildVarArrayInt
9 stdcall ADsOpenObject(wstr wstr wstr long ptr ptr)
12 stub ADsSetLastError
-13 stub ADsGetLastError
+13 stdcall ADsGetLastError(ptr wstr long wstr long)
Both of those wstr parameters are out pointers so they
On Thu, Aug 21, 2008 at 2:13 PM, Louis. Lenders
[EMAIL PROTECTED] wrote:
Thanks for reviewing the patch James
@@ -6,7 +6,7 @@
8 stub ADsBuildVarArrayInt
9 stdcall ADsOpenObject(wstr wstr wstr long ptr ptr)
12 stub ADsSetLastError
-13 stub ADsGetLastError
+13 stdcall ADsGetLastError(ptr
The I'll send the rest later is a warning light. You should further develop
this and send it all later so we know this is actually going somewhere.
The whole patch, that lets Governor of Poker start i have attached to the bug
http://bugs.winehq.org/attachment.cgi?id=15297
a few weeks ago. As i
You've handled *a* successful case, but what about the error case?
As i said already in the mail with the patch, it might be *a* case, but this is
the case
that most apps will follow as far as i can see. Futhermore, when apps are
really crashing
into the other cases, it can be added later
On Thu, Aug 21, 2008 at 2:46 PM, Louis. Lenders
[EMAIL PROTECTED] wrote:
You've handled *a* successful case, but what about the error case?
As i said already in the mail with the patch, it might be *a* case, but this
is the case
that most apps will follow as far as i can see. Futhermore,
Thanks. But Julliard has pointed out that my fix in patch [2/6] is
wrong, and it is. It works, but not for the right reason. I didn't
(and still don't) understand how everything in wineserver works
together very well. Without the patch [2/6] the conformance tests will
fail due to a thread race
- Original Message
From: James Hawkins [EMAIL PROTECTED]
To: Louis. Lenders [EMAIL PROTECTED]
Cc: wine-devel@winehq.org
Sent: Thursday, 21 August, 2008 3:55:07 PM
Subject: Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 4)
That whole paragraphs reads hack now,
On Thu, Aug 21, 2008 at 3:59 PM, Louis. Lenders
[EMAIL PROTECTED] wrote:
- Original Message
From: James Hawkins [EMAIL PROTECTED]
To: Louis. Lenders [EMAIL PROTECTED]
Cc: wine-devel@winehq.org
Sent: Thursday, 21 August, 2008 3:55:07 PM
Subject: Re: kernel32: Tiny improvement to
Am Donnerstag, den 21.08.2008, 13:26 -0500 schrieb James Hawkins:
Also, you're copying 4 bytes of filename into volumepathname. I don't
think you understand what lstrcpyn does. Imagine this case:
volumepathname =
buflen = 8
filename = C:\\file
After the call to lstrcpyn:
On Wednesday 20 of August 2008 01:14:10 Maarten Lankhorst wrote:
I would like to request from the mentors to fill in the final evaluation
form and from the students to give a final write up: What went well? Did
you meet the goals you set? Did you have fun? Is there anything we can
do to make
2008/8/21 Rico Schüller [EMAIL PROTECTED]:
+/* Set the scissor rect values */
+scissor.left=0;
+scissor.right=ThisDevice-ddraw_width;
+scissor.top=0;
+scissor.bottom=ThisDevice-ddraw_height;
+IWineD3DDevice_SetScissorRect(device, scissor);
+
Are you sure you
On Thu, Aug 21, 2008 at 4:35 PM, Michael Karcher
[EMAIL PROTECTED] wrote:
page, stating that
lstrcpyn(dest,abcdefghi,4)
puts abc into dest.
Seems like Wine's version at least always null terminates it, so
abc\0. Just so anyone, who like me had to look it up, can see.
Am Donnerstag, den 21.08.2008, 17:35 -0500 schrieb John Klehm:
On Thu, Aug 21, 2008 at 4:35 PM, Michael Karcher
[EMAIL PROTECTED] wrote:
page, stating that
lstrcpyn(dest,abcdefghi,4)
puts abc into dest.
Seems like Wine's version at least always null terminates it, so
abc\0.
Sorry if my
Louis wrote:
Hi, apparently none of my patches is making it into git, nor did i recieve
any response from Alexandre about what's wrong with them. I guess i'm kind of
blacklisted
I don't think so. LOTS of people, me included, have trouble getting
patches into git. You just have to have
Why doesn't the WM_DESTROY case handle this properly? At first glance,
it appears to have code for stopping the running applets and quitting
from the main loop.
Calling ExitProcess from WM_CLOSE is anything but graceful.
Vincent Povirk
On Thu, Aug 21, 2008 at 2:25 PM, Steven Edwards [EMAIL
On Thu, Aug 21, 2008 at 9:00 PM, Vincent Povirk
[EMAIL PROTECTED] wrote:
Why doesn't the WM_DESTROY case handle this properly? At first glance,
it appears to have code for stopping the running applets and quitting
from the main loop.
Calling ExitProcess from WM_CLOSE is anything but graceful.
Commenting out FreeLibrary(applet-hModule); in Control_UnloadApplet
avoids the crash. The problem is that the applet's dialog still exists
when FreeLibrary is called. Since its dialog procedure was in the
freed library, the program crashes when that dialog gets a message.
I don't know what the
On Thu, Aug 21, 2008 at 9:41 PM, Stefan Dösinger [EMAIL PROTECTED]wrote:
These changes may be correct, but they need a test. Take a look at
dlls/d3d9/tests/device.c to see how the other tests look. I guess the
changes are likely to be correct, but they have to be tested
I'll add a test case
I think the proper fix is for appwiz.cpl to process the CPL_STOP and
CPL_EXIT messages (see
http://msdn.microsoft.com/en-us/library/aa454656.aspx)
Vincent Povirk
On Thu, Aug 21, 2008 at 9:55 PM, Vincent Povirk
[EMAIL PROTECTED] wrote:
Commenting out FreeLibrary(applet-hModule); in
Vincent Povirk wrote:
Why doesn't the WM_DESTROY case handle this properly? At first glance,
it appears to have code for stopping the running applets and quitting
from the main loop.
WM_CLOSE is different than WM_DESTROY. This is a missing case that
needs to be handled whenever the
WM_CLOSE is already handled by the default window procedure,
DefWindowProcW, which calls DestroyWindow. It's only necessary to
override the default for WM_CLOSE if you want to prevent the window
from being destroyed.
Vincent Povirk
On Thu, Aug 21, 2008 at 10:44 PM, James McKenzie
[EMAIL
On Thu, Aug 21, 2008 at 11:08 PM, Vincent Povirk
[EMAIL PROTECTED] wrote:
I think the proper fix is for appwiz.cpl to process the CPL_STOP and
CPL_EXIT messages (see
http://msdn.microsoft.com/en-us/library/aa454656.aspx)
I still think there could be a bug as I have IE installed and I assume
38 matches
Mail list logo
